Journalisation Entra ID : Rétention, Diagnostic Settings, SIEM Export

Journalisation Entra ID, rétention, diagnostic settings, export SIEM : ce qui manque

Journalisation Entra ID, rétention, diagnostic settings, export SIEM — trois contrôles distincts, et par défaut aucun ne fait ce que la plupart des équipes supposent. Les logs de connexion et d'audit expirent en quelques jours, pas en mois. Rien n'est routé nulle part sans diagnostic setting explicite. Et tant que personne n'a branché un event hub ou un workspace Log Analytics, Microsoft Sentinel ou un SIEM tiers ne voit jamais un seul événement Entra ID.

C'est une lacune de configuration, pas une technique d'attaque — mais c'est l'une des lacunes à plus fort effet de levier de tout le catalogue Azure, car elle détermine si toutes les autres détections de ce blog sont réellement exploitables. Une politique d'accès conditionnel qui bloque l'authentification legacy ne sert à rien pour l'investigation a posteriori si la connexion qui l'a déclenchée a déjà expiré du log. Une détection de risque d'identity protection ne signifie rien pour un SOC qui n'a aucun pipe l'alimentant vers son SIEM.

Quatre constats liés composent ce cluster :

• AZ_AUDIT_LOG_RETENTION_SHORT — les logs d'audit sont conservés moins longtemps que ce à quoi la licence du tenant donne droit (ou que ce qu'exige une fenêtre de réponse à incident).
• AZ_SIGN_IN_LOGS_NOT_RETAINED — les logs de connexion sont sur la fenêtre par défaut du niveau gratuit et disparaissent avant que la plupart des chronologies de détection de compromission n'aient même commencé.
• AZ_DIAGNOSTIC_SETTINGS_MISSING — aucun diagnostic setting n'existe pour router les logs où que ce soit, donc la fenêtre de rétention par défaut est la seule rétention qui existe.
• AZ_NO_SIEM_EXPORT — les logs atteignent peut-être un workspace Log Analytics mais n'en ressortent jamais vers un SIEM surveillé, donc personne n'alerte dessus.

Comment ces lacunes apparaissent réellement

La rétention est un plafond de licence, pas un paramètre qu'on règle

Selon la documentation Microsoft sur la rétention des données Microsoft Entra, la fenêtre de rétention intégrée pour les logs d'audit et de connexion est :

Deux détails aggravent la situation :

1. Les changements de rétention ne sont pas rétroactifs. La documentation Microsoft l'indique directement : en passant de Free à P1/P2, on ne récupère que ce qui se trouve encore dans la fenêtre gratuite de 7 jours — les données déjà expirées sont perdues, sauf si elles avaient été archivées au préalable.
2. Les logs d'activité Microsoft Graph ne sont pas du tout disponibles sur Entra ID Free, et ne sont pas conservés par défaut même en P1/P2 — le tableau de rétention de Microsoft les répertorie comme nécessitant une intégration avec du stockage ou des outils analytiques dès le départ ; il n'y a pas de fenêtre par défaut de repli comme pour les logs d'audit et de connexion.

Si un incident est découvert neuf jours après les faits — une chronologie tout à fait normale pour une compromission liée aux identifiants — un tenant P1/P2 sans export configuré a déjà perdu les preuves de connexion pour les deux premiers jours de l'intrusion, et un tenant Free a presque tout perdu.

Les diagnostic settings sont opt-in, par catégorie de log, par destination

Router les logs hors de la fenêtre de rétention par défaut d'Entra ID nécessite un diagnostic setting, configuré dans Centre d'administration Entra → Monitoring & health → Diagnostic settings par un utilisateur ayant le rôle Security Administrator (Comment configurer les diagnostic settings Microsoft Entra). Ce n'est pas automatique, et cela ne couvre pas « tout » sauf si chaque catégorie de log pertinente est explicitement sélectionnée.

