Cómo auditar y monitorizar usuarios en Azure AD (Microsoft Entra ID) para evitar riesgos de seguridad: guía completa

Resumen rápido: auditoría y monitorización de usuarios en Azure AD/Entra ID en 11 puntos

1. Definir objetivo y alcance: qué riesgos se quieren reducir (phishing, fuerza bruta, robo de tokens, privilegios excesivos, invitados olvidados).
2. Elegir señales y fuentes: audit logs, sign-in logs (interactivos y no interactivos), logs de apps/servicios y señales de Identity Protection.
3. Establecer retención: cuánto tiempo se guardan registros y dónde (portal vs Log Analytics/Storage) para poder investigar incidentes semanas después.
4. Baselining: definir qué es “normal” (países habituales, apps usadas, horarios, dispositivos, roles) para que lo anómalo destaque.
5. Priorizar alertas: fallos masivos de inicio de sesión, MFA inusual, deshabilitación de MFA, asignación de roles, creación de apps sospechosas.
6. Bloquear autenticación heredada: identificar y eliminar POP/IMAP/SMTP AUTH y otros patrones que elevan mucho el riesgo.
7. Acceso Condicional bien monitorizado: report-only para probar, registros para entender impacto y ajuste fino para evitar agujeros o bloqueos.
8. Privilegios bajo control: PIM, activaciones just-in-time, auditoría de roles y alertas ante cambios críticos.
9. Gobierno de invitados: control de invitaciones, limpieza, revisiones de acceso periódicas y caducidad de colaboraciones.
10. Centralizar y correlacionar: Log Analytics/Sentinel para detección, KQL para investigación y playbooks para respuesta.
11. Operación continua: rutinas diarias/semanales/mensuales con responsables claros (IT, seguridad, negocio) y evidencias.

Idea para “respirar” antes de entrar en detalle: lo importante no es acumular registros, sino convertirlos en señales y decisiones. Esta guía va de cómo hacerlo con un enfoque práctico y mantenible.

Introducción: por qué auditar y monitorizar usuarios en Azure AD (Microsoft Entra ID)

La identidad es el punto de entrada más repetido en incidentes modernos: si una cuenta cae, el atacante no necesita “romper” un servidor; le basta con iniciar sesión como si fuera una persona real. Por eso, auditar y monitorizar usuarios en Azure AD (hoy Microsoft Entra ID) no es un lujo: es la base para detectar accesos anómalos, reducir el tiempo de respuesta y tener evidencias cuando hay que explicar qué ocurrió.

La auditoría no consiste solo en “tener logs”. Consiste en responder con rapidez a preguntas que, en un incidente, aparecen siempre: ¿quién inició sesión?, ¿desde dónde?, ¿con qué aplicación?, ¿qué políticas se aplicaron?, ¿hubo cambios en MFA o roles?, ¿qué se modificó en el tenant? y ¿durante cuánto tiempo estuvo expuesto?.

Esta guía propone un enfoque práctico: qué mirar, cómo interpretarlo, cómo centralizarlo y cómo convertirlo en un sistema operable por el equipo (sin depender de héroes, ni de revisiones improvisadas).

Resumen de esta introducción: monitorizar identidades es convertir “eventos sueltos” en señales investigables y accionables. Lo que sigue baja a tierra cómo hacerlo con Entra ID.

1. Modelo de riesgo: qué se intenta evitar y qué señales ayudan

Antes de configurar alertas, conviene definir un modelo simple de riesgo. No hace falta un marco teórico complejo: basta con identificar los escenarios que más daño pueden causar y las señales que los delatan.

1.1 Escenarios de riesgo habituales (en identidades)

• Robo de credenciales (phishing): el usuario introduce la contraseña en un sitio falso o aprueba un MFA indebido.
• Ataques de fuerza bruta / password spray: muchos intentos contra muchas cuentas, a veces con pocas contraseñas comunes.
• Acceso desde ubicaciones o dispositivos no esperados: países no habituales, ASNs sospechosos, dispositivos no registrados.
• Persistencia: el atacante crea una app, concede permisos, añade un método MFA, crea reglas o prepara puertas traseras.
• Escalada de privilegios: asignación de roles, activaciones administrativas, cambios en políticas de seguridad.
• Riesgo por invitados: accesos externos que permanecen meses sin revisión, invitados con permisos más altos de lo esperado.

