Crear políticas coherentes es muy sencillo con NinjaOne, lo que le permite gestionar los puntos finales de forma fácil y eficiente. En esta guía, abordaremos conceptos clave sobre políticas con ejemplos reales de cómo funcionan estas dentro de la consola de NinjaOne.
Índice:
- Acerca de la funcionalidad de políticas de NinjaOne
- Herencia de políticas
- Jerarquías de políticas
- Anulaciones de dispositivos
- Estrategias de gestión de políticas
- Documentación relacionada
Acerca de la funcionalidad de políticas de NinjaOne:
¿Qué son las políticas en NinjaOne?
Las políticas son el motor centralizado de gestión y automatización de dispositivos de NinjaOne. Las políticas que configure determinarán cómo gestiona NinjaOne sus dispositivos.
¿Qué contiene una política?
Con las políticas, le indicas a NinjaOne cómo quieres que se gestionen tus terminales en el día a día. NinjaOne ejecuta automáticamente y de forma continua las acciones establecidas por las políticas en todos los dispositivos relacionados.
Las políticas incluyen reglas de supervisión de terminales, reglas de automatización, opciones de gestión granular de parches, preferencias de soluciones de seguridad y copia de seguridad y retención de datos.
¿En qué se diferencia NinjaOne a la hora de gestionar las políticas?
Con NinjaOne, utilizamos una sencilla regla de «una política por dispositivo», lo que le ofrece mayor visibilidad y comprensión sobre cómo se gestiona cada dispositivo. Con otras soluciones, es posible que se apliquen varias políticas a un único punto final, lo que hace que la gestión sea más difícil y confusa. Al utilizar este método de política única, obtendrá una experiencia más intuitiva y eficiente.
Herencia de políticas:
NinjaOne incluye un concepto denominado «herencia de políticas» que permite una gestión más estandarizada y eficiente de los dispositivos. Al crearse, una nueva política (hija) puede asignarse para heredar otra política (padre), lo que vincula ambas políticas de tal forma que cualquier cambio realizado en la política padre se refleja en la política hija. Esta relación es continua y unidireccional, lo que le permite equilibrar las necesidades de personalización con la estandarización y la gestión eficiente.
Aunque los siguientes no son estados de política definidos en NinjaOne, las políticas se pueden clasificar como:
- Políticas independientes, que son aquellas que no tienen ni política principal ni secundaria.
- Las políticas raíz son las políticas de nivel superior que no tienen políticas padre. Estas políticas definen las reglas generales para cualquier política que se encuentre por debajo de ellas. La mayor parte de su trabajo se realizará en el nivel raíz. Una vez que configure sus nuevos rasgos, los desactivará todos y, a continuación, activará esas reglas o las anulará en el nivel padre o hijo. Las políticas raíz incluirán todas las condiciones, scripts programados, políticas de gestión de parches, planes de copia de seguridad, etc. Todo lo que se aplique a más de un grupo de dispositivos o sea complejo de configurar se ubicará generalmente en el nivel de política raíz.
- Las políticas principales son las políticas de nivel intermedio que coordinan las decisiones entre los diferentes niveles de políticas. Mediante las políticas principales, puede habilitar o deshabilitar los rasgos creados en el nivel superior. Como gestión intermedia, estas políticas están ahí simplemente para impulsar una mayor eficiencia en el nivel secundario.
- Las políticas secundarias habilitan características específicas de los dispositivos. Todo lo que sea exclusivo de un cliente individual o un grupo de dispositivos, que requiera credenciales específicas o que incluya cualquier elemento aplicable únicamente a un pequeño grupo de rutinas se ubicará generalmente en el nivel de política secundaria.
Cómo interactúan las políticas
A continuación se muestra un ejemplo de cómo puede ser un conjunto de políticas dentro de NinjaOne. Tenga en cuenta que cada dispositivo se encuentra bajo una única política en lugar de bajo varias, lo que simplifica las operaciones.
En lo que respecta a las interacciones entre políticas, se aplica lo siguiente:
- Cualquier cambio en una política principal o raíz se transmitirá al resto de las políticas secundarias enumeradas a continuación.
- Las políticas secundarias pueden anular las decisiones tomadas en la política principal o añadir características adicionales.
- Cuando se realizan cambios en las políticas secundarias, las políticas principales no cambian.
- La herencia puede acumularse en varios niveles, desde la raíz hasta las políticas secundarias.
Cómo afectan las jerarquías a la creación de políticas
Al crear tus políticas, es importante tener en cuenta que las políticas principales deben crearse antes de crear una política secundaria bajo ellas. Cada vez que crees una nueva política, tendrás la opción de asignarla a cualquier otra política, que se convertirá entonces en la principal.
No puede crear una política y luego asignarla como política heredada más adelante. Si desea asignarla a una política principal, deberá hacerlo antes de publicarla. Una vez publicada, no podrá asignarla a una nueva política principal.
Tienes la opción de copiar políticas, pero se trata estrictamente de una copia y no heredará ninguna característica modificada por la política original que se copió.
Jerarquías de políticas:
Ahora que hemos establecido un nivel básico sobre lo que puede esperar de la gestión de políticas, echemos un vistazo a tres estructuras de políticas diferentes para comparar casos de uso y ventajas.
Políticas aisladas
Las políticas aisladas son la versión más sencilla de las políticas y requieren la menor planificación previa. Las políticas aisladas rara vez son la mejor opción para la gestión de dispositivos en NinjaOne, ya que cada política es independiente, sin consolidación ni eficiencia entre políticas. Casi siempre se obtienen algunas ventajas al tener una política principal para cada rol de dispositivo.
Esto también significa que cualquier actualización del flujo de trabajo que sea necesaria, como cambios en los calendarios de parches o en las reglas de copia de seguridad, deberá duplicarse manualmente en todas las políticas relevantes, en lugar de aprovechar una política principal global. Este tipo de estructura puede funcionar en entornos muy sencillos, pero carece de la eficiencia de escala a medida que se añaden más dispositivos a NinjaOne.
Las políticas aisladas pueden ser eficaces si:
- Todos los dispositivos de una función se gestionan de la misma manera, sin variaciones entre dispositivos o grupos de dispositivos.
- Cada grupo de dispositivos se gestiona de forma tan diferente que no se obtiene ninguna ventaja en términos de eficiencia al consolidar el trabajo en una política principal.
Políticasprincipales globales
Las estructuras principales globales son un nivel superior a las políticas aisladas, ya que el trabajo de las políticas se consolida en el nivel principal global en lugar de gestionar cada conjunto de dispositivos a través de políticas secundarias aisladas. Sigue siendo una jerarquía bastante plana, pero ofrece un poco más de profundidad y facilidad de gestión. Esta estructura es ideal para entornos que se benefician de la flexibilidad y la estandarización.
Al aprovechar la estructura principal y secundaria, puede impulsar una mayor eficiencia. El trabajo que se realice en el nivel principal se duplicará automáticamente en las políticas secundarias. Debe realizar todo el trabajo posible en la política principal global y, a continuación, realizar personalizaciones y ajustes en el nivel de las políticas secundarias. La gestión de estaciones de trabajo, por ejemplo, suele estandarizarse fácilmente desde el punto de vista de la supervisión, la automatización de tareas, el antivirus y las copias de seguridad, siendo las variaciones en los calendarios de aplicación de parches las más comunes.
Esta es la estructura de políticas más habitual que observamos en clientes consolidados y resulta adecuada para la mayoría de las situaciones.
Políticasmulticapa
Las configuraciones de múltiples capas serán la estructura más complicada de las tres, ya que añaden mayor complejidad con políticas de nivel raíz, principal y secundario. Esta estructura puede ser increíblemente eficaz en entornos complejos pero muy estructurados, pero también puede volverse compleja y difícil de gestionar si no se controla adecuadamente.
Contar con múltiples capas de herencia permite establecer un estándar de referencia para la gestión de dispositivos, la personalización por grupos de dispositivos y la personalización a gran escala. En general, siempre es recomendable aplicar las configuraciones lo más arriba posible en el árbol de políticas y consolidarlas en el menor número posible de políticas para alcanzar sus objetivos.
Esta estructura de políticas se utiliza más comúnmente para la gestión de servidores, en la que se gestionan muchos servidores con diferentes fines, o para MSP que desean estandarizar entre clientes.
Ejemplo real
Una vez que empieces a añadir más dispositivos a la plataforma NinjaOne, así es como podría quedar la estructura de tu organización, aprovechando cada tipo de estructura en una plataforma cohesionada:
Anulaciones de dispositivos:
Siempre tendrá la oportunidad de anular políticas a nivel de dispositivo. Por ejemplo, si tiene un portátil concreto que debe quedar exento del calendario de parches existente, puede anular ese dispositivo específico y asignarle un calendario de parches independiente. Cualquier característica de la política, como condiciones y scripts, puede añadirse o anularse a nivel de dispositivo.
Las anulaciones tendrán prioridad sobre las normas de las políticas. Si realiza una anulación a nivel de dispositivo y se modifica la política principal, la anulación seguirá teniendo prioridad e ignorará el cambio en la política principal.
Estrategias de gestión de políticas:
A medida que avanza en la gestión de políticas y en la creación o actualización de su estructura de políticas, aquí tiene algunos aspectos que debe tener en cuenta:
-
Planifique antes de crear. Antes de crear o actualizar sus políticas, decida la función de las jerarquías. Recuerde que siempre puede planificar el crecimiento, pero utilice solo las capas necesarias por ahora. Preguntas que debe plantearse:
- ¿Las políticas relacionadas con los dispositivos son por cliente? ¿Por filial? ¿Por grupo funcional?
- ¿Necesita una jerarquía de varios niveles?
- Si utiliza una estructura de varios niveles, ¿en qué se traducen las políticas de nivel intermedio?
- La consolidación es clave. Ahora es el momento de invertir en políticas raíz. Cuanto más trabajo dediques a la fase de planificación, menos trabajo tendrás que hacer más adelante. Recuerda que siempre puedes desactivar características en el padre global de forma predeterminada si no son de aplicación general. Utiliza políticas de nivel intermedio o dirigidas a dispositivos para habilitar funcionalidades y habilita solo lo necesario a través de los niveles padre e hijo.
- Estandarice en todas partes. Si ya tiene políticas existentes, piense si realmente necesita la diferenciación entre los grupos de políticas existentes. Empiece a consolidarlas en políticas únicas en lugar de gestionarlas individualmente. Si ciertos dispositivos necesitan excepciones, establezca esas excepciones en las políticas en lugar de anulaciones. Minimice el número de anulaciones y políticas independientes en su estructura, ya que esas excepciones suelen provocar más dolores de cabeza más adelante.
- Tener una política principal adicional nunca está de más. Dado que NinjaOne no permite asignar una política principal de forma retroactiva, nunca está de más tener una política principal global que abarque todas las políticas de una función de dispositivo. Configura una política principal global, aunque esté en blanco, y asigna todas las políticas nuevas a esa política principal a medida que se creen. La probabilidad de que no puedas aplicar algunas condiciones, scripts programados o prácticas recomendadas de aplicación de parches a una política principal para una mayor eficiencia es muy baja.