¿No puedes aplicar parches con la suficiente rapidez? La confianza cero como última línea de defensa

La velocidad con la que se añaden funciones nuevas y la evolución de las aplicaciones aumentan directamente la complejidad arquitectónica. Este ritmo incesante no solo se debe al deseo de incorporar funciones nuevas, sino que el descubrimiento constante de vulnerabilidades lo fuerza cada vez más. Aplicar parches a una sola dependencia crítica puede desencadenar una cascada de actualizaciones necesarias y cambios arquitectónicos inesperados, ya que cada producto y solución ofrece una gran cantidad de opciones de implementación y diversas funciones para habilitar o deshabilitar. Adaptar esta complejidad a tu entorno específico dificulta garantizar que cada componente se implemente según las prácticas recomendadas del sector. Los patrones validados acortan esta brecha al proporcionar patrones de implementación listos para usar y probados exhaustivamente para diversos casos de uso, lo que reduce la necesidad de diseñar desde cero arquitecturas complejas centradas en la seguridad.

La incómoda verdad sobre la gestión de vulnerabilidades

En 2025, se publicaron más de 40000 CVE nuevos. Eso representa más de 100 cada día. En la actualidad, la generación de amenazas basadas en la inteligencia artificial acelera drásticamente el tiempo que transcurre desde que se descubre una vulnerabilidad hasta que se aprovecha de forma activa. "Persiguiendo el santo grial" muestra cómo buscar una puntuación perfecta de cero CVE puede ser contraproducente si distrae de estrategias de defensa en profundidad más exhaustivas. Un componente que está "limpio" a las 9:00 podría tener una vulnerabilidad recién descubierta a las 17:00. Incluso cuando alcances los cero CVE conocidos, siempre quedarán vulnerabilidades desconocidas.

Las matemáticas de los parches (la idea errónea de que la seguridad es solo un juego de números donde menos CVE significan menos riesgo) simplemente no cuadran en entornos empresariales que ejecutan cientos de cargas de trabajo en contenedores. A diferencia de las arquitecturas monolíticas tradicionales que se ejecutan en un solo sistema operativo, los entornos de contenedores distribuidos introducen una complejidad arquitectónica significativamente mayor. Innumerables microservicios y puntos de contacto de red ofrecen muchas más opciones de configuración donde algo puede fallar y crear una brecha de seguridad de forma inadvertida. Intentar solucionar absolutamente todo al instante es una tarea interminable que entra en conflicto con una estrategia de seguridad moderna basada en el riesgo. También ignora una verdad fundamental: no importa con cuánta agresividad intentes aplicar las actualizaciones, siempre habrá un retraso.

Entonces, ¿qué haces en el lapso entre la divulgación de la vulnerabilidad y la implementación del parche? La respuesta reside en un principio de seguridad que existe desde hace años, pero que hoy es más crítico que nunca: Arquitectura de confianza cero.

Qué significa la confianza cero para tu clúster de Red Hat OpenShift

La confianza cero no es un producto que instalas. Es una filosofía arquitectónica que asume que ya ha ocurrido una brecha, lo que exige que cada interacción se verifique y autorice explícitamente. Según el NIST SP 800-207, la confianza cero significa eliminar la confianza implícita otorgada a los recursos (activos, aplicaciones o cuentas de usuario) basándose únicamente en su ubicación física o de red. La autenticación y la autorización son funciones independientes que se realizan antes de establecer cualquier sesión con un recurso empresarial.

Implementar la confianza cero en Kubernetes y Red Hat OpenShift requiere un enfoque de varias capas que abarque la identidad de la carga de trabajo, la gestión de secretos y el control de acceso en tiempo de ejecución. Específicamente dentro del dominio de las redes, una de las implicaciones más críticas de esta filosofía es ir más allá de la postura de red plana predeterminada donde cada pod puede comunicarse libremente. De forma predeterminada, Kubernetes no aplica restricciones de red interna, lo que equivale a dejar sin llave todas las puertas internas de un edificio simplemente porque este tiene una puerta principal (como un controlador de ingreso del clúster, una puerta de enlace de API o un firewall perimetral). Sin embargo, confiar únicamente en esta defensa perimetral resulta fundamentalmente insuficiente para los entornos modernos nativos de la nube.

