En las arquitecturas VPN tradicionales, el túnel suele gestionarse aparte de la política de identidad. Por un lado el directorio corporativo, por otro el sistema de autenticación VPN, además el servicio MFA, otra herramienta para la confianza de dispositivo y una línea de logs separada para la auditoría. Esta estructura fragmentada hace que el acceso remoto sea operativamente frágil más que seguro.
Que el usuario conozca la contraseña correcta no basta por sí solo. ¿El dispositivo está gestionado, el cifrado de disco activo, el software de seguridad actualizado, el usuario en el grupo correcto, la IP de origen o la franja horaria son riesgosas? Si estas preguntas no se responden antes de abrir el túnel, la VPN se convierte en una puerta incontrolada que extiende la red corporativa.
El split tunneling, el túnel completo y el acceso por segmentos tampoco son solo una cuestión de ruta de red. El usuario de finanzas y el contratista no deben acceder a la misma red; un dispositivo corporativo gestionado y un dispositivo personal no deben tener la misma autorización. Cuando la política de túnel no se diseña junto con la identidad, el grupo y la confianza de dispositivo, el alcance del acceso queda más amplio de lo necesario.
En el lado operativo el problema también crece. Si SSL VPN, IKEv2, MFA, política de grupo, registro de sesión y exportación a SIEM se gestionan por separado, el equipo de seguridad no puede ver el panorama completo en el momento de un incidente. Quién se conectó, con qué dispositivo, a qué segmentos accedió y por qué se cortó la conexión deben verse en un único rastro de auditoría.
El enfoque de TR7 AAM trata el acceso VPN no como un servicio de red aparte, sino como una capa de acceso remoto controlada donde convergen las decisiones de identidad, MFA, postura de dispositivo, acceso condicional y auditoría.
TR7 AAM evalúa el acceso remoto con cliente como una decisión de identidad, confianza de dispositivo y alcance de acceso antes de la elección del protocolo.
El usuario puede autenticarse mediante LDAP/AD, RADIUS, OIDC, SAML o un origen de usuario local. La misma decisión de identidad constituye la base común de política para las opciones de acceso con cliente como SSL VPN o IKEv2.
El score de confianza de dispositivo se trata como parte de la decisión de acceso condicional. Puede aplicarse un modelo de acceso amplio para dispositivos gestionados, acceso restringido para dispositivos personales y denegación de acceso para dispositivos no confiables.
El enfoque SSL VPN basado en TLS, al operar a través del puerto 443, facilita el paso por entornos de firewall y proxy corporativos. La decisión de split tunneling o túnel completo puede vincularse al modelo de política.
IKEv2/IPsec ofrece un modelo de acceso remoto compatible con los clientes VPN nativos de sistemas operativos como Windows, macOS, iOS y Android. Para la continuidad del túnel en cambios de red móvil, el enfoque IKEv2 aporta una ventaja práctica.
TR7 SSL VPN e IKEv2 colocan en el centro, más que el protocolo de túnel, la decisión de identidad, MFA, postura y alcance de acceso de AAM.
SSL VPN se posiciona, con su enfoque de túnel basado en HTTPS/TLS, para el acceso a recursos corporativos desde redes restringidas. El uso del puerto 443 facilita el acceso en muchos entornos corporativos, hoteles, aeropuertos o redes externas. Este modelo es especialmente valioso cuando se restringen clientes adicionales o puertos UDP específicos.
IKEv2/IPsec es adecuado para un modelo de acceso remoto corporativo compatible con los clientes VPN nativos del sistema operativo. En plataformas como Windows, macOS, iOS y Android puede reducir la complejidad adicional de la experiencia de usuario. En escenarios donde los usuarios móviles cambian de red, la arquitectura IKEv2 es ventajosa en cuanto a reconexión.
La conexión VPN puede evaluarse junto con la política de acceso condicional de AAM. La identidad del usuario, la pertenencia a grupos, la IP de origen, la ventana horaria, la confianza de dispositivo y las señales de riesgo entran en el proceso de decisión antes de abrir el túnel. Este enfoque saca a la VPN de ser una puerta abierta a nivel de red. La decisión de acceso queda limitada al contexto de usuario y dispositivo.
El enfoque MFA de TR7 AAM puede usarse como un factor de confianza común que se aplica también a la decisión de acceso VPN. Métodos como TOTP, SMS OTP o e-mail OTP refuerzan la verificación del usuario. Con un modelo de dispositivo confiable o de verificación basada en riesgo, se equilibran experiencia de usuario y seguridad. Así se reduce la necesidad de operar una infraestructura MFA aparte para la VPN.
AAM cuenta con un modelo de proveedor de identidad que puede trabajar con orígenes de usuario LDAP/AD, RADIUS, OIDC, SAML y locales. El acceso VPN no se trata como una base de datos de usuarios aparte ni como una isla de identidad separada. Con cualquier identidad con la que el usuario ya se gestione en la organización, la decisión de abrir el túnel se vincula al mismo contexto de identidad. Esta estructura simplifica la gestión del ciclo de vida del usuario.
A qué segmentos de red puede acceder el usuario puede asociarse a la pertenencia a grupos o a la política de usuario de AAM. El equipo de finanzas puede dirigirse solo a los sistemas financieros, el contratista solo a los servicios del proyecto, el equipo de DevOps solo al entorno de desarrollo. Este modelo reduce el error de conceder acceso a toda la red una vez abierta la VPN. El acceso por túnel se convierte en un control de segmentos basado en identidad.
Las señales de postura de dispositivo ETM pueden usarse para separar dispositivos gestionados y no gestionados en el acceso por túnel. Señales como el cifrado de disco, el software de seguridad, el estado de parches o la gestión corporativa pueden influir en el nivel de acceso. Un dispositivo confiable puede dirigirse a la red completa, y un dispositivo de baja confianza solo a servicios backend limitados. Este enfoque hace visible el riesgo del dispositivo en el acceso remoto.
Las sesiones VPN pueden vincularse al rastro de auditoría con campos como identidad de usuario, IP de origen, hora de sesión, duración de la conexión y resultado de política. Estos registros pueden trasladarse al flujo SIEM y correlacionarse con eventos de seguridad. El equipo de operaciones puede ver no solo que la conexión se abrió, sino también con qué decisiones de confianza se abrió. Esta visibilidad es crítica para el cumplimiento y la investigación de incidentes.
El split tunneling permite que solo los rangos de IP corporativos o servicios específicos pasen por el túnel. El túnel completo, en cambio, lleva todo el tráfico del cliente al punto de paso corporativo. Qué modelo se aplica puede determinarse según el grupo de usuario, la confianza de dispositivo, la ubicación o el nivel de riesgo.
Si la postura del dispositivo empeora durante la conexión, si cambia el score de riesgo o si se infringe la política de usuario, es necesario cortar la sesión o solicitar una nueva verificación. La arquitectura TR7 AAM asocia esta decisión con el modelo de acceso condicional y auditoría. Este enfoque saca al acceso VPN de ser un canal permanente que se olvida una vez abierto. El acceso debe ser observable y revocable a lo largo de toda la sesión.
En la arquitectura SSL VPN e IKEv2, las capacidades de identidad AAM ya probadas deben abordarse junto con los requisitos operativos del túnel.
Los proveedores de identidad, MFA, acceso condicional y el concepto de postura de dispositivo ETM son la base fiable de esta página. El mensaje principal de la página es que la VPN se conecta a este motor de acceso. El protocolo de túnel se posiciona como el canal en el que se aplica la decisión de identidad y política.
El enfoque SSL VPN se posiciona sobre TLS 1.2+ y el puerto 443. Esto aporta ventaja en cuanto al acceso desde redes restringidas. La comodidad de paso por entornos de firewall y proxy corporativos es la ventaja práctica destacada frente a IKEv2.
En el modelo IKEv2/IPsec, los puertos UDP 500 (IKE) y UDP 4500 (NAT-T), el comportamiento NAT-T y los permisos de firewall se vuelven críticos. Frente a SSL VPN, la probabilidad de bloqueo en algunas redes restringidas es mayor. Por ello, SSL VPN e IKEv2 son opciones complementarias para distintas condiciones de acceso.
En la arquitectura VPN debe planificarse el pool de IP de túnel que se asignará a cada sesión. Si el pool se agota, las nuevas conexiones pueden rechazarse o ponerse en espera. El tamaño del pool y el modelo de gestión deben configurarse según los requisitos de despliegue.
En el acceso VPN puede ser necesario que los dominios corporativos se resuelvan a través del DNS interno y los demás dominios a través de la resolución externa. El split DNS es el complemento natural del diseño de split tunneling. Este comportamiento depende de la arquitectura de despliegue y la configuración de política.
Los protocolos de túnel generan un coste de cabecera adicional. El ajuste de MTU/MSS es importante especialmente para el rendimiento de IPsec ESP y del túnel TLS. Los ajustes incorrectos pueden producir fragmentación, bajo rendimiento o problemas de conexión en algunas aplicaciones.
Cuando el gateway AAM opera en pareja, el comportamiento de failover de las sesiones VPN depende de la tecnología de túnel. En el lado IKEv2 la arquitectura de reconexión móvil puede ser ventajosa; en el lado SSL VPN, el diseño de VIP y continuidad de sesión debe abordarse aparte.
El usuario que trabaja desde casa o en viaje se autentica a través de AAM con su identidad corporativa y MFA. Si la confianza de dispositivo ETM es suficiente, se concede acceso a los servicios de intranet a través de SSL VPN; en dispositivos personales el acceso se limita a segmentos más estrechos.
El técnico de campo puede conectarse a la red corporativa con el cliente IKEv2 nativo de su dispositivo móvil. Si el dispositivo tiene perfil gestionado y un alto score de confianza ETM, se concede un acceso más amplio; en los cambios de red, el enfoque IKEv2 es más adecuado para el uso móvil.
Al contratista externo se le asigna una cuenta de usuario y un grupo restringido válidos solo durante la duración del proyecto. El acceso VPN se abre únicamente al segmento donde se encuentran los servicios backend del proyecto y todas las sesiones se vinculan al registro de auditoría.
El ingeniero de automatización de planta recibe una política VPN que le da acceso solo al segmento OT. El acceso condicional limita la decisión con la franja horaria laboral, el grupo de usuario, la IP de origen y la confianza de dispositivo; no se concede acceso amplio a la red corporativa general.
Conozca la arquitectura que combina el túnel SSL VPN e IKEv2 con el motor de identidad AAM, MFA y la postura de dispositivo ETM. Le hacemos un recorrido en una instalación en vivo en su propio entorno.