La mayoría de las empresas no construyen intencionalmente una estrategia de parches híbrida. Por lo general, ocurre una decisión de infraestructura a la vez. Los servidores de Windows permanecen en las instalaciones locales. Las nuevas aplicaciones se trasladan a AWS o Azure. Las cargas de trabajo de Linux se expanden para soportar nuevos servicios. Las máquinas virtuales (VM) se multiplican en todos los entornos. Con el tiempo, la aplicación de parches se distribuye entre múltiples herramientas, equipos y plataformas de infraestructura.
Sin embargo, esta situación no es inusual. Es el resultado predeterminado cuando la infraestructura se expande más rápido que la estrategia de parches que la respalda.
La mayoría de las empresas ya cuentan con las múltiples herramientas necesarias para parchear su infraestructura. La parte más difícil proviene de gestionar la aplicación de parches en múltiples plataformas, cada una con sus propios flujos de trabajo, programaciones y modelos de informes. Con el tiempo, esa fragmentación crea Acuerdos de Nivel de Servicio (SLA) inconsistentes, lo que dificulta la comprensión del cumplimiento general.
- Por qué la aplicación de parches en servidores se vuelve caótica a escala empresarial
- El problema de la fragmentación en entornos híbridos
- Lo que realmente cuestan los ciclos de parches inconsistentes
- Lo que debe abarcar un enfoque de gestión de parches centralizado
- Visibilidad unificada en cargas de trabajo de Windows, Linux, máquinas virtuales y en la nube
- Automatización y ciclos de remediación más rápidos
- Gobernanza y cumplimiento en todo el patrimonio
- Simplificar la gestión de parches sin forzar una migración completa
- Conclusión
Por qué la aplicación de parches en servidores se vuelve caótica a escala empresarial
Una pequeña infraestructura con 200 servidores Windows puede operar de manera limpia en Microsoft Configuration Manager. Los problemas comienzan cuando el entorno se expande lateralmente. Aparece una flota de Linux. Las bases de datos se trasladan a la nube. Los equipos de desarrollo despliegan cargas de trabajo en entornos virtuales. Los equipos de seguridad presionan por la cobertura de aplicaciones de terceros después de que las vulnerabilidades exponen brechas en el proceso de aplicación de parches.
Cada expansión toma su propia decisión de herramientas porque la herramienta existente no cubre el nuevo requisito. Configuration Manager no gestiona completamente Linux. Satellite no gestiona cargas de trabajo nativas de la nube. Las herramientas de parches nativas de la nube saben poco sobre la infraestructura local. Mientras tanto, el equipo de infraestructura termina ejecutando múltiples sistemas de parches sin visibilidad compartida, programación unificada ni respuesta a una pregunta operativa básica: ¿cuál es el estado real de los parches en el entorno en este momento?
El impacto en el personal se vuelve visible rápidamente. Los ingenieros que mantienen cuatro o cinco plataformas de parches separadas también mantienen cuatro o cinco ventanas de mantenimiento, estructuras de informes, sistemas de alertas, ciclos de actualización y procesos de implementación. Esa carga operativa crece con el número de herramientas, no con el número de servidores.
El problema de la fragmentación en entornos híbridos
La mayoría de las empresas no tienen dificultades porque sus herramientas fallen individualmente. Tienen dificultades porque las herramientas operan de manera independiente. El ciclo de parches de Windows ya puede estar maduro y automatizado. El entorno de Linux aún puede depender de la coordinación manual antes de que puedan ocurrir reinicios de producción. Es posible que las aplicaciones de servidor de terceros no pertenezcan a ningún flujo de trabajo de parches estandarizado en absoluto.
La infraestructura en la nube introduce otra capa de fragmentación. Las organizaciones que operan cargas de trabajo en AWS, Azure y GCP a menudo terminan manteniendo procesos de parches separados para cada proveedor. Cada plataforma en la nube genera sus propios informes, programa las implementaciones de manera diferente y rastrea el cumplimiento de forma independiente.
Lo que surge es una mezcla de cobertura superpuesta en algunas áreas y brechas de visibilidad en otras, lo que dificulta comprender la exposición a los parches en todo el entorno en su conjunto. Esto se vuelve especialmente difícil durante auditorías, revisiones de vulnerabilidades o investigaciones de respuesta a incidentes en las que los equipos de infraestructura necesitan explicar la exposición a los parches en todo el parque de servidores de forma rápida.
Lo que realmente cuestan los ciclos de parches inconsistentes
La razón por la que los ciclos de parches de Linux se extienden a 60 o 90 días en muchas empresas rara vez es técnica, sino operativa. Antes de que los servidores de producción puedan reiniciarse, los propietarios de las aplicaciones necesitan visibilidad del impacto. Las ventanas de mantenimiento necesitan aprobación. Los servicios necesitan secuencias controladas de apagado y reinicio. Sin la automatización del flujo de trabajo, cada implementación se convierte en un ejercicio de coordinación entre los equipos de infraestructura, los equipos de aplicaciones y el liderazgo de operaciones.
Cuanto más tiempo lleve esa coordinación, más tiempo permanecerán expuestas las vulnerabilidades. Un servidor Windows puede recibir actualizaciones durante el próximo ciclo mensual, mientras que una carga de trabajo de Linux que tenga la misma vulnerabilidad permanece sin parchear durante otros dos meses debido a un proceso de implementación más lento.
El impacto real es que las vulnerabilidades permanecen abiertas más tiempo del que deberían. Las organizaciones que avanzan hacia la gestión centralizada de parches a menudo recuperan un tiempo de ingeniería significativo que antes se perdía en la coordinación manual, informes fragmentados y flujos de trabajo de implementación desconectados. El impacto operativo importa más que la cifra de costos en sí. Cada hora dedicada a conciliar paneles de control, coordinar ventanas de mantenimiento o recopilar informes de cumplimiento es tiempo en el que el parche aún no se ha implementado. Por eso la importancia de mantener un proceso de parches consistente se vuelve un factor operativo crítico cuando los plazos de exposición se miden en días, no en meses.
Lo que debe abarcar un enfoque de gestión de parches centralizado
Una plataforma de parches consolidada tiene que gestionar más que actualizaciones del sistema operativo. Los equipos de infraestructura son cada vez más responsables de mantener actualizadas las actualizaciones de controladores, las definiciones de antivirus, los componentes de middleware, los tiempos de ejecución y otro software de soporte junto con el sistema operativo. A medida que los entornos crecen, la gestión de estas actualizaciones mediante procesos separados a menudo crea los mismos desafíos de visibilidad y cumplimiento que las organizaciones intentan eliminar.
El alcance de la aplicación de parches en servidores modernos generalmente se extiende a través de:
- Entornos de Windows Server.
- Distribuciones de Linux de múltiples proveedores.
- Aplicaciones de servidor de terceros.
- Máquinas virtuales (VM).
- Cargas de trabajo alojadas en la nube.
- Dependencias de middleware y tiempos de ejecución.
En muchos entornos, cada una de estas capas termina siguiendo un proceso de aplicación de parches diferente a pesar de ser parte de la misma carga de trabajo de producción.
Patch Manager Plus integra Windows, Linux, más de 1.100 aplicaciones de terceros y cargas de trabajo alojadas en la nube en el mismo flujo de trabajo operativo. La cobertura de aplicaciones de terceros incluye tiempos de ejecución de backend, pilas de middleware, servidores web y componentes de infraestructura de soporte que frecuentemente quedan fuera de los procesos tradicionales de parches del sistema operativo.
Muchas de las vulnerabilidades por encima de la capa del sistema operativo son las que crean la mayor interrupción en la actualidad, originándose dentro de los tiempos de ejecución, middleware, bibliotecas y servicios de soporte. Log4Shell no fue una vulnerabilidad del sistema operativo. Fue un problema de dependencia que habitaba dentro de las pilas de middleware empresariales.
Visibilidad unificada en cargas de trabajo de Windows, Linux, máquinas virtuales y en la nube
En la mayoría de los entornos, generar una vista completa del cumplimiento de parches a menudo requiere combinar manualmente informes de múltiples sistemas. A menudo, los equipos de infraestructura dedican más tiempo a recopilar visibilidad que a analizar riesgos durante las auditorías o revisiones ejecutivas.
En lugar de pedir informes de parches a equipos individuales, los líderes de infraestructura pueden identificar de inmediato qué unidades de negocio se están quedando atrás en los objetivos de remediación, qué entornos tienen la mayor exposición a vulnerabilidades y dónde las fallas de implementación están creando riesgos. Lo que cambia es la cantidad de tiempo que se dedica a recopilar información antes de que se pueda tomar una decisión. Los equipos pueden pasar directamente a la planificación de la remediación en lugar de pasar días recolectando informes de diferentes sistemas.
Para entornos virtualizados, las relaciones entre el host y la máquina virtual siguen siendo visibles dentro del mismo sistema de inventario, eliminando otra capa de sobrecarga en el seguimiento de la infraestructura.
Automatización y ciclos de remediación más rápidos
Los beneficios de la consolidación a menudo son más fáciles de ver en los informes, pero el impacto diario generalmente se manifiesta en otras áreas. Los ciclos de implementación se vuelven más fáciles de gestionar porque se necesitan menos personas involucradas en cada decisión de parcheo.
La automatización previa a la implementación maneja los apagados de servicios antes de que comiencen los ciclos de reinicio. Los flujos de trabajo posteriores a la implementación reinician las aplicaciones automáticamente después de que se completen las actualizaciones. Los equipos de infraestructura configuran el flujo de trabajo una vez en lugar de coordinar cada implementación manualmente.
Una vez que esos pasos forman parte del flujo de trabajo, las implementaciones de parches dejan de depender del mismo esfuerzo de coordinación manual en cada ciclo.
Para vulnerabilidades críticas, las implementaciones automatizadas combinadas con flujos de trabajo de aprobación pueden reducir drásticamente los plazos de remediación. Además, las capacidades de reversión reducen la resistencia que muchos equipos de aplicaciones tienen hacia programaciones de parches agresivas porque las implementaciones fallidas ya no se convierten en ejercicios de recuperación a gran escala.
Los equipos de infraestructura no buscan una experiencia de parches diferente cada mes; necesitan un proceso en el que puedan confiar para producir el mismo resultado en cada ciclo. Cuando la aplicación de parches se vuelve repetible, los plazos de remediación mejoran naturalmente y el riesgo operativo se vuelve más fácil de gestionar.
Gobernanza y cumplimiento en todo el patrimonio
Los marcos de cumplimiento auditan la consistencia operativa, no las herramientas individuales.
Los auditores necesitan evidencia de que los sistemas se identifican correctamente, las vulnerabilidades se rastrean de manera consistente, las implementaciones siguen los flujos de trabajo aprobados y las brechas de remediación se documentan hasta su cierre.
Eso se vuelve difícil cuando la evidencia de cumplimiento está dispersa en múltiples plataformas desconectadas. Productos como Patch Manager Plus centralizan los informes de cumplimiento en todos los sistemas operativos, entornos y grupos de implementación, al mismo tiempo que se integran con los flujos de trabajo de ITSM para el seguimiento de la aprobación de cambios.
Antes de la implementación, la plataforma puede generar automáticamente solicitudes de cambio con los sistemas afectados, planes de reversión, alcance de la implementación y resúmenes de riesgos adjuntos. Después de la implementación, los re-escaneos validan el estado de la remediación y actualizan la pista de auditoría automáticamente.
El resultado es un proceso de parches que es más fácil de auditar, más fácil de validar y más fácil de demostrar durante las revisiones de cumplimiento.
Simplificar la gestión de parches sin forzar una migración completa
Una de las razones por las que los entornos de parches fragmentados persisten durante años es el riesgo de migración. Los equipos de infraestructura se muestran reacios a reemplazar sistemas de parches que ya funcionan porque los fallos en la gestión de parches afectan directamente la estabilidad de la producción.
La transición a una plataforma consolidada no requiere el reemplazo inmediato de las herramientas existentes. Las cargas de trabajo de Windows, los entornos de Linux, la infraestructura en la nube y los centros de datos regionales pueden moverse de forma independiente en función de la preparación operativa en lugar de una fecha límite fija.
La mayoría de las empresas no buscan un rediseño completo de su estrategia de parches. Buscan una forma práctica de reducir la complejidad que se acumuló a medida que la infraestructura se expandió a través de centros de datos, plataformas en la nube y pilas de aplicaciones.
Conclusión
La mayoría de las empresas llegaron a su entorno de parches actual a través de una serie de decisiones de infraestructura razonables. Diferentes equipos adoptaron diferentes herramientas para resolver problemas específicos, y esas herramientas a menudo funcionaron bien dentro de su alcance original.
El desafío aparece más adelante, cuando se espera que esos sistemas independientes soporten un único proceso operativo. A medida que los entornos crecen, el esfuerzo requerido para coordinar informes, aprobaciones, actividades de remediación y programaciones de mantenimiento en múltiples plataformas comienza a consumir más tiempo que la aplicación de parches en sí.
Para muchas organizaciones, simplificar la gestión de parches se trata en última instancia menos de reemplazar herramientas y más de crear un proceso que pueda escalar de manera consistente a medida que la infraestructura a su alrededor evoluciona.
Sobre el autor: Hari Prasadh T
Hari es especialista en marketing de producto en la solución de Gestión Unificada de Endpoints y Seguridad de ManageEngine. Le apasiona hacer que la tecnología compleja sea fácil de entender y convertir ideas técnicas en historias simples y cercanas.
