Registro Entra ID: Retención, Diagnostic Settings, SIEM Exportación

Registro de Entra ID, retención, diagnostic settings, exportación SIEM: qué falta

Registro de Entra ID, retención, diagnostic settings, exportación SIEM — tres controles distintos, y por defecto ninguno hace lo que la mayoría de los equipos asume. Los logs de inicio de sesión y auditoría caducan en días, no en meses. Nada se enruta a ningún sitio sin un diagnostic setting explícito. Y a menos que alguien haya conectado un event hub o un workspace de Log Analytics, Microsoft Sentinel o un SIEM de terceros nunca ve un solo evento de Entra ID.

Esto es una carencia de configuración, no una técnica de ataque — pero es una de las carencias de mayor apalancamiento de todo el catálogo de Azure, porque decide si cualquier otra detección de este blog es realmente utilizable. Una política de acceso condicional que bloquea la autenticación legacy no sirve para investigar a posteriori si el inicio de sesión que la disparó ya expiró del log. Una detección de riesgo de identity protection no significa nada para un SOC que no tiene ningún canal alimentándola hacia su SIEM.

Cuatro hallazgos relacionados componen este clúster:

• AZ_AUDIT_LOG_RETENTION_SHORT — los logs de auditoría se retienen durante menos tiempo del que la licencia del tenant permite (o del que exige una ventana de respuesta a incidentes).
• AZ_SIGN_IN_LOGS_NOT_RETAINED — los logs de inicio de sesión están en la ventana por defecto del nivel gratuito y desaparecen antes de que empiecen la mayoría de las cronologías de detección de brechas.
• AZ_DIAGNOSTIC_SETTINGS_MISSING — no existe ningún diagnostic setting para enrutar los logs a ningún sitio, así que la ventana de retención por defecto es la única retención que existe.
• AZ_NO_SIEM_EXPORT — los logs pueden llegar a un workspace de Log Analytics pero nunca salen de ahí hacia un SIEM monitorizado, así que nadie recibe alertas.

Cómo ocurren realmente estas carencias

La retención es un techo de licencia, no un ajuste que se configura

Según la documentación de Microsoft sobre la retención de datos de Microsoft Entra, la ventana de retención integrada para los logs de auditoría e inicio de sesión es:

Dos detalles empeoran esto:

1. Los cambios de retención no son retroactivos. La documentación de Microsoft lo indica directamente: al pasar de Free a P1/P2, solo se recupera lo que aún está dentro de la ventana gratuita de 7 días — los datos ya caducados se pierden salvo que se hubieran archivado previamente.
2. Los logs de actividad de Microsoft Graph no están disponibles en absoluto en Entra ID Free, y no se retienen por defecto ni siquiera en P1/P2 — la propia tabla de retención de Microsoft los lista como requiriendo integración con almacenamiento o herramientas analíticas desde el primer día; no hay una ventana por defecto de respaldo como sí la hay para los logs de auditoría e inicio de sesión.

Si un incidente se descubre nueve días después de los hechos — una cronología muy normal para una compromisión basada en credenciales — un tenant P1/P2 sin exportación configurada ya ha perdido la evidencia de inicio de sesión de los dos primeros días de la intrusión, y un tenant Free ha perdido casi todo.

Los diagnostic settings son opt-in, por categoría de log, por destino

Enrutar los logs fuera de la ventana de retención por defecto de Entra ID requiere un diagnostic setting, configurado en Centro de administración de Entra → Monitoring & health → Diagnostic settings por un usuario con el rol de Security Administrator (Cómo configurar los diagnostic settings de Microsoft Entra). Esto no es automático, y no cubre "todo" a menos que se seleccione explícitamente cada categoría de log relevante.

Microsoft documenta las categorías de logs que se pueden transmitir, cada una de las cuales hay que elegir individualmente (Logs disponibles para streaming desde Microsoft Entra ID) — las relevantes para la seguridad incluyen:

AuditLogs                          SignInLogs
NonInteractiveUserSignInLogs       ServicePrincipalSignInLogs
ManagedIdentitySignInLogs          ProvisioningLogs
ADFSSignInLogs                     RiskyUsers
UserRiskEvents                     RiskyServicePrincipals
ServicePrincipalRiskEvents         RiskyAgents / AgentRiskEvents
NetworkAccessTrafficLogs           MicrosoftGraphActivityLogs
EnrichedOffice365AuditLogs         CustomSecurityAttributeAuditLogs

Un tenant puede tener un diagnostic setting que solo reenvía AuditLogs, mientras que SignInLogs, RiskyUsers y UserRiskEvents — las categorías que realmente contienen la telemetría de autenticación y riesgo — permanecen sin enrutar y sujetas al techo de 7/30 días mencionado arriba. Este es un estado a medio configurar muy común: alguien activó el logging una vez para cumplir un requisito de compliance, eligió una o dos categorías, y nunca volvió a revisarlo. Esta misma carencia socava directamente las investigaciones sobre la actividad de roles privilegiados rastreada mediante Azure PIM — un historial de activación es tan duradero como el log de auditoría en el que está escrito.

El propio destino debe existir antes de que el diagnostic setting pueda apuntar a él: un workspace de Log Analytics, un event hub, o una cuenta de almacenamiento. Los logs pueden tardar hasta tres días en aparecer tras guardar un setting, lo cual importa al validar una corrección.

Un workspace de Log Analytics no es un SIEM

Aquí es donde AZ_NO_SIEM_EXPORT diverge de AZ_DIAGNOSTIC_SETTINGS_MISSING: un tenant puede tener los diagnostic settings totalmente configurados, volcando cada categoría en un workspace de Log Analytics, y aun así tener cero cobertura de detección — porque nadie ejecuta reglas analíticas sobre ese workspace, o porque el workspace nunca se conectó a Microsoft Sentinel ni se exportó a un SIEM de terceros (Splunk, Elastic, QRadar) vía event hub.

La propia documentación de integración de Microsoft señala que conectar los logs de Entra con los logs de Azure Monitor activa automáticamente el conector de datos de Microsoft Entra dentro de Microsoft Sentinel (Integrar los logs de Microsoft Entra con los logs de Azure Monitor) — pero solo si Sentinel está desplegado en ese mismo workspace en primer lugar. Un workspace sin Sentinel (ni una ingesta SIEM equivalente) encima es un archivo de solo escritura: los datos se retienen, pero nadie, y nada, los está mirando.

Detección

Verifique cada una de las cuatro carencias de forma independiente — un tenant frecuentemente ha corregido algunas pero no todas.

1. Confirme qué está realmente configurado, no lo que asume que está configurado. En el centro de administración de Entra, vaya a Monitoring & health → Diagnostic settings y revise cada setting existente: qué categorías de log están seleccionadas, y a qué destino apuntan. Si la lista está vacía, AZ_DIAGNOSTIC_SETTINGS_MISSING aplica inmediatamente — el tenant funciona solo con la retención por defecto.

2. Verifique el techo de retención impuesto por la licencia frente a sus requisitos reales de respuesta a incidentes. Una ventana de 7 días en Entra ID Free, o incluso la ventana de 30 días en P1/P2, es corta comparada con las estadísticas típicas de tiempo de permanencia para intrusiones basadas en identidad — si nada la extiende, marque AZ_AUDIT_LOG_RETENTION_SHORT / AZ_SIGN_IN_LOGS_NOT_RETAINED.

3. Verifique que los datos realmente llegan a Log Analytics, no solo que existe un setting. En Sentinel o un workspace conectado, ejecute:

SigninLogs
| summarize LastEvent = max(TimeGenerated), Count = count()

AuditLogs
| summarize LastEvent = max(TimeGenerated), Count = count()