1.2 Señales que conviene convertir en “alertas” (no solo en logs)

Con estas señales, el proyecto deja de ser “vamos a revisar usuarios” y pasa a ser “vamos a detectar patrones concretos con impacto”. Esa diferencia es lo que hace que el sistema sea mantenible.

Resumen de la sección 1: definir riesgos y señales evita monitorizar “todo” sin criterio. El resto de la guía convierte esas señales en registros, alertas y rutinas.

2. Preparación: roles, acceso a logs, retención y evidencia

Dos problemas aparecen en casi todas las organizaciones: (1) no todo el mundo tiene acceso a los registros cuando ocurre un incidente y (2) cuando se va a investigar, los datos ya no están (o están incompletos). Esta sección ordena esa base.

2.1 Roles mínimos y separación de funciones

Es recomendable que el acceso a logs no dependa solo de Global Administrator. Un enfoque realista es crear roles por función: lectores de logs, administradores de seguridad, operadores de SIEM, etc. Además, los accesos privilegiados deberían ser temporales (PIM) y auditables.

2.2 Retención: el punto que más se echa de menos “después”

En la consola se ven logs “recientes”, pero los incidentes muchas veces se investigan tarde: cuando un proveedor avisa, cuando aparece un movimiento extraño o cuando se detecta fuga. Por eso conviene decidir desde el principio:

• Qué tipo de registros hay que conservar más tiempo (sign-ins, auditoría, riesgo, cambios de rol, consentimiento de apps).
• Qué plataforma los conservará (Log Analytics, Storage, SIEM) y con qué coste.
• Cómo se accede a esa evidencia (KQL, paneles, exportaciones, procesos de auditoría).

2.3 Diferenciar “actividad de identidad” y “auditoría M365”

Entra ID aporta registros de identidad (inicios de sesión y cambios en el directorio). Pero muchas organizaciones también necesitan auditoría de acciones dentro de Microsoft 365 (por ejemplo, actividad sobre documentos, Teams, etc.). Es importante no mezclarlo: la auditoría de identidad y la auditoría de actividad en M365 se complementan, pero no son lo mismo.

Resumen de la sección 2: sin retención y sin roles claros, la monitorización falla en el momento crítico. La siguiente parte entra en los dos pilares: audit logs y sign-in logs.

3. Audit Logs en Entra ID: qué registran y cómo usarlos bien

Los audit logs registran cambios: lo que se crea, se modifica o se elimina en el directorio y en elementos relacionados (usuarios, grupos, apps, licencias, roles, configuraciones). Son la respuesta a “¿quién cambió qué y cuándo?”.

3.1 Qué conviene buscar en auditoría (ejemplos de alto impacto)

• Creación / eliminación de usuarios y reactivación de cuentas deshabilitadas.
• Cambios en métodos de autenticación (registro/actualización de MFA) y resets de contraseña.
• Asignación de roles (directa o vía PIM) y cambios en privilegios.
• Creación de aplicaciones, consentimientos y cambios en permisos de apps.
• Cambios en políticas (Acceso Condicional, seguridad, configuración de identidad).

3.2 Cómo leer un evento de auditoría sin perderse

Para que el audit log sea útil, conviene entrenar una forma de lectura:

1. Actor: quién ejecutó el cambio (usuario, servicio, app, automatización).
2. Target: qué objeto fue afectado (usuario/grupo/app/política).
3. Operation: qué operación se realizó (Add, Update, Delete, Assign, Consent).
4. Resultado: éxito/fallo y detalles de error.
5. Contexto: IP, ubicación, app usada, correlación con sign-ins y con tickets.

3.3 Patrón realista para investigar “persistencia”

En incidentes de identidad, la persistencia suele aparecer como cambios “pequeños” pero críticos: un nuevo consentimiento de app, un cambio de método MFA, una asignación de rol o una regla creada por automatización. Una investigación ordenada suele seguir este orden:

1. Confirmar el inicio de sesión sospechoso (sign-in logs).
2. Revisar auditoría para ver qué cambió después de ese acceso.
3. Buscar cambios equivalentes en cuentas similares (mismo patrón, misma IP, misma app).
4. Revocar sesiones / tokens, revertir cambios y documentar evidencia.

Resumen de la sección 3: el audit log explica cambios. El siguiente paso es entender los inicios de sesión, porque ahí se ve el acceso que habilita esos cambios.

