ZTNA vs VPN: Acceso a la Red de Confianza Cero Explicado

Comparativa técnica: ZTNA frente a VPN

Panorama de proveedores y herramientas relevantes

El mercado de ZTNA se consolida en torno a tres grandes categorías de proveedores, todos compatibles con entornos de nube pública y con integraciones nativas en los principales hiperescalares:

• Plataformas SASE integradas: soluciones que combinan ZTNA con Secure Web Gateway (SWG), Cloud Access Security Broker (CASB) y SD-WAN en una arquitectura unificada. Son idóneas para organizaciones que quieren consolidar proveedores.
• Soluciones ZTNA independientes: más adecuadas para empresas que ya tienen inversiones en SD-WAN o firewall y solo necesitan modernizar la capa de acceso remoto.
• ZTNA nativo de nube pública: AWS Verified Access, por ejemplo, permite definir políticas de acceso por aplicación usando AWS IAM Identity Center y señales de postura del dispositivo, sin necesidad de agentes de terceros en instancias EC2 o contenedores en Amazon EKS.

En el plano de la automatización de políticas, herramientas como Terraform permiten gestionar las reglas ZTNA como código, integrándolas en pipelines de CI/CD. La monitorización continua de comportamiento anómalo puede complementarse con servicios como AWS GuardDuty o Microsoft Sentinel, que correlacionan eventos de acceso ZTNA con amenazas detectadas en la nube. Para entornos Kubernetes, la segmentación de red a nivel de pod mediante Network Policies nativas —y su refuerzo con mallas de servicio como Istio— actúa como una capa ZTNA interna, especialmente relevante en clústeres gestionados por ingenieros con certificaciones CKA/CKAD.

Casos de uso y cuándo elegir cada solución

Cuándo ZTNA es la elección correcta

ZTNA resulta superior en los siguientes escenarios:

• Acceso de terceros y contratistas: permite otorgar acceso granular a una única aplicación sin exponer el resto de la red, reduciendo el riesgo de movimiento lateral en caso de credenciales comprometidas.
• Entornos multi-cloud y SaaS: cuando las aplicaciones están distribuidas en AWS, Azure y Google Cloud, ZTNA elimina el cuello de botella del concentrador VPN y reduce la latencia significativamente.
• Cumplimiento regulatorio en España y la UE: la trazabilidad por sesión que ofrece ZTNA simplifica la demostración de conformidad ante auditorías de ENS (categorías Media y Alta), RGPD y los controles técnicos exigidos por NIS2 a operadores de servicios esenciales.
• Equipos remotos permanentes: la verificación continua del dispositivo garantiza que un portátil comprometido no mantenga el acceso aunque la sesión inicial fuera legítima.

Cuándo la VPN sigue siendo válida

La VPN mantiene su relevancia en casos concretos: acceso a sistemas legacy que requieren conectividad a nivel de red (por ejemplo, aplicaciones que dependen de rangos IP en lugar de nombres de host), entornos industriales (OT/ICS) con restricciones de dispositivo extremas, o como capa de transición durante una migración progresiva hacia ZTNA. No obstante, incluso en estos casos es recomendable segmentar la VPN al máximo y complementarla con controles adicionales.

Criterios de evaluación y errores frecuentes en la adopción

Criterios de evaluación

Antes de seleccionar una solución ZTNA, los equipos de seguridad deben evaluar los siguientes factores:

• Integración con el proveedor de identidad (IdP) existente: compatibilidad con Azure AD / Microsoft Entra ID, Okta u otros directorios corporativos mediante SAML 2.0 u OIDC.
• Evaluación de postura del dispositivo: capacidad para verificar en tiempo real si el dispositivo cumple las políticas de seguridad (parches, antivirus, cifrado de disco).
• Soporte para aplicaciones legacy: el modelo service-initiated es clave para aplicaciones que no pueden modificarse para soportar autenticación moderna.
• Registro y auditoría: los logs deben ser suficientemente granulares para cumplir los requisitos de retención del RGPD y del ENS.
• Modelo de despliegue: SaaS gestionado, nube privada o híbrido, según los requisitos de soberanía de datos aplicables en el sector.

