Comunicación segura y zero trust

Por qué dejó de funcionar el perímetro de red

Durante décadas, la mayoría de las organizaciones protegieron sus sistemas como un castillo con foso. Un firewall separaba el interior de confianza de un internet que no lo era, el personal se conectaba al interior mediante una red privada virtual (VPN) y todo lo que ya estaba dentro se trataba como amigo. Los servicios del centro de datos se llamaban entre sí por HTTP sin cifrar y sin autenticación, porque la propia red era la credencial. El Capítulo 6 incluyó la red es segura entre las falacias de la computación distribuida; el modelo perimetral es esa falacia convertida en arquitectura.

Tres cosas lo rompieron. Primero, el interior se volvió demasiado grande para defenderlo: los portátiles viajan, el personal trabaja desde casa, los socios se conectan, y un solo correo electrónico de phishing o una contraseña de VPN robada pone a un atacante dentro del foso. Una vez allí, el atacante se desplaza de máquina en máquina, lo que se llama movimiento lateral. En la brecha de 2013 en el minorista estadounidense Target, los atacantes usaron primero credenciales de red robadas a un contratista de calefacción y ventilación y desde ahí llegaron a los terminales de pago, llevándose datos de unos 40 millones de tarjetas. Segundo, el interior se disolvió: las cargas de trabajo se ejecutan ahora en varias cuentas de nube, productos SaaS y API de terceros, así que no hay un único muro donde poner un firewall. Tercero, el interior se volvió dinámico: los contenedores aparecen y desaparecen cada minuto y las direcciones IP se reutilizan, de modo que reglas escritas como permitir que 10.0.4.0/24 llegue a 10.0.7.12 no describen nada estable.

La idea de abandonar el perímetro es más antigua que el nombre. El Jericho Forum, un grupo de responsables de seguridad de grandes empresas, defendió la desperimetrización desde 2004; John Kindervag, entonces analista de Forrester Research, acuñó el término zero trust hacia 2010; y los artículos de Google sobre BeyondCorp a partir de 2014 mostraron que funcionaba a gran escala. El lema es nunca confíes, verifica siempre: ninguna solicitud es de confianza por su procedencia.

Zero trust según la definición del NIST

El texto de referencia es la publicación especial 800-207 del NIST, Zero Trust Architecture, publicada en agosto de 2020 (Rose, Borchert, Mitchell y Connelly). Describe zero trust (confianza cero) como un conjunto de principios que trasladan las defensas desde perímetros estáticos basados en la red hacia los usuarios, los activos y los recursos, y una arquitectura zero trust como el plan de una organización para aplicarlos. Su afirmación central es que no se concede ninguna confianza implícita a un activo o a una cuenta de usuario basándose solo en su ubicación física o en la red, ni en quién es su propietario. La autenticación y la autorización son funciones independientes que se realizan antes de establecer una sesión con un recurso.

La publicación enumera siete principios. Vale la pena conocerlos en sus propios términos, porque muchos productos dicen ser zero trust aunque solo cumplen uno o dos.

Puntos de decisión y de aplicación de políticas

SP 800-207 describe la maquinaria con un pequeño conjunto de componentes lógicos. Un punto de aplicación de políticas (PEP) se sitúa delante de un recurso y deja pasar el tráfico solo cuando se le indica: en la práctica, un proxy con reconocimiento de identidad, un API gateway, un sidecar de una service mesh o un proxy de base de datos. El punto de decisión de políticas (PDP) toma la decisión. El NIST lo divide en un motor de políticas, que evalúa la solicitud frente a la política y las entradas y decide, y un administrador de políticas, que ejecuta la decisión abriendo o cerrando la vía, por ejemplo emitiendo un token de sesión de corta duración o configurando el PEP. Las entradas incluyen el proveedor de identidad, la postura del dispositivo y de la carga de trabajo (nivel de parches, configuración, integridad), la inteligencia de amenazas, las propias políticas de acceso y los registros de actividad.