4. Sign-in Logs en Azure AD/Entra ID: tipos de inicios de sesión y lectura práctica

Los sign-in logs explican accesos: intentos de autenticación y resultado. Son la base para detectar fuerza bruta, ubicaciones extrañas, cambios de dispositivo, aplicaciones sospechosas y fallos sistemáticos. Además, ayudan a entender qué políticas de seguridad se evaluaron (Acceso Condicional, MFA, riesgo, etc.).

4.1 Tipos de sign-ins (importa más de lo que parece)

No todo inicio de sesión es un “login con usuario y contraseña”. En Entra ID existen varios tipos, y entenderlos evita falsos positivos o puntos ciegos:

• Interactive user sign-ins: el usuario inicia sesión de forma “visible” (portal, app, Office, etc.).
• Non-interactive user sign-ins: actividades donde el usuario no “ve” un login (renovaciones de token, procesos en segundo plano, apps que actúan en nombre del usuario).
• Service principal sign-ins: autenticaciones de aplicaciones (identidad de app), claves/certificados, automatizaciones.
• Managed identity sign-ins: identidades administradas en Azure (workloads) que acceden a recursos sin credenciales tradicionales.

4.2 Campos que conviene “dominar” en un sign-in

• User / Identity: quién inicia (UPN, object ID, tipo: miembro, invitado, workload).
• Application: a qué aplicación accede (Microsoft 365, Azure Portal, app de terceros, app interna).
• Client app / Authentication protocol: navegador, mobile/desktop, legacy, etc.
• Device: registrado, compliant, join type, sistema operativo, navegador.
• Location / IP: país, ciudad aproximada, ASN (si se correlaciona en SIEM).
• Conditional Access: qué políticas se aplicaron, si hubo MFA, si se bloqueó y por qué.
• Risk: señales de riesgo asociadas (cuando aplica) y correlación con Identity Protection.

4.3 Lectura práctica: cinco preguntas que aceleran cualquier investigación

1. ¿Es un patrón aislado o repetido? ¿ocurre una vez o en serie (muchas cuentas / muchas IPs)?
2. ¿Encaja con el comportamiento normal del usuario? ubicación, horario, dispositivo y apps habituales.
3. ¿Qué falló exactamente? credenciales, MFA, CA, dispositivo, sesión, usuario bloqueado.
4. ¿Qué políticas intervinieron? CA en modo real o report-only, requisitos y resultado.
5. ¿Qué pasó después? auditoría: cambios en cuenta, roles, MFA, apps, permisos.

Resumen de la sección 4: los sign-ins explican accesos y contexto. La siguiente sección ataca un foco de riesgo clásico y muy rentable de eliminar: la autenticación heredada.

5. Detectar y bloquear autenticación heredada (legacy auth) para reducir riesgo

La autenticación heredada (protocolos antiguos y patrones sin MFA moderna) sigue apareciendo en muchos entornos por compatibilidades históricas. El problema es que, en términos de riesgo, suele ser una puerta de entrada preferida para ataques automatizados.

5.1 Cómo detectar legacy auth con sign-in logs

La detección práctica suele ser un proceso en dos pasos:

1. Identificar qué cuentas y apps lo usan (qué usuarios, desde qué IPs, qué client apps, con qué frecuencia).
2. Entender si es necesario (aplicación heredada real, impresora/MFP, integración antigua, o simplemente configuración que se mantuvo por inercia).

5.2 Bloqueo con Acceso Condicional (sin improvisar)

El bloqueo suele hacerse con una política específica. Lo importante es hacerlo con control:

• Empezar en report-only si hay dudas, para ver impacto antes de aplicar.
• Excluir cuentas de emergencia (break-glass) con controles compensatorios, y revisar que estén bien protegidas.
• Confirmar dependencias en impresoras, integraciones o apps antiguas y planificar sustituciones.

Resumen de la sección 5: bloquear legacy auth recorta una parte grande del riesgo. A partir de aquí, el siguiente salto de madurez es usar señales de riesgo y detecciones (Identity Protection).

6. Microsoft Entra ID Protection: riesgo, detecciones y respuesta ante cuentas comprometidas

Microsoft Entra ID Protection aporta una capa clave: señales de riesgo y detecciones que ayudan a identificar actividad sospechosa antes de que se convierta en una intrusión mayor. El valor práctico aparece cuando esas señales se conectan a decisiones: requerir MFA, bloquear, forzar reset, o disparar un proceso de investigación.

