Cómo funciona Zero Trust Network Access
Zero Trust Network Access (ZTNA) es un enfoque arquitectónico para controlar cómo usuarios y dispositivos acceden a aplicaciones y otros recursos protegidos.
La idea central es sencilla:
El acceso debe autorizarse explícitamente para el recurso solicitado, en lugar de inferirse de la ubicación de red o del hecho de que un usuario ya se haya conectado a una red privada.
Por tanto, ZTNA no es un único protocolo, una única arquitectura de producto ni un único modelo de despliegue. Cada proveedor lo implementa de manera diferente.
El flujo de decisión ZTNA
Un modelo lógico útil es:
Los detalles varían según el producto, pero estas responsabilidades capturan el patrón central de ZTNA.
1. Identificar al solicitante
Antes de autorizar el acceso, el sistema necesita saber quién —o qué— lo está solicitando.
Para un usuario humano, la identidad puede proceder de:
- un proveedor de identidad OIDC
- un directorio empresarial
- registros de identidad locales
- otros sistemas de autenticación
Identidad no es lo mismo que autorización. Demostrar correctamente quién es un usuario no debería concederle automáticamente acceso a todos los recursos privados.
2. Identificar el dispositivo
Un usuario puede tener varios endpoints, y esos endpoints no tienen necesariamente el mismo estado de seguridad.
Un sistema ZTNA puede seguir el dispositivo por separado del usuario mediante:
- registro de dispositivos
- certificados o claves de dispositivo
- identificadores de dispositivos gestionados
- señales MDM
- señales EDR
- comprobaciones del sistema operativo o de postura
El resultado es una decisión de política capaz de distinguir, por ejemplo, entre un portátil corporativo registrado y un endpoint desconocido del mismo usuario.
3. Recopilar contexto
Identidad y dispositivo son importantes, pero la política puede incluir contexto adicional:
- recurso solicitado
- rol o grupo
- postura del dispositivo
- ubicación
- hora
- duración del acceso
- aprobación previa
- autenticación adicional requerida
Un producto no necesita todas las señales posibles para considerarse ZTNA. Lo importante es que el acceso sea explícito y esté gobernado por políticas, en lugar de concederse automáticamente porque el endpoint está “dentro”.
4. Tomar una decisión de política
El motor de políticas responde a una pregunta como:
¿Está este usuario, en este dispositivo, autorizado para acceder a este recurso bajo las condiciones actuales?
La decisión debe ser lo suficientemente precisa como para expresar directamente la relación de acceso prevista.
Por ejemplo:
- desarrolladores → servidores de desarrollo
- finanzas → aplicación de contabilidad
- proveedor → un portal de mantenimiento hasta el viernes
- administrador → consola de producción solo después de aprobación
Esto es diferente de simplemente admitir un endpoint en una red y depender después de controles aguas abajo para limitar el acceso.
5. Aplicar la decisión
ZTNA requiere un punto de aplicación entre el solicitante y el recurso.
Los modelos habituales incluyen:
Cliente y gateway / conector
Un cliente en el endpoint establece conectividad segura a través de un gateway, conector o componente de aplicación similar.
Este modelo funciona bien para protocolos que necesitan conectividad a nivel de red.
Proxy sin cliente
Para aplicaciones basadas en navegador, un proxy HTTP/HTTPS puede autenticar y autorizar al usuario sin instalar software de túnel en el endpoint.
El proxy se convierte en el punto de aplicación entre el navegador y la aplicación protegida.
Redes orientadas a pares
Algunos productos utilizan redes peer-to-peer coordinadas, con una política central que distribuye los permisos necesarios para que los pares se comuniquen.
Todos son enfoques arquitectónicos válidos si el acceso a los recursos permanece explícitamente autorizado.
6. Limitar el alcance del acceso
El propósito de ZTNA no es únicamente el cifrado.
El transporte cifrado protege el tráfico en tránsito. ZTNA también debe responder a qué puede acceder el solicitante autenticado.
Una política limitada a recursos concretos puede reducir la exposición innecesaria y el movimiento lateral frente a conceder una amplia accesibilidad de red.
Esto no elimina la necesidad de segmentación de red ni de controles a nivel de host. Ambos siguen siendo medidas útiles de defensa en profundidad.
7. Reevaluar el acceso
Las condiciones pueden cambiar después de que comience el acceso.
Por ejemplo:
- caduca una ventana de acceso temporal
- se deshabilita una cuenta
- un dispositivo deja de tener una postura aceptable
- cambia una asignación de rol o grupo
- un administrador revoca una aprobación
Una arquitectura ZTNA debe poder reaccionar a cambios relevantes de política en lugar de asumir que una conexión inicial válida seguirá siendo válida indefinidamente.
8. Registrar lo ocurrido
Las decisiones de acceso también son eventos de seguridad.
Los registros útiles pueden incluir:
- identidad
- dispositivo
- recurso solicitado
- evento de autenticación
- resultado de política
- hora de acceso
- revocación o denegación
Estos registros pueden respaldar investigaciones, revisiones de acceso, resolución de problemas e integración con flujos SIEM.
ZTNA no es solo MFA
La autenticación multifactor refuerza la autenticación, pero la autenticación por sí sola no define la autorización de recursos.
Un usuario puede superar MFA y seguir sin estar autorizado para una aplicación concreta.
ZTNA combina autenticación con políticas de recursos y otro contexto.
ZTNA no es solo un protocolo VPN
WireGuard, IPsec y TLS pueden proporcionar transporte seguro en distintas arquitecturas.
Un túnel seguro no conoce el rol empresarial de un empleado, si un dispositivo cumple las políticas, si el acceso fue aprobado durante 30 minutos o si la aplicación solicitada queda fuera de la política del usuario.
Esas son cuestiones de autorización gestionadas por el sistema de acceso circundante.
Descubra cómo encaja WireGuard en ZTNA
Plano de control frente a plano de datos
Comprender esta distinción ayuda al comparar productos ZTNA.
Plano de control
El plano de control suele gestionar responsabilidades como:
- configuración
- identidades y grupos
- definiciones de recursos
- políticas
- coordinación de claves o autorizaciones
- flujos administrativos
Plano de datos
El plano de datos transporta o hace proxy del tráfico real de las aplicaciones.
Algunos proveedores operan ambas capas como servicio en la nube. Otros operan el plano de control en la nube mientras los clientes despliegan conectores. Algunos productos permiten autoalojar toda la plataforma de acceso o funcionar sin una dependencia obligatoria de la nube del proveedor.
La expresión “ZTNA” por sí sola no indica qué modelo utiliza un producto.
Compare ZTNA autoalojado y suministrado desde la nube
Modelos habituales de despliegue ZTNA
Suministrado desde la nube
El proveedor opera el servicio de control y suele proporcionar infraestructura de aplicación distribuida globalmente.
Plano de control del proveedor + conectores del cliente
El proveedor opera servicios de política/coordinación mientras el cliente despliega conectores o gateways cerca de las aplicaciones privadas.
Autoalojado
El cliente o MSP opera la infraestructura principal de gestión y aplicación.
Independiente / desconectado
El sistema de acceso puede seguir funcionando sin un servicio de control obligatorio alojado por el proveedor y puede desplegarse de forma permanente dentro de un entorno aislado.
Cada modelo presenta compensaciones distintas en operación, disponibilidad, control de datos y dependencia de Internet.
Dónde encaja ZTXGate
ZTXGate utiliza una plataforma de acceso operada por el cliente o MSP.
Su ruta de acceso gestionado utiliza transporte basado en WireGuard, mientras que el acceso sin cliente licenciado puede hacer proxy de aplicaciones HTTP/HTTPS compatibles. Identidad, dispositivo, recurso, postura, tiempo, estado de aprobación y requisitos de autenticación adicional pueden contribuir a la política de acceso.
ZTXGate puede funcionar de forma independiente sin un plano de control en la nube obligatorio alojado por CoreZT, incluso en entornos aislados. Los despliegues conectados pueden utilizar opcionalmente ZTXHub, operado por CoreZT, para gestión centralizada de licencias y actualizaciones de software.
Explorar la arquitectura de ZTXGate · Explorar ZTXGate