Según el modelo de confianza cero, asumimos que ya se ha producido una brecha y que los actores maliciosos ya están dentro de tu entorno, ya sean atacantes externos que superaron el perímetro, un componente de la cadena de suministro comprometido o amenazas internas maliciosas que operan directamente desde el interior. Al implementar restricciones de recursos de red de Kubernetes, creamos una conexión de red de denegación predeterminada con autenticación y autorización explícitamente definidas para usar la red y alcanzar otros recursos conectados a ella (Figura 1).

De la teoría a la práctica: El Layered Zero Trust Validated Pattern (ZTVP)

Para hacer realidad estas mejores prácticas, aprovechamos el Layered Zero Trust Validated Pattern (ZTVP). Un patrón validado incorpora las mejores prácticas de infraestructura como código (IaC) y la automatización de GitOps, lo que reduce drásticamente el tiempo de configuración para implementaciones complejas de OpenShift diseñadas para la seguridad y la escalabilidad. Durante los últimos tres meses, el proyecto ZTVP ha avanzado significativamente y ha logrado la acreditación Tested Tier.

El patrón reúne múltiples componentes en una arquitectura de confianza cero coherente implementada mediante GitOps:

• Zero trust workload identity manager: Proporciona identidades criptográficas de corta duración basadas en el proyecto SPIFFE/SPIRE a las cargas de trabajo.
• HashiCorp Vault: Almacena activos sensibles y secretos del clúster con un enfoque de seguridad integral, integrado con ZTWIM para la autenticación JWT.
• Red Hat build of Keycloak: Gestiona la autenticación de usuarios y la identidad federada.
• Red Hat Advanced Cluster Security for Kubernetes: Actúa como el cerebro de seguridad inteligente, proporcionando supervisión unificada de múltiples clústeres, control de admisión proactivo, detección de anomalías de comportamiento en tiempo real y, fundamentalmente en nuestro ejemplo, un analizador de políticas de red.

Políticas de red: La última línea de defensa

Aunque a menudo se habla de las políticas de red como base de la confianza cero, no son un principio en sí mismas. En su lugar, son un mecanismo arquitectónico proactivo que se utiliza para aplicar los resultados deseados de un modelo de confianza cero. Red Hat describe cuatro principios básicos de la confianza cero, y las políticas de red bien diseñadas respaldan activamente cada uno de ellos:

• Microsegmentación: Al regular el tráfico a nivel de pod individual, las políticas de red dividen intrínsecamente el clúster en segmentos granulares con seguridad mejorada.
• Acceso con privilegios mínimos: Una postura de denegación predeterminada garantiza que a las cargas de trabajo solo se les concedan los permisos de red exactos que necesitan para funcionar, y nada más.
• Desperimetrización: Los controles de seguridad se alejan de la simple "puerta principal" del clúster y se aplican directamente alrededor de las propias cargas de trabajo.
• Asumir la brecha: Al eliminar proactivamente las rutas de ataque lateral, ya existen reglas estrictas de entrada y salida para contener el radio de impacto en el momento en que ocurre un compromiso.

Además, un aspecto extremadamente importante de las políticas de red de Kubernetes es que existen en un plano de control separado de los pods de aplicaciones que protegen. Esto significa que incluso si un atacante logra vulnerar un contenedor y obtiene privilegios elevados dentro de esa aplicación, no puede simplemente redefinir o eludir los límites de red que lo restringen. Para mejorar la postura de seguridad general del entorno interno y poner realmente en práctica estos principios, debemos definir políticas de red granulares que regulen tanto el tráfico de entrada como el de salida a nivel de pod:

• Políticas de entrada: Estas controlan el tráfico entrante a un pod, aplicando una regla que establece que un servicio solo acepta conexiones de fuentes autorizadas explícitamente. Si un pod vecino en el clúster se ve comprometido, una política de entrada sólida evita que el atacante acceda lateralmente a tus cargas de trabajo sensibles.
• Políticas de salida: Estas controlan el tráfico saliente de un pod. Su objetivo es limitar estrictamente a qué recursos externos o internos puede llegar un pod. Si un pod se ve comprometido, las políticas de salida neutralizan la capacidad de un atacante para filtrar datos, realizar un reconocimiento de red amplio o descargar cargas maliciosas de servidores externos de comando y control.

La base de denegación predeterminada

Aunque definir reglas específicas de entrada y salida es crucial, confiar solo en ellas deja una brecha peligrosa que permite errores humanos y ataques engañosos. De forma predeterminada, Kubernetes funciona con un modelo de permitir todo, lo que significa que se permite cualquier tráfico que no esté restringido explícitamente. Si un desarrollador simplemente olvida aplicar una política, ese pod queda totalmente expuesto. Pero el riesgo va más allá de los errores honestos. En un ataque a la cadena de suministro, un desarrollador podría ser engañado sin saberlo para implementar un componente de terceros comprometido, sin ser consciente de la carga maliciosa oculta ni de sus consecuencias.

Una política de denegación predeterminada cambia este paradigma de una lista de bloqueo a una lista de permitidos. El principio central de la confianza cero exige que cada interacción sea autorizada explícitamente, por lo que lógicamente se deduce que absolutamente ningún acceso puede ser implícito. Al bloquear estrictamente todo el tráfico desde el principio, una postura de denegación predeterminada crea un entorno donde una omisión accidental (o un contenedor malicioso disfrazado que intenta comunicarse con el exterior) resulta en una conexión bloqueada de forma segura. Te obliga a conceder acceso explícitamente por diseño, convirtiendo lo que podría ser una brecha silenciosa y catastrófica en un error de implementación notable y fácil de corregir.

El enfoque comienza con una regla simple pero potente: Denegar todo el tráfico de forma predeterminada. Cada espacio de nombres recibe una NetworkPolicy de denegación predeterminada que bloquea todas las entradas y salidas de cada pod, a menos que exista una política de permiso explícita.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-in-namespace
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Tan pronto como una NetworkPolicy se dirige a un pod en un espacio de nombres, este deja de tener acceso sin restricciones. Al definir una política que bloquea el acceso de forma predeterminada, se alinea con una postura de denegación por defecto de confianza cero.

Por qué esto importa cuando no puedes aplicar parches

Considera un escenario empresarial que recuerde a la infame crisis de Log4j o a crisis de marcos de trabajo más recientes como la vulnerabilidad React2Shell (CVE-2025-55182):

1. Se divulga repentinamente una vulnerabilidad crítica de ejecución remota de código (RCE) en una biblioteca ubicua utilizada por tu aplicación.
2. La vulnerabilidad permite la toma de control total del servidor si un atacante simplemente puede enviar una solicitud especialmente diseñada al servicio afectado.
3. Debido a que la biblioteca está profundamente integrada en tus dependencias, un parche validado no se probará ni se implementará en producción con éxito durante varios días.

El impacto en una organización con políticas de red de confianza cero es mínimo:

• Un atacante que comprometa cualquier pod puede llegar fácilmente al servicio vulnerable a través de cualquier espacio de nombres (sin aislamiento lateral).
  • Con las políticas de red de ZTVP: El atacante no puede llegar al servicio desde otro espacio de nombres (aislamiento de espacios de nombres).
• Un atacante puede conectarse a cualquier puerto expuesto en el servicio, incluidos los puertos críticos o de gestión (sin filtrado a nivel de puerto).
  • Con las políticas de red de ZTVP: El atacante no puede conectarse a puertos que no estén explícitamente permitidos (filtrado a nivel de puerto).
