¡Llegó la solución! Red Hat Advanced Cluster Security: respuesta ante amenazas en tiempo real

Segunda parte de una serie sobre la implementación de la confianza cero en Red Hat OpenShift con el patrón validado de confianza cero en capas (ZTVP)

En nuestro artículo anterior, analizamos los motivos por los que las políticas de red, en especial la de denegación predeterminada combinada con reglas estrictas de entrada y salida, son tu última línea de defensa fundamental cuando no puedes aplicar parches con la suficiente rapidez o cuando fallan todas las demás barreras de seguridad. Al bloquear la comunicación de red, eliminamos de forma efectiva las rutas de ataque lateral y contenemos el radio de impacto de una carga de trabajo comprometida.

Sin embargo, una verdadera arquitectura de confianza cero, según la definición de NIST SP 800-207, no consiste en construir muros perimetrales más sólidos, sino en diseñar mejores puertas y verificar de forma continua lo que pasa a través de ellas. Las políticas de red nos proporcionan las puertas. Sin embargo, si asumimos que ya ocurrió una vulneración de seguridad, debemos reconocer una dura realidad: Incluso los mejores controles de acceso estáticos no bastan por sí solos. Cuando surge una vulnerabilidad de día cero, necesitas una supervisión activa en tiempo de ejecución para detectar comportamientos anómalos dentro de la carga de trabajo. Incluso con las mejores políticas de red implementadas, siempre existe la amenaza latente de una vulnerabilidad de día cero imprevista.

Si tus políticas de red atrapan a un atacante dentro de un contenedor, ¿qué está haciendo allí? Para responder a eso, necesitas un "cerebro" de seguridad central. En el patrón validado de confianza cero en capas (ZTVP), ese cerebro es Red Hat Advanced Cluster Security.

Red Hat Advanced Cluster Security: El cerebro

Mientras que las políticas de red dictan lo que debe suceder, Red Hat Advanced Cluster Security (ACS) supervisa lo que realmente ocurre. En el contexto de una arquitectura idealizada de confianza cero según NIST 800-207, esta supervisión continua es lo que completa el ciclo crítico de control de seguridad. Recopila de forma continua el contexto de transacciones y comportamientos en tiempo real, y actúa como un punto de información de políticas (PIP). Esto se envía al motor de inteligencia central, el punto de decisión de políticas (PDP). De esta manera, Red Hat Advanced Cluster Security puede activar respuestas automáticas de inmediato en el punto de aplicación de políticas (PEP), como la revocación del acceso o la finalización de una carga de trabajo comprometida.

En ZTVP, no solo implementamos la configuración predeterminada de Red Hat Advanced Cluster Security. Lo implementamos configurado con políticas de seguridad personalizadas y adaptadas que cumplen con las prácticas recomendadas del sector para aplicar este modelo dinámico de confianza cero en tiempo de ejecución. Nuestra implementación personalizada incorpora cuatro políticas fundamentales —completamente definidas y disponibles en el repositorio de patrones validados de confianza cero en capas— diseñadas para funcionar en conjunto con la capa de red. Para ofrecer una visibilidad clara de estos controles, se dividen en dos categorías operativas distintas: Generación de alertas (que comprueba que las "puertas" de nuestra red estén configuradas correctamente durante la implementación) y Terminación (que neutraliza activamente una amenaza en curso en tiempo de ejecución).

Estas cuatro políticas se describen a continuación:

Confía, pero comprueba: Supervisión del cumplimiento de las políticas de red

¿Cómo garantizas exactamente que cada carga de trabajo esté realmente protegida por estas puertas y que no se haya omitido ni eliminado un límite de red crítico por accidente durante una actualización de la implementación? Además, si una política está mal configurada y un atacante logra eludirla, ¿cómo lo detectas?

En el ZTVP, abordamos esto combinando nuestra aplicación en tiempo de ejecución con controles estrictos de implementación. Para ayudar a garantizar que ninguna carga de trabajo quede expuesta debido a la falta de una política de red o a su eliminación accidental, el ZTVP incluye dos políticas de implementación de ACS específicas y personalizadas, habilitadas de forma predeterminada en modo de alerta:

• Las implementaciones deben tener al menos una política de red de entrada
• Las implementaciones deben tener al menos una política de red de salida

Actualmente, para demostrar esta función de manera controlada y evitar la fatiga por alertas en todo el clúster, estas políticas personalizadas están habilitadas de forma predeterminada solo para nuestra aplicación de demostración de ZTVP. Dentro de este alcance, las políticas analizan el entorno de forma continua. Si un desarrollador envía una implementación sin definir sus límites de red específicos, ACS lo marca de inmediato. Esto ayuda a garantizar que las "puertas" fundamentales siempre se comprueben como presentes, mientras que nuestras políticas de terminación en tiempo de ejecución permanecen listas para detectar cualquier comportamiento anómalo en caso de que esas puertas se configuren incorrectamente o se eludan.

Sin embargo, seamos francos sobre las limitaciones técnicas del análisis de configuración: Red Hat Advanced Cluster Security no puede supervisar directamente si se aplica activamente una política de denegación predeterminada en todo el espacio de nombres. No todas las prácticas recomendadas de arquitectura se pueden validar a la perfección mediante comprobaciones estáticas. Debido a estos puntos ciegos inevitables en la supervisión de la implementación, depender únicamente de las alertas deja una brecha crítica en nuestra protección.

Defensa activa: Eliminación de amenazas en tiempo de ejecución

