Proteger las identidades de los usuarios es una de las tareas más críticas en la administración de servicios en la nube. Azure Active Directory ofrece mecanismos para detectar inicios de sesión sospechosos, como los llamados viajes imposibles, donde un mismo usuario aparece autenticándose desde ubicaciones geográficas distantes en un periodo muy corto de tiempo. A continuación se explica cómo funciona este escenario en la práctica y qué herramientas tienes a tu disposición para responder ante estos riesgos.
¿Cómo se simula un viaje imposible en Azure Active Directory?
El concepto de viaje atípico o atypical travel se refiere a cuando un usuario inicia sesión desde una ubicación y, minutos después, aparece autenticándose desde otra ubicación geográficamente lejana, algo que sería físicamente imposible. Para reproducir este escenario se utilizó un usuario creado en México, específicamente en Metepec [01:42].
El proceso fue el siguiente:
- Se realizaron inicios de sesión exitosos desde Metepec, México, para establecer el comportamiento habitual del usuario [03:00].
- Luego, desde una máquina virtual ubicada en Frankfurt, Alemania, se inició sesión utilizando un navegador Tor [04:14]. La red Tor redirigió la petición, y Azure Active Directory registró el inicio de sesión como proveniente de Budapest, Hungría.
- Minutos después, se repitió el proceso desde otra máquina virtual en Campinas, São Paulo, Brasil [06:05], donde además se intentaron contraseñas incorrectas antes de acceder con la correcta.
Este flujo generó señales de alerta porque el usuario supuestamente estuvo en tres países distintos en cuestión de minutos.
¿Qué detecta Azure Active Directory en los reportes de riesgo?
Al revisar los user sign-ins del usuario Luis en el portal de Azure [09:37], se pudo observar una línea de tiempo detallada:
- A las 10:17 a.m. inició sesión desde Metepec, México, de forma exitosa.
- A las 10:18 apareció un inicio de sesión desde Budapest, Hungría, a través de la red Tor.
- Posteriormente se registraron accesos desde Frankfurt y São Paulo.
- En São Paulo hubo dos o tres intentos fallidos antes de un acceso exitoso.
Azure Active Directory clasifica automáticamente estas señales como detecciones de riesgo [10:16]. En la sección de usuarios en riesgo, el usuario Luis apareció marcado con una última señal a las 10:24, justo después de la secuencia de inicios desde múltiples países.
¿Qué acciones puedes tomar ante un usuario comprometido?
Cuando Azure Active Directory identifica un usuario en riesgo, tienes varias opciones [10:55]:
- Descartar el riesgo (dismiss) si confirmas que el comportamiento fue legítimo.
- Confirmar que la identidad está comprometida para activar medidas de protección.
- Resetear la contraseña del usuario para impedir futuros accesos no autorizados.
- Contactar al usuario y mostrarle las ubicaciones desde donde se detectaron los inicios de sesión.
- Registrar al usuario en multi-factor authentication para agregar una capa adicional de seguridad.
¿Cómo configurar políticas de acceso condicional para prevenir estos escenarios?
El acceso condicional (Conditional Access) [07:07] permite definir reglas que controlan bajo qué circunstancias un usuario puede acceder a los recursos. Funciona como una serie de condiciones encadenadas: si se cumple una condición y además se cumple otra, entonces se bloquea el acceso, se solicita multi-factor authentication o se pide un cambio de contraseña.
¿Qué son las ubicaciones de confianza y cómo se configuran?
Antes de crear una política, es recomendable definir ubicaciones de confianza (named locations) [07:25]. Por ejemplo, puedes indicar que las peticiones desde México o Colombia no deben considerarse sospechosas porque ahí se encuentran tus usuarios legítimos. También puedes registrar rangos de direcciones IP específicos, como los de una oficina o un home office [08:15].
Al crear la política de acceso condicional se configura:
- A qué usuarios aplica: todos, algunos roles, grupos específicos o usuarios individuales.
- A qué aplicaciones aplica: todas las aplicaciones en la nube o solo aquellas que manejan información sensible [09:00].
- Qué ubicaciones incluir o excluir: se pueden incluir todas las ubicaciones y excluir las de confianza.
- Qué acción tomar: permitir el acceso con requisitos adicionales como MFA o bloquear completamente.
Un punto fundamental es tener mucha cautela al configurar estas políticas [09:08]. Si aplicas un bloqueo generalizado sin crear excepciones adecuadas, podrías bloquearte a ti mismo como administrador. La recomendación es probar la política primero en modo de solo reporte y, una vez verificado su comportamiento, activar las restricciones como multi-factor authentication.
La latencia también es un factor a considerar al trabajar con máquinas virtuales en diferentes regiones [05:32]. La recomendación general es desplegar recursos en la región con mejor latencia respecto a tu ubicación. En el escenario demostrado, la conexión desde México hacia Alemania y Brasil presentó mayor lentitud comparada con una conexión hacia Estados Unidos.
Si ya trabajas con Azure Active Directory, experimenta con las detecciones de riesgo y las políticas de acceso condicional en un entorno de prueba. Comparte tu experiencia configurando estas protecciones y qué estrategias te han funcionado mejor para proteger las identidades de tus usuarios.