Errores frecuentes en la adopción

La experiencia acumulada en más de 3.000 proyectos desde 2022 permite a Opsio identificar los patrones de error más habituales:

• Migrar sin inventario de aplicaciones: desplegar ZTNA sin un mapa completo de aplicaciones y sus dependencias de red genera interrupciones de servicio y políticas incompletas.
• Ignorar el dispositivo no gestionado: muchas organizaciones olvidan definir una política para dispositivos BYOD o de contratistas, creando un hueco de seguridad justo donde más se necesita control.
• Asumir que ZTNA es solo una capa de red: ZTNA es un modelo arquitectónico que requiere alinear identidad, dispositivo, aplicación y datos. Tratarlo como un sustituto directo de la VPN sin rediseñar las políticas es el error más costoso.
• No integrar la telemetría en el SIEM: sin enviar los eventos ZTNA a Microsoft Sentinel o al SIEM corporativo, la capacidad de detección y respuesta queda fragmentada.
• Desestimar la formación del equipo: los operadores deben entender el modelo de confianza cero para gestionar excepciones y alertas correctamente; la tecnología por sí sola no es suficiente.

Cómo Opsio acompaña la migración de VPN a ZTNA

Opsio es un socio de servicios gestionados en la nube con presencia en Karlstad (Suecia, sede central) y Bangalore (India, centro de entrega). Como AWS Advanced Tier Services Partner con AWS Migration Competency, Microsoft Partner y Google Cloud Partner, Opsio cubre las tres nubes principales en las que suelen distribuirse las aplicaciones de las organizaciones que migran de VPN a ZTNA.

El equipo de más de 50 ingenieros certificados, incluyendo especialistas con certificaciones CKA y CKAD, diseña la arquitectura ZTNA como código desde el primer día. Esto significa que las políticas de acceso se definen en Terraform, se versionan en Git y se despliegan mediante pipelines reproducibles, eliminando la deriva de configuración que suele afectar a los entornos VPN gestionados manualmente.

El NOC 24/7 de Opsio monitoriza la disponibilidad y el comportamiento de las políticas ZTNA en tiempo real, con un SLA de disponibilidad del 99,9 %. Las alertas de acceso anómalo generadas por AWS GuardDuty o Microsoft Sentinel se correlacionan con el contexto ZTNA para acelerar la respuesta ante incidentes. Para cargas de trabajo en Kubernetes, los ingenieros de Opsio implementan segmentación de red a nivel de pod complementaria a la capa ZTNA perimetral, aplicando Network Policies y, cuando el entorno lo requiere, mallas de servicio con mTLS.

En lo relativo al cumplimiento normativo, la oficina de Bangalore cuenta con certificación ISO 27001, lo que refuerza los procesos de gestión de la seguridad de la información que Opsio aplica en los proyectos de sus clientes. Aunque Opsio no es titular de SOC 2 propio, sí dispone de la experiencia y los marcos de control necesarios para ayudar a los clientes a alcanzar la conformidad SOC 2, así como a cumplir los requisitos técnicos del RGPD, el ENS y la Directiva NIS2.

El proceso de migración de Opsio sigue tres fases diferenciadas:

• Descubrimiento y diseño: inventario de aplicaciones, flujos de tráfico actuales y diseño de la arquitectura de identidad y acceso objetivo.
• Despliegue progresivo: coexistencia de VPN y ZTNA durante la transición, con validación de políticas aplicación por aplicación antes de retirar el acceso VPN correspondiente.
• Operación y mejora continua: gestión del ciclo de vida de las políticas, incorporación de nuevas aplicaciones al modelo ZTNA y revisión periódica de accesos conforme a los principios de mínimo privilegio.

Para las organizaciones en España que operan bajo el ENS o que forman parte del tejido de operadores esenciales regulados por NIS2, Opsio aporta tanto la capacidad técnica de implementación como el conocimiento del marco normativo europeo necesario para que la modernización del acceso remoto no se convierta en un riesgo regulatorio adicional.