Azure Identity Protection: Politicas de Riesgo

Que Es Azure Identity Protection?

Microsoft Entra ID Identity Protection es una capa de seguridad basada en riesgos que evalua continuamente las senales de inicio de sesion y riesgo de usuario para detectar compromiso de credenciales, viajes imposibles y ataques de phishing AiTM en tiempo real.

Sin politicas de Identity Protection, estas senales son visibles en los registros pero no generan ninguna respuesta automatizada. Un atacante que usa credenciales robadas de una base de datos de brechas se autenticara con exito — incluso si la puntuacion de riesgo es "alta" — a menos que una politica este configurada para bloquear el acceso.

Como Funciona

Identity Protection evalua dos tipos de riesgos:

Riesgo de inicio de sesion — senales: IP anonima (Tor, VPN), viaje atipico, propiedades inusuales de inicio de sesion, patrones de spray de contrasenas, anomalias de token (indicadores de phishing AiTM).

Riesgo de usuario — senales: credenciales filtradas (Microsoft monitorea bases de datos de brechas), actividad sospechosa, uso anomalo de token.

La Cadena de Ataque (Sin Politicas de Riesgo)

Escenario 1 - Credenciales Filtradas

# El atacante encuentra credenciales corp.com en una base de datos publica
# Identity Protection detecta y establece riesgo de usuario = Alto
# Sin politica: el atacante se autentica exitosamente
# Con politica: usuario de alto riesgo → requerir cambio de contrasena → atacante bloqueado

Escenario 2 - Phishing AiTM

# El atacante ejecuta proxy AiTM Evilginx2
# La victima ingresa credenciales + codigo MFA
# El atacante captura el token de sesion (elude MFA)
# Identity Protection detecta: anomalia de token
# Con politica: sesion de alto riesgo requiere re-autenticacion MFA → atacante bloqueado

Deteccion

Consulta SIEM (Elastic KQL)

azure.signinlogs.properties.risk_level_during_sign_in: ("high" OR "medium") AND
azure.signinlogs.properties.status.error_code: 0

Remediacion

💡 Accion Rapida: Active las politicas de riesgo de usuario e inicio de sesion en Identity Protection hoy. Ambas se pueden configurar en menos de 5 minutos.

1. Configurar Politica de Riesgo de Inicio de Sesion

Entra ID > Seguridad > Identity Protection > Politica de riesgo de inicio de sesion:
Usuarios: Todos los usuarios
Riesgo de inicio de sesion: Medio y superior
Acceso: Requerir MFA
Habilitar: Si

2. Configurar Politica de Riesgo de Usuario

Entra ID > Seguridad > Identity Protection > Politica de riesgo de usuario:
Riesgo de usuario: Alto
Acceso: Permitir acceso + Requerir cambio de contrasena
Habilitar: Si

3. Revisar Usuarios Marcados

Connect-MgGraph -Scopes "IdentityRiskEvent.Read.All", "IdentityRiskyUser.ReadWrite.All"
Get-MgRiskyUser -Filter "riskLevel eq 'high'" |
    Select-Object UserPrincipalName, RiskLevel, RiskLastUpdatedDateTime
Invoke-MgConfirmRiskyUserCompromised -UserIds @("id-usuario-comprometido")

Como EtcSec Detecta Esto

La categoria Risk Protection verifica si las politicas de riesgo de inicio de sesion y de usuario estan configuradas y aplicadas.

Los hallazgos incluyen: sin politica de riesgo, politicas en modo "solo informe", configuracion de notificaciones faltante.

ℹ️ Nota: EtcSec audita la configuracion de Identity Protection automaticamente. Ejecute una auditoria gratuita.

Lecturas Relacionadas

Este tema se entiende mejor cuando se compara con Seguridad de Identidad Azure: Por Que el MFA Solo No Es Suficiente, Brechas Acceso Condicional Azure: Bypass MFA y Acceso Privilegiado Azure: Demasiados Global Admins. Esos articulos cubren las rutas adyacentes, las hipotesis de privilegio y los fallos de control que suelen aparecer juntos en una evaluacion real.