6.1 Qué se monitoriza en ID Protection

• Risky users: usuarios con riesgo elevado según señales y detecciones.
• Risky sign-ins: inicios de sesión con riesgo (por comportamiento, ubicación, patrón, etc.).
• Detections: eventos que explican por qué se asigna riesgo (p. ej., anomalías, credenciales filtradas, etc.).

6.2 Respuesta práctica: un flujo de actuación realista

Cuando un usuario aparece como riesgoso o hay un sign-in riesgoso, conviene seguir un flujo consistente:

1. Triage rápido: confirmar si el evento encaja con el contexto del usuario (viajes, VPN corporativa, cambios de dispositivo).
2. Correlación: revisar sign-ins cercanos en el tiempo, apps objetivo, ubicaciones y fallos previos.
3. Contención: revocar sesiones, forzar reset de contraseña, exigir MFA fuerte o bloquear temporalmente.
4. Reversión: eliminar métodos MFA añadidos de forma indebida, retirar consentimientos sospechosos, revisar roles.
5. Cierre: documentar evidencia, ajustar políticas y crear una alerta preventiva si el patrón se repite.

6.3 Evitar el error típico: “muchas señales, poca acción”

ID Protection puede generar información valiosa, pero si no existe un proceso para priorizar, investigar y actuar, se convierte en un panel más. La forma práctica de evitarlo es definir:

• Qué umbral dispara un ticket o incidente (alto riesgo, sign-ins repetidos, detecciones concretas).
• Qué acciones están autorizadas (bloqueo, reset, revocación de sesiones, revisión de roles).
• Cómo se confirma con el usuario (y por qué canal, asumiendo que correo/Teams pueden estar comprometidos).

Resumen de la sección 6: ID Protection aporta señales de riesgo; el valor real aparece cuando esas señales se conectan a Acceso Condicional y a un procedimiento de respuesta.

7. Monitorizar Acceso Condicional: impacto, report-only y troubleshooting sin fricción

Acceso Condicional es uno de los controles más potentes para reducir riesgo, pero también uno de los que más incidencias puede generar si se despliega sin visibilidad. Por eso, monitorizar su impacto es casi tan importante como diseñar la política.

7.1 Report-only: probar sin bloquear

El modo report-only permite simular el efecto de muchas políticas sin aplicarlas, registrando qué habría pasado en los sign-in logs. Es una forma práctica de evitar que un cambio de seguridad termine bloqueando a un área crítica sin aviso.

7.2 Qué revisar en sign-in logs cuando hay problemas

• Policy details: qué políticas evaluaron y cuál fue el resultado (grant, block, require MFA, device compliance).
• Failure reason: por qué falló (MFA, dispositivo no compliant, usuario fuera de alcance, app no prevista).
• Client app: si el acceso viene por un cliente antiguo o por un protocolo heredado.
• Ubicación: si hay políticas por país, named locations, o detección errónea por VPN.

7.3 Insights & Reporting: de “casos” a visión global

Para organizaciones con Acceso Condicional maduro, los paneles de insights ayudan a ver tendencias: qué políticas bloquean más, dónde hay fricción y qué cambios conviene priorizar. Esto es especialmente útil si se está endureciendo el acceso por fases.

Resumen de la sección 7: Acceso Condicional se gobierna con visibilidad. Con report-only y análisis de logs se reduce fricción y se mejora la seguridad sin bloquear negocio.

8. Privilegios y roles: auditar admins, PIM y cambios críticos

En identidades, hay una regla simple: cuanto más privilegio, más control y más evidencias. Un administrador comprometido o una asignación de rol indebida puede tener impacto inmediato y amplio. Por eso, la auditoría de roles y privilegios debe ser prioritaria.

8.1 Controles recomendados para cuentas admin

• Separación de cuentas: cuenta de usuario normal y cuenta administrativa (si aplica por modelo de la organización).
• MFA fuerte: preferiblemente phishing-resistant cuando sea posible.
• Acceso Condicional específico: requerir dispositivo compliant, ubicación controlada o paso adicional de seguridad.
• Sin privilegios permanentes: usar PIM para activación temporal y justificada.

8.2 Qué monitorizar en PIM (más allá de “está activado”)

