ZTNA local para aplicaciones privadas

El ZTNA local es una implementación de « zero trust network access » en la que el punto de aplicación de políticas para aplicaciones privadas se ejecuta en la infraestructura situada dentro de los propios centros de datos y sucursales de la organización. Los usuarios y los sistemas se autentican y autorizan por aplicación, al igual que en cualquier ZTNA, pero el tráfico entre los usuarios locales y las aplicaciones locales no tiene que desplazarse hasta la nube del proveedor y volver.

Este artículo forma parte de la guía sobre seguridad en la nube híbrida.

Cómo funciona el ZTNA

ZTNA verifica la identidad, el dispositivo y el contexto de cada usuario y, a continuación, lo conecta a una única aplicación en lugar de a una red.

La arquitectura «zero trust» del NIST, la norma SP 800-207, separa el punto de decisión de políticas (que determina si un sujeto puede acceder a un recurso) del punto de aplicación de políticas (que habilita, supervisa y da por terminada la conexión). Los productos ZTNA aplican ese modelo a las aplicaciones privadas:

1. Un usuario o un sistema solicita acceso a una aplicación.
2. La solicitud llega a un punto de ejecución, que suele ser una pasarela, un intermediario o un proxy.
3. La política evalúa la identidad, el grupo, el estado del dispositivo, la ubicación, el riesgo y la aplicación específica solicitada.
4. Si se permite, el punto de aplicación conecta al usuario únicamente con dicha aplicación. El resto de la red permanece invisible.
5. La sesión está supervisada y puede interrumpirse si cambian las condiciones.

La guía práctica SP 1800-35 del NIST , titulada «Implementación de una arquitectura de confianza cero», publicada en junio de 2025, recoge 19 ejemplos de implementación realizados con 24 proveedores en entornos tanto locales como en la nube, y constituye una referencia útil sobre cómo encajan estos componentes en la práctica.

ZTNA gestionado en la nube frente a ZTNA local

La diferencia radica en dónde se lleva a cabo el control: en la nube del proveedor para todas las sesiones, o en las propias pasarelas del cliente para las sesiones locales.

En un modelo típico de intermediación en la nube, una máquina virtual de conexión ligera se ejecuta junto a la aplicación y abre un túnel de salida hacia la pasarela del proveedor, por lo que no se necesitan puertos de entrada en el cortafuegos. Skyhigh Private Access funciona de esta manera para el acceso remoto: el tráfico del cliente se gestiona en el punto de presencia de SSE y se enruta a través de túneles TLS hacia conectores desplegados en el mismo centro de datos, nube privada o nube pública que la aplicación.

El ZTNA local añade una vía de aplicación local para que los usuarios y los sistemas que se encuentran dentro de la red dispongan del mismo control por aplicación sin necesidad de salir del edificio.

Por qué es importante la aplicación de la ley a nivel local

La aplicación local evita el «hairpinning», llega al tráfico interno y al de los agentes de IA, y sigue funcionando durante las interrupciones del servicio en la nube.

Ruta en bucle. Enviar el tráfico de un usuario de oficina a un intermediario en la nube y de vuelta a un servidor situado al final del pasillo aumenta la latencia y la dependencia de Internet sin aportar ningún beneficio en materia de seguridad.

Tráfico interno. Gran parte del tráfico que debería regular el modelo «zero trust» nunca traspasa el perímetro de Internet: sesiones de administración, llamadas entre aplicaciones y acceso de ingeniería de tecnología operativa (OT). La aplicación exclusiva en la nube no lo detecta.

Agentes de IA y cuentas de servicio. Los agentes autónomos y las cuentas de servicio pueden disponer de acceso a nivel de usuario y transferir datos entre sistemas internos a la velocidad de una máquina. Skyhigh sostiene que el control de estos flujos debe realizarse dentro de la red en la que se origina el tráfico (Skyhigh Security).

