Es posible que muchos de vosotros conozcáis Identity Protectión de AzureAD, servicio el cual nos permite que analice los inicios de sesión de nuestros usuarios y medir su riesgo en tiempo real. Identity Protectión detecta múltiples riesgos, entre los que se incluyen:
- Uso de una dirección IP anónima
- Viaje atípico
- Dirección IP vinculada al malware
- Propiedades de inicio de sesión desconocidas
- Credenciales con fugas
- Difusión de contraseña
Estos riesgos son tomados por MSFT para que nos permita tomar decisiones de corrección de forma automatizada, ejemplo, bloquear un usuario, pedirle que se vuelta a autenticar o que se autentique con un método específico (Microsoft Azure: Requerir Intensidad de Autenticación (FIDO2) con las Reglas de Acceso Condicional), etc.. Todo esto se vasa en la investigación de riesgos:
- Usuarios de riesgo
- Inicios de sesión no seguros
- Detecciones de riesgo
Yo os voy a mostrar como con directivas de Acceso Condicional podemos bloquear un usuario cuando se detecte un nivel de riesgo determinado o pedirle que se autentique forzando un método en concreto. Dicho esto, aqui os dejo información al respecto para que podáis ampliar información:
- ¿Qué es Azure Active Directory Identity Protection? – Microsoft Entra | Microsoft Learn
- Condiciones en la directiva de acceso condicional – Microsoft Entra | Microsoft Learn
Aquí os dejo la infografía del artículo de hoy, voy a iniciar sesión con un usuario desde España y luego con la típica aplicación de VPN (TunnelBear) que te permite “esconder” tu IP Pública y que te identifique tu sesión en otro país:
Lo primero que haré será crear una directiva de Acceso Condicional para que cuando detecte que mi el usuario esté en un nivel de riesgo determinado, mi directiva será creada para un único usuario de prueba, pero hay que hacerlo lo más global posible:
Importante que siempre se validen todas las aplicaciones que tengamos registradas en AzureAD: 
Aquí es donde viene lo importante, yo para la prueba voy a definir que ante cualquier nivel de riesgo de usuario 
o riesgo de inicio de sesión de cualquier nivel para que podamos ver rápidamente el efecto: 
Lo que haré será bloquear el acceso si el usuario tiene algún nivel de riesgo: 
Ahora que ya tenemos nuestra directiva de acceso condicional configurada, he iniciado sesión con la cuenta que vamos a utilizar de pruebas desde España, pero luego de 5min hemos iniciada sesión desde el mismo equipo para utilizando previamente TunnelBear para que la nueva conexión nos identifique en otro pais.
TunnelBear es una aplicación que te conecta mediante VPN a otra parte del mundo y desde ahí con su IP “anonimizada” te permite navegar en Internet evitando mostrar tu propia IP. Creo que no necesita ni explicación, simplemente la instalas, tienes 1GB de transferencia mensual gratis y pulsamos en algún país donde queremos conectarnos via VPN: 
En cuestión de unos segundos ya estamos conectados desde Lituania:
Si ahora tratamos de identificar la IP Pública que tenemos ahora mismo, vemos que ya no es nuestra IP Pública de nuestro ISP y si la de otro país: 
Una vez conectados a la VPN tratamos de conectarnos a los servicios de O365 y … el acceso condicional + Identity Protection han hecho su trabajo y nos bloquea el acceso. 
Ahora si accedemos al portal de Azure, podemos ver en la sección de Seguridad – Usuarios en riesgo se puede ver claramente la IP desde donde se está conectando el usuario que es la misma que hemos visto anteriormente: 
Y fijamos, MSFT detecta esa IP como una IP clasificada como “anónima”, que es justo lo que hace TunnelBear, pero AzureAD lo tiene bien identificado: 
Ahora que ya sabemos como bloquear, os voy a mostrar que podemos conceder el acceso pero para ello debe por ejemplo requerir autenticación mutilfactor: 
Si volvemos a intentar iniciar sesión, mirad, ya nos pide que nos autentiquemos con alguno de los métodos de doble factor de autenticación que hemos configurado previamente en el usuario: 
También podemos configurar que si detecta un nivel de riesgo xxxx, en vez de bloquear o pedirle autenticación multifactor pero debido a que se ha encontrado una vulnerabilidad por fatiga de autenticación: Defend your users from MFA fatigue attacks – Microsoft Community Hub
Se pueden utilizar otros métodos para evitar este ataque que os he comentado, pero a mi me gusta utilizar la opción de MFA Resistente que ya os había comentado en su momento (Microsoft Azure: Requerir Intensidad de Autenticación (FIDO2) con las Reglas de Acceso Condicional), la configuración es muy sencilla pero debéis utilizar vuestras tarjetas FIDO2 :-). 
Claramente, si vuelvo a iniciar sesión con el usuario con alguno de los niveles de riesgo definidos en la directiva de Acceso Condicional, pues me pide que tengo que utilizar la tarjeta inteligente y sin otra opción: 
Creo que es una solución súper fácil de implementar, segura y que nos permite mantener el control de la cantidad ingente de intentos de inicio de sesión que todos tenemos.
Espero que os sea de utilidad!!