Microsoft documente les catégories de logs diffusables, qu'il faut sélectionner une par une (Logs disponibles en streaming depuis Microsoft Entra ID) — les catégories pertinentes pour la sécurité incluent :

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

Un tenant peut avoir un diagnostic setting qui ne transmet que AuditLogs, tandis que SignInLogs, RiskyUsers et UserRiskEvents — les catégories qui portent réellement la télémétrie d'authentification et de risque — restent non routées et soumises au plafond de 7/30 jours ci-dessus. C'est un état à moitié configuré très courant : quelqu'un a activé la journalisation une fois pour cocher une case de conformité, a choisi une ou deux catégories, et n'y est jamais revenu. La même lacune fragilise directement les investigations sur l'activité des rôles privilégiés suivie via Azure PIM — un historique d'activation n'est aussi durable que le log d'audit dans lequel il est écrit.

La destination elle-même doit déjà exister avant que le diagnostic setting puisse la cibler : un workspace Log Analytics, un event hub, ou un compte de stockage. Les logs peuvent mettre jusqu'à trois jours à apparaître après l'enregistrement d'un setting, ce qui compte lors de la validation d'un correctif.

Un workspace Log Analytics n'est pas un SIEM

C'est ici que AZ_NO_SIEM_EXPORT diverge de AZ_DIAGNOSTIC_SETTINGS_MISSING : un tenant peut avoir des diagnostic settings entièrement configurés, déversant chaque catégorie dans un workspace Log Analytics, et avoir malgré tout une couverture de détection nulle — parce que personne n'exécute de règles analytiques sur ce workspace, ou que le workspace n'a jamais été connecté à Microsoft Sentinel ni exporté vers un SIEM tiers (Splunk, Elastic, QRadar) via event hub.

La documentation d'intégration de Microsoft note que connecter les logs Entra aux logs Azure Monitor active automatiquement le connecteur de données Microsoft Entra dans Microsoft Sentinel (Intégrer les logs Microsoft Entra avec les logs Azure Monitor) — mais seulement si Sentinel est déployé sur ce même workspace en premier lieu. Un workspace sans Sentinel (ni ingestion SIEM équivalente) au-dessus est une archive en écriture seule : les données sont conservées, mais personne, et rien, ne les regarde.

Détection

Vérifiez chacune des quatre lacunes indépendamment — un tenant a fréquemment corrigé certaines d'entre elles mais pas toutes.

1. Confirmez ce qui est réellement configuré, pas ce que vous supposez configuré. Dans le centre d'administration Entra, allez dans Monitoring & health → Diagnostic settings et vérifiez chaque setting existant : quelles catégories de log sont sélectionnées, et vers quelle destination elles pointent. Si la liste est vide, AZ_DIAGNOSTIC_SETTINGS_MISSING s'applique immédiatement — le tenant tourne uniquement sur la rétention par défaut.

2. Vérifiez le plafond de rétention imposé par la licence face à vos exigences réelles de réponse à incident. Une fenêtre de 7 jours sur Entra ID Free, ou même la fenêtre de 30 jours sur P1/P2, est courte comparée aux statistiques typiques de temps de présence pour les intrusions basées sur l'identité — si rien ne l'étend, signalez AZ_AUDIT_LOG_RETENTION_SHORT / AZ_SIGN_IN_LOGS_NOT_RETAINED.

3. Vérifiez que les données arrivent réellement dans Log Analytics, pas seulement qu'un setting existe. Dans Sentinel ou un workspace connecté, exécutez :

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

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

Notez que les noms de table utilisent SigninLogs (« i » minuscule) dans Log Analytics, ce qui diffère du nom de catégorie de diagnostic setting SignInLogs — une source fréquente de confusion « pourquoi ma requête est-elle vide ». Si LastEvent est obsolète ou si la table n'existe pas, le diagnostic setting n'est soit pas enregistré, soit n'inclut pas cette catégorie, soit pointe vers un workspace différent de celui que vous interrogez.