Continuidad. Si se produce un fallo en la nube del proveedor o en la conexión a Internet, las sesiones locales continúan según la política aplicada localmente. Confirme con su proveedor el intervalo de desconexión admitido y el comportamiento de las comprobaciones de estado de seguridad e identidad.

Soberanía. El tráfico de aplicaciones locales puede permanecer en la infraestructura del cliente. Registre dónde se procesan y almacenan las decisiones relativas a las políticas, las comprobaciones de identidad y los metadatos de las sesiones. Cuando una sesión de Skyhigh requiera protección de datos aplicada en la nube, el contenido pertinente se reenvía a la nube de Skyhigh para su inspección con arreglo a la misma política.

Controles de identidad

El ZTNA local debe aplicar el mismo rigor en materia de identidad que el acceso remoto:

• Autenticación a través del proveedor de identidad de la empresa con autenticación multifactorial (MFA) resistente al phishing
• Estado del dispositivo: estado de gestión, versión del sistema operativo, cifrado del disco, protección de terminales
• Grupo y rol, asignados a los derechos por aplicación
• Contexto: ubicación, hora y puntuación de riesgo derivada del análisis del comportamiento
• Carga de trabajo e identidad del agente para el acceso no humano
• Evaluación continua, con interrupción de la sesión en caso de cambios en la postura o en los factores de riesgo

Una deficiencia habitual consiste en eximir a los usuarios que se encuentran en las instalaciones de las comprobaciones del estado de los dispositivos. El mero hecho de estar conectado a la red LAN de la empresa no constituye un estado de seguridad.

Ubicación de los conectores y las pasarelas

Coloque las puertas de enlace cerca de las aplicaciones que protegen, en grupos redundantes, con segmentación a su alrededor.

• Coloque las puertas de enlace cerca de las aplicaciones que protegen, en el mismo segmento o en uno adyacente, de modo que solo se pueda acceder a la aplicación protegida a través de la puerta de enlace.
• Implemente en grupos para garantizar la capacidad y la disponibilidad, y asocie las aplicaciones a grupos en lugar de a puertas de enlace individuales.
• Mantenga la conectividad exclusivamente de salida para las rutas gestionadas a través de la nube, de modo que las aplicaciones no queden expuestas a conexiones entrantes.
• Utilice la segmentación de red gestionada por el cliente para impedir que una pasarela comprometida acceda a sistemas no relacionados.
• Planifique las sucursales. Decida si cada sucursal contará con una pasarela local o si se conectará a una regional.

Rutas de acceso locales

Un diseño híbrido de ZTNA requiere tres vías de acceso explícitas, todas ellas reguladas por una única política:

1. De usuario local a aplicación local: pasarela local, sin tráfico de ida y vuelta a la nube.
2. De un usuario remoto a una aplicación in situ: de un intermediario en la nube a un conector o pasarela local.
3. De una aplicación local a una aplicación alojada en la nube: pasarela local o intermediario en la nube hacia un conector en el entorno de la nube.

Los tres deberían utilizar una única definición de política, de modo que los derechos de un usuario no varíen en función de su ubicación.

Un ejemplo de arquitectura de confianza cero para la nube híbrida

Una arquitectura híbrida de «zero trust» combina la aplicación de medidas de seguridad tanto a nivel local como en la nube bajo una única capa de identidad y políticas, tal y como muestra este ejemplo.

Imaginemos una empresa de servicios financieros que cuenta con un centro de datos en la sede central, 40 sucursales, un entorno IaaS y una plantilla que trabaja a distancia.

