Acceso seguro basado en ZTNA para conectar usuarios con aplicaciones específicas

¿Qué es el acceso seguro basado en ZTNA?

Es un enfoque de acceso que verifica cada solicitud y permite la conexión solamente con los recursos definidos por una política.

En una arquitectura tradicional, ingresar a una red corporativa puede proporcionar visibilidad o conectividad hacia varios sistemas internos. ZTNA busca reducir esa exposición al separar la decisión de acceso de la ubicación física o lógica del usuario.

La decisión puede utilizar información sobre la identidad, el grupo o función de la persona, la aplicación solicitada, el dispositivo, la autenticación realizada, el estado de seguridad, la ubicación y otras señales disponibles.

El acceso puede aplicarse a personal remoto, usuarios dentro de las instalaciones, proveedores, contratistas, administradores o servicios automatizados. Las políticas y mecanismos necesarios cambian según el tipo de identidad y recurso.

¿Cómo funciona el acceso ZTNA?

ZTNA recibe una solicitud de acceso, reúne las señales definidas por la organización, evalúa una política y establece una ruta limitada cuando la solicitud resulta autorizada.

1. El usuario solicita una aplicación. La persona intenta acceder a un recurso empresarial desde un navegador, cliente, portal o agente instalado.
2. Se verifica la identidad. El sistema puede redirigir la autenticación hacia un proveedor de identidad y solicitar uno o más factores.
3. Se obtiene el contexto disponible. La plataforma puede consultar el rol, los grupos, el dispositivo, su estado de seguridad, la ubicación, el horario, el riesgo y otros atributos.
4. Se evalúa la política. Un motor de decisión compara la solicitud y sus señales con las reglas establecidas para el recurso.
5. Se permite o rechaza el acceso. Cuando la solicitud cumple las condiciones, se habilita una ruta hacia la aplicación autorizada. Si no las cumple, puede denegarse o solicitarse una medida adicional.
6. Se limita la comunicación. El punto de aplicación de políticas controla la conexión y evita proporcionar acceso innecesario a otros recursos.
7. Se supervisa la sesión. La plataforma registra actividad y puede reevaluar determinadas señales durante el acceso.
8. Se modifica o termina la conexión. Si cambia el riesgo, la identidad, la postura o la política, el acceso puede restringirse, solicitar una nueva autenticación o finalizarse.

¿Dónde se utiliza el acceso basado en ZTNA?

Puede utilizarse cuando una organización necesita conectar identidades autorizadas con aplicaciones privadas sin depender exclusivamente de la ubicación de la red.

Ventajas específicas del acceso ZTNA

Una implementación adecuada puede reducir la exposición innecesaria de recursos y aplicar decisiones de acceso más precisas que una política basada únicamente en la red.

• Acceso por aplicación. Permite limitar la conectividad al recurso que una identidad necesita utilizar.
• Menor confianza implícita. Evita asumir que una conexión es confiable solamente porque proviene de una oficina o red corporativa.
• Políticas contextuales. Puede considerar identidad, dispositivo, postura, ubicación, riesgo y sensibilidad del recurso.
• Reducción de exposición. Puede evitar que determinadas aplicaciones privadas queden disponibles directamente para cualquier origen de internet.
• Acceso para terceros. Facilita proporcionar conectividad delimitada a proveedores, socios y contratistas.
• Soporte para trabajo híbrido. Puede aplicar políticas similares sin depender de que el usuario se encuentre dentro de una sede específica.
• Integración con identidad. Favorece políticas relacionadas con roles, grupos, autenticación y ciclo de vida de las cuentas.
• Información para auditoría. Puede registrar quién solicitó un recurso, qué decisión se tomó y bajo qué condiciones.
• Limitación del movimiento lateral. Al reducir las rutas disponibles, puede dificultar que una identidad comprometida alcance recursos no autorizados.
• Migración gradual. Permite incorporar aplicaciones por etapas sin reemplazar necesariamente todos los mecanismos de acceso al mismo tiempo.

Consideraciones antes de implementar ZTNA

La implementación debe comenzar con los recursos, identidades y flujos de acceso. Instalar una plataforma sin conocer estas relaciones puede trasladar permisos excesivos o interrumpir dependencias necesarias.