Separar la decisión de la aplicación es el mismo movimiento que separar la política del mecanismo en los sistemas operativos, y compensa por la misma razón: las políticas pueden escribirse una vez, revisarse, probarse y cambiarse de forma centralizada, mientras que la aplicación se reparte por todos los lugares por donde fluye el tráfico. Los motores de políticas de la Sección 8.3, como Open Policy Agent, suelen ser el motor que hay detrás de un PDP. La pregunta de diseño para un arquitecto es dónde poner los puntos de aplicación para que no exista ningún camino que los rodee, y cómo mantener la decisión rápida y disponible, porque un PDP en la ruta crítica de cada solicitud es ahora una dependencia con su propio presupuesto de disponibilidad y de latencia. Las respuestas habituales son almacenar en caché las decisiones durante unos segundos, enviar políticas compiladas al PEP para que pueda decidir localmente y decidir de antemano qué ocurre si no se puede contactar con el PDP (normalmente denegar, con una pequeña lista de permitidos para las comprobaciones de estado).

BeyondCorp: zero trust para las personas

Google empezó a abandonar su red corporativa privilegiada después de la intrusión de 2009 conocida como Operación Aurora, y describió el resultado en BeyondCorp: A New Approach to Enterprise Security (Rory Ward y Betsy Beyer, ;login:, diciembre de 2014), al que siguieron varios artículos más. El diseño tiene tres partes principales. Cada dispositivo se registra en un inventario de dispositivos y se identifica mediante un certificado. Un proxy de acceso, accesible desde internet, se sitúa delante de cada aplicación interna; los empleados llegan a las aplicaciones a través de él desde cualquier red, incluida la de la oficina, que no recibe ningún privilegio especial. Un componente de inferencia de confianza combina quién es el usuario con el estado del dispositivo para asignar un nivel de confianza, y cada aplicación declara el nivel mínimo que exige.

La consecuencia que sorprendió fue la eliminación de la VPN: un empleado en una cafetería y un empleado en su escritorio de la oficina pasan las mismas comprobaciones. Hoy la idea se vende en productos con los nombres de proxy con reconocimiento de identidad (identity-aware proxy) y acceso a la red zero trust (ZTNA). El Zero Trust Maturity Model de la Cybersecurity and Infrastructure Security Agency de EE. UU. (versión 2.0, abril de 2023) es una herramienta útil de autoevaluación: puntúa cinco pilares (identidad, dispositivos, redes, aplicaciones y cargas de trabajo, y datos) desde tradicional hasta óptimo, con visibilidad, automatización y gobernanza transversales a todos ellos.

TLS mutuo, certificados e identidad de carga de trabajo

Zero trust entre servicios necesita dos cosas en cada llamada: cifrado y una identidad sólida para ambos extremos. Transport Layer Security proporciona las dos. TLS 1.3 (RFC 8446, agosto de 2018) completa su negociación (handshake) en un solo viaje de ida y vuelta: el cliente envía los algoritmos que admite y una parte de la clave (key share), el servidor responde con su parte de la clave y su certificado, y ambos derivan las claves de sesión con Diffie-Hellman efímero, de modo que cada sesión tiene secreto hacia adelante (forward secrecy): una clave de servidor robada no puede descifrar el tráfico pasado que se haya grabado. TLS 1.3 eliminó las opciones débiles de versiones anteriores, como el intercambio de claves RSA, los cifrados en modo CBC, RC4, las firmas SHA-1, la compresión y la renegociación; TLS 1.0 y 1.1 quedaron formalmente obsoletos con el RFC 8996 en 2021. Un modo opcional sin viaje de ida y vuelta (0-RTT) permite a un cliente que vuelve enviar datos de inmediato, pero un atacante puede reenviar esos datos tempranos, así que deben limitarse a solicitudes idempotentes. Los principales navegadores y proveedores de nube también han empezado a usar un intercambio de claves híbrido poscuántico que combina X25519 con ML-KEM (estandarizado por el NIST como FIPS 203 en 2024), lo que protege el tráfico grabado hoy frente a una futura computadora cuántica.

