Journaux Entra ID : 30 jours de rétention ne suffisent pas pour enquêter
Quand un compte est compromis, la première question est toujours la même : depuis quand ? Sans export des journaux Entra ID, la réponse s'arrête souvent à trente jours, voire sept. Voici comment organiser la collecte pour que l'enquête reste possible.
Une rétention native volontairement courte
Entra ID conserve ses journaux d'activité dans le portail pendant une durée qui dépend de la licence. Avec l'offre gratuite, les journaux de connexion et d'audit ne sont disponibles que quelques jours (sept jours selon la documentation actuelle). Avec Entra ID P1 ou P2, la durée passe à trente jours. C'est suffisant pour dépanner un utilisateur, mais pas pour reconstituer une compromission découverte plusieurs semaines après les faits, ce qui est pourtant le cas le plus fréquent.
Ces durées évoluent de temps à autre : vérifiez la documentation Microsoft en vigueur plutôt que de vous fier à un chiffre mémorisé.
Exporter via les paramètres de diagnostic
La solution passe par les paramètres de diagnostic d'Entra ID (Surveillance et intégrité > Paramètres de diagnostic), qui nécessitent une licence P1 ou P2. Trois destinations sont possibles, et rien n'empêche de les combiner :
- Log Analytics : requêtes KQL, classeurs, alertes ; c'est aussi la base de Microsoft Sentinel ;
- compte de stockage : archivage longue durée à faible coût, peu pratique pour la recherche ;
- Event Hub : transfert vers un SIEM tiers.
La durée de conservation devient alors celle que vous définissez sur l'espace de travail ou le stockage, avec un coût d'ingestion à anticiper.
Quelles catégories collecter
L'erreur classique consiste à ne cocher que SignInLogs et AuditLogs. Or une grande partie de l'activité réelle se trouve ailleurs :
NonInteractiveUserSignInLogs: renouvellements de jetons par les clients, là où se voit l'usage d'un jeton volé ;ServicePrincipalSignInLogs: authentifications des applications avec secret ou certificat ;ManagedIdentitySignInLogs: activité des identités managées Azure ;ProvisioningLogs,RiskyUsersetUserRiskEventsselon vos licences ;MicrosoftGraphActivityLogs, utile pour retracer les appels API d'une application malveillante.
Les connexions non interactives sont volumineuses. Si le budget est serré, envoyez-les au moins vers un stockage d'archive plutôt que de les ignorer.
À retenir. Un export configuré après l'incident ne récupère rien du passé. Les paramètres de diagnostic ne sont pas rétroactifs : c'est aujourd'hui qu'il faut les activer.
Pourquoi les enquêtes échouent sans ces journaux
Lors d'une réponse à incident, on cherche à établir la première connexion suspecte, l'adresse IP et l'agent utilisateur, les modifications faites ensuite (méthodes MFA ajoutées, consentements applicatifs, règles de boîte aux lettres) et la persistance éventuelle via un principal de service. Chacune de ces étapes s'appuie sur une catégorie de journaux différente. Sans l'historique complet, on ne peut ni borner l'incident ni démontrer à un assureur ou à une autorité que l'exposition est maîtrisée.
Une requête simple dans Log Analytics permet de vérifier que la collecte fonctionne :
union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs | where TimeGenerated > ago(1d) | summarize count() by Type
Ce qu'un audit vérifie
- l'existence d'au moins un paramètre de diagnostic actif sur le locataire ;
- la présence des catégories non interactives, principaux de service et identités managées ;
- une durée de conservation cohérente avec la politique interne et les obligations réglementaires ;
- la restriction des droits de lecture et de suppression sur l'espace de travail de destination.