• Seguridad de Identidad Azure: Por Que el MFA Solo No Es Suficiente
• Brechas Acceso Condicional Azure: Bypass MFA
• Acceso Privilegiado Azure: Demasiados Global Admins

Esa revision cruzada ayuda a validar si estas corrigiendo un fallo aislado o toda la cadena de exposicion alrededor de identidades, delegacion y privilegios.

Prioridades de Revision

Azure Identity Protection: Automatizando la Respuesta a Credenciales Filtradas debe tratarse como una exposicion real dentro de su tenant Entra ID y Azure, no como una configuracion aislada. El primer paso es definir el perimetro de revision: que admins, invitados, service principals, app registrations, exclusiones de politicas y cuentas break-glass estan afectados, que dependencias de negocio existen, que privilegios exponen y que excepciones de emergencia se fueron acumulando con el tiempo. Ese trabajo evita una remediacion superficial, porque el sintoma tecnico suele ser menor que el radio de impacto operativo. Cuando el equipo documenta el camino completo entre configuracion, privilegio y uso real, puede priorizar cambios que reducen riesgo sin romper accesos legitimos ni bloquear operaciones esenciales.

Controles Adyacentes a Revisar

Cuando un atacante entra en su tenant Entra ID y Azure, rara vez se queda en el primer hallazgo. Alrededor de Azure Identity Protection: Automatizando la Respuesta a Credenciales Filtradas, normalmente intenta encadenar el acceso con auth legacy, mala gobernanza de invitados, consentimientos amplios, cuentas de emergencia obsoletas y roles nunca revisados. Por eso la defensa debe revisar no solo la debilidad principal, sino tambien cada dependencia cercana que convierta un acceso inicial en persistencia o escalada. Hay que confirmar que identidades, roles, permisos y supuestos de confianza se pueden reutilizar. Si el cambio solo cierra un objeto, pero deja abiertas rutas vecinas, el riesgo real apenas mejora. Una revision seria de las cadenas de abuso es lo que convierte este tema en una accion de hardening y no en un parche aislado.

Evidencia y telemetria que conviene revisar

Una respuesta madura a Azure Identity Protection: Automatizando la Respuesta a Credenciales Filtradas necesita evidencia que pueda ser revisada por ingenieria y deteccion. Recopile logs de inicio de sesion, logs de auditoria, cambios de roles, eventos de consentimiento, cambios de credenciales y senales de riesgo, compare cambios recientes con ventanas de mantenimiento esperadas y separe cuentas u objetos cuyo comportamiento no tenga una justificacion de negocio clara. Esa evidencia debe responder tres preguntas: cuando aparecio la exposicion, quien puede seguir aprovechandola y si existen variantes similares en otra parte de su tenant Entra ID y Azure. Revisar telemetria tambien permite diferenciar deuda tecnica antigua de abuso activo o de controles relajados recientemente. Esa diferencia cambia por completo la prioridad, la comunicacion y el orden correcto de remediacion.

Debilidades vecinas que deben entrar en la revision

Muy pocos entornos contienen Azure Identity Protection: Automatizando la Respuesta a Credenciales Filtradas de forma aislada. En la practica, la misma zona del tenant o del directorio suele contener tambien auth legacy, mala gobernanza de invitados, consentimientos amplios, cuentas de emergencia obsoletas y roles nunca revisados, y esas debilidades vecinas determinan si la exposicion se queda en un problema molesto o se convierte en un camino critico. Revise owners compartidos, permisos heredados, excepciones duplicadas y atajos administrativos que ya nadie cuestiona. Si el mismo patron de riesgo se repite en varios objetos, lo mas probable es que exista una falla de proceso y no solo un error tecnico individual. Esa vista ampliada mejora la probabilidad de eliminar la ruta completa y no solo una pieza visible.

Orden de remediacion que reduce riesgo rapido