Un certificado vincula una clave pública a un nombre y está firmado por una autoridad de certificación (CA); el cliente comprueba la cadena de firmas hasta una raíz en la que ya confía. Este sistema de CA, certificados, almacenes de confianza y revocación es una infraestructura de clave pública (PKI). Los certificados públicos también se anotan en los registros de Certificate Transparency, de modo que se puede detectar un certificado emitido por error para tu dominio. El HTTPS normal solo autentica al servidor. En el TLS mutuo (mTLS), el cliente también presenta un certificado, así que el servidor sabe qué carga de trabajo está llamando. Los certificados internos proceden de una CA privada que gestiona la propia organización, normalmente dentro de su plataforma de secretos o de su malla, porque las CA públicas no emiten certificados para nombres internos.

¿Qué nombre va en el certificado? Los nombres de host y las direcciones IP son malas identidades para los contenedores. SPIFFE (Secure Production Identity Framework for Everyone, un proyecto graduado de la Cloud Native Computing Foundation) estandariza la identidad de carga de trabajo: cada carga de trabajo recibe un URI como spiffe://fooddelivery.example/ns/prod/sa/orders y un SPIFFE Verifiable Identity Document de corta duración, ya sea un certificado X.509 para mTLS o un JWT. Su implementación de referencia, SPIRE, atestigua la carga de trabajo (comprueba qué cuenta de servicio de Kubernetes o qué instancia de nube es realmente) antes de emitir el documento, y lo rota automáticamente, normalmente más o menos cada hora. Así, las reglas de autorización pueden decir Pedidos puede llamar a Pagos en lugar de nombrar direcciones.

Service meshes

Implementar mTLS, la rotación de certificados, los reintentos y la autorización por llamada dentro de cada servicio, en cada lenguaje, es caro e incoherente. Una service mesh (malla de servicios) traslada ese trabajo a la infraestructura. En el diseño clásico, cada instancia de servicio recibe un proxy sidecar (Envoy en Istio, un microproxy escrito en Rust en Linkerd) que intercepta su tráfico; un plano de control emite identidades, distribuye políticas y recopila telemetría. Los diseños más recientes sin sidecar, como el modo ambient de Istio, ponen un proxy compartido por nodo a cargo de mTLS y añaden un proxy aparte solo donde se necesita política a nivel de HTTP. NIST SP 800-207A (septiembre de 2023) describe este patrón como la forma de aplicar zero trust a las aplicaciones nativas de la nube: segmentación basada en la identidad, con políticas que la malla aplica en cada llamada.

Una malla es una decisión de plataforma importante. Añade latencia en cada salto (normalmente pequeña, pero medible en el p99), memoria por pod, un plano de control que a su vez debe tener alta disponibilidad y estar protegido, y una curva de aprendizaje para cada equipo. Además, solo protege el tráfico que pasa por ella: un job que se conecta directamente a la base de datos la esquiva. Los sistemas pequeños con un puñado de servicios suelen arreglarse mejor con mTLS proporcionado por una biblioteca o por los balanceadores de carga de la plataforma. Las preguntas decisivas son cuántos servicios y lenguajes tienes y si existe un equipo de plataforma que la opere (consulta la Sección 10.7).

Automatizar los certificados

Los certificados caducan, y los certificados caducados son una de las causas más comunes de caídas evitables. El 6 de diciembre de 2018, un certificado caducado en software de Ericsson usado por la red móvil británica O2 dejó a unos 32 millones de clientes sin servicio de datos durante la mayor parte de un día. La cura es la automatización. El protocolo ACME (Automatic Certificate Management Environment, RFC 8555, 2019), desarrollado para la autoridad de certificación Let's Encrypt, permite que el software demuestre el control de un dominio (sirviendo un token por HTTP, añadiendo un registro DNS o respondiendo a un desafío TLS), obtenga un certificado y lo renueve sin intervención de una persona. Let's Encrypt, una CA gratuita y sin ánimo de lucro que empezó a emitir certificados en 2015, convirtió en norma los certificados de corta duración renovados automáticamente; herramientas como cert-manager hacen lo mismo dentro de Kubernetes, y todos los grandes balanceadores de carga en la nube pueden gestionar los certificados por ti.