• Identidad: un proveedor de identidad con autenticación multifactorial (MFA); estado del dispositivo a través de la gestión de terminales.
• Sede central: Las pasarelas locales de ZTNA actúan como interfaz para las interfaces de administración del sistema bancario central y las herramientas internas. El personal de la sede se conecta directamente a través de la pasarela local.
• Sucursales: Las pasarelas de las sucursales controlan el acceso a los sistemas de las sucursales y redirigen el tráfico a las pasarelas de la sede central para las aplicaciones centrales.
• IaaS: Los conectores del entorno en la nube actúan como interfaz para las cargas de trabajo; los usuarios, tanto remotos como in situ, acceden a ellas a través del intermediario correspondiente.
• Personal remoto: los puntos de presencia en la nube facilitan el acceso tanto al centro de datos como a las aplicaciones IaaS.
• Agentes de IA: Las identidades de servicio de los asistentes de IA internos reciben derechos específicos para cada aplicación, que se aplican de forma local.
• Política: Un único conjunto de normas rige todas las rutas, gestionadas desde una única consola.

En caso de que falle la conexión a Internet, el personal de la sede central y de las sucursales seguirá trabajando con las aplicaciones locales, y la aplicación de la normativa a nivel local continuará durante el periodo de desconexión admitido.

Requisitos de implementación que deben evaluarse

Evalúe las soluciones ZTNA locales en función de estos requisitos antes de preseleccionar a los proveedores.

• Ejecución local para usuarios in situ sin «hairpinning» en la nube
• La misma política y los mismos derechos para las rutas locales y remotas
• Aplicación de las normas de configuración de dispositivos para los usuarios presenciales
• Compatibilidad con identidades no humanas y agentes de inteligencia artificial
• Protocolos cubiertos: web, SSH, RDP, bases de datos y TCP/UDP heredados
• Alta disponibilidad y grupos de conectores
• Comportamiento definido cuando no se puede acceder a la nube del proveedor o al proveedor de identidad
• Registro de la ubicación e integración con SIEM
• Integración con la pasarela web y el sistema DLP para garantizar la protección de los datos en las sesiones de aplicaciones privadas

Software de arquitectura «zero trust» para la nube híbrida

ZTNA es uno de los componentes de una arquitectura híbrida de «zero trust».

Funciona en combinación con proveedores de identidad, gestión de terminales, pasarelas web, CASB, DLP y segmentación. Evalúe el ZTNA como parte de la plataforma que se encargará de hacer cumplir el resto de su política, y no como un sustituto independiente de la VPN. Consulte «Soluciones de seguridad para la nube híbrida: cómo comparar proveedores».

Cómo Skyhigh ofrece ZTNA en las propias instalaciones

Skyhigh ofrece ZTNA en las propias instalaciones a través de puertas de enlace locales en Hybrid SSE Mesh, junto con el servicio gestionado en la nube « Private Access ».

En Skyhigh Hybrid SSE Mesh, el ZTNA local se ejecuta en las propias puertas de enlace locales y de las sucursales de la organización, en una infraestructura de su propiedad y cuyos cambios están bajo su control, en lugar de en un nodo local gestionado por un proveedor, lo que amplía la aplicación del modelo «zero trust» a los usuarios internos, los recursos y los agentes de IA. Skyhigh Private Access sigue gestionando el acceso remoto a través de los puntos de presencia de Skyhigh, y ambos se gestionan desde una única consola y un único motor de políticas, junto con SWG, CASB y DLP.

Fuentes

1. NIST. SP 800-207: Arquitectura «Zero Trust» (agosto de 2020). https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST NCCoE. SP 1800-35: Implementación de una arquitectura de confianza cero (junio de 2025). https://csrc.nist.gov/pubs/sp/1800/35/final
3. CISA. Modelo de madurez de «Zero Trust», versión 2.0. https://www.cisa.gov/zero-trust-maturity-model
4. Skyhigh Security. «Cómo funciona Skyhigh Private Access ». https://success.skyhighsecurity.com/docs/how-skyhigh-private-access-works
5. Skyhigh Security. «Modernización de su solución Symantec Edge Secure Web Gateway con Skyhigh Hybrid SSE Mesh» (15 de julio de 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html