Zero Trust se fundamenta en la definición de controles granulares y políticas de autorización por aplicación, usuario y dispositivo. Para ello, es imprescindible contar con un sistema con un nivel de granularidad suficiente, a fin de cumplir con los requisitos normativos y de seguridad. Sin embargo, un número tan elevado de controles supone un posible inconveniente: para resolver los problemas de los usuarios, un administrador debe tener en cuenta una compleja combinación de variables de las aplicaciones, la identidad de los usuarios y la información de los dispositivos, y todo esto puede requerir un análisis minucioso de los registros.
Creemos que hay una forma mejor de hacerlo. Por este motivo, a partir de hoy, los administradores pueden auditar fácilmente todas las sesiones de usuario activas y los datos asociados utilizados por sus políticas de Cloudflare One. Esto permite lo mejor de ambos mundos: controles muy granulares al mismo tiempo que se mantiene una capacidad mejorada de resolución y diagnóstico de problemas de las implementaciones Zero Trust en un único y sencillo panel de control. Ahora los administradores pueden acceder a la información que anteriormente se encontraba en el navegador de un usuario o que cambiaba dinámicamente, sin necesidad de molestar a un usuario final o de analizar los registros.
Una introducción rápida a la autenticación y la autorización de aplicaciones
La autenticación y la autorización son los dos componentes que evalúa una política Zero Trust antes de permitir que un usuario acceda a un recurso.
La autenticación es el proceso de verificar la identidad de un usuario, un dispositivo o un sistema. Algunos de los métodos más comunes de autenticación son la especificación de nombres de usuario y contraseñas, la presentación de un certificado digital o incluso factores biométricos como una huella dactilar o un reconocimiento facial. La autenticación multifactor (MFA) requiere dos o más métodos independientes de autenticación para una mayor seguridad, por ejemplo, una clave de hardware junto con una contraseña.
La autorización es el proceso de otorgar o denegar el acceso a recursos o permisos específicos una vez que se ha autenticado con éxito una entidad. Define qué puede y no puede hacer la entidad autenticada en el sistema.
Mecanismos de autenticación/autorización de aplicaciones
Las aplicaciones web, en las que nos centraremos, suelen utilizar cookies HTTP para gestionar la autenticación y la autorización.
Autenticación:
Inicio de sesión: cuando un usuario inicia sesión en una aplicación web especificando su nombre de usuario y contraseña, la aplicación verifica estas credenciales respecto a su base de datos o en un proveedor de identidad (IdP). También es posible aplicar otros métodos de autenticación para un mecanismo de autenticación de varios factores. Si estos coinciden, el servidor o el servicio de seguridad externo (p. ej., Cloudflare Access) considera que el usuario se ha autenticado.
Creación de cookies/tokens: el servidor crea a continuación una sesión para el usuario como una cookie o un token web JSON. La cookie es válida durante cierto tiempo, hasta que sea necesario que el usuario se vuelva a autenticar.
Envío y almacenamiento de cookies: el servidor envía una respuesta al navegador del usuario, y esta incluye en la cookie el ID de sesión y otra información de identificación sobre el usuario. A continuación, el navegador almacena esta cookie, que se utiliza para reconocer el usuario en sus solicitudes posteriores.
Autorización:
Solicitudes posteriores: para todas las solicitudes posteriores enviadas a la aplicación web, el navegador del usuario incluye automáticamente la cookie (con el ID de sesión y otra información de identificación) en la solicitud.
Verificación del lado del servidor: el servidor recibe los datos del usuario de la cookie y comprueba si la sesión es válida. Si es válida, el servidor recupera también los detalles del usuario y sus permisos de acceso asociados con ese ID de sesión.
Decisión de autorización: en función de los permisos de acceso del usuario, el servidor decide si se autoriza al usuario a realizar la operación solicitada o a acceder al recurso solicitado.
De esta forma, el usuario se mantiene autenticado (y su autorización se puede comprobar) para todas las solicitudes posteriores a su inicio de sesión, hasta que esta caduque o hasta que el usuario cierre la sesión.
En las aplicaciones web modernas, este estado de la sesión se suele almacenar como un token web JSON (JWT).
Depuración de la autenticación basada en JWT
Los JWT se utilizan en muchas aplicaciones web modernas, y en soluciones de acceso a la red Zero Trust (ZTNA) como Cloudflare Access, para la autenticación y la autorización. Un JWT incluye una carga que codifica la información acerca del usuario y posiblemente otros datos, e incluye la firma del servidor para evitar su manipulación. Los JWT se utilizan a menudo sin estado, lo que significa que el servidor no mantiene una copia de cada JWT (simplemente los verifica y descodifica cuando llegan con las solicitudes). Esta condición "sin estado" de los JWT significa que no tienes que depender de un sistema central para gestionar las sesiones de los usuarios, lo que evita que surjan problemas de escalabilidad cuando aumente el número de usuarios que accedan a un sistema.
No obstante, esta condición "sin estado" de los JWT hace que la depuración de la autenticación basada en JWT resulte complicada si no se dispone del JWT específico de un usuario. Estas son las razones:
1. Especificidad de los tokens: cada JWT es específico de un usuario y de una sesión. Contiene información (afirmaciones) sobre el usuario, la autoridad emisora, la fecha y hora de emisión del token, la fecha de caducidad y posiblemente otros datos. Por lo tanto, para depurar un problema, a menudo necesitas el JWT exacto que causa el problema.
2. No hay registros del lado del servidor: puesto que los JWT son sin estado, el servidor no almacena las sesiones por defecto. No puede buscar tokens anteriores o su estado asociado, a menos que se haya diseñado específicamente para registrarlos. Esto no suele ser el caso, debido a consideraciones acerca de la privacidad y la minimización de los datos.
3. Problemas temporales: los problemas vinculados con los JWT pueden ser temporales (relacionados con el momento específico en que se ha utilizado el token). Por ejemplo, si un token había caducado cuando un usuario intentaba utilizarlo, necesitarías ese token específico para depurar el problema.
4. Privacidad y seguridad: los JWT pueden contener información confidencial, por lo que se deben manejar cuidadosamente. Obtener un JWT de un usuario podría exponer su información personal o sus credenciales de seguridad a quienquiera que esté depurando el problema. Asimismo, si un usuario envía su JWT mediante un canal no seguro a un desarrollador o a un servicio de asistencia informática, este podría ser interceptado (Cloudflare lanzó recientemente una solución gratuita, HAR Sanitizer, para ayudar a mitigar este problema).
Estos factores dificultan la resolución de problemas vinculados con la autenticación basada en JWT si no se dispone del token específico.
Una forma mejor de depurar los problemas de identidad
Nos propusimos desarrollar una forma mejor de depurar los problemas relacionados con la identidad de un usuario en Cloudflare Zero Trust sin necesidad de compartir los JWT o los archivos HAR. Ahora los administradores pueden ver la identidad del registro de un usuario (que se utiliza para las políticas de Gateway) y todas las sesiones de Access activas.
Esta información de la sesión incluye la identidad completa evaluada por Zero Trust, que incluye las afirmaciones del IdP, la información acerca de la postura del dispositivo, el contexto de red y más. Gracias a Cloudflare Workers KV, hemos podido desarrollar esta función sin añadir más carga a la lógica de autenticación de Access. Cuando un usuario se autentica con Access, su identidad asociada se guarda de inmediato en un par clave-valor en Workers KV. Todo esto tiene lugar en el contexto del evento de autenticación del usuario, lo que significa que el impacto en la latencia o la dependencia de un servicio externo son mínimos.
Esta función está disponible para todos los clientes en todos los planes Zero Trust. Si deseas empezar con Cloudflare Zero Trust, regístrate hoy mismo para conseguir una cuenta gratuita para hasta 50 usuarios. O bien colabora con los expertos de Cloudflare para comentar las opciones SSE o SASE para tu organización y abordar tus casos Zero Trust paso a paso.