Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Los parches sin reinicio del núcleo de Linux aplican correcciones de seguridad a un núcleo en ejecución, por lo que la corrección ya no tiene que esperar a que se reinicie el sistema.
- En esta entrada del blog, analizamos el caso de un equipo de cinco personas que gestiona aproximadamente 10 000 sistemas críticos de negociación sin necesidad de realizar ni un solo reinicio obligatorio para aplicar parches.
- Los intervalos entre reinicios se duplicaron, pasando de unos seis meses a aproximadamente un año, y pasaron a ser operaciones de mantenimiento opcionales.
- Al eliminar la necesidad de reiniciar el sistema, se redujo la coordinación entre equipos y se evitó que las medidas correctivas de la norma PCI DSS se incluyeran en el calendario de mantenimiento.
Una plataforma de negociación puede soportar muchos días malos. Sin embargo, un reinicio del núcleo en pleno proceso de ejecución de una orden no es uno de ellos.
Existe un lapso de tiempo entre el momento en que se publica una corrección del núcleo y el momento en que el sistema de producción queda realmente protegido. Una vez que se publica la actualización, alguien tiene que encontrar un hueco, obtener la aprobación del cambio, coordinarse con los responsables de las aplicaciones y reiniciar el equipo. Los parches sin reinicio del núcleo de Linux eliminan ese lapso al aplicar las correcciones de seguridad pertinentes al núcleo en ejecución, de modo que la protección ya no depende del reinicio.
Ahora amplía la perspectiva del problema. Cinco ingenieros. Aproximadamente 10 000 sistemas críticos repartidos por varios centros de datos, principalmente basados en RHEL y, en gran parte, en AlmaLinux. A todo ello hay que añadir el PCI DSS, además de otras normas de seguridad y auditoría que exigen que las vulnerabilidades conocidas se corrijan en un plazo mucho más breve que una escala de tiempo geológica.
Esa era la situación en una entidad global de servicios financieros, donde el tiempo de disponibilidad se traduce directamente en ingresos y en la que incluso las interrupciones más leves en la ejecución de órdenes repercuten en los resultados.
Cuando la aplicación de parches al núcleo se convierte en un proyecto operativo
La aplicación de parches mediante reinicio se realizaba aproximadamente cada seis meses. No porque nadie considerara aceptable un periodo de exposición de medio año, sino porque esa era la frecuencia que la coordinación podía soportar en la práctica. Planificar un solo ciclo podía llevar días al responsable del equipo, incluso antes de que se involucrara el resto de la empresa, y cada responsable de aplicación y cada persona encargada de aprobar los cambios tenía una opinión diferente sobre cuándo se podía dejar un sistema fuera de servicio.
Seis meses, y aún así no fue suficiente. Los equipos de seguridad y cumplimiento normativo querían una corrección más rápida. El equipo de ingeniería ya estaba al límite con esa frecuencia. Ambas cosas eran ciertas al mismo tiempo, lo que suele ser señal de que el problema está en el proceso y no en las personas que lo llevan a cabo.
La mayor parte de ese coste nunca se refleja en la cola de incidencias. Se destina a la programación de llamadas, la planificación de reversiones y la comprobación de dependencias. Nada de eso sirve para corregir ni un solo CVE adicional.
Los cálculos sobre el horario de mantenimiento nunca han funcionado
Así es como el jefe de equipo describió el problema de planificación:
«Estos sistemas son fundamentales; no se pueden detener. Si hay que detenerlos, solo se puede hacer durante determinados intervalos de mantenimiento. Esos intervalos eran prácticamente imposibles de aprovechar porque son demasiado cortos, y se necesitarían unas 100 personas para reiniciar todo».
Esa es la ecuación con la que, tarde o temprano, se encuentra cualquier empresa que apueste por la alta disponibilidad. Los plazos se acortan a medida que el negocio se internacionaliza, la flota no deja de crecer y la plantilla no aumenta.
Con unos pocos cientos de servidores, puedes ir a ciegas durante un fin de semana de reinicios y llamarlo «plan». Con 10.000 sistemas críticos y solo cinco personas, ya no es posible ir a ciegas, y la acumulación de parches pendientes se convierte en una constante del entorno. Contratar a 100 personas por cada CVE del kernel no es una estrategia.
Si tu capacidad para reiniciar aumenta a medida que crece tu parque informático, las ventanas de mantenimiento programadas pueden seguir funcionando. Si no es así, la única solución real es dejar de vincular por completo la corrección de vulnerabilidades a los reinicios.
Qué ha cambiado la aplicación de parches sin necesidad de reiniciar para un equipo de cinco personas
Tras evaluar varias opciones, la organización se decantó por KernelCare de TuxCare y lo implementó en aproximadamente 10 000 de sus sistemas más críticos. Las pruebas demostraron que la distribución de parches era fiable y coherente, y la implementación se gestionó de forma centralizada a través de ePortal, lo que permitió que cinco personas mantuvieran una visión global de todo el proceso.
Los reinicios obligatorios para aplicar parches se redujeron a cero. Los reinicios siguen produciéndose, pero el intervalo se ha ampliado de unos seis meses a aproximadamente un año, y su finalidad ha cambiado con el tiempo. Pasaron a ser tareas de mantenimiento opcionales, en lugar de requisitos previos para corregir vulnerabilidades del núcleo. La coordinación entre equipos para la aplicación de parches al núcleo prácticamente desapareció, al igual que los días de planificación que solían precederla.
La distribución de parches también ha cambiado. En lugar de que las correcciones acumuladas se apliquen en un único periodo de tiempo limitado, los parches se aplican de forma continua, por lo que se evita que los riesgos se acumulen en los sistemas que llevan mucho tiempo en funcionamiento.
Por qué esto es importante para la norma PCI DSS y las pruebas de auditoría
Los marcos de cumplimiento miden el tiempo transcurrido. El esfuerzo no se tiene en cuenta. La norma PCI DSS exige que los parches de seguridad para vulnerabilidades críticas y de alto riesgo se instalen dentro de un plazo determinado tras su publicación, y el auditor solicita pruebas de que se ha cumplido el plazo, en lugar de una explicación de por qué se ha retrasado la ventana de mantenimiento.
Un ciclo de seis meses garantiza que haya un intervalo entre la disponibilidad de un parche y su aplicación. En los 10 000 sistemas, ese intervalo queda documentado en cada informe de análisis, trimestre tras trimestre. Al eliminar el reinicio del proceso, este se cierra sin añadir ni una sola ventana al calendario.
¿A quién va dirigido este libro?
Cualquiera que gestione un sistema Linux de alta disponibilidad bajo la presión de una auditoría y con un equipo más reducido de lo que cabría esperar. Las plataformas de negociación son el ejemplo más evidente, pero el mismo razonamiento se aplica a las bases de datos, las cargas de trabajo en clúster, las telecomunicaciones, el procesamiento de pagos y cualquier servicio de atención al cliente en el que «basta con reiniciarlo» no sea una estrategia de seguridad.
El caso práctico explica por qué el ciclo de seis meses dejó de ser sostenible, qué aspectos tuvo en cuenta el equipo al evaluar la aplicación de parches sin necesidad de reinicio y qué cambios se produjeron a partir de entonces en materia de cumplimiento normativo y en la carga de trabajo diaria, todo ello expresado en gran medida con las propias palabras de la organización. Es un texto breve y se centra en cifras concretas, más que en adjetivos.
Lee el caso práctico completo:
Garantizar la seguridad de los sistemas de comercio global sin afectar al tiempo de actividad →
