En la seguridad de aplicaciones Zero Trust se deniega cualquier solicitud a una aplicación a no ser que supere un conjunto específico de políticas de seguridad definidas. La mayoría de soluciones Zero Trust permiten utilizar la identidad, el dispositivo y la ubicación del usuario como variables para definir estas políticas de seguridad.
Algunos clientes nos han comentado que querían más control y más personalización a la hora de definir sus políticas Zero Trust.
Desde hoy, estamos encantados de que las políticas de Access pueden analizar cualquier cosa antes de permitir al usuario acceder a una aplicación, y con cualquier cosa, nos referimos a absolutamente todo. Ahora puedes crear políticas que son personalizables hasta el infinito con la opción de reglas de evaluación externa, que te permite llamar a cualquier API durante la evaluación de una política de Access.
Por qué creamos reglas de evaluación externa
En los últimos años, hemos añadido la posibilidad de comprobar la información sobre la ubicación y el estado del dispositivo en Access. Sin embargo, siempre hay señales adicionales que se pueden tener en cuenta en función de la aplicación y los requisitos específicos de una organización. Nos propusimos dar a los clientes la posibilidad de comprobar cualquier señal que necesitaran sin ningún soporte directo en las políticas de Access.
Por ejemplo, el equipo de seguridad de Cloudflare necesitaba la capacidad de poder verificar el certificado mTLS de un usuario contra un registro para garantizar que solo el usuario correcto pudiera acceder a las aplicaciones desde un dispositivo de la empresa. Originalmente, pensaron en utilizar un Worker para comprobar el certificado del usuario después de que Access evaluara la solicitud. Sin embargo, esto implicaría la necesidad de desarrollo de software personalizado y mantenimiento a lo largo del tiempo. Con las reglas de evaluación externa, se puede realizar una llamada a la API para verificar si un usuario presenta el certificado correcto para su dispositivo. La llamada a la API se realiza a un Worker que almacena la correlación de los certificados mTLS y los dispositivos de los usuarios. El Worker ejecuta la lógica personalizada y luego devuelve un verdadero o un falso a Access.
Cómo funciona
Cloudflare Access es un proxy inverso situado frente a cualquier aplicación web. Si un usuario todavía no se ha autenticado, le aparecerá una pantalla de inicio de sesión para hacerlo. El usuario debe cumplir los criterios definidos en tu política de Access. Una política típica se parecería a lo siguiente:
● El correo electrónico del usuario termina en @ejemplo.com.
● El usuario se autentica con un token de hardware.
● El usuario inició sesión desde Estados Unidos.
Si el usuario supera la política, se le concede una cookie que le dará acceso a la aplicación hasta que expire su sesión.
Para evaluar al usuario según otros criterios personalizados, puedes añadir una regla de evaluación externa a la política de Access. La regla de evaluación externa requiere dos valores: un punto final de la API al que llamar, y una clave para verificar que cualquier respuesta a la solicitud procede de una fuente de confianza.
Después de que el usuario se haya autenticado con tu proveedor de identidad, toda la información sobre el usuario, el dispositivo y la ubicación se pasa a tu API externa. La API devuelve una respuesta de apto o no apto a Access, que permitirá o denegará el acceso al usuario.
/**
* Where your business logic should go
* @param {*} claims
* @returns boolean
*/
async function externalEvaluation(claims) {
return claims.identity.email === 'address@example.com'
}Un ejemplo de lógica para la API sería de la siguiente manera:
Donde el objeto de notificación incluye toda la información sobre el usuario, el dispositivo y la red que realiza la solicitud. Esta función externalEvaluation se puede ampliar para realizar cualquier lógica empresarial que se desee. Hemos puesto a disposición de los usuarios un repositorio de código abierto con código de ejemplo para usar las notificaciones de Access y verificar las claves de inicio de sesión de Access.
¡Es muy eficaz! Cualquier política de Access se puede ampliar ahora infinitamente para que se tenga en cuenta cualquier tipo de información antes de permitir el acceso a un usuario. Entre los ejemplos potenciales están:
● Integración con herramientas de protección de puntos finales con las que aún no nos integramos, desarrollando un middleware que compruebe la API de la herramienta de protección de puntos finales.
● Comprobación de las direcciones IP con respecto a las fuentes de amenazas externas.
● Llamada a los registros de usuarios específicos del sector.
● ¡Y mucho más!
Esta ampliación de las políticas de Access es solo el comienzo. En el futuro facilitaremos la toma de decisiones mediante programación sobre cómo se debe tratar a un usuario antes de acceder a una aplicación, y no se tratará solo de permitir o denegar el acceso.
Esta función está disponible hoy en el panel de control de Cloudflare Zero Trust. ¡Consulta esta guía para empezar!