Como sabemos que no podemos comprobar de forma estática cada control de seguridad, debemos asumir que pueden pasarse por alto algunos errores de configuración o que un atacante puede encontrar una forma novedosa de vulnerar una carga de trabajo. Cuando se está produciendo un ataque activo, las alertas simplemente no bastan; cada segundo cuenta. Aquí es donde la implementación de ZTVP de Red Hat Advanced Cluster Security pasa de ser una herramienta de supervisión pasiva a un implacable mecanismo de defensa activa. Para salvar la brecha que dejan las limitaciones de la supervisión estática, se implementaron dos políticas personalizadas adicionales y se habilitaron en modo de terminación:

• Supervisión del comportamiento sospechoso en pods
• Detección de ejecución de comandos peligrosos

Demostración: Detección de amenazas y terminación de pods en tiempo real

En este breve video, ponemos a prueba el principio básico de confianza cero de "asumir una brecha de seguridad", establecido en nuestro primer artículo. Simulamos un escenario donde un atacante ya superó con éxito los límites iniciales y obtuvo acceso a un pod en ejecución.

• Sin ZTVP: En un entorno estándar sin una supervisión estricta en tiempo de ejecución, un atacante dispone de tiempo ilimitado para ejecutar comandos de descubrimiento, mapear la red interna, sondear archivos locales y experimentar con diversas opciones de ataque sin ser detectado.
• Con ZTVP: En un clúster protegido por ZTVP, la supervisión en tiempo de ejecución de Red Hat Advanced Cluster Security detecta de inmediato el comando de reconocimiento inicial de un atacante. Esta acción activa una política de terminación instantánea, lo que interrumpe la sesión de terminal y elimina el pod no autorizado en tiempo real para neutralizar la amenaza antes de que ocurran más actividades.

Imagina un escenario en el que una vulnerabilidad de día cero en un componente de la cadena de suministro permite a un atacante ejecutar código dentro de uno de tus pods. Incluso si tus políticas de red le impiden desplazarse a otros espacios de nombres o filtrar datos, el atacante sigue dentro del pod, donde pueden ocurrir intentos de ejecutar scripts de reconocimiento, inyectar cargas maliciosas o ejecutar comandos de shell.

En el momento en que el atacante intenta ejecutar un comando peligroso o muestra un comportamiento sospechoso, ACS detecta la anomalía. Como estas políticas están configuradas en modo de terminación dentro del ZTVP, Red Hat Advanced Cluster Security no solo envía una alerta, sino que elimina de inmediato el pod no autorizado.

Esta es la máxima sinergia de la defensa en profundidad: Las políticas de red bloquean las rutas de escape del atacante y la supervisión activa en tiempo de ejecución elimina la amenaza por completo. Incluso si se pasó por alto una configuración, el riesgo de un ataque exitoso y prolongado se reduce prácticamente a cero.

Respuesta ante amenazas en tiempo real con Red Hat Advanced Cluster Security al asumir una brecha de seguridad y neutralizar las amenazas.

Cierre del ciclo: Visibilidad en tiempo real para administradores

Al eliminar un pod comprometido se neutraliza la amenaza inmediata, pero el equipo de mantenimiento del entorno y el equipo de seguridad aún necesitan saber que se intentó un ataque. En la actualidad, todas estas alertas de alta fidelidad, que detallan el comportamiento sospechoso, los comandos específicos que se intentaron y la acción de aplicación adoptada, se registran de inmediato y se pueden ver directamente en la consola de Red Hat Advanced Cluster Security. Esto permite a los equipos investigar la causa principal, como la identificación de un componente vulnerable de la cadena de suministro, sin la presión de una brecha activa y creciente. Sin embargo, para cerrar el ciclo, estamos trabajando activamente para ampliar esta función. El plan de ZTVP incluye integraciones previstas con sistemas externos de seguimiento y alertas, como Atlassian Jira. Muy pronto, los administradores de clústeres y los equipos de seguridad podrán recibir estas notificaciones críticas en tiempo real directamente en sus canales operativos preferidos, lo que brindará una mayor visibilidad y un flujo de trabajo de respuesta a incidentes más rápido.

La realidad de la confianza cero

Destacar esta defensa en tiempo de ejecución nos devuelve al núcleo del modelo de confianza cero. Ningún sistema es impenetrable. En nuestro artículo anterior, establecimos que la búsqueda del "santo grial" de cero CVE conocidos es una batalla perdida cuando no puedes aplicar parches con la suficiente rapidez. La conclusión fundamental del modelo de confianza cero es que las vulnerabilidades (tanto los CVE conocidos como las vulnerabilidades de día cero aún no descubiertas) son inevitables.

Si bien las políticas de red estrictas son fundamentales para establecer "puertas" y los controles avanzados, como las firmas de contenido y la verificación de canales, son cruciales para proteger la cadena de suministro, no son integrales. La capacidad de supervisar las cargas de trabajo en tiempo real, detectar comportamientos anómalos y eliminar automáticamente las amenazas en tiempo de ejecución es lo que distingue a un sistema frágil de uno verdaderamente resistente frente a lo desconocido.

No tienes que esperar a la próxima entrega para implementar una defensa resistente.

• Implementa la supervisión activa: Implementa las políticas personalizadas de Red Hat Advanced Cluster Security descritas en este artículo (siguiendo la tabla de políticas en el repositorio de patrones validados) para comenzar a transformar los bloqueos de red silenciosos en inteligencia de seguridad de alta fidelidad.
• Explora la arquitectura: Revisa la arquitectura completa del patrón validado de confianza cero en capas para comprender el papel de esta supervisión en tiempo de ejecución en el panorama general.

En la próxima entrega de esta serie, analizaremos cómo ZTVP protege las identidades de las cargas de trabajo con SPIFFE/SPIRE y el administrador de identidades de cargas de trabajo de confianza cero, lo que garantiza que, incluso cuando una carga de trabajo se comporte a la perfección, todavía tenga que demostrar criptográficamente quién es con exactitud.