PIM reduce exposición, pero lo importante es monitorizar su uso:

• Activaciones fuera de horario o sin justificación clara.
• Nuevas asignaciones elegibles a roles sensibles.
• Cambios en configuración de PIM (por ejemplo, requisitos de aprobación, duración, MFA).
• Roles críticos asignados directamente (si ocurre, debería ser excepcional).

Resumen de la sección 8: los privilegios requieren control “extra”: PIM, auditoría y alertas. Después de admins, el siguiente foco suele ser el ecosistema de invitados.

9. Usuarios invitados (B2B) en Azure AD/Entra ID: control, revisiones y limpieza

Los invitados suelen crecer sin que nadie lo note: proyectos, proveedores, consultores, clientes. Y con el tiempo se convierten en un riesgo si no hay caducidad, revisiones de acceso y limpieza. Un sistema de auditoría de usuarios serio incluye a los invitados desde el principio.

9.1 Señales para monitorizar invitados

• Invitados con acceso a sitios o apps sensibles.
• Invitados que no han iniciado sesión en meses pero mantienen permisos.
• Invitaciones masivas o inusuales (picos en auditoría).
• Cambios de rol o pertenencia a grupos críticos (debería ser raro).

9.2 Access Reviews: la herramienta que más “orden” aporta

Las revisiones de acceso permiten establecer una rutina: cada X semanas o meses, propietarios revisan quién debe seguir teniendo acceso. Es especialmente útil para invitados y para grupos que dan acceso a recursos críticos.

9.3 Buenas prácticas que evitan problemas repetidos

• Definir un dueño de negocio por colaboración externa (proyecto/cliente/proveedor).
• Evitar compartir “hacia dentro” recursos internos que no están pensados para externos; crear espacios dedicados.
• Caducidad y limpieza cuando el proyecto termina (o cuando el invitado no se usa).

Resumen de la sección 9: los invitados no son “un detalle”: son identidades con acceso. Access Reviews y limpieza periódica convierten el riesgo difuso en un proceso controlado.

10. Centralizar logs de Entra ID: Log Analytics, Event Hub, Storage y correlación

Cuando la organización necesita investigar incidentes con profundidad (o demostrar cumplimiento), los logs del portal no suelen ser suficientes. Centralizarlos permite más retención, búsquedas potentes (KQL), correlación y alertas más inteligentes.

10.1 Opciones típicas (y cuándo elegir cada una)

• Log Analytics: análisis e investigación (KQL), workbooks, alertas, integración con Sentinel.
• Event Hub: streaming a SIEMs o plataformas externas en tiempo casi real.
• Storage Account: archivado a largo plazo y conservación económica para auditorías.

10.2 Qué logs conviene exportar como mínimo

Un mínimo razonable suele incluir:

• Sign-in logs (incluyendo no interactivos y, si aplica, service principals).
• Audit logs (cambios en usuarios, roles, apps, políticas).
• Risk events / Identity Protection si se dispone de licencias y se usa como señal de seguridad.

10.3 Primeros casos de uso en Log Analytics (para que aporte valor rápido)

Si se centraliza pero nadie lo usa, se convierte en coste. Por eso, conviene empezar por casos de uso concretos:

• Top usuarios con fallos de inicio de sesión en 24h.
• Países/ubicaciones nuevas por usuario (últimos 7 días).
• Apps con picos de acceso o fallos anómalos.
• Eventos de auditoría críticos (roles, MFA, apps, consentimientos).

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| summarize Failed=count(), Apps=dcount(AppDisplayName), IPs=dcount(IPAddress) by UserPrincipalName
| order by Failed desc
| take 20

let lookback = 30d;
let recent = 2d;
let baseline =
  SigninLogs
  | where TimeGenerated between (ago(lookback) .. ago(recent))
  | summarize CountriesBaseline=make_set(LocationDetails.countryOrRegion) by UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(recent)
| summarize CountriesRecent=make_set(LocationDetails.countryOrRegion) by UserPrincipalName
| join kind=leftouter baseline on UserPrincipalName
| extend NewCountries=set_difference(CountriesRecent, CountriesBaseline)
| where array_length(NewCountries) > 0
| project UserPrincipalName, NewCountries, CountriesRecent

Resumen de la sección 10: centralizar logs permite retención y correlación. El siguiente paso es convertir esa base en detección y respuesta: Sentinel y automatización.

