En mi blog anterior sobre SASE consciente de la identidad hablé de la confianza cero, el papel de SASE y la importancia de la identidad en los controles de acceso.
Otro blog sobre el proxy SASE explicaba cómo las soluciones SASE obtienen las identidades de los usuarios tras autenticarlos a través de los proveedores de identidad (IdP).
En resumen, la parte de proxy de reenvío de las soluciones SASE autentica a los usuarios a través de los métodos de autenticación Kerberos, NTLM, Digest y Basic.
Por su parte, los portales cautivos autentican a los usuarios a través de Kerberos u OIDC.
La parte de proxy inverso de las soluciones SASE suele utilizar Kerberos u OIDC para autenticar a los usuarios.
La pasarela VPN de SASE también autentica a los usuarios con las bases de datos de autenticación de la empresa.
Las soluciones SASE esperan información del usuario como el proveedor de identidad que validó las credenciales del usuario, la dirección de correo electrónico del usuario, los grupos y roles a los que pertenece el usuario, etc. en formato JWT (JSON Web Token).
Las soluciones SASE utilizan esta información (conocida como reclamaciones en la terminología JWT) para hacer cumplir los controles de acceso específicos de la identidad.
Agente de identidad
Un corredor de identidad es un servicio que actúa como intermediario, facilitando la autenticación de los usuarios finales mediante soluciones SASE con varios proveedores de identidad (IdP).
No todos los IdP implementan todos los protocolos de autenticación; algunos sólo implementan OIDC, OAuth2 o SAMLv2.
Dado que las soluciones SASE están diseñadas para trabajar con varios IdP, su complejidad aumenta al tener que soportar distintos protocolos de autenticación.
Los corredores de identidad, como servicios intermediarios de confianza, pueden permitir que la solución SASE utilice un único protocolo de autenticación en el backend y dejar que el corredor de identidad proxy el proceso de autenticación a los IdP a través de los protocolos de autenticación que los IdP soportan.
La siguiente imagen muestra la solución SASE con y sin corredor de identidad. 
La parte izquierda de la imagen muestra SASE sin un broker de identidad: Los navegadores/aplicaciones de los usuarios se autentican en el proxy de reenvío de SASE utilizando Kerberos, NTLM, nombre de usuario/contraseña, nombre de usuario/digesto-contraseña.
SASE necesita validar las credenciales del usuario.
Utiliza múltiples módulos funcionales backend para hablar con varios IdPs/sistemas de autenticación.
En el caso de Kerberos, el ticket de servicio es validado localmente dentro del plano de datos de SASE y luego obtiene las decoraciones de usuario de los sistemas de autenticación como AD vía LDAP o SCIM.
En el caso de nombre de usuario/contraseña, el backend LDAP se utiliza también para validar las credenciales de usuario.
El proxy inverso SASE y los portales cautivos autentican a los usuarios vía OIDC (Open ID Connect) o vía SAMLv2.
Si el IdP backend también está basado en OIDC o SAMLv2, entonces redirige a los usuarios a los IdP.
En caso de sistemas basados en LDAP, se espera que SASE funcione como IdP y utilice LDAP a AD para validar las credenciales de los usuarios y también para obtener las decoraciones de los usuarios para crear el token de identidad en forma JWT.
VPN Gateway es otro módulo que se utiliza para el acceso remoto.
Como parte del establecimiento del túnel IKEv2, la pasarela VPN autentica al usuario.
Las credenciales del usuario se validan con la base de datos local, el servidor RADIUS o el servidor LDAP.
Como puede ver, se requieren múltiples componentes del plano de datos para soportar diferentes protocolos para trabajar con varios navegadores de usuario y aplicaciones nativas.
Además, necesitan trabajar múltiples IdPs no sólo de varios inquilinos, sino también múltiples requisitos de IdPs dentro de un entorno de inquilino.
La parte derecha de la imagen muestra SASE con broker de identidad incorporado: Con el broker de identidades, el plano de datos de SASE se simplifica drásticamente.
El plano de datos de SASE sólo necesita trabajar con un protocolo de autenticación hacia el broker.
En la imagen anterior, OIDC es el único protocolo que el plano de datos SASE necesita soportar.
El broker puede orquestar/federar sesiones de autenticación con múltiples IdPs.
También se espera que el broker de identidades cree JWT a partir de la información de usuario del token de seguridad SAMLv2, a partir de JWT procedentes de los servidores IdP upstream o a partir de la información de usuario en la base de datos local o accesible a través de LDAP.
Es decir, se espera que el corredor de identidad diseñado para SASE proporcione JWT en todos los casos – Tanto si el usuario se está autenticando utilizando Kerberos a través de cabeceras proxy, Kerberos a través de cabeceras WWW, OIDC, IKEv2 y si los IdP están basados en OIDC, SAMLv2 o LDAP.
Existen múltiples ventajas de desglosar el plano de datos SASE del broker de identidad SASE.
Algunas ventajas se enumeran a continuación.
- La modularidad hace que toda la solución sea menos compleja, menos propensa a errores y, por tanto, más robusta.
- Secure:Identity broker puede instanciarse por separado del plano de datos SASE en entornos informáticos confidenciales para garantizar que las claves/contraseñas/credenciales utilizadas para comunicarse con los IdP están protegidas incluso mientras se utilizan.
- Extensibilidad:Nuevos IdPs con protocolos de autenticación más recientes pueden ser soportados sin impactar en el plano de datos SASE.
- Consolidación:Las soluciones de corredor de identidades se están considerando cada vez más también para otras aplicaciones.
Las empresas pueden utilizar el broker de identidades que viene con la solución SASE para sus aplicaciones en lugar de ir con un servicio/solución de broker de identidades por separado.
Características específicas de SASE
La funcionalidad del corredor de identidades puede, de hecho, desempeñar un papel importante a la hora de detener el acceso directo a los servicios SaaS/Cloud, aplicando comprobaciones de políticas y garantizando que sólo los usuarios autenticados con un control de acceso adecuado puedan acceder a estos recursos.
Además, los corredores de identidad tradicionales pueden no tener un buen soporte para Kerberos proxy, que es esencial para la autenticación SASE.
Por lo tanto, es importante que los corredores de identidades tengan soporte para Kerberos proxy y otros requisitos SASE para integrarse eficazmente con las soluciones SASE.
Al proporcionar estas mejoras, los corredores de identidades pueden mejorar la seguridad y la facilidad de uso de las soluciones SASE para las empresas.
- Garantizar el control de acceso basado en identidades para los servicios SaaS y en la nube siempre y de forma determinista: Las empresas utilizan cada vez más los servicios SaaS y de infraestructura en la nube, a los que se puede acceder desde cualquier lugar.
Esto es una gran ventaja, pero también una preocupación de seguridad para muchas empresas.
Las empresas quieren restringir el acceso a sus datos en los servicios SaaS/Nube para empleados específicos, y se espera que SASE lo garantice.
Sin embargo, esto sólo es posible si el tráfico de usuarios a los servicios SaaS/Cloud va a través del plano de datos de SASE.
Si el tráfico va a los servicios SaaS/Nube directamente, saltándose el plano de datos de SASE, se espera que el acceso sea denegado.
Un corredor de identidades puede ayudar a detener estos accesos.
Configurando los servicios SaaS/Cloud para que utilicen el broker de identidades SASE, cualquier nueva sesión de autenticación de usuario aterriza primero en el broker de identidades SASE.
El agente de identidades SASE, a través de sus comprobaciones de políticas, puede impedir que los usuarios accedan directamente a los servicios. - Compatibilidad con la concesión Kerberos: Para muchos casos de uso, el tipo de concesión de autorización implícita y los tipos de concesión de contraseña son suficientes.
Sin embargo, estos dos tipos de concesión no son suficientes para soportar la autenticación Kerberos.
La expectativa es que el plano de datos SASE, una vez que reciba el ticket de servicio Kerberos, ya sea a través de cabeceras proxy o cabeceras WWW del usuario (navegadores, por ejemplo), se espera que valide el ticket de servicio y obtenga las correspondientes decoraciones de usuario de las bases de datos de autenticación.
Dado que el broker se utiliza para validar las credenciales, la implementación del protocolo OIDC requiere una mejora para soportar el envío del ticket de servicio desde el plano de datos SASE al broker de identidad y obtener el JWT si las credenciales son validadas.
Reflexiones finales
De hecho, los corredores de identidad pueden desempeñar un papel crucial en una solución SASE (Secure Access Service Edge) completa.
Al integrar un corredor de identidades en la arquitectura SASE, las organizaciones pueden simplificar la integración de las soluciones de gestión de identidades y accesos (IAM) con su infraestructura SASE.
Esto puede conducir a un proceso de autenticación y control de acceso más racionalizado y seguro para los usuarios.
Además, mediante la aplicación de los principios de seguridad de confianza cero, un agente de identidad puede ayudar a garantizar que sólo los usuarios autorizados están accediendo a los recursos dentro del entorno SASE.
Esto puede ayudar a reducir el riesgo de violaciones de datos y otros incidentes de seguridad.
Aunque es posible que los analistas del sector no hablen actualmente de los corredores de identidad en el contexto de SASE, es posible que esto cambie a medida que las organizaciones sigan buscando formas de mejorar la seguridad y la eficiencia de sus entornos de TI.
-
Blog CTO Insights
La serie de blogs Aryaka CTO Insights proporciona liderazgo de pensamiento para temas de red, seguridad y SASE.
Para conocer las especificaciones de los productos Aryaka, consulte Aryaka Datasheets.
