La mayoría de las redes empresariales siguen operando bajo una premisa fundamental: todo lo que está dentro del perímetro es de confianza. Esa premisa colapsó hace años, y NIS2 y DORA han codificado su reemplazo en la ley. El acceso de red de confianza cero (ZTNA) ya no es una aspiración arquitectónica: para las empresas europeas de finanzas, energía, sanidad e infraestructuras críticas, es la base de cumplimiento normativo. La pregunta no es si implementarlo, sino cómo hacerlo sobre una infraestructura que cumpla realmente con los requisitos de soberanía europea.
Esta guía recorre las decisiones de arquitectura que importan en la práctica, los compromisos que el marketing de los proveedores suele omitir, y en qué se diferencia la implementación de ZTNA sobre infraestructura cloud soberana europea del manual genérico de los grandes proveedores de nube.
Qué significa ZTNA realmente, y qué no significa
NIST SP 800-207 define la confianza cero como «un conjunto evolutivo de paradigmas de ciberseguridad que desplazan las defensas desde los perímetros estáticos basados en la red hacia los usuarios, los activos y los recursos». Zero Trust Architecture (ZTA) es el marco general; Zero Trust Network Access (ZTNA) es la aplicación de esos principios en la capa de red, concretamente la aplicación del control de acceso basado en identidad para cada conexión a cada recurso.
La distinción importa porque ZTNA no es un producto que se compra. Es un conjunto de decisiones arquitectónicas: dónde se aplica la política, cómo se evalúa la confianza de forma continua, con qué granularidad se segmenta la red y cómo se gestiona el acceso privilegiado. Un proveedor que vende una «solución de confianza cero» está vendiendo un componente de esa arquitectura, no la arquitectura en sí.
Los cuatro principios que deben guiar cada decisión son: nunca confiar, siempre verificar (cada solicitud se trata como si procediera de una red no confiable, independientemente del origen); acceso de mínimo privilegio (los usuarios y sistemas obtienen solo lo que necesitan para la tarea concreta, en el contexto específico y en ese momento preciso); microsegmentación (los segmentos de red son tan granulares como sea operativamente viable, limitando el movimiento lateral cuando se produce una brecha); y monitorización y validación continuas (la confianza se evalúa de forma continua, sin asumir que persiste tras la autenticación inicial).
El umbral regulatorio: requisitos de NIS2 y DORA para el control de acceso
El artículo 21 de NIS2 exige medidas de control de acceso que incluyen la autenticación multifactor para todas las entidades en su ámbito de aplicación. La directiva nombra explícitamente la MFA y las soluciones de autenticación continua como requisitos, y aborda directamente la prevención del movimiento lateral como parte de sus medidas técnicas y organizativas. Las sanciones para las entidades esenciales alcanzan los 10 millones de euros o el 2 % de la facturación anual global. La directiva entró en aplicación en octubre de 2024, aunque la transposición sigue incompleta en varios estados miembros, incluidos Alemania y Francia.
DORA, que entró en aplicación el 17 de enero de 2025, va más lejos para las entidades financieras. El artículo 9 exige políticas de seguridad de la información documentadas, controles de acceso, autenticación robusta para el acceso remoto y privilegiado, y gestión de parches. El artículo 10 exige detección de anomalías y monitorización del comportamiento de los usuarios. Las Normas Técnicas de Regulación de DORA requieren autenticación robusta para cualquier acceso a activos de TIC que soporten funciones críticas o sistemas accesibles públicamente. DORA opera como lex specialis para los servicios financieros, por lo que las entidades financieras que cumplen con DORA satisfacen simultáneamente las obligaciones de seguridad TIC de NIS2.
La arquitectura que satisface NIS2 y DORA no es una capa de cumplimiento superpuesta a tu red existente. Es una red rediseñada desde la premisa de que el perímetro no existe.
En la práctica, ambas regulaciones apuntan al mismo conjunto de controles técnicos: MFA en todos los accesos, mínimo privilegio aplicado a nivel de recurso, microsegmentación para contener el movimiento lateral, monitorización continua del comportamiento de usuarios y sistemas, y gestión del acceso privilegiado para funciones administrativas.
Decisiones clave de arquitectura
La identidad como plano de control
En una arquitectura ZTNA, la identidad reemplaza a la ubicación en la red como señal de confianza principal. Cada solicitud de acceso lleva contexto de identidad: quién solicita, desde qué dispositivo, en qué estado, para qué recurso y bajo qué condiciones. Tu proveedor de identidad se convierte en infraestructura crítica, no en una conveniencia de autenticación.
Esto tiene implicaciones concretas. Tu IdP necesita alta disponibilidad en las regiones donde se ejecutan tus cargas de trabajo. Debe integrarse con tu capa de IAM en la nube, tu directorio local y tu plataforma de gestión de endpoints. El inicio de sesión único no es opcional: es el mecanismo que hace que la autenticación continua sea operativamente sostenible. Gestionamos SSO e IAM como un producto administrado precisamente porque la infraestructura de identidad añadida a posteriori genera las brechas que ZTNA está diseñado para cerrar.
Microsegmentación: aquí está el trabajo real
La microsegmentación es la parte más intensiva en trabajo de cualquier implementación ZTNA, y la que con más frecuencia se subestima. El objetivo es reducir el radio de impacto de una credencial o carga de trabajo comprometida, garantizando que el movimiento lateral entre segmentos requiera autorización explícita, no solo alcanzabilidad de red.
En infraestructura cloud, la microsegmentación se implementa simultáneamente en varias capas:
- Capa de red: grupos de seguridad y listas de control de acceso de red aplicadas en el hipervisor, no en un firewall perimetral. El tráfico entre cargas de trabajo en la misma red virtual debe denegarse por defecto y permitirse solo mediante reglas explícitas.
- Capa de aplicación: mallas de servicios o proxies con reconocimiento de aplicación que aplican la política basándose en la identidad del servicio, no en la dirección IP. Las reglas basadas en IP no sobreviven a la orquestación de contenedores a escala.
- Capa de datos: cifrado en reposo y en tránsito, con gestión de claves separada de la carga de trabajo. AES-256 para datos en reposo, TLS 1.3 para datos en tránsito, y gestión centralizada de claves que no resida en la misma infraestructura que los datos que protege.
El compromiso operativo es real: una segmentación más granular implica más superficie de política que gestionar. Empieza por tus activos más críticos, mapea sus rutas de comunicación legítimas y aplica denegación por defecto. Expande hacia afuera. Intentar microsegmentar todo simultáneamente es la razón por la que los proyectos ZTNA se estancan.
Reemplazo de VPN frente a complemento de VPN
ZTNA se presenta habitualmente como un sustituto de la VPN. La realidad es más matizada. Las VPN otorgan acceso a nivel de red; ZTNA otorga acceso a nivel de aplicación basándose en identidad y contexto. Para la mayoría de las empresas, un enfoque por fases funciona mejor: ZTNA para el acceso a aplicaciones, con VPN retenida solo para sistemas heredados que no pueden soportar la aplicación de políticas en la capa de aplicación, y una hoja de ruta para eliminar esas dependencias.
La diferencia práctica importa especialmente para las entidades reguladas por DORA. Las RTS de DORA exigen autenticación robusta para el acceso remoto a la red de la entidad financiera. Una VPN con MFA satisface el requisito de autenticación, pero no hace nada respecto al movimiento lateral una vez establecido el túnel. ZTNA con control de acceso por aplicación satisface tanto el requisito de autenticación como el de contención.
La infraestructura soberana como requisito de arquitectura, no como casilla de cumplimiento
ZTNA sobre infraestructura sujeta a jurisdicción no europea crea un problema estructural. Tu plano de identidad, tus puntos de aplicación de políticas y tus datos de monitorización son todos sensibles. Si el plano de control de tu proveedor ZTNA se encuentra fuera de Europa, o si tu proveedor de nube está sujeto a órdenes de acceso de gobiernos extranjeros, tu arquitectura de confianza cero tiene un límite de confianza que no diseñaste.
Operamos nuestra infraestructura en MAD1 en Madrid, MUC1 en Múnich y HEL1 en Helsinki, todas bajo legislación europea, sin empresa matriz extranjera. Nuestro peering directo con AWS, Azure, GCP y Cloudflare en todos los sitios significa que las arquitecturas híbridas, donde algunas cargas de trabajo permanecen en los grandes proveedores de nube durante la migración, no requieren que el tráfico salga de la infraestructura europea para alcanzar los puntos de aplicación de políticas europeos. El plano de política y el plano de datos permanecen en el mismo lado del Atlántico.
Para los equipos de finanzas e infraestructuras críticas que implementan ZTNA bajo DORA y NIS2, esto no es un argumento de marketing. Es un requisito de arquitectura que determina si tu modelo de control de acceso está realmente cerrado.
Secuencia de implementación que funciona
- Inventaría tus rutas de acceso. No puedes aplicar el mínimo privilegio sobre rutas de acceso que no has mapeado. Empieza por el acceso privilegiado y el acceso remoto a sistemas críticos.
- Aplica MFA de forma universal. Este es el mínimo exigido por NIS2 y DORA, y la base sobre la que se construye todo lo demás.
- Despliega proxies con reconocimiento de identidad para las aplicaciones críticas. Reemplaza el acceso directo a la red por control de acceso a nivel de aplicación para tus sistemas de mayor riesgo primero.
- Implementa segmentación de denegación por defecto para las cargas de trabajo críticas. Mapea el tráfico legítimo, escribe reglas de permiso explícitas, aplica denegación por defecto y monitoriza las infracciones.
- Instrumenta todo para la monitorización continua. El artículo 10 de DORA exige detección de anomalías y monitorización del comportamiento de los usuarios. Tu segmentación y control de acceso generan los eventos; tu SIEM necesita consumirlos.
La confianza cero no es un estado que se alcanza. Es una postura operativa que se mantiene. Las decisiones de arquitectura anteriores crean las condiciones para ello; la monitorización y la iteración la sostienen.