11. Microsoft Sentinel para identidades: detección, reglas y playbooks

Microsoft Sentinel permite ir más allá del “log”: correlaciona, alerta, abre incidentes y automatiza respuesta. Si la organización ya usa Sentinel (o quiere usarlo), Entra ID suele ser una de las fuentes más valiosas para detección temprana.

11.1 Casos de detección que suelen merecer regla

• Password spray / fuerza bruta: muchos fallos contra muchas cuentas desde una o pocas IPs.
• Actividad imposible o inconsistente: cambios bruscos de país/dispositivo para cuentas sensibles.
• Escalada de privilegios: asignación de roles, cambios en CA, cambios en MFA.
• Persistencia vía apps: consentimiento inusual o permisos altos concedidos.
• Reaparición de legacy auth: si se bloqueó, cualquier intento debería alertar.

11.2 Playbooks de respuesta (lo que conviene automatizar)

No todo debe automatizarse, pero hay respuestas que ahorran mucho tiempo:

• Notificar a seguridad/IT con contexto (usuario, IP, app, país, políticas aplicadas).
• Bloquear temporalmente o requerir reset (si el procedimiento lo permite y está aprobado).
• Revocar sesiones y tokens (cuando hay indicios fuertes de compromiso).
• Crear ticket y asignar responsable con checklist de investigación.

Resumen de la sección 11: Sentinel convierte logs en incidentes gestionables y automatiza pasos. La siguiente parte aterriza cómo presentar todo esto en paneles y reporting que el equipo sí use.

12. Paneles y reporting: workbooks y cuadros de mando que ayudan de verdad

Un panel útil no es el que enseña “muchas gráficas”, sino el que responde a preguntas operativas: ¿qué está empeorando?, ¿dónde hay actividad extraña?, ¿qué políticas están bloqueando demasiado?, ¿qué cuentas requieren revisión?

12.1 Panel mínimo recomendado (para empezar)

• Salud de accesos: tasa de fallos, top apps con fallos, top usuarios con fallos.
• Geografía: países nuevos, accesos desde ubicaciones raras, cuentas sensibles por país.
• Seguridad: eventos de auditoría críticos (roles/MFA/apps), intentos de legacy auth.
• Riesgo: usuarios en riesgo, sign-ins riesgosos, tendencias semanales.

12.2 Reporting mensual para dirección / auditoría (sin ruido)

Un reporting mensual suele funcionar si evita detalles técnicos y se centra en:

• Número de incidentes de identidad, severidad y tendencia.
• Tiempo medio de detección y respuesta (MTTD/MTTR).
• Principales causas: legacy auth residual, MFA débil, excepciones de CA, apps con permisos altos.
• Acciones tomadas: políticas nuevas, reducción de privilegios, limpieza de invitados, mejoras en retención.

Resumen de la sección 12: los paneles conectan el mundo técnico con decisiones. La siguiente sección define rutinas concretas para que la monitorización no dependa de “cuando alguien se acuerda”.

13. Operación continua: rutinas diarias, semanales y mensuales para evitar riesgos

La auditoría funciona cuando se convierte en rutina. Un modelo simple suele ser suficiente:

13.1 Revisión diaria (10–20 minutos, enfocada)

• Alertas críticas (roles, MFA, políticas, picos de fallos).
• Usuarios con riesgo alto o sign-ins riesgosos (si aplica).
• Incidentes abiertos y estado de contención.

13.2 Revisión semanal (más analítica)

• Top patrones de fallos y su causa (apps, CA, dispositivos, ubicaciones).
• Revisión de cuentas “sensibles” (admins, finanzas, RRHH) y su actividad.
• Revisión de invitados nuevos / inactivos y accesos fuera de norma.

13.3 Revisión mensual (gobierno y mejora continua)

• Revisiones de acceso (Access Reviews) para grupos o recursos críticos.
• Revisión de políticas de CA: excepciones, report-only, ajuste por fricción.
• Revisión de apps con permisos altos y consentimientos recientes.
• Prueba de investigación: seleccionar un caso real y validar que hay evidencia suficiente (retención, correlación, procedimientos).

Resumen de la sección 13: la monitorización sostenible se apoya en rutinas. A continuación se ofrecen checklists y snippets para aterrizarlo aún más.

14. Checklists operativos para auditar y monitorizar usuarios en Azure AD/Entra ID

