Autenticación y autorización viene en varios colores
El componente Zero Trust Network Access (ZTNA) de SASE está diseñado para proporcionar un acceso entrante seguro a las aplicaciones privadas de la empresa.
En línea con el principio básico de control de acceso basado en identidades de la Arquitectura de Confianza Cero (ZTA), ZTNA desempeña un papel vital en la autenticación de usuarios y en la aplicación de controles de acceso basados en tipos de usuario, grupos y roles en cada sesión entrante a las aplicaciones de la empresa.
La seguridad ZTNA ofrece ventajas significativas en los siguientes escenarios:
- Aplicaciones heredadas: Las aplicaciones heredadas que carecen de medidas de seguridad incorporadas a menudo no se exponen a los usuarios de Work-From-Anywhere (WFA) por motivos de seguridad.
Mediante la utilización de ZTNA como front-end de estas aplicaciones heredadas, se puede proporcionar terminación HTTPS con gestión de certificados, autenticación mediante protocolos como OIDC y autorización basada en controles de acceso conscientes del contexto.
Esto permite que los usuarios de WFA puedan acceder de forma segura a las aplicaciones heredadas a través de Internet. - Aplicaciones rotas: A pesar de haber sido desarrolladas pensando en la seguridad, algunas aplicaciones pueden no haber sido actualizadas durante un largo periodo de tiempo.
Estas aplicaciones pueden carecer de una gestión de certificados adecuada, con un soporte anticuado o inexistente para la carga de nuevos certificados o la renovación automática.
ZTNA puede actuar como sustituto de seguridad para estas aplicaciones rotas, garantizando un acceso seguro y superando al mismo tiempo sus limitaciones de seguridad. - Nueva arquitectura de aplicaciones: Las aplicaciones empresariales modernas se diseñan a menudo trasladando las consideraciones de seguridad a entidades externas como la ZTNA y las tecnologías de malla de servicios.
Este enfoque libera a los desarrolladores de aplicaciones de la carga de gestionar HTTPS, la autenticación y la autorización, ya que la seguridad se descarga a la entidad front-end.
Al centralizar la gestión de la seguridad, se obtienen ventajas como la aplicación uniforme de las políticas de seguridad, el aumento de la productividad en el desarrollo de aplicaciones y la simplificación del mantenimiento.
Además, como las actualizaciones de seguridad se gestionan externamente, se puede reducir significativamente la frecuencia de los lanzamientos de parches destinados a solucionar problemas de seguridad.
En la actualidad, muchas soluciones de ZTNA son buenas para aplicaciones empresariales sencillas de front-ending, pero fallan a la hora de proporcionar autenticación y autorización para aplicaciones multi-tenant como las aplicaciones SaaS.
El papel de la ZTNA en las aplicaciones SaaS: En el contexto de las aplicaciones de software como servicio (SaaS), la ZTNA desempeñará un papel vital en el refuerzo y la mejora de los mecanismos de autenticación y autorización, en mi opinión.
Las aplicaciones SaaS tienen requisitos específicos, como la multitenencia, la resiliencia frente a ataques DoS/DDoS y una sólida protección frente a la elusión de la autenticación y los ataques de escalada de privilegios.
Este artículo profundizará en las características de la ZTNA de nueva generación que pueden ayudar a descargar o mejorar los procesos de autenticación y autorización de las aplicaciones SaaS.
Tenga en cuenta que este artículo no cubrirá otras características de ZTNA, como WAAP (Web Application and API Protection), la terminación HTTPS, la gestión del tráfico de las sesiones entrantes a varias instancias de aplicaciones, la webificación de los servicios SSH/RDP/VNC y hacer que las aplicaciones sean invisibles a los escáneres de puertos.
Se centra principalmente en los aspectos de autenticación y autorización de ZTNA.
Es importante señalar que puede haber confusión entre las funciones de CASB (Cloud Access Security Broker) y ZTNA en el contexto de SaaS.
El componente CASB de SASE se centra en asegurar las conexiones a los servicios SaaS utilizados por las empresas, donde las empresas son consumidoras de los servicios SaaS y CASB.
Por otro lado, ZTNA, en el contexto de SaaS, está diseñado para proteger la propia aplicación SaaS, lo que convierte a las empresas SaaS en consumidores de los servicios ZTNA.
Esta diferenciación es esencial para comprender las distintas funciones y responsabilidades de CASB y ZTNA en las soluciones SASE.
En un artículo anterior sobre los corredores de identidad, exploramos las numerosas ventajas de integrar corredores en las soluciones SASE.
Las ventajas discutidas giraban principalmente en torno a la modularidad y la simplicidad del diseño, que en última instancia mejoran la resistencia de las soluciones SASE.
En este artículo, profundizaremos en el papel fundamental de los brokers de identidad en el soporte de aplicaciones complejas, centrándonos especialmente en las aplicaciones SaaS.
¿Cuáles son los retos de las aplicaciones multiusuario?
La ZTNA de SASE destaca por ofrecer un sólido soporte para la autorización basada en políticas.
Los motores de autorización dentro de SASE ofrecen la capacidad de gestionar múltiples tablas de políticas, con cada tabla conteniendo múltiples políticas.
Cada política se compone de múltiples reglas y especifica la acción a tomar tras una coincidencia exitosa.
Las propias reglas engloban varios atributos de coincidencia, que pueden clasificarse como atributos de origen y de destino.
Los atributos de destino pertenecen principalmente a los recursos de las aplicaciones a los que se accede, como las URI y los métodos (por ejemplo, GET, PUT, POST, DELETE) utilizados para interactuar con esos recursos.
Por otro lado, los atributos de origen suelen estar asociados a los sujetos que acceden a los recursos.
Estos atributos engloban atributos relacionados con el usuario como el nombre, el grupo, el rol, el servicio de autenticación que validó las credenciales del usuario y otras afirmaciones del usuario.
También incluyen atributos de contexto del dispositivo, que capturan la postura segura de los dispositivos utilizados por el sujeto y la ubicación del dispositivo desde el que el usuario accede a los recursos.
Sin embargo, muchas soluciones de ZTNA se quedan cortas cuando se trata de abordar escenarios de autenticación completos, y a menudo limitan sus capacidades a las aplicaciones que no son SaaS.
La inclusión de un agente de identidades en las soluciones SASE/SSE es un paso progresivo hacia la consecución de una autenticación integral en todo tipo de aplicaciones.
Aunque se puede argumentar que los proveedores de SaaS poseen la capacidad de gestionar la autenticación y la autorización dentro de sus aplicaciones, el panorama ha evolucionado significativamente.
En el ágil entorno actual, los proveedores de SaaS reconocen cada vez más las ventajas de descargar las responsabilidades de seguridad en entidades externas como SASE.
Al hacerlo, pueden beneficiarse de una mayor productividad y una mayor confianza en su postura de seguridad general.
Además, este enfoque permite a los nuevos proveedores de SaaS entrar en el mercado más rápidamente, ya que pueden descargar la autenticación y autorización a una entidad externa y centrarse principalmente en su lógica de negocio principal.
Las soluciones SASE pueden desempeñar un papel fundamental en el apoyo a estos nuevos proveedores de SaaS.
Creemos que las soluciones SASE deben estar y estarán preparadas para asumir este reto de proporcionar seguridad de autenticación y autorización en nombre de aplicaciones complejas como las aplicaciones SaaS.
El siguiente escenario ofrece un ejemplo representativo de una aplicación SaaS y explora cómo SASE, mediante la integración de brokers de identidad, puede ayudar en la delegación de autenticación y autorización de las aplicaciones.
Considere este escenario de ejemplo de aplicación SaaS (alojada en app.example.com) que consta de múltiples recursos API:
| /app.example.com/servicio-admin-api/ | Este espacio API es exclusivo para administradores de proveedores de servicios de aplicaciones. |
| /app.example.com/tenants//administrador-inquilino-api/ | Sólo los administradores de inquilinos pueden acceder a este espacio API bajo su respectivo inquilino. |
| /app.example.com/tenants//usuario-tenant-api/ | Este espacio API está reservado para los usuarios arrendatarios. |
| /app.example.com/tenants//public-api/ | Cualquiera puede acceder a esta API siempre que proporcione credenciales válidas a través de las redes sociales u otros servicios de autenticación admitidos. |
| /app.example.com/tenants//colaboration-api/ | Sólo los socios arrendatarios pueden utilizar esta API. |
En este escenario, supongamos también que el IDP del proveedor de SaaS es example-idp.
Hay dos inquilinos: XYZ y ABC, con sus respectivos servicios IDP siendo XYZ-idp y ABC-idp.
Cada inquilino tiene también dos socios, cada uno con su propio servicio IDP.
XYZ-P1-idp y XYZ-P2-idp son los servicios IDP de los socios de XYZ.
ABC-P1-idp y ABC-P2-idp son servicios IDP de socios ABC.
Además, el arrendatario XYZ requiere autenticación a través de Google y Facebook para acceder al espacio público de API, mientras que el arrendatario ABC prefiere la autenticación a través de LinkedIn y GitHub.
Se necesitan las siguientes políticas de autorización en ZTNA para abordar el escenario anterior:
- Dominio = app.example.com; user-role=app-admin; authservice=example-idp; uri = /service-admin-api/* ALLOW: Permitir el acceso a cualquier usuario que haya iniciado sesión correctamente en el servicio example-idp y posea el rol app-admin para todos los recursos bajo el admin-api de la aplicación con el dominio app.example.com.
- Dominio = app.example.com; user-group=admin-group; authservice=XYZ-idp; uri = /inquilinos/XYZ/inquilino-admin-api/* ALLOW: Permitir el acceso a cualquier usuario que haya iniciado sesión correctamente en el servicio XYZ-idp que posea el rol admin-group para todos los recursos bajo XYZ/tenant-admin-api.
- Dominio = app.ejemplo.com; user-role=admin-role; authservice=ABC-idp; uri = /inquilinos/ABC/inquilinos-admin-api/* ALLOW: Permitir el acceso a cualquier usuario con el rol admin, autenticado con el servicio ABC-idp, que acceda a los recursos ABC/tenant-admin-api
- Dominio = app.example.com; authservice=XYZ-idp; uri = /inquilinos/XYZ/inquilino-usuario-api/*, /inquilinos/XYZ/colaboración-api/*, /inquilinos/XYZ/público-api/* PERMITIR: Permitir el acceso a los recursos especificados en la regla a cualquier usuario que se haya autenticado correctamente con el servicio XYZ-idp.
- Dominio = app.ejemplo.com; authservice=ABC-idp; uri = /inquilinos/ABC/inquilino-usuario-api/*, /inquilinos/ABC/colaboración-api/*, /inquilinos/ABC/público-api/* ALLOW: Permitir el acceso a los recursos especificados en la regla a cualquier usuario que se haya autenticado correctamente con el servicio ABC-idp
- Dominio = app.ejemplo.com; authservice=XYZ-P1-idp; uri = /inquilinos/XYZ/collaboration-api/*, /inquilinos/XYZ/public-api/* ALLOW: Permitir el acceso al espacio de colaboración XYZ a los usuarios autentificados con el servicio XYZ-P1-idp.
- Dominio = app.ejemplo.com; authservice=XYZ-P2-idp; uri = /inquilinos/XYZ/collaboration-api/*, /inquilinos/XYZ/public-api/* ALLOW: Permitir el acceso al espacio de colaboración XYZ a los usuarios autentificados con el servicio XYZ-P2-idp.
- Dominio = app.ejemplo.com; authservice=ABC-P1-idp; uri = /inquilinos/ABC/collaboration-api/*, /inquilinos/ABC/public-api/* ALLOW: Permitir el acceso al espacio de colaboración ABC a los usuarios autenticados con el servicio ABC-P1-idp.
- Dominio = app.ejemplo.com; authservice=ABC-P2-idp; uri = /inquilinos/ABC/collaboration-api/*, /inquilinos/ABC/public-api/* ALLOW: Permitir el acceso al espacio de colaboración ABC a los usuarios autenticados con el servicio ABC-P2-idp.
- Dominio = app.ejemplo.com; authservice=google.com; uri = /inquilinos/XYZ/public-api/* ALLOW: Permitir el acceso al espacio public-api de XYZ a todos los usuarios autenticados con google.com.
- Dominio = app.ejemplo.com; authservice=facebook.com; uri = /inquilinos/XYZ/public-api/* ALLOW: Permitir el acceso al espacio public-api XYZ a todos los usuarios autenticados con facebook.com
- Dominio = app.ejemplo.com; authservice=linkedin.com; uri = /inquilinos/ABC/public-api/* ALLOW: Permitir el acceso al espacio ABC public-api a todos los usuarios autenticados con linkedin.com
- Dominio = app.ejemplo.com; authservice=github.com; uri = /inquilinos/ABC/public-api/* ALLOW: Permitir el acceso al espacio XYZ public-api a todos los usuarios autenticados con github.com
- Dominio = app.ejemplo.com; DENEGAR: Denegar el acceso a la aplicación si ninguna de las reglas anteriores coincide.
Las soluciones SASE destacan en el control de acceso basado en atributos.
Esto significa que manejan bien la funcionalidad de autorización.
Sin embargo, no son muy completas cuando se trata de la autenticación.
En las políticas anteriores, se conceden diferentes niveles de acceso en función del servicio de proveedor de identidad (IDP) con el que los usuarios eligen autenticarse.
Además, algunos usuarios pueden querer autenticarse deliberadamente con un servicio IDP específico para acceder a recursos con permisos mínimos para evitar posibles errores de exfiltración de datos.
Papel de los intermediarios de identidad
Para abordar estos escenarios, se requiere la funcionalidad integrada de un corredor de identidades.
Los corredores de identidad sirven como proveedores de OIDC (OpenID Connect) al componente proxy SASE/SSE al tiempo que actúan como clientes OIDC/SAML/LDAP para los servicios de identidad ascendentes (servicios de autenticación).
Keycloak, un sistema IAM de código abierto, es una opción popular para muchos.
Puede configurarse para desempeñar el papel de intermediario de identidades y lo utilizan habitualmente los proveedores de servicios SASE y los vendedores de productos de malla de servicios.
De ahí que aquí se utilice la terminología Keycloak.
Keycloak ofrece la flexibilidad necesaria para gestionar la autenticación de varios tipos de aplicaciones, incluidas las aplicaciones SaaS multi-tenant.
La autenticación para aplicaciones SaaS multi-tenant puede lograrse utilizando «corredores de identidad» de la siguiente manera: Un dominio con un cliente para cada aplicación SaaS con flujos de autenticación modificados: En los casos en los que la aplicación-arrendatario no pueda identificarse a partir de la ruta URL o las cabeceras de solicitud HTTP, el componente proxy SASE puede tener un único cliente OIDC para comunicarse con el agente de identidades.
Durante la autenticación del usuario, el agente de identidades necesita saber contra qué servicio OIDC debe autenticar al usuario.
Keycloak proporciona flujos de autenticación estándar como el flujo de navegador y permite la creación de flujos personalizados y asociados con clientes Keycloak.
SASE aprovecha esta característica creando flujos de autenticación en los que se pide a los usuarios que proporcionen información sobre el arrendatario.
Basándose en esta información, los flujos de autenticación pueden presentar los proveedores de identidad disponibles para que el usuario los seleccione.
Con esta información, el agente puede redirigir a los usuarios al servicio de identidad apropiado. Un dominio con varios clientes para cada aplicación SaaS: Si la aplicación-arrendatario puede identificarse a partir de la URL o de las cabeceras de solicitud HTTP, el componente proxy SASE puede configurarse para utilizar un cliente para cada aplicación-arrendatario.
En este caso, se pueden emplear flujos de navegador estándar con diferentes conjuntos de proveedores de identidad y asociarlos con las entidades cliente correspondientes en Keycloak.
La ventaja de esto es que no se pide al usuario que dé el nombre del arrendatario, lo que mejora la experiencia del usuario.
En resumen, estas estrategias permiten a las soluciones SASE gestionar eficazmente la autenticación para aplicaciones SaaS multiarrendatario, aprovechando las capacidades de Keycloak como agente de identidad.
Selección de clientes OIDC basada en políticas
El broker Keycloak ofrece soporte para múltiples reinos y múltiples clientes dentro de cada reino.
Permite flujos de autenticación estándar, la creación de flujos de autenticación personalizados y la asociación de estos flujos con los clientes.
La funcionalidad del broker Keycloak también permite la intermediación de sesiones de autenticación entre los mecanismos de autenticación del lado del usuario y los servicios de autenticación backend (upstream).
Ya hemos hablado anteriormente de cómo Keycloak puede solicitar a los usuarios que identifiquen su aplicación-inquilino y seleccionen el servicio de identidad para la autenticación.
Estas capacidades también deben ser aprovechadas por el proxy SASE, que actúa como cliente OIDC (también conocido como relé OIDC) para varias aplicaciones de clientes, incluyendo aplicaciones multi-arrendatario.
El proxy SASE necesita soportar múltiples clientes OIDC.
Un enfoque es tener un conjunto de clientes OIDC para cada cliente, asegurando que las configuraciones relacionadas con la autenticación específicas del cliente estén aisladas de las demás.
Típicamente, el conjunto de OIDC de cada cliente de SASE está asociado con un dominio en Keycloak.
En escenarios donde un cliente del proxy SASE tiene múltiples aplicaciones, cada una con su propio nombre de dominio, se hace necesario proporcionar aislamiento entre múltiples administradores de aplicaciones.
En tales casos, debe configurarse un subconjunto de clientes OIDC, con un cliente asignado a cada aplicación.
Para muchas aplicaciones, un único cliente OIDC es suficiente si se trata de aplicaciones de un único inquilino o si el inquilino no puede ser identificado a partir del tráfico, como se ha comentado anteriormente.
Sin embargo, si se puede identificar al arrendatario, se puede configurar un cliente OIDC para cada aplicación-arrendatario.
Debido al requisito de múltiples clientes OIDC, el proxy SASE debe ofrecer un mecanismo para seleccionar el cliente OIDC apropiado.
Aquí es donde la selección de OIDC basada en políticas se vuelve crucial.
Se utiliza una tabla de políticas con múltiples políticas, en la que cada política apunta al registro de cliente OIDC correspondiente.
Durante el flujo de tráfico, el proxy SASE comprueba si se requiere autenticación OIDC y, a continuación, compara el cliente, el nombre de dominio de la aplicación y la aplicación-arrendatario con las políticas de la tabla.
Si se encuentra una coincidencia, se utiliza el registro de cliente OIDC correspondiente para comunicarse con el agente.
Algunas implementaciones pueden tener múltiples tablas de políticas, con una tabla dedicada a cada cliente, para agilizar el proceso de cotejo de políticas.
La ZTNA NextGen se adaptará a las aplicaciones multiusuario
ZTNA (Zero Trust Network Access) dentro de las soluciones SASE (Secure Access Service Edge) desempeña un papel crucial en la seguridad de las aplicaciones.
Permite descargar las tareas de autenticación y autorización de las aplicaciones, lo que permite a los desarrolladores centrarse en su lógica empresarial principal.
Este enfoque mejora la productividad y refuerza la seguridad general.
Las vulnerabilidades de elusión de autenticación y escalada de privilegios son comunes en las aplicaciones, ya que no todos los desarrolladores tienen experiencia en seguridad.
Descargar la seguridad puede eliminar estas vulnerabilidades, garantizando una mayor resistencia de las aplicaciones.
Centralizar la seguridad en un lugar común, como SASE, simplifica el trabajo de los administradores de seguridad, que sólo tienen que gestionar una única interfaz para todas las aplicaciones.
Para lograr tanto seguridad como flexibilidad, la próxima generación de soluciones ZTNA dentro de SASE debe abordar diversos tipos de aplicaciones.
Muchas de las soluciones ZTNA existentes suelen tener dificultades para soportar eficazmente las aplicaciones multi-tenant.
Se espera que las futuras mejoras incorporen la funcionalidad de agente de identidades y la selección de clientes OIDC (OpenID Connect) basada en políticas para atender a una amplia gama de escenarios de aplicación.
-
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.