Zero Trust Network Access para entornos aislados
El aislamiento reduce la exposición, pero no elimina la necesidad de controlar quién puede acceder a sistemas sensibles dentro del entorno aislado.
ZTXGate puede funcionar dentro de redes completamente aisladas sin depender de un plano de control en la nube alojado por CoreZT. Los controles de identidad, dispositivo, recurso, política, autenticación y auditoría pueden permanecer dentro del entorno.
Qué significa ZTNA aislado
ZTNA aislado no es una forma de hacer que un sistema aislado sea accesible remotamente desde Internet pública.
Es una forma de aplicar controles de acceso Zero Trust dentro de un entorno aislado o desconectado.
Los usuarios, administradores y dispositivos que ya dispongan de una ruta aprobada hacia ese entorno pueden seguir sujetos a una política explícita antes de acceder a aplicaciones e infraestructura protegidas.
Esto importa porque el aislamiento de red por sí solo no responde preguntas como:
- ¿Qué usuario debería poder acceder a este recurso?
- ¿Qué dispositivo registrado puede utilizarse?
- ¿Debe existir el permiso permanentemente o solo durante un período limitado?
- ¿Debe el acceso sensible requerir autenticación adicional?
- ¿Pueden los administradores determinar quién accedió a un recurso y cuándo?
ZTXGate aborda esas cuestiones de control de acceso sin exigir que su funcionamiento básico se comunique con un servicio en la nube de CoreZT.
Mantenga la plataforma de acceso dentro del perímetro
Un despliegue independiente de ZTXGate puede funcionar íntegramente dentro del entorno protegido.
La ruta de acceso principal permanece dentro del perímetro de red.
Funcionamiento independiente
Los clientes no necesitan ZTXHub para operar ZTXGate, y el funcionamiento básico no requiere un plano de control alojado por CoreZT.
En un despliegue independiente y aislado:
- la política de acceso se gestiona localmente
- las licencias se gestionan manualmente
- las actualizaciones de software se gestionan manualmente
- las copias de seguridad se gestionan localmente
- los datos de auditoría permanecen disponibles dentro del despliegue
Este modelo operativo está pensado expresamente para redes donde no se permite conectividad externa de gestión.
ZTXHub opcional para despliegues conectados
CoreZT también proporciona ZTXHub, un servicio opcional propiedad de CoreZT y operado por CoreZT.
Los despliegues ZTXGate conectados pueden utilizar ZTXHub para gestión centralizada de actualizaciones de software y licencias.
No es necesario para una instalación completamente aislada. Los clientes que requieran aislamiento estricto pueden omitirlo y mantener el modelo operativo manual.
Esto hace que la gestión centralizada sea una elección de despliegue y no un requisito previo para que ZTXGate funcione.
Explorar el modelo de plano de control
ZTXBAS funciona en entornos aislados
La autenticación adicional suele resultar difícil en entornos desconectados porque muchos productos MFA dependen de un servicio alojado en Internet.
Cuando se licencia con ZTXGate, ZTXBAS está estrechamente integrado como biblioteca y funciona en todos los modelos de despliegue de ZTXGate, incluidas redes completamente aisladas, sin requerir un despliegue separado del servidor ZTXBAS.
Esto mantiene disponible la autenticación biométrica resistente al phishing dentro del mismo entorno aislado, en lugar de requerir acceso a un servicio externo de autenticación push.
Los despliegues conectados pueden seguir utilizando alternativas compatibles como Okta Verify o Duo cuando esos servicios sean accesibles.
Identidad dentro de un entorno aislado
Un despliegue aislado solo puede utilizar sistemas de identidad accesibles desde dentro de ese entorno.
Si una organización opera un proveedor de identidad interno compatible o una integración de directorio, ZTXGate puede utilizar los servicios disponibles dentro del perímetro de red.
Un proveedor de identidad alojado en Internet no puede participar en la autenticación salvo que el entorno proporcione deliberadamente conectividad hacia él.
El mismo principio se aplica a todas las integraciones externas: ZTXGate no pretende que una red desconectada pueda alcanzar un servicio en la nube físicamente inaccesible.
Identidad del dispositivo y política
ZTXGate registra los dispositivos individualmente y puede utilizar la identidad del dispositivo como parte de la política de acceso.
Las políticas pueden combinar factores como:
- identidad del usuario
- rol
- dispositivo registrado
- información de postura disponible localmente
- ubicación de red
- hora
- recurso protegido
- duración del acceso
Cuando un servicio MDM o EDR está alojado fuera del entorno aislado, sus datos de postura no estarán disponibles sin conectividad. Por tanto, la política debe diseñarse alrededor de las señales disponibles dentro del entorno.
Acceso con cliente y sin cliente
Los entornos aislados pueden contener tanto servicios de red como aplicaciones basadas en navegador.
Los endpoints gestionados pueden utilizar acceso basado en WireGuard a través de ZTXGate para recursos autorizados.
Las aplicaciones HTTP y HTTPS también pueden utilizar el proxy sin cliente de ZTXGate cuando el acceso desde navegador sea apropiado, permitiendo aplicar políticas de acceso y controles de auditoría sin requerir software de túnel en ese endpoint.
Auditoría y visibilidad locales
Los entornos desconectados siguen necesitando investigación y responsabilidad.
ZTXGate mantiene localmente registros de acceso, autenticación y políticas. Cuando exista un SIEM interno o una plataforma de registros dentro de la red aislada, ZTXGate puede reenviar eventos utilizando formatos y transportes compatibles.
Los servicios SIEM alojados en la nube requieren conectividad y, por tanto, no forman parte de una arquitectura estrictamente aislada.
Actualizaciones de software y licencias
Un despliegue independiente completamente aislado utiliza flujos manuales para licencias y actualizaciones de software.
Esto difiere de un despliegue conectado que utiliza ZTXHub opcional, donde la gestión de licencias y actualizaciones puede centralizarse.
El modelo manual permite al cliente o MSP que opera el despliegue controlar cuándo entra software o material de licencia en el entorno aislado conforme a sus procedimientos operativos.
Copias de seguridad y recuperación ante desastres
ZTXGate no utiliza clustering HA convencional.
El portal de administración admite copias de seguridad periódicas. Si se pierde un despliegue, una copia puede restaurarse en una instalación nueva de ZTXGate para recuperar el entorno configurado.
Para un despliegue aislado, el cliente o MSP debe almacenar copias de seguridad protegidas y mantener un proceso documentado para aprovisionar infraestructura de sustitución dentro del entorno aislado.
Se trata de un modelo de recuperación ante desastres basado en copia de seguridad y restauración, no en conmutación por error continua.
Capacidades conectadas frente a aisladas
| Capacidad | Despliegue conectado | Despliegue independiente completamente aislado |
|---|---|---|
| Acceso básico de ZTXGate | Sí | Sí |
| Plano de control en la nube alojado por CoreZT requerido | No | No |
| ZTXBAS | Sí | Sí |
| Okta Verify / Duo | Cuando el servicio sea accesible | No, salvo que se proporcione conectividad deliberadamente |
| Proveedor de identidad en la nube | Cuando el servicio sea accesible | No, salvo que se proporcione conectividad deliberadamente |
| Postura MDM / EDR en la nube | Cuando el servicio sea accesible | No, salvo que se proporcione conectividad deliberadamente |
| SIEM en la nube | Cuando el servicio sea accesible | No, salvo que se proporcione conectividad deliberadamente |
| Gestión de licencias | Manual o ZTXHub opcional operado por CoreZT | Manual |
| Actualizaciones de software | Manual o ZTXHub opcional operado por CoreZT | Manual |
| DR mediante copia/restauración | Sí | Sí |
Dónde encaja el ZTNA aislado
Este modelo puede ser relevante para entornos como:
- redes aisladas de investigación y desarrollo
- entornos operativos restringidos
- infraestructura interna sensible
- redes con conectividad a Internet deliberadamente limitada
- organizaciones cuya arquitectura exige servicios de seguridad locales
La idoneidad de un despliegue concreto sigue dependiendo de los requisitos de seguridad y controles circundantes de la organización.
Preguntas frecuentes
¿El ZTNA aislado proporciona acceso remoto desde Internet a una red aislada?
No. El objetivo es aplicar acceso Zero Trust dentro del entorno aislado, no eludir el aislamiento.
¿Necesita ZTXGate ZTXHub en un despliegue aislado?
No. ZTXHub es opcional y es propiedad de CoreZT y operado por CoreZT. Un despliegue ZTXGate completamente aislado no utiliza ZTXHub y puede usar flujos manuales de licencia y actualización de software.
¿Puede seguir funcionando la MFA biométrica sin acceso a Internet?
Sí. Cuando se licencia con ZTXGate, ZTXBAS integrado proporciona autenticación biométrica resistente al phishing en despliegues completamente aislados sin un servidor ZTXBAS separado.
¿Qué ocurre con las integraciones en la nube?
Solo están disponibles si los servicios correspondientes son accesibles. Un entorno estrictamente aislado debe utilizar los servicios de identidad, autenticación, postura, registro y gestión disponibles dentro de su perímetro.
¿Proporciona ZTXGate HA para entornos aislados?
No en el sentido convencional de clustering. El modelo de resiliencia compatible es la copia de seguridad periódica y la restauración en un despliegue nuevo después de un desastre.
Aplique Zero Trust sin romper el aislamiento
Mantenga la plataforma de acceso, la opción de autenticación, la política y la ruta de auditoría dentro del entorno aislado operado por el cliente o MSP.
Compare modelos operativos aislados
Para comparaciones actuales de arquitectura, consulte ZTXGate vs Cloudflare Access, ZTXGate vs Zscaler Private Access y ZTXGate vs Tailscale.