14.1 Checklist de diseño (antes de configurar)

• Definir riesgos prioritarios (credenciales, privilegios, apps, invitados).
• Elegir señales/alertas y su umbral (qué abre incidente y qué solo informa).
• Definir roles y responsables (lectura, investigación, cambios, aprobación).
• Definir retención y destino de logs (portal vs Log Analytics/Storage/SIEM).
• Plan de eliminación de legacy auth y dependencias.

14.2 Checklist de despliegue (configuración)

• Activar y validar acceso a audit logs y sign-in logs.
• Configurar exportación/ingesta a Log Analytics (si aplica) y validar tablas.
• Configurar workbooks/paneles base y al menos 5 consultas de investigación.
• Configurar políticas de CA (incluyendo report-only para pruebas) y validar resultados en logs.
• Activar y configurar PIM (si aplica) y alertas de roles.

14.3 Checklist de operación (día a día)

• Revisión diaria de alertas críticas y usuarios de riesgo.
• Revisión semanal de patrones (fallos, ubicaciones, apps) y limpieza de invitados inactivos.
• Revisión mensual de accesos (Access Reviews), apps con permisos altos y pruebas de investigación.
• Documentar cambios en políticas y evidencias de incidentes para auditoría.

Resumen de la sección 14: los checklists convierten la seguridad en proceso repetible. La siguiente sección aporta ejemplos técnicos listos para adaptar (KQL/PowerShell/Graph).

15. Queries y snippets útiles para auditoría y monitorización (KQL/PowerShell/Graph)

Estos ejemplos están pensados como punto de partida. En un entorno real conviene adaptarlos a naming, ubicaciones, roles y aplicaciones de la organización.

15.1 KQL — picos de fallos por IP (posible password spray)

SigninLogs
| where TimeGenerated > ago(6h)
| where ResultType != 0
| summarize Failed=count(), Users=dcount(UserPrincipalName) by IPAddress
| where Failed > 50 and Users > 10
| order by Failed desc

15.2 KQL — cambios críticos en auditoría (roles, MFA, apps)

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("Add member to role", "Add eligible member to role", "Update user", "Add app role assignment", "Consent")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result

15.3 PowerShell / Graph — ideas de auditoría (conceptual)

En muchos equipos, el valor está en automatizar informes: usuarios sin métodos MFA registrados, invitados inactivos, cuentas deshabilitadas con actividad reciente, etc. Según el stack de la organización, esto se hace con Microsoft Graph (SDK, REST) o con scripts operativos.

Resumen de la sección 15: los ejemplos aceleran investigación y reporting, pero el valor real aparece cuando se integran en rutinas y alertas.

16. Preguntas frecuentes (FAQ) sobre auditoría y monitorización de usuarios en Azure AD/Entra ID

17. Recursos oficiales y enlaces recomendados

• Audit logs en Microsoft Entra ID
• Sign-in logs en Microsoft Entra ID (tipos)
• Microsoft Entra ID Protection (visión general)
• Acceso Condicional: report-only
• Insights & Reporting para Acceso Condicional
• Configurar diagnostic settings para logs de Entra
• Integrar activity logs con Azure Monitor Logs
• Conector de Microsoft Entra ID en Microsoft Sentinel
• Retención de datos de logs y reportes (Entra)

Servicios relacionados de MSAdvance: Seguridad Microsoft 365, Microsoft Sentinel, Modern Workplace.

18. Conclusión: cómo auditar y monitorizar usuarios en Azure AD/Entra ID sin perder el control

Auditar y monitorizar usuarios en Azure AD (Microsoft Entra ID) funciona cuando se apoya en cuatro pilares: señales claras (qué detectar), evidencia disponible (retención y centralización), controles bien ajustados (Acceso Condicional, PIM, eliminación de legacy auth), y operación continua (rutinas, revisiones, reporting).

Como siguientes pasos, suele funcionar bien:

• Definir 10 alertas de alto valor (roles, MFA, picos de fallos, apps/consentimientos, legacy auth).
• Centralizar logs en Log Analytics o SIEM y validar que se puede investigar 30–90 días atrás (o lo que exija el negocio).
• Aplicar un plan por fases: report-only → ajustes → aplicación real, evitando cambios masivos sin visibilidad.
• Incorporar gobierno de invitados y revisiones de acceso como rutina.