En Azure Identity Protection: Automatizando la Respuesta a Credenciales Filtradas, la remediacion debe seguir un orden que baje el riesgo antes de perseguir la perfeccion. Primero elimine las rutas con mayor valor de escalada, despues proteja las identidades u objetos mas sensibles y, por ultimo, corrija los problemas de higiene secundarios. Use Conditional Access, PIM, minimo privilegio, access reviews, validacion de owners de aplicaciones, flujos de aprobacion y MFA fuerte como conjunto de controles objetivo. Cada cambio debe tener owner, nota de rollback y una validacion clara. Esa disciplina evita que el trabajo se detenga despues de la primera mejora tecnica. Si una reforma completa no es posible hoy, documente controles intermedios y programe el trabajo estructural para el siguiente revision operativa semanal y revision de hardening mensual.

Como validar despues de cada cambio

Tras modificar cualquier configuracion relacionada con Azure Identity Protection: Automatizando la Respuesta a Credenciales Filtradas, valide el resultado desde la vista del administrador legitimo y desde la vista de la ruta de ataque. Confirme que usuarios y sistemas autorizados siguen funcionando y demuestre a la vez que el camino peligroso ya no entrega el mismo apalancamiento. Recoja de nuevo logs de inicio de sesion, logs de auditoria, cambios de roles, eventos de consentimiento, cambios de credenciales y senales de riesgo, revise aprobaciones y verifique que ningun objeto vecino conserva una via de escape. La validacion tambien debe incluir criterios de exito escritos. En equipos maduros, un cambio se cierra solo cuando el camino de riesgo desaparece, el servicio sigue operativo y el estado final coincide con el objetivo de hardening.

Ownership, escalado y gobierno

Los temas como Azure Identity Protection: Automatizando la Respuesta a Credenciales Filtradas fallan cuando se corrige el sintoma tecnico pero nadie asume el control a largo plazo. Asigne responsabilidades claras entre ingenieria de identidad, seguridad cloud, responsables IAM y equipos de aplicaciones, defina quien aprueba excepciones y que equipo debe autorizar la reintroduccion de un objeto riesgoso. Este gobierno no es burocracia gratuita. Sirve para evitar que una migracion, una urgencia o una integracion de terceros vuelva a abrir la misma ruta unas semanas despues. Documente los puntos de decision que hicieron posible la debilidad y actualice el proceso circundante para que la siguiente solicitud se evalúe contra la nueva baseline y no contra un atajo historico.

Preguntas utiles para la revision

Durante una sesion de revision sobre Azure Identity Protection: Automatizando la Respuesta a Credenciales Filtradas, las preguntas practicas aportan mas que los discursos abstractos. Que objetos conservan mas privilegios de los necesarios? Que excepcion sigue viva solo porque nadie la reviso al terminar un proyecto? Que equipo detectaria antes un abuso y con que evidencia? Que dependencia de negocio bloquea la correccion hoy y que control compensatorio existe hasta eliminarla? Estas preguntas exponen ambiguedad operativa que el inventario tecnico no refleja. Ademas obligan a conectar diseno de identidad, calidad de logs, ownership y gestion del cambio dentro de una misma conversacion.

Lecturas Relacionadas

Conviene revisar este tema junto con Identidad Azure: Por Que el MFA No Basta, Brechas Acceso Condicional Azure: Bypass MFA, Acceso Privilegiado Azure: Demasiados Global Admins, Endurecimiento del Tenant Azure: Corregir Defaults Inseguros y Cuentas Invitado Azure: Riesgos del Tenant. Estos articulos muestran como las mismas debilidades de identidad y permisos suelen encadenarse en una evaluacion real.

• Identidad Azure: Por Que el MFA No Basta
• Brechas Acceso Condicional Azure: Bypass MFA
• Acceso Privilegiado Azure: Demasiados Global Admins
• Endurecimiento del Tenant Azure: Corregir Defaults Inseguros
• Cuentas Invitado Azure: Riesgos del Tenant

Estas referencias internas ayudan a evaluar el camino de riesgo completo y no solo un hallazgo aislado.