Tema
Para elaborar esta guía, hemos colaborado con socios de NinjaOne con el fin de comprender cómo utilizan las funciones de administración de parches de NinjaOne y hemos combinado su experiencia con la nuestra. En esta guía, compartimos esos conocimientos para que los nuevos socios puedan sacar el máximo partido a la administración de parches.
Entorno
Administración autónoma de parches de NinjaOne
Descripción
- Cómo configuran los usuarios de NinjaOne la aplicación de parches en Windows
- Horarios de análisis
- Horario de actualización
- Horarios omitidos
- Aprobaciones de parches
- Perfiles de parches comunes
- Comportamiento al reiniciar
Cómo configuran los usuarios de NinjaOne la aplicación de parches en Windows
La gestión de parches es una de las tareas más importantes que lleva a cabo un equipo de TI. Las empresas dedican importantes recursos a mantener su infraestructura actualizada; sin embargo, más de la mitad de las brechas de seguridad podrían haberse evitado instalando los parches disponibles para el software y el sistema operativo.
Además de las implicaciones de seguridad, una estrategia eficaz de aplicación de parches garantiza que los usuarios finales dispongan del software más actualizado y con más funcionalidades para realizar su trabajo.
Sin embargo, si algunas de las organizaciones más grandes y mejor financiadas del mundo tienen dificultades con la gestión de parches, ¿qué posibilidades tienen las pequeñas y medianas empresas con un soporte informático limitado? Sin las herramientas adecuadas, el proceso requiere mucho tiempo, es complicado, supone una interrupción para los usuarios finales y es propenso a errores.
El software de gestión de parches, como el que incluye NinjaOne, ofrece a los usuarios una visión completa y centralizada de su índice de cumplimiento de parches y automatiza la identificación, la descarga y el despliegue de parches en todos los dispositivos gestionados.
NinjaOne te ofrece un control minucioso sobre tu proceso de aprobación de parches, mejora tu tasa de éxito en la primera aplicación de parches y reduce el tiempo que tus técnicos dedican a la instalación de parches.
Horario de análisis
Las políticas de NinjaOne permiten a los usuarios programar análisis de parches de forma independiente del proceso de actualización. El análisis identifica todos los parches aún no instalados en un dispositivo y los clasifica en las categorías «Aprobados», «Pendientes» o «Rechazados» según la configuración de aprobación basada en políticas.
Por ejemplo, al realizar el escaneo horas o días antes de ejecutar una actualización, puedes ajustar manualmente el estado de aprobación de un parche, lo que el proceso de actualización respetará posteriormente. Esto resulta de gran ayuda para los parches aprobados manualmente o para evitar parches problemáticos que, normalmente, se aprobarían automáticamente.
Cuándo programar los análisis
Día de la semana
La mayoría de los socios de NinjaOne programan sus análisis de parches una vez a la semana. Los viernes son, con diferencia, el día más habitual para realizar análisis de parches. La siguiente opción más común es ejecutar un análisis todos los días. Los análisis diarios de parches consumen más recursos, pero maximizan el tiempo del que disponen los socios para realizar cambios puntuales en los parches.
| Dom | Lun | Mar | Mie | Jue | Vie | Sáb | Diariamente |
|---|---|---|---|---|---|---|---|
| 3 % | 3 % | 5% | 10 % | 7 % | 40 % | 7 % | 25 % |
Hora del día
La hora más común para realizar análisis de parches es entre las 17:00 y las 18:00, según la hora del dispositivo. Muchos usuarios programan los análisis después de las 18:00 para evitar afectar a los usuarios finales que trabajan hasta más tarde. Aunque el análisis de parches no consume muchos recursos, la mayoría de los análisis se programan fuera del horario laboral habitual para evitar afectar a los usuarios finales. Los usuarios que programan análisis durante el horario laboral pueden hacerlo para detectar el mayor número posible de dispositivos conectados.
| 00:00 – 8:50 | 9:00 – 16:59 | 17:00 – 23:59 |
|---|---|---|
| 16 % | 24 % | 60 % |
Duración del análisis
La mayoría de los usuarios de NinjaOne no establecen una duración para los análisis, lo que permite que estos duren todo el tiempo que sea necesario. Para aquellos que sí limitan la duración, las opciones más comunes son 9 horas, 6 horas y 3 horas. La duración de los análisis puede utilizarse cuando se toma el control de una nueva infraestructura o cuando usuarios de varias zonas horarias necesitan acceder a un servidor, y es necesario que el intervalo de aplicación de parches sea más corto para minimizar el impacto en el usuario final.
| 1 hora | 2 horas | 3 horas | 4 horas | 5 horas | 6 horas | 7 horas | 8 horas | 9+ horas | ∞ |
|---|---|---|---|---|---|---|---|---|---|
| 0 % | 0 % | 1 % | 1 % | 1 % | 3 % | 0 % | 0 % | 10 % | 85 % |
Horarios de actualización
El programa de actualizaciones de NinjaOne busca primero los parches disponibles y, a continuación, descarga y aplica tanto los parches recién detectados como los ya identificados mediante un análisis de parches, basándose en las configuraciones de aprobación de la política y en cualquier anulación aplicable. A continuación, la gestión de parches de NinjaOne realiza un análisis adicional para finalizar el proceso.
El estado de aprobación aplicado por la política puede anularse para dispositivos concretos o para políticas completas, siempre que un análisis lo identifique antes de que se aplique.
Una vez que se ha intentado instalar un parche durante un ciclo de actualización, se clasificará en el panel de control de parches del sistema operativo como «Instalado» o «Fallido».
Cuándo programar las actualizaciones
Día de la semana
Los parches se suelen aplicar los fines de semana para evitar interrumpir a los usuarios finales. Los viernes —normalmente fuera del horario laboral— también son comunes. Después de la incorporación inicial del dispositivo, muchos usuarios también aplican parches diariamente para minimizar el tiempo en que los terminales están vulnerables.
| Dom | Lun | Mar | Mie | Jue | Vie | Sáb | Diariamente |
|---|---|---|---|---|---|---|---|
| 19 % | 4 % | 5% | 9 % | 10 % | 15 % | 19 % | 19 % |
Hora del día
La hora más común para iniciar el proceso de aplicación de parches es entre las 17:00 y las 18:00, hora del dispositivo. Muchos usuarios programan sus actualizaciones después de las 18:00 para evitar afectar a los usuarios finales que trabajan hasta más tarde. Dado que la aplicación de parches consume más recursos y a menudo requiere un reinicio, la mayoría de las actualizaciones se programan fuera del horario laboral.
| 00:00 – 8:50 | 9:00 – 16:59 | 17:00 – 23:59 |
|---|---|---|
| 33 % | 18 % | 48 % |
Duración de la actualización
La mayoría de los usuarios de NinjaOne no establecen una duración para la aplicación de parches, lo que permite que las actualizaciones tarden el tiempo que sea necesario. En el caso de aquellos que sí limitan la duración, la mayoría la limita a 4 horas o menos.
| 1 hora | 2 horas | 3 horas | 4 horas | 5 horas o más | ∞ |
|---|---|---|---|---|---|
| 3 % | 5% | 4 % | 5% | 10 % | 74 % |
Escaneos o actualizaciones omitidos
NinjaOne habilita a los usuarios para que recuperen los análisis o las actualizaciones que se hayan omitido. Esto suele ocurrir cuando el dispositivo está apagado en el momento en que está previsto que comience el análisis o la actualización.
Las opciones de análisis y actualización se pueden habilitar por separado.
Los análisis y las actualizaciones omitidos se ejecutan tan pronto como el agente de NinjaOne se conecta con el servidor.
Recuperación de análisis y actualizaciones omitidos
Escaneos omitidos
Casi la mitad de los usuarios de NinjaOne recuperan automáticamente cualquier análisis de parches que se haya omitido. Esta función resulta especialmente útil para quienes suelen realizar análisis fuera de las horas de trabajo, cuando es probable que haya más dispositivos apagados.
| Recuperar análisis | No recuperar el análisis |
|---|---|
| 51 % | 49 |
Actualizaciones omitidas
La recuperación de actualizaciones perdidas es menos habitual que la de escaneos. Las actualizaciones fuera de horario suelen interrumpir más a los usuarios finales debido a la utilización de recursos o a la necesidad de reiniciar el dispositivo tras la actualización.
| Recuperar una actualización | No recuperar la actualización |
|---|---|
| 60 % | 40 % |
Aprobaciones de parches
NinjaOne te permite configurar flujos de trabajo de aprobación para cada uno de los cuatro niveles de gravedad de las actualizaciones de seguridad de Microsoft y las siete categorías de actualizaciones de Microsoft. Puedes aprobar o rechazar automáticamente, o bien aprobar o rechazar manualmente, los parches en función de su categoría.
En las siguientes secciones, compartiremos los perfiles de aplicación de parches más comunes que los usuarios de NinjaOne aplican a sus dispositivos.
Aprobaciones de actualizaciones de seguridad
| Gravedad | Descripción ( desde Microsoft) |
|---|---|
| Crítico | Una vulnerabilidad cuya explotación podría permitir la ejecución de código sin la intervención del usuario. Estos casos incluyen malware que se propaga por sí mismo (por ejemplo, gusanos de red) o situaciones de uso habitual inevitables en las que se ejecuta código sin advertencias ni avisos. Esto podría significar navegar por una página web o abrir un correo electrónico. |
| Importante | Una vulnerabilidad cuya explotación podría comprometer la confidencialidad, la integridad o la disponibilidad de los datos del usuario, o la integridad o disponibilidad de los recursos de procesamiento. Estos escenarios incluyen situaciones de uso habitual en las que el cliente recibe advertencias o mensajes, independientemente de la procedencia, la calidad o la usabilidad de dichos mensajes. |
| Moderado | Factores como los requisitos de autenticación o su aplicabilidad exclusiva a configuraciones no predeterminadas mitigan significativamente el impacto de la vulnerabilidad. |
| Bajo | Las características del componente afectado mitigan de forma exhaustiva el impacto de la vulnerabilidad. Microsoft recomienda a los clientes que evalúen si deben aplicar la actualización de seguridad a los sistemas afectados. |
Categorías de actualizaciones
| Gravedad | Descripción ( desde Microsoft) |
|---|---|
| Crítico | Solución muy difundida para un problema específico que soluciona un error crítico y no está relacionado con la seguridad. |
| Regular | Solución muy difundida para un problema específico que soluciona un error crítico y no está relacionado con la seguridad. |
| Paquete acumulativo | Conjunto acumulativo y probado de revisiones, actualizaciones de seguridad, actualizaciones críticas y actualizaciones que se agrupan para facilitar su despliegue. |
| Paquete de servicio | Conjunto acumulativo y probado de todas las revisiones, actualizaciones de seguridad, Actualizaciones críticas y actualizaciones. Además, los Service Packs pueden contener correcciones adicionales para problemas detectados internamente desde el lanzamiento del producto. |
| Paquetes de características | Nueva funcionalidad del producto que se distribuye por primera vez fuera del contexto de una versión del producto y que, por lo general, se incluye en la siguiente versión completa del producto. |
| Paquete de definición | Actualización de software frecuente y de amplia difusión que contiene incorporaciones a la base de datos de definiciones de un producto. Las bases de datos de definiciones se utilizan a menudo para detectar objetos que tienen atributos específicos, como código malicioso. |
| Unidades | Software que controla la entrada y la salida de un dispositivo. |
| Actualización de características | Especifica una actualización de las funciones y características de Windows 10. |
Perfiles de parches comunes
Selecciona un tipo de perfil para aprender más:
- Perfil de aplicación de parches predeterminado
- Perfil de automatización con aprobación total
- Perfil de automatización equilibrado y de bajo riesgo
- Perfil de bajo riesgo y baja automatización
- Perfil lleno de funciones manuales
Perfil de aplicación de parches predeterminado
Muchos de nuestros socios utilizan el perfil de aplicación de parches predeterminado de NinjaOne, que se centra en encontrar un equilibrio entre la automatización, que ahorra tiempo, y la reducción de riesgos.
Casi todas las aprobaciones de este perfil están automatizadas. Se aprueban las actualizaciones importantes y se rechazan las opcionales para maximizar el ahorro de tiempo. Los parches opcionales y de baja prioridad se rechazan automáticamente para mantener un alto nivel de automatización, pero evitando el riesgo operativo.
Las actualizaciones de controladores y de funciones están desactivadas en este perfil, ya que este tipo de actualizaciones son más propensas a causar problemas a los usuarios finales.
| Aprobaciones de actualizaciones de seguridad | Estado de aprobación |
|---|---|
| Bajo | Rechazar |
| Moderado | Manual |
| Importante | Aprobar |
| Crítico | Aprobar |
| Aprobaciones | Importante | Opcional |
|---|---|---|
| Actualizaciones críticas | Aprobar | Rechazar |
| Actualizaciones periódicas | Aprobar | Rechazar |
| Rollups de actualizaciones | Aprobar | Rechazar |
| Paquetes de servicio | Aprobar | Rechazar |
| Paquetes de definición | Aprobar | Rechazar |
| Aprobaciones avanzadas | |
|---|---|
| Unidades | Deshabilitado |
| Actualizaciones de características | Deshabilitado |
Perfil de automatización total de aprobaciones
El perfil de automatización total es el segundo perfil más usado por los socios de NinjaOne. Este perfil aprueba automáticamente todos los parches de Microsoft.
Este perfil garantiza que todos los dispositivos asociados a la política estén siempre actualizados, pero expone a los dispositivos a cierto riesgo operativo debido a parches problemáticos.
Combinar este perfil con análisis frecuentes de parches permite a los técnicos evitar el riesgo operativo rechazando los parches problemáticos cuando surgen y antes de que se apliquen.
Combinar este perfil con dispositivos de prueba también permite observar el resultado de la aplicación de parches antes de implementarlos en los equipos de producción.
| Aprobaciones de actualizaciones de seguridad | Estado de aprobación |
|---|---|
| Bajo | Aprobar |
| Moderado | Aprobar |
| Importante | Aprobar |
| Crítico | Aprobar |
| Aprobaciones | Importante | Opcional |
|---|---|---|
| Actualizaciones críticas | Aprobar | Aprobar |
| Actualizaciones periódicas | Aprobar | Aprobar |
| Rollups de actualizaciones | Aprobar | Aprobar |
| Paquetes de servicio | Aprobar | Aprobar |
| Paquetes de definición | Aprobar | Aprobar |
Avanzado:Aprobaciones | ||
|---|---|---|
| Unidades | Habilitado | Aprobar |
| Actualizaciones de características | Habilitado | Aprobar |
Perfil de automatización equilibrado y de bajo riesgo
Este perfil da prioridad al cumplimiento del 100 % de los parches, al tiempo que intenta minimizar el riesgo operativo equilibrando la automatización con las aprobaciones manuales.
Este perfil requiere una mayor intervención manual para alcanzar el cumplimiento total de los parches, pero ofrece la ventaja añadida de que se pueden evitar los parches problemáticos que no son críticos para la seguridad o la funcionalidad de un dispositivo.
Para aprovechar las ventajas de este perfil, los técnicos deben realizar revisiones periódicas y aprobar o negar manualmente los parches.
| Aprobaciones de actualizaciones de seguridad | Estado de aprobación |
|---|---|
| Bajo | Manual |
| Moderado | Manual |
| Importante | Aprobar |
| Crítico | Aprobar |
| Aprobaciones | Importante | Opcional |
|---|---|---|
| Actualizaciones críticas | Aprobar | Manual |
| Actualizaciones periódicas | Aprobar | Manual |
| Rollups de actualizaciones | Aprobar | Manual |
| Paquetes de servicio | Aprobar | Manual |
| Paquetes de definición | Aprobar | Manual |
| Aprobacionesavanzadasde « » | ||
|---|---|---|
| Unidades | Habilitado | Manual |
| Actualizaciones de características | Habilitado | Manual |
Perfil de bajo riesgo y baja automatización
Este perfil también equilibra la automatización con la intervención manual.
En este caso, los parches opcionales se rechazan automáticamente, mientras que las actualizaciones de seguridad y las importantes requieren aprobación manual.
Este perfil intenta automatizar la aplicación de los parches menos importantes, al tiempo que minimiza los riesgos operativos derivados de los parches problemáticos.
Los socios de NinjaOne que utilicen este perfil deberán revisar y aprobar periódicamente los parches pendientes para garantizar la seguridad de los terminales.
| Aprobaciones de actualizaciones de seguridad | Estado de aprobación |
|---|---|
| Bajo | Manual |
| Moderado | Manual |
| Importante | Manual |
| Crítico | Manual |
| Aprobaciones | Importante | Opcional |
|---|---|---|
| Actualizaciones críticas | Manual | Rechazar |
| Actualizaciones periódicas | Manual | Rechazar |
| Rollups de actualizaciones | Manual | Rechazar |
| Paquetes de servicio | Manual | Rechazar |
| Paquetes de definición | Manual | Rechazar |
| Aprobaciones avanzadas | ||
|---|---|---|
| Unidades | Habilitado | Manual |
| Actualizaciones de características | Habilitado | Manual |
Perfil manual lleno
El perfil de aplicación de parches totalmente manual permite a los técnicos controlar por completo qué parches se aplican y cuáles no.
Cada parche disponible para un dispositivo aparecerá en la lista como pendiente hasta que se apruebe o se niegue.
Aunque sigue siendo mucho más eficiente que la aplicación de parches tradicional, este perfil será el que requiera más trabajo en NinjaOne. Podría exponer a los usuarios a riesgos tanto para la seguridad como para las operaciones si los parches no se aplican con la suficiente rapidez.
Los usuarios que usen este perfil deben contar con procedimientos operativos estándar (SOP) para comprobar periódicamente su cadencia de aplicación de Parches.
| Aprobaciones de actualizaciones de seguridad | Estado de aprobación |
|---|---|
| Bajo | Manual |
| Moderado | Manual |
| Importante | Manual |
| Crítico | Manual |
| Aprobaciones | Importante | Opcional |
|---|---|---|
| Actualizaciones críticas | Manual | Manual |
| Actualizaciones periódicas | Manual | Manual |
| Rollups de actualizaciones | Manual | Manual |
| Paquetes de servicio | Manual | Manual |
| Paquetes de definición | Manual | Manual |
| Aprobaciones avanzadas | ||
|---|---|---|
| Unidades | Habilitado | Manual |
| Actualizaciones de características | Habilitado | Manual |
Comportamiento al reiniciar
Para completar las actualizaciones de Windows, a menudo es necesario reiniciar los dispositivos.
Conseguir que los usuarios finales reinicien sus dispositivos es casi imposible, por lo que NinjaOne te permite automatizar este proceso.
Las políticas de NinjaOne permiten aplicar diferentes acciones y programaciones en función de si el usuario ha iniciado sesión o no.
Usuario conectado
Acciones de reinicio
La mayoría de los usuarios de NinjaOne no utilizarán políticas para forzar un reinicio en los usuarios finales después de la aplicación de parches; en su lugar, solicitarán al usuario que reinicie el equipo. Muchas políticas no provocan ningún reinicio automático. Solo un pequeño porcentaje de políticas fuerza el reinicio.
| Acción | Descripción | Frecuencia |
|---|---|---|
| Solicitar al usuario | Impulsar reinicio hasta que se acepte el reinicio | 65 % |
| Notificar al usuario | Notificar al usuario y, después de un tiempo, reiniciar el sistema | 10 % |
| Reinicio automático | Reiniciar automáticamente después de un período de tiempo determinado | 4 % |
| Ninguno | No hacer nada | 20 % |
Reiniciar / Tiempo de espera de la solicitud
El intervalo de tiempo más común entre avisos, entre el aviso y el reinicio, o entre la finalización de la aplicación del parche y el reinicio es de 5 minutos. A medida que la acción de reinicio se vuelve más agresiva, también lo hace el plazo.
| Duración | Prompt | Notificar | Reinicio automático |
|---|---|---|---|
| 5 minutos | 65 % | 41 % | 76 % |
| 5 – 59 | 9 % | 37 % | 18 % |
| 60 – 239 | 14 % | 13 % | 4 % |
| 240+ | 12 % | 9 % | 6 % |
Usuario sin iniciar sesión
Acciones de reinicio
La mayoría de las políticas de NinjaOne reinician los dispositivos tras la aplicación de parches según un calendario preestablecido. Dado que no hay ningún usuario conectado, los reinicios inmediatos son más habituales que cuando los usuarios están conectados.
| Acción | Descripción | Frecuencia |
|---|---|---|
| Reinicio programado | Notificar al usuario y luego reiniciar tras un periodo de tiempo | 67 % |
| Reiniciar inmediatamente | Reiniciar el dispositivo inmediatamente | 18 % |
| Ninguno | No hacer nada | 14 % |
Horario de reinicio (semanalmente)
El 12 % de las políticas que se reinician semanalmente lo harán en los siguientes días:
| Dom | Lun | Mar | Mie | Jue | Vie | Sáb |
|---|---|---|---|---|---|---|
| 46 % | 5% | 5% | 3 % | 5% | 8 % | 27 % |
Horario de reinicio (diariamente)
El 85 % de las políticas que se reinician diariamente lo harán en los siguientes horarios:
| 00:00 – 8:50 | 9:00 – 16:59 | 17:00 – 17:59 | 18:00 – 23:59 |
|---|---|---|---|
| 19 % | 2 % | 57 % | 22 % |