La automatización ya no es opcional. Según la votación SC-081 del CA/Browser Forum, la vida útil máxima de los certificados TLS de confianza pública bajó a 200 días para los certificados emitidos a partir del 15 de marzo de 2026, y baja a 100 días a partir del 15 de marzo de 2027 y a 47 días a partir del 15 de marzo de 2029. Las vidas útiles cortas limitan el daño de una clave robada y reducen la dependencia de la revocación, que siempre ha funcionado mal. En términos de arquitectura, esto significa que cada certificado, público o interno, necesita un propietario, renovación automatizada, monitorización de las fechas de caducidad con alertas mucho antes del plazo y un procedimiento manual alternativo ensayado.

Segmentación y microsegmentación

Zero trust no significa que la red ya no importe; significa que la red ya no es el único control. La segmentación de red divide la infraestructura en zonas con caminos controlados entre ellas: subredes públicas para los balanceadores de carga, subredes privadas para los servicios, subredes aisladas para las bases de datos y cuentas de nube separadas para producción, preproducción y herramientas de seguridad. La microsegmentación reduce las zonas a cargas de trabajo individuales, de modo que cada servicio solo puede recibir tráfico de los llamadores que necesita y solo puede enviar tráfico a sus dependencias declaradas.

En Kubernetes, todos los pods pueden llegar a todos los demás pods salvo que los recursos NetworkPolicy lo restrinjan, así que el primer paso es una política de denegación por defecto por namespace, seguida de permisos explícitos. El control del tráfico de salida (egress) es tan importante como el de entrada (ingress): un servicio comprometido que no puede abrir conexiones hacia internet no puede sacar fácilmente datos robados ni descargar más herramientas. Los grupos de seguridad de la nube, las políticas de red de Kubernetes y las políticas de autorización de la malla trabajan en capas distintas (direcciones y puertos, pods y etiquetas, identidades de carga de trabajo y métodos HTTP) y lo mejor es usarlas juntas: las capas exteriores dan una protección gruesa que sobrevive a un error de configuración de la malla, y la capa interior expresa la intención con precisión. Esto es la defensa en profundidad (Sección 8.1) aplicada a la red.

Proteger el API gateway

El API gateway es el principal punto de aplicación entre internet y los servicios, así que asume varias funciones. Autenticación: termina TLS y luego valida cada token de acceso (firma con un algoritmo fijado, emisor, audiencia, caducidad y momento de validez inicial), rechaza las solicitudes que no lo traen y pasa a los servicios una identidad verificada, nunca las afirmaciones en bruto del cliente. Limitación de tasa (rate limiting): limita las solicitudes por cliente, por usuario y por ruta, normalmente con un token bucket, respondiendo HTTP 429 con una cabecera Retry-After; límites separados y más estrictos protegen el inicio de sesión, el restablecimiento de contraseña y el canje de cupones frente al relleno de credenciales (credential stuffing) y la enumeración. Validación de la entrada: impone tamaños máximos de solicitud y de número de cabeceras, acepta solo los tipos de contenido declarados y valida los cuerpos frente al esquema OpenAPI para que las solicitudes mal formadas nunca lleguen a un servicio. Un firewall de aplicaciones web puede añadir firmas de ataques genéricas, pero es un complemento, no un sustituto de un código correcto.

Conoce lo que un gateway no puede hacer. Ve la ruta y el token, pero no si el pedido 81723 pertenece al cliente que lo pide. La autorización rota a nivel de objeto (broken object level authorisation), en la que un usuario cambia un identificador en la URL y lee los datos de otra persona, ocupó el primer puesto del OWASP API Security Top 10 tanto en su edición de 2019 como en la de 2023, y solo el servicio propietario de los datos puede impedirla. Por tanto, los servicios deben autorizar ellos mismos cada solicitud, usando la identidad verificada que reenvía el gateway. Cuando un servicio llama a otro en nombre de un usuario, debe pasar un token que nombre tanto al usuario como al servicio que llama, obtenido por ejemplo mediante el intercambio de tokens de OAuth 2.0 (RFC 8693), en lugar de su propia credencial todopoderosa; de lo contrario, un bug en un servicio lo convierte en un delegado confundido (confused deputy) que puede actuar en nombre de cualquiera.