Observe que los nombres de tabla usan SigninLogs (con "i" minúscula) en Log Analytics, distinto del nombre de categoría del diagnostic setting SignInLogs — una fuente habitual de confusión de "por qué mi consulta está vacía". Si LastEvent está desactualizado o la tabla no existe, el diagnostic setting no está guardado, no incluye esa categoría, o apunta a un workspace distinto del que está consultando.

4. Confirme el lado del SIEM, no solo el canal. Si Microsoft Sentinel es el destino, verifique que Data connectors → Microsoft Entra ID muestre "conectado", con SignInLogs y AuditLogs ambos activados — es un interruptor separado del diagnostic setting del lado de Entra, y ambos deben apuntar al mismo workspace. Para un SIEM de terceros, confirme que el event hub tiene realmente un grupo de consumidores activo leyéndolo, no solo que el diagnostic setting liste un event hub como destino.

5. Para recopilación de evidencia programática, el SDK de Microsoft Graph PowerShell expone directamente los datos subyacentes, independientemente de cualquier pipeline SIEM, lo cual es útil para confirmar lo que Entra ID retiene actualmente:

# Confirmar hasta dónde llegan actualmente los datos de inicio de sesión
Get-MgAuditLogSignIn -Top 1 -Sort "createdDateTime asc"

# Misma verificación para los eventos de auditoría de directorio
Get-MgAuditLogDirectoryAudit -Top 1 -Sort "activityDateTime asc"

Remediación

1. Cree primero el destino. Cree (o identifique) un workspace de Log Analytics, y si también se requiere almacenamiento en frío a largo plazo, una cuenta de almacenamiento separada — los diagnostic settings necesitan que el destino exista antes de poder apuntar a él.
2. Cree el diagnostic setting con cada categoría relevante para la seguridad seleccionada, no solo AuditLogs. Como mínimo: AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, RiskyUsers, UserRiskEvents. Añada ADFSSignInLogs y ProvisioningLogs si aplican a su entorno.
3. Conecte el workspace a Microsoft Sentinel (o al consumidor de event hub de su SIEM) y confirme que el conector de datos de Microsoft Entra ID muestra SignInLogs y AuditLogs como conectados — un workspace que recibe datos sin un SIEM que los lea cierra AZ_DIAGNOSTIC_SETTINGS_MISSING pero deja AZ_NO_SIEM_EXPORT abierto.
4. Extienda la retención más allá del techo de la licencia configurando la política de retención propia del workspace de Log Analytics o de la cuenta de almacenamiento, de forma independiente de la ventana por defecto de 7/30 días de Entra ID — la ventana de retención de Entra ID deja de importar una vez que los datos viven en Azure Monitor. Las organizaciones con licencia Microsoft 365 E5 / Purview Suite pueden, alternativamente, extender la retención mediante Microsoft Purview Audit (Premium).
5. Vuelva a ejecutar las consultas de detección anteriores después de guardar el setting — permita hasta tres días para que aparezcan los datos antes de concluir que falló — y confirme que LastEvent en SigninLogs / AuditLogs está actualizado, no solo que la consulta devuelve algunas filas.
6. Documente quién es responsable de la revalidación. Los diagnostic settings se desvían silenciosamente: una migración de workspace, un onboarding de Sentinel que olvidó reapuntar el conector, o una licencia de Purview vencida pueden detener discretamente el pipeline sin ningún error visible en el centro de administración de Entra.

Cómo lo detecta EtcSec

EtcSec verifica AZ_AUDIT_LOG_RETENTION_SHORT, AZ_SIGN_IN_LOGS_NOT_RETAINED, AZ_DIAGNOSTIC_SETTINGS_MISSING y AZ_NO_SIEM_EXPORT como parte de cada auditoría de Azure/Entra ID — confirmando no solo que existe un diagnostic setting, sino qué categorías de log reenvía realmente y si el destino es monitorizado por su SOC. Este es un control complementario al panorama más amplio de hardening del tenant cubierto en cómo auditar la seguridad de Microsoft Entra ID y la línea base de hardening del tenant de Azure.