Que es Azure Identity Protection?
Azure Identity Protection, ahora Microsoft Entra ID Protection, es la capa de deteccion y respuesta al riesgo para las identidades de Microsoft Entra. Evalua senales que pueden indicar una compromision de cuenta y las expone como riesgo de usuario, riesgo de inicio de sesion, usuarios de riesgo y detecciones de riesgo.
El punto operativo importante es que la deteccion por si sola no contiene un ataque. Un tenant puede mostrar usuarios de riesgo e inicios de sesion de riesgo en el portal mientras sigue permitiendo que el atacante continue si ninguna politica exige remediacion, autenticacion multifactor, reautenticacion, cambio de contrasena o bloqueo. Este articulo se centra en esa brecha: el riesgo es visible, pero la respuesta del tenant esta ausente, incompleta o demasiado limitada.
Las recomendaciones actuales de Microsoft situan los controles basados en riesgo dentro de Acceso Condicional. Las politicas de riesgo heredadas de Identity Protection todavia existen en algunos tenants, pero la documentacion de Microsoft indica que las politicas heredadas de riesgo de usuario y riesgo de inicio de sesion deben migrarse a Acceso Condicional y que su retiro esta previsto para el 1 de octubre de 2026.
Como Funciona Azure Identity Protection
Identity Protection utiliza dos conceptos de riesgo estrechamente relacionados:
El riesgo de inicio de sesion es la probabilidad de que una solicitud de autenticacion especifica no la realice el propietario legitimo de la identidad. Se evalua durante el inicio de sesion y puede usarse como condicion en Acceso Condicional.
El riesgo de usuario es la probabilidad de que la cuenta de usuario misma este comprometida. Puede persistir mas alla de un unico inicio de sesion y puede requerir cambio de contrasena, revocacion de sesion, investigacion por un administrador o descarte.
Microsoft documenta detecciones de riesgo como credenciales filtradas, direccion IP anonima, viaje atipico, propiedades de inicio de sesion inusuales, direccion IP maliciosa, reglas sospechosas de manipulacion de bandeja de entrada, spray de contrasenas, token anomalo y otras senales. Algunas detecciones son en tiempo real, mientras que otras se calculan fuera de linea y pueden aparecer mas tarde. Ese tiempo importa operativamente: un evento de riesgo puede surgir despues de que la autenticacion original ya se haya completado.
Por Que las Politicas de Riesgo Fallan en la Practica
Identity Protection rinde por debajo de lo esperado cuando los equipos tratan el panel como si fuera el control. Los modos de fallo comunes incluyen:
- ninguna politica de Acceso Condicional usa condiciones de riesgo de inicio de sesion o de usuario
- las politicas quedan en modo solo informe despues de las pruebas
- las politicas de riesgo cubren usuarios piloto pero no usuarios privilegiados ni a la poblacion general
- las cuentas de emergencia se excluyen sin monitoreo compensatorio
- los usuarios hibridos no pueden completar la autoremediacion porque la escritura diferida de contrasena no esta disponible donde se necesita
- las notificaciones de usuarios de riesgo llegan a un buzon que nadie revisa
- los analistas pueden descartar el riesgo sin un estandar de evidencia documentado
- los service principals se confunden con cobertura de Acceso Condicional orientada a usuarios
El ultimo punto es importante. Las politicas de riesgo de usuario y de inicio de sesion se dirigen a los inicios de sesion de usuarios. El riesgo de identidades de carga de trabajo y service principals requiere un modelo de control diferente y no debe asumirse cubierto por las politicas de riesgo de usuario humano.
La Cadena de Ataque Sin Respuesta al Riesgo
Escenario 1 - Credenciales Filtradas
Las credenciales de un usuario aparecen en datos de brechas o se evaluan de otro modo como riesgosas. Identity Protection eleva el riesgo de usuario, pero ninguna politica de riesgo de usuario exige remediacion. La cuenta sigue siendo utilizable hasta que otro control bloquee al atacante.
Escenario 2 - Un Inicio de Sesion de Riesgo que Aun Asi se Completa
Un inicio de sesion tiene riesgo medio o alto debido a senales como infraestructura anonima, propiedades de inicio de sesion inusuales o viaje atipico. Si no se aplica ninguna politica de riesgo de inicio de sesion, la sesion puede completarse igualmente. Existe una entrada de registro, pero el atacante ya obtuvo acceso.
Escenario 3 - Spray de Contrasenas Contra Cuentas Cloud
Una campana de spray de contrasenas genera un ruido de autenticacion amplio y puede producir detecciones de riesgo. Si los inicios de sesion exitosos no se fuerzan a traves de autenticacion adicional (step-up) o no se bloquean segun la politica, el atacante conserva las sesiones exitosas.
Escenario 4 - Riesgo Descartado Sin Investigacion
Un usuario de riesgo se descarta porque la alerta resulta inconveniente o ruidosa. Si el proceso de descarte no exige evidencia, el tenant puede normalizar una compromision real y eliminar la senal que los defensores necesitaban.
Deteccion
Senales de Riesgo a Monitorear
| Senal | Que Indica | Uso Operativo |
|---|---|---|
| Credenciales filtradas | Se encontraron credenciales asociadas a la cuenta en material comprometido conocido | Tratar como evidencia de compromision de cuenta hasta su revision |
| Direccion IP anonima | El inicio de sesion provino de infraestructura de anonimato | Correlacionar con dispositivo, ubicacion e historial de usuario |
| Viaje atipico | La geografia del inicio de sesion es incoherente con la actividad reciente | Revisar patrones de viaje imposibles o sospechosos |
| Propiedades de inicio de sesion inusuales | El inicio de sesion difiere del comportamiento normal del usuario | Util combinado con el contexto de dispositivo y ubicacion |
| Direccion IP maliciosa | La infraestructura de origen esta asociada a actividad maliciosa | Mayor urgencia para usuarios privilegiados |
| Spray de contrasenas | Se detecta un comportamiento amplio de adivinacion de contrasenas | Correlacionar con bloqueos, fallos e inicios de sesion exitosos |
| Token anomalo | El comportamiento del token parece sospechoso | Revisar la actividad de sesion y revocar cuando corresponda |
Eventos e Informes a Revisar
La deteccion debe incluir:
- el informe de usuarios de riesgo
- el informe de detecciones de riesgo
- los registros de inicio de sesion con nivel y detalle de riesgo
- los resultados de Acceso Condicional para inicios de sesion de riesgo
- los registros de auditoria para descarte de riesgo, restablecimiento de contrasena, cambios de politica y acciones administrativas
- el contexto de rol privilegiado para las identidades afectadas
Un inicio de sesion de alto riesgo para un administrador global no tiene la misma prioridad operativa que un evento de bajo riesgo para una cuenta de prueba inactiva. La alerta debe incluir rol, dispositivo, ubicacion, aplicacion, resultado de politica y desenlace de la sesion.
Remediacion
Identity Protection se vuelve util cuando el riesgo desencadena una respuesta. Un panel sin Acceso Condicional aplicado es solo visibilidad.
1. Configurar Politicas de Riesgo Separadas
Las recomendaciones de Microsoft advierten contra combinar las condiciones de riesgo de usuario y de inicio de sesion en la misma politica de Acceso Condicional. Cree politicas separadas para que cada condicion de riesgo tenga una via de respuesta clara.
Para el riesgo de inicio de sesion, Microsoft recomienda exigir autenticacion multifactor para riesgo medio y alto. Para el riesgo de usuario, Microsoft recomienda exigir remediacion del riesgo cuando el riesgo de usuario es alto. Las organizaciones pueden elegir umbrales mas estrictos, pero deben equilibrar seguridad, falsos positivos e interrupcion del usuario.
2. Usar el Modo Solo Informe y Luego Aplicar
El modo solo informe es util para el despliegue. No es un estado final. Revise que usuarios, aplicaciones y escenarios se verian afectados, corrija las roturas esperadas y luego cambie la politica a Activado. Mantenga un registro fechado del despliegue para que las politicas en modo solo informe no se conviertan en configuraciones permanentes sin aplicar.
3. Hacer que la Autoremediacion Funcione
La autoremediacion depende de requisitos previos. Los usuarios deben estar registrados para la autenticacion multifactor de Microsoft Entra antes de poder satisfacer la remediacion basada en MFA. Los usuarios hibridos pueden requerir escritura diferida de contrasena para escenarios de cambio de contrasena seguro. Si faltan esos requisitos, los usuarios pueden quedar bloqueados y requerir intervencion del administrador.
4. Definir el Flujo de Trabajo del Analista
Una politica de riesgo no reemplaza la investigacion. Defina quien puede:
- confirmar la compromision de un usuario
- descartar el riesgo de usuario
- restablecer contrasenas
- revocar sesiones
- desbloquear usuarios
- aprobar exclusiones
- actualizar los umbrales de riesgo de Acceso Condicional
Cada accion debe tener un estandar de evidencia. Descartar el riesgo porque el usuario dice que viajo no equivale a validar el dispositivo, la IP, el metodo de autenticacion y la actividad de sesion.
5. Revisar Exclusiones y Cuentas de Servicio
Las cuentas de acceso de emergencia pueden requerir un tratamiento especial, pero las exclusiones deben ser pocas y estar muy monitoreadas. Las cuentas de servicio y las identidades de carga de trabajo no deben excluirse silenciosamente de la conversacion sobre riesgo; pueden necesitar Acceso Condicional para identidades de carga de trabajo, identidades administradas, rotacion de credenciales o un monitoreo diferente.
Secuencia de Despliegue Segura
Un despliegue seguro no comienza bloqueando todo el tenant sin evidencia. Comience con politicas en modo solo informe para la poblacion prevista, revise el impacto de la politica, corrija los requisitos previos de registro y escritura diferida de contrasena, y luego aplique la politica por etapas. Las identidades privilegiadas deben priorizarse porque un inicio de sesion de riesgo exitoso para un administrador tiene un radio de impacto mucho mayor que el mismo evento en una cuenta de bajo privilegio.
Mantenga el despliegue medible. Registre cuantos inicios de sesion de riesgo se habrian bloqueado o desafiado, cuantos usuarios pudieron autoremediarse, que cuentas estan excluidas y que incidentes requirieron accion del administrador. Esas cifras ayudan a distinguir un programa de proteccion funcional de una politica que existe pero no se puede aplicar de forma segura.
Validacion Tras Habilitar la Respuesta al Riesgo
Valide el control tanto desde el portal como desde la perspectiva del atacante:
- confirme que las politicas de riesgo de inicio de sesion y de usuario estan habilitadas, no solo configuradas
- confirme que los usuarios objetivo incluyen identidades privilegiadas y usuarios normales dentro del alcance
- confirme que los usuarios excluidos estan documentados y monitoreados
- revise los inicios de sesion de riesgo recientes y verifique que se aplico el resultado de politica previsto
- confirme que los inicios de sesion exitosos de alto riesgo son raros, explicables e investigados
- confirme que los administradores pueden confirmar compromision, descartar riesgo, revocar sesiones y restablecer credenciales mediante flujos de trabajo documentados
- pruebe el enrutamiento de alertas para que las notificaciones de usuarios de riesgo lleguen al equipo de respuesta
- revise si las identidades de carga de trabajo requieren Acceso Condicional o monitoreo separados
Si el tenant detecta el riesgo pero permite que los usuarios de riesgo continuen sin remediacion, el control esta incompleto.
Como Detecta Esto EtcSec
EtcSec audita si las detecciones de riesgo estan vinculadas a una via de respuesta aplicada.
La categoria Risk Protection destaca la ausencia de politica de riesgo de inicio de sesion, la ausencia de politica de riesgo de usuario, y una respuesta de tenant debil donde la actividad de riesgo es visible pero la aplicacion esta ausente o incompleta.
Esa es la brecha operativa que aborda este articulo: detecciones de riesgo sin contencion.
Controles Relacionados
Identity Protection funciona mejor cuando se combina con Identidad Azure: MFA, metodos y Security Defaults, Brechas acceso condicional Entra ID: que errores dejan una exposicion real, Acceso privilegiado Azure: roles, PIM y administracion permanente, Cuentas invitado Azure: gobierno, MFA y riesgo de acceso externo, y Registros de Aplicaciones Azure: Apps Sobreprivilegiadas. De lo contrario, el tenant puede detectar el riesgo pero seguir dejando faciles de explotar las rutas adyacentes de privilegio y aplicaciones.
Referencias Principales
Explore las páginas de identidad que apoyan este tema