• Un atacante puede realizar libremente conexiones salientes para filtrar datos o establecer canales de comando y control (C2) (sin restricciones de salida).
  • Con las políticas de red de ZTVP: El atacante no puede filtrar datos a extremos externos (restricciones de salida).

Demostración: Eliminar la ruta de ataque

Hemos creado un vídeo de demostración en el que observamos exactamente cómo las políticas de red implementadas correctamente eliminan activamente las rutas de ataque. Inicialmente, vemos un entorno sin una postura de denegación predeterminada, donde un atacante que aprovecha una vulnerabilidad de la cadena de suministro puede realizar fácilmente un reconocimiento exhaustivo, sondeando libremente la red en busca de otros componentes sin parches para explotar. Luego vemos que, una vez que se aplican políticas de red estrictas, la historia cambia por completo.

Incluso si un atacante logra vulnerar con éxito un pod, su capacidad para investigar la red, buscar vulnerabilidades o pivotar lateralmente queda totalmente neutralizada. Las políticas lo restringen al contenedor comprometido, conteniendo eficazmente la amenaza y dándote el tiempo crucial necesario para implementar acciones correctivas. Aunque no sean el único sistema de seguridad en una estrategia integral, establecer límites de red estrictos es posiblemente el mejor punto de partida para construir tu última línea de defensa.

Esta demostración muestra cómo las políticas de red restringen un ataque al contenedor comprometido, conteniendo eficazmente la amenaza y dándote el tiempo crucial necesario para implementar acciones correctivas.

La imagen general: Defensa en capas

Las políticas de red son solo una capa de una estrategia integral. El Layered Zero Trust Validated Pattern combina estas políticas con identidades de carga de trabajo SPIFFE/SPIRE (usando el Zero trust workload identity manager), secretos gestionados por Vault, autenticación centralizada mediante un proveedor de identidad (IdP) como nuestra Red Hat build of Keycloak predeterminada y supervisión del tiempo de ejecución con Red Hat Advanced Cluster Security for Kubernetes. Las políticas de red completan el panorama al garantizar que, incluso si fallan la identidad, los secretos y la seguridad de las aplicaciones, la capa de red proporcione contención.

Pero, ¿cómo sabes si tus políticas de red están funcionando realmente o si un contenedor comprometido está sondeando repetidamente tus límites internos? ¿Qué sucede cuando una amenaza del día cero activa una conexión denegada?

Ayudamos a responder estas preguntas críticas a lo largo de esta serie de blogs que explora cómo el Layered Zero Trust Validated Pattern implementa prácticas de seguridad de confianza cero. Esto es lo que puedes esperar a medida que avanzamos:

• Defensa activa con Red Hat Advanced Cluster Security for Kubernetes: Implementar una supervisión profunda del tiempo de ejecución, escaneo automatizado de políticas de red y alertas en tiempo real para actuar como tu cerebro de seguridad central.
• Identidad y secretos: Gestionar las identidades de las cargas de trabajo de forma más segura con el Zero trust workload identity manager y la integración de Vault.
• Cadena de suministro: Blindar tu cadena de suministro de software de extremo a extremo mediante la aplicación de firmas de contenido y la verificación de las tareas del canal para garantizar que solo el código de confianza llegue a tu clúster.

¿Todo listo para verla en acción? No tienes que esperar al próximo artículo para empezar. Consulta el Layered Zero Trust Validated Pattern para explorar la arquitectura y prueba la demostración de las políticas de red por ti mismo.

Referencias

• NIST SP 800-207: Arquitectura de confianza cero
• NIST SP 800-207A: Confianza cero para aplicaciones nativas de la nube
• CISA: Guía de microsegmentación de confianza cero
• Layered Zero Trust Validated Pattern
• Validated Patterns
• En busca del santo grial: Por qué el Hummingbird Project de Red Hat tiene como objetivo lograr casi cero CVE
• Métricas de CVE