• Inventario de aplicaciones. Deben identificarse recursos, propietarios, usuarios, ubicaciones, protocolos y nivel de criticidad.
• Mapa de flujos. Conviene documentar qué identidades acceden a cada aplicación y qué dependencias necesita su funcionamiento.
• Madurez de identidades. Las cuentas, grupos, roles y bajas deben encontrarse suficientemente organizados para construir políticas confiables.
• Autenticación multifactor. Debe definirse qué recursos y situaciones requieren una comprobación adicional.
• Dispositivos administrados y no administrados. La política debe decidir qué nivel de acceso corresponde a equipos corporativos, personales o desconocidos.
• Integración con endpoints. Cuando se utilice postura, debe comprobarse qué señales puede proporcionar la plataforma de protección o administración.
• Compatibilidad de aplicaciones. Deben revisarse protocolos, clientes, direcciones, DNS, certificados, puertos, sesiones y dependencias de red.
• Aplicaciones heredadas. Los sistemas que dependen de autenticación antigua, direcciones fijas o acceso amplio a la red pueden requerir ajustes o controles alternos.
• Acceso sin agente. Puede ser adecuado para determinadas aplicaciones web, pero no debe asumirse que cubre todos los protocolos o dispositivos.
• Acceso con agente. Deben validarse compatibilidad, despliegue, actualización, consumo de recursos y convivencia con otras herramientas.
• Conectores y gateways. Conviene determinar su ubicación, capacidad, redundancia, mantenimiento y conectividad con las aplicaciones.
• Disponibilidad. La identidad, el motor de políticas y los puntos de aplicación pueden convertirse en dependencias críticas para el acceso.
• Comportamiento ante fallas. Debe definirse qué sucede cuando un componente, enlace o proveedor de identidad deja de estar disponible.
• Rendimiento y latencia. Es necesario revisar dónde circula el tráfico y cómo la arquitectura afecta la experiencia de cada sede o usuario.
• Políticas de mínimo privilegio. Los permisos deben limitarse a las aplicaciones y funciones necesarias, evitando grupos excesivamente amplios.
• Accesos privilegiados. Las cuentas administrativas pueden requerir estaciones, autenticación y controles más estrictos.
• Acceso de emergencia. Deben existir procedimientos controlados para recuperar la operación cuando los mecanismos normales no están disponibles.
• Privacidad y telemetría. La organización debe conocer qué señales se recopilan, dónde se almacenan y quién puede consultarlas.
• Registros y monitoreo. Deben definirse responsables para revisar decisiones, intentos fallidos, cambios de políticas y anomalías.
• Migración gradual. Resulta conveniente iniciar con aplicaciones delimitadas, observar los flujos y ampliar el alcance después de validar la operación.
• Retiro de accesos anteriores. Después de la migración deben eliminarse rutas, cuentas y permisos que ya no sean necesarios.

Relación con otras soluciones de Ciberseguridad

ZTNA controla quién puede conectarse con un recurso y bajo qué condiciones. Las demás capas protegen el dispositivo, el tráfico y la aplicación durante diferentes etapas.

• Seguridad perimetral NGFW: controla conexiones entre redes y segmentos, y puede complementar los puntos de acceso definidos por ZTNA.
• Protección de endpoints: aporta controles y señales sobre el dispositivo que solicita acceso a una aplicación.
• Protección de aplicaciones web: analiza las solicitudes dirigidas a la aplicación después de que el usuario obtiene una ruta autorizada.

Cobertura y atención de proyectos en México

Solidem contempla la atención de proyectos relacionados con acceso seguro basado en ZTNA en todo México, de acuerdo con la infraestructura, ubicaciones, aplicaciones y alcance definido para cada organización.

La revisión puede considerar organizaciones con personal remoto, múltiples sucursales, proveedores externos, aplicaciones alojadas localmente, servicios en la nube y recursos utilizados desde diferentes redes o dispositivos.

Para delimitar el proyecto es útil conocer la cantidad de usuarios y sedes, aplicaciones privadas, mecanismos de acceso actuales, proveedor de identidad, sistemas operativos, dispositivos permitidos, perfiles externos y requerimientos de continuidad.