Crear políticas coherentes es muy sencillo con NinjaOne, lo que le permite gestionar los terminales de forma fácil y eficiente. En esta guía, abordaremos los conceptos clave de las políticas con ejemplos reales de cómo funcionan las políticas dentro de la consola NinjaOne.
Índice:
- Acerca de la funcionalidad de políticas de NinjaOne
- Heredar 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 establezca determinarán cómo NinjaOne gestiona sus dispositivos.
¿Qué contiene una política?
Con las políticas, le indica a NinjaOne cómo desea que se gestionen sus terminales en el día a día. NinjaOne ejecuta automáticamente y de forma continua las acciones proporcionadas 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 en el manejo de las políticas?
Con NinjaOne, utilizamos una sencilla regla de «una política por dispositivo», lo que le ofrece más 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 dificulta la gestión y la confunde. Con este método de política única, obtendrá una experiencia más intuitiva y eficiente.
Heredar 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, se puede asignar una nueva política (secundaria) para que herede otra política (principal), lo que vincula ambas políticas de modo que cualquier cambio realizado en la política principal se refleja en la secundaria. 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 en:
- Políticas independientes, que son políticas 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 bajo ellas. La mayor parte de su trabajo se realizará en el nivel raíz. Una vez que haya configurado 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 incluirá generalmente en el nivel de política raíz.
- Las políticas de nivel superior son las políticas de nivel intermedio que coordinan las decisiones entre los diferentes niveles de políticas. Mediante las políticas de nivel superior, puede habilitar o deshabilitar los rasgos creados en el nivel superior. Como gestión intermedia, estas políticas solo sirven para impulsar la eficiencia adicional en el nivel inferior.
- Las políticas secundarias habilitan los rasgos específicos de los dispositivos. Todo lo que sea exclusivo de un cliente o grupo de dispositivos concreto, que requiera credenciales específicas o que incluya algo que solo sea aplicable a un pequeño grupo de rutinas, se incluirá 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 que figuran debajo.
- 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 se puede acumular en varios niveles, desde la raíz hasta la secundaria.
Cómo afectan las jerarquías a la creación de políticas
A medida que crea sus políticas, es importante tener en cuenta que las políticas principales deben crearse antes de crear una política secundaria debajo de ellas. Cada vez que crea una nueva política, tiene la opción de asignarla a cualquier otra política, que pasará a ser 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. Después de publicarla, 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, veamos 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 las que requieren menos 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 puede ganar en eficiencia si se dispone de una política principal para cada función de dispositivo.
Esto también significa que cualquier actualización del flujo de trabajo que sea necesario realizar, como cambios en los calendarios de parches o en las reglas de copia de seguridad, deberá duplicarse manualmente en todas las políticas pertinentes, en lugar de aprovechar una política principal global. Este tipo de estructura puede funcionar en entornos muy sencillos, pero carece de la eficiencia a gran escala cuando se empiezan a añadir 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 hay ninguna ventaja en términos de eficiencia al consolidar el trabajo en una política principal.
Políticasglobales principales
Las estructuras globales principales son un nivel superior a las políticas aisladas, ya que el trabajo de las políticas se consolida en el nivel global principal en lugar de gestionar cada conjunto de dispositivos a través de políticas secundarias aisladas. Se trata de una jerarquía bastante plana, pero que ofrece un poco más de profundidad y facilidad de gestión. Esta estructura es la más adecuada para entornos que se benefician de la flexibilidad y la estandarización.
Al aprovechar la estructura principal y secundaria, puede aumentar la eficiencia. El trabajo que se realiza 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 la política secundaria. La gestión de estaciones de trabajo, por ejemplo, suele ser fácil de estandarizar 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 programas de aplicación de parches las más comunes.
Esta es la estructura de políticas más común que vemos en clientes maduros y es adecuada para la mayoría de las situaciones.
Políticasmulticapa
Las configuraciones de varias 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.
Disponer de varias 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 llevar las configuraciones lo más alto posible en el árbol de políticas y consolidarlas en el menor número de políticas posible para alcanzar sus objetivos.
Esta estructura de políticas se utiliza más comúnmente para la gestión de servidores, donde se gestionan muchos servidores con diferentes propósitos, o para MSP que desean estandarizar entre clientes.
Ejemplo real
Una vez que empiece a añadir más dispositivos a la plataforma NinjaOne, así es como podría ser la estructura de su organización, aprovechando cada tipo de estructura en una plataforma cohesionada:
Anulaciones de dispositivos:
Siempre tendrá la oportunidad de anular las políticas a nivel de dispositivo. Por ejemplo, si tiene un portátil concreto que debe quedar excluido de la programación de parches existente, puede anular ese dispositivo específico y asignarle una programación de parches independiente. Cualquier característica de la política, como condiciones y scripts, se puede añadir o anular a nivel de dispositivo.
Las anulaciones tendrán prioridad sobre las normas de la política. Si realiza una anulación a nivel de dispositivo y se cambia 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í hay algunas cosas que debe tener en cuenta:
- Planifique y luego construya. Antes de crear o actualizar sus políticas, decida la función de las jerarquías. Recuerde que siempre puede planificar el crecimiento, pero solo utilice las capas necesarias por ahora. Preguntas que debe hacerse
- ¿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 medio?
- La consolidación es clave. Ahora es el momento de invertir en políticas básicas. Cuanto más trabajo realice en la fase de planificación, menos trabajo tendrá que hacer más adelante. Recuerde que siempre puede desactivar los rasgos en el elemento principal global de forma predeterminada si no son de aplicación general. Utilice políticas de nivel medio o dirigidas a dispositivos para habilitar la funcionalidad y habilite solo lo necesario a través de los niveles principal y secundario.
- Estandarice todo. Si ya tiene políticas, piense si realmente necesita diferenciar entre los grupos de políticas existentes. Empiece a consolidar en políticas únicas en lugar de gestionar cada una por separado. Si algunos dispositivos necesitan excepciones, aplíquelas a las políticas en lugar de anularlas. Minimice el número de anulaciones y políticas independientes en su estructura, ya que esas excepciones suelen provocar más problemas más adelante.
- Nunca está de más tener una política principal adicional. Dado que NinjaOne no permite asignar una política principal de forma retroactiva, nunca está de más tener una política principal global para todas las políticas de un rol de dispositivo. Configure una política principal global, aunque esté en blanco, y asigne todas las políticas nuevas a esa política principal a medida que se creen. Es muy poco probable que no pueda aplicar algunas condiciones, scripts programados o prácticas recomendadas de parcheo a una política principal para mayor eficiencia.