4. Confirmez le côté SIEM, pas seulement le pipe. Si Microsoft Sentinel est la cible, vérifiez que Data connectors → Microsoft Entra ID affiche « connecté », avec SignInLogs et AuditLogs tous deux activés — c'est un interrupteur distinct du diagnostic setting côté Entra, et les deux doivent pointer vers le même workspace. Pour un SIEM tiers, confirmez que l'event hub a bien un groupe de consommateurs actif qui le lit, pas seulement que le diagnostic setting liste un event hub comme destination.

5. Pour une collecte de preuves programmatique, le SDK Microsoft Graph PowerShell expose directement les données sous-jacentes, indépendamment de tout pipeline SIEM, ce qui est utile pour confirmer ce qu'Entra ID détient actuellement :

# Confirmer jusqu'où remontent actuellement les données de connexion
Get-MgAuditLogSignIn -Top 1 -Sort "createdDateTime asc"

# Même vérification pour les événements d'audit d'annuaire
Get-MgAuditLogDirectoryAudit -Top 1 -Sort "activityDateTime asc"

Remédiation

1. Mettez d'abord en place la destination. Créez (ou identifiez) un workspace Log Analytics, et si un stockage froid à long terme est également requis, un compte de stockage distinct — les diagnostic settings ont besoin que la destination existe avant de pouvoir la cibler.
2. Créez le diagnostic setting avec chaque catégorie pertinente pour la sécurité sélectionnée, pas seulement AuditLogs. Au minimum : AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, RiskyUsers, UserRiskEvents. Ajoutez ADFSSignInLogs et ProvisioningLogs si applicables à votre environnement.
3. Connectez le workspace à Microsoft Sentinel (ou au consommateur event hub de votre SIEM) et confirmez que le connecteur de données Microsoft Entra ID affiche SignInLogs et AuditLogs comme connectés — un workspace qui reçoit des données sans SIEM qui les lit referme AZ_DIAGNOSTIC_SETTINGS_MISSING mais laisse AZ_NO_SIEM_EXPORT ouvert.
4. Étendez la rétention au-delà du plafond de licence en configurant la politique de rétention propre du workspace Log Analytics ou du compte de stockage, indépendamment de la fenêtre par défaut de 7/30 jours d'Entra ID — la fenêtre de rétention d'Entra ID cesse d'importer une fois que les données vivent dans Azure Monitor. Les organisations avec licence Microsoft 365 E5 / Purview Suite peuvent alternativement étendre la rétention via Microsoft Purview Audit (Premium).
5. Relancez les requêtes de détection ci-dessus après avoir enregistré le setting — laissez jusqu'à trois jours pour que les données apparaissent avant de conclure à un échec — et confirmez que LastEvent dans SigninLogs / AuditLogs est actuel, pas seulement que la requête retourne des lignes.
6. Documentez qui est responsable de la revalidation. Les diagnostic settings dérivent silencieusement : une migration de workspace, un onboarding Sentinel qui a oublié de repointer le connecteur, ou une licence Purview expirée peuvent tous interrompre discrètement le pipeline sans aucune erreur visible dans le centre d'administration Entra.

Comment EtcSec détecte cela

EtcSec vérifie AZ_AUDIT_LOG_RETENTION_SHORT, AZ_SIGN_IN_LOGS_NOT_RETAINED, AZ_DIAGNOSTIC_SETTINGS_MISSING et AZ_NO_SIEM_EXPORT dans le cadre de chaque audit Azure/Entra ID — en confirmant non seulement qu'un diagnostic setting existe, mais quelles catégories de log il transmet réellement et si la destination est surveillée par votre SOC. C'est un contrôle complémentaire au panorama plus large de durcissement du tenant couvert dans comment auditer la sécurité de Microsoft Entra ID et la baseline de durcissement du tenant Azure.