Los proveedores lanzan sus soluciones, el equipo de seguridad recuerda a todos los plazos, y las operaciones comienzan a enviar correos electrónicos a los propietarios de los servicios. ¿Cuándo se pueden reiniciar los servidores de aplicaciones? ¿Es aceptable la noche del martes, o hay que esperar hasta el fin de semana? ¿Y qué hay del sistema que tardó más de lo esperado en volver la última vez? Las respuestas llegan tarde, algunas no llegan en absoluto. Al final, parte del sistema se parchea y el resto se pospone para "el próximo mes".
Este ciclo se repite todos los meses y agota la energía en ambos lados. Los administradores están frustrados porque no pueden hacer el trabajo que les corresponde. Los propietarios de los servicios sienten que las operaciones siempre les están pidiendo algo. Y el equipo de seguridad ve crecer la lista de soluciones diferidas.
Por qué la misma pregunta vuelve una y otra vez
A menudo vemos que la aplicación de parches se realiza como una serie de eventos puntuales. Cada mes trae una nueva lista de servidores, un nuevo conjunto de solicitudes de interrupción y una nueva ronda de aprobaciones. Sin embargo, la mayoría de las respuestas no cambian de un mes a otro: el servicio sigue teniendo los mismos horarios comerciales, la misma redundancia y el mismo propietario.
Por lo tanto, el problema no es que la gente no esté dispuesta a acordar. El problema es que el acuerdo nunca se escribe, y al mes siguiente todos comienzan desde cero. A esto se suman otras debilidades:
- no está claro quién decide por un servicio, por lo que la solicitud se pasa entre varias personas,
- los servidores se parchean uno a uno a partir de una lista, no por servicio y sus dependencias,
- los nodos redundantes a veces se reinician al mismo tiempo, porque solo unas pocas personas saben que son redundantes,
- una solución crítica espera en la misma cola que una actualización mensual rutinaria.
Cómo abordarlo
En lugar de negociar cada mes, es mejor llegar a un acuerdo con el propietario del servicio que siga siendo válido hasta que alguien lo cambie deliberadamente. El acuerdo establece cuándo se puede realizar la aplicación de parches, si la aplicación de parches dentro de esa ventana está preaprobada y cómo se manejan los nodos redundantes. La planificación mensual deja de ser una cuestión de "¿podemos?" y se convierte simplemente en "¿qué sigue?".
El segundo principio es separar la ruta rutinaria de la urgente. Una vulnerabilidad crítica no debe esperar a la siguiente ventana establecida, pero tampoco debe eludir al propietario del servicio por completo.
Cómo lo maneja Eywo Stratum
Eywo Stratum introduce un acuerdo de parcheo entre las operaciones y el propietario del servicio. Cubre:
- una ventana establecida - un momento regular en que el servicio puede ser parcheado,
- parcheo preaprobado dentro de la ventana - los cambios cubiertos por el acuerdo no necesitan una aprobación de interrupción fresca cada mes,
- parcheo continuo de nodos redundantes - los nodos en un grupo de redundancia se parchean uno a la vez para que el servicio siga estando disponible,
- un modo acelerado para problemas críticos - un camino más corto para vulnerabilidades graves, acordado de antemano por ambas partes.
Un acuerdo de parcheo propuesto llega a la cola única de "Aprobar" del propietario del servicio, junto con cambios de interrupción y solicitudes. Una regla define quién es el propietario; si un servicio no tiene propietario, el gestor de cambios decide. Un rechazo siempre viene con una razón, para que las operaciones sepan qué ajustar.
Los acuerdos de parcheo alimentan un plan de parcheo basado en ondas. Los servidores se agrupan en ondas según sus servicios y ventanas, y el plan genera los cambios correspondientes en un solo paso. Esos cambios pasan por los mismos controles que cualquier otro cambio en el sistema: impacto en los servicios, ventanas de mantenimiento, congelaciones y colisiones. El panel de vulnerabilidad y remediación muestra cómo avanza el trabajo.
Acordar una vez, descansar tranquilo cada mes
La aplicación de parches no tiene que ser una negociación mensual. Una vez que se acuerda cuándo y cómo se parchea un servicio, los administradores pueden trabajar según un plan, los propietarios de los servicios saben qué esperar y el equipo de seguridad puede ver que las soluciones realmente llegan a producción. La conversación con el propietario del servicio ocurre ocasionalmente y se trata de lo que importa, no de la misma pregunta cada mes.
Los acuerdos de parcheo, los planes de parcheo basados en ondas y el panel de remediación están incluidos en la edición Business.
Eywo Stratum Business
Para operaciones que desean conectar monitorización, seguridad y proveedores.