Conserver les logs Entra ID au-delà de 30 jours avec Log Analytics

Microsoft Entra ID génère quotidiennement des journaux d’audit et de connexion qui retracent l’ensemble de l’activité de votre tenant. Ces informations sont précieuses lors d’une investigation de sécurité ou d’un simple contrôle de conformité. Malheureusement, Entra ID ne les conserve que 7 jours avec une licence Free, et 30 jours avec une licence P1 ou P2. Au-delà, la donnée est définitivement perdue.

Pour dépasser cette limite, la solution consiste à exporter ces journaux vers un Log Analytics workspace grâce aux paramètres de diagnostic Entra ID.

Dans cet article, nous verrons :

• Comment créer un Log Analytics workspace depuis le portail Azure.
• Comment configurer le paramètre de diagnostic depuis le centre d’administration Entra.
• Comment vérifier la bonne réception des journaux à l’aide de requêtes KQL.

Prérequis et informations pertinentes

Pour réaliser cette configuration, vous devez disposer du rôle Administrateur de la sécurité sur votre tenant Entra ID afin de créer le paramètre de diagnostic, ainsi que du rôle Contributeur sur votre souscription Azure pour créer les ressources associés.

Vous devez également disposer d’une souscription Azure active. Attention sur ce point : un paramètre de diagnostic Entra ID ne peut cibler qu’un Log Analytics workspace situé dans une souscription rattachée au même tenant. Si vous administrez plusieurs tenants, il vous faudra donc un workspace par tenant.

Enfin, sachez que le nom d’un paramètre de diagnostic ne peut pas être modifié après sa création. Il faudra le supprimer et le recréer, alors autant le nommer correctement dès le départ.

Choisir le nom de ses ressources Azure

Avant de créer quoi que ce soit, prenons deux minutes pour le nommage. Un groupe de ressources ne peut pas être renommé dans Azure : il faut supprimer et recréer les ressources qu’il contient… Autant donc partir sur de bonnes bases.

Microsoft propose une convention dans son Cloud Adoption Framework, sous la forme suivante :

<type-de-ressource>-<charge-de-travail>-<environnement>-<région>-<instance>

Ce qui donne par exemple rg-monitoring-prd-frc-001 pour le groupe de ressources et log-entraid-prd-frc-001 pour le workspace.

Si votre environnement ne comporte qu’un seul tenant, une seule région et pas de distinction entre production et préproduction, vous pouvez simplifier sans complexe : rg-monitoring et log-entraid. 

Pensez simplement à toujours travailler en minuscules, car certaines ressources Azure refusent purement et simplement les majuscules.

Un dernier conseil : gardez le nom de votre groupe de ressources générique. Si vous le nommez rg-monitoring-entraid et que vous y ajoutez plus tard des alertes Azure ou du VM Insights, le nom deviendra trompeur…

Créer le Log Analytics workspace depuis le portail Azure

Voici les actions à faire pour créer votre workspace depuis le portail Azure :

1. Connectez-vous au portail Azure avec un compte disposant des droits nécessaires. (https://portal.azure.com)
2. Dans la barre de recherche en haut, saisissez Log Analytics workspaces puis cliquez sur le résultat correspondant.
3. Cliquez sur Créer en haut à gauche de la page.
4. Sélectionnez votre souscription, puis cliquez sur Créer sous le champ Groupe de ressources pour en créer un nouveau nommé rg-monitoring.
5. Renseignez le nom de votre workspace, par exemple log-entraid.
6. Choisissez la région dans laquelle vos données seront stockées. Si vos données doivent rester en France, sélectionnez France Central.
7. Cliquez sur Vérifier + créer, puis sur Créer.

Le déploiement prend généralement moins d’une minute. Une fois terminé, votre workspace est prêt à recevoir des données.

Voici les actions en image :

Protéger son workspace d’une suppression accidentelle

Je vous recommande vivement d’ajouter un verrou de suppression sur votre groupe de ressources. En cas de suppression accidentelle du workspace, vous ne disposez que de 14 jours de suppression réversible pour le récupérer. Ce serait dommage de perdre justement les journaux que vous cherchiez à conserver.

1. Ouvrez votre groupe de ressources rg-monitoring dans le portail Azure.
2. Dans le menu de gauche, cliquez sur Verrous.
3. Cliquez sur Ajouter.
4. Donnez un nom à votre verrou, par exemple lock-monitoring.
5. Sélectionnez le type Supprimer.
6. Cliquez sur OK.

Toutes les ressources contenues dans le groupe héritent automatiquement de ce verrou.

Configurer le paramètre de diagnostic dans Entra ID

C’est ici que tout se joue : le paramètre de diagnostic constitue le pont entre Entra ID et votre workspace.

1. Connectez-vous au centre d’administration Entra avec un compte Administrateur de la sécurité. (https://entra.microsoft.com)
2. Dans le menu de gauche, cliquez sur Entra ID, puis sur Surveillance et intégrité, et enfin sur Paramètres de diagnostic.
3. Cliquez sur Ajouter un paramètre de diagnostic.
4. Donnez un nom à votre paramètre, par exemple diag-entraid.
5. Dans la partie gauche, cochez les catégories de journaux que vous souhaitez exporter.
6. Dans la partie droite, cochez Envoyer à Log Analytics, puis sélectionnez votre souscription et votre workspace log-entraid.
7. Cliquez sur Enregistrer.

Voici les actions en image :

Quelles catégories faut-il cocher ?

La liste proposée par Microsoft est longue et une bonne partie ne vous concernera probablement pas. Voici les catégories essentielles à activer dans la majorité des cas :

• AuditLogs : toutes les modifications réalisées sur les utilisateurs, les groupes, les applications et les licences de votre tenant.
• SignInLogs : les connexions interactives, c’est-à-dire lorsqu’un utilisateur saisit son mot de passe ou valide un défi MFA.
• NonInteractiveUserSignInLogs : les connexions effectuées au nom d’un utilisateur par une application cliente, comme le renouvellement de jeton d’Outlook ou de Teams.
• ServicePrincipalSignInLogs : les authentifications d’applications réalisées avec un certificat ou un secret client.
• ProvisioningLogs : le provisionnement d’utilisateurs vers des applications tierces, à activer si vous utilisez le provisionnement automatique.

D’autres catégories existent mais ne produiront aucune donnée si vous n’utilisez pas les services associés. C’est le cas de RiskyUsers et UserRiskEvents qui nécessitent une licence Entra ID P2, de NetworkAccessTrafficLogs réservée à Global Secure Access, ou encore de ADFSSignInLogs si vous n’avez plus de ferme ADFS.

Une catégorie mérite une attention particulière : MicrosoftGraphActivityLogs. Elle enregistre toutes les requêtes HTTP adressées à Microsoft Graph sur les ressources de votre tenant. C’est extrêmement utile en investigation, puisque cela permet de reconstituer ce qu’un compte compromis a réellement fait et pas uniquement de constater qu’il s’est connecté. Attention toutefois, le volume généré est important.

À l’inverse, laissez la catégorie MicrosoftServicePrincipalSignInLogs décochée. Microsoft précise lui-même qu’elle n’est pas nécessaire à la plupart des clients et déconseille fortement de désactiver des applications en se basant sur ces données.

Vérifier que les journaux arrivent bien

Une fois la configuration enregistrée, ne paniquez pas si rien n’apparaît immédiatement. Comptez entre 15 minutes et 1 heure avant de voir les premiers enregistrements.

Retenez également ce point important : une table n’existe dans le workspace qu’à partir du moment où elle reçoit son premier enregistrement. Une table absente ne signifie donc pas forcément que votre configuration est erronée.

Pour contrôler l’arrivée des données, connectez-vous à votre workspace, cliquez sur Journaux dans le menu de gauche, puis exécutez la requête KQL suivante :

union isfuzzy=true withsource=Table
    AuditLogs, SigninLogs, AADNonInteractiveUserSignInLogs,
    AADServicePrincipalSignInLogs, AADProvisioningLogs
| where TimeGenerated > ago(24h)
| summarize Evenements = count(),
            Premier = min(TimeGenerated),
            Dernier = max(TimeGenerated)
      by Table
| order by Table asc

Le paramètre isfuzzy=true est indispensable ici. Sans lui, la requête échouera dès qu’une seule des tables listées n’existe pas encore dans votre workspace.

Vous pouvez également vérifier le délai d’ingestion de vos données avec cette requête :

SigninLogs
| where TimeGenerated > ago(2h)
| extend Latence = ingestion_time() - TimeGenerated
| summarize Moyenne = avg(Latence), Maximum = max(Latence), Evenements = count()

Une latence de 5 à 20 minutes est tout à fait normale. Si vous constatez des délais supérieurs à une heure de façon persistante, il y a effectivement un souci à investiguer.

Si tout reste vide et que vous doutez de votre configuration, provoquez vous-même un événement. Créez puis supprimez un groupe de test dans Entra ID pour alimenter la table AuditLogs, ou déconnectez-vous puis reconnectez-vous au portail pour alimenter la table SigninLogs. Vérifiez ensuite le résultat avec cette requête :

AuditLogs
| where TimeGenerated > ago(30m)
| project TimeGenerated, OperationName, InitiatedBy, TargetResources
| order by TimeGenerated desc

Adapter la durée de conservation

Par défaut, un Log Analytics workspace conserve les données 30 jours. Vous pouvez étendre cette durée jusqu’à 730 jours en rétention interactive, c’est-à-dire la période pendant laquelle vos données restent interrogeables en KQL.

Pour modifier cette valeur au niveau du workspace :

1. Ouvrez votre workspace log-entraid dans le portail Azure.
2. Dans le menu de gauche, cliquez sur Paramètres d’utilisation et coûts estimés.
3. Cliquez sur Rétention des données en haut de la page.
4. Ajustez le curseur sur la valeur souhaitée, par exemple 90 jours.
5. Cliquez sur OK.

Sachez que 31 jours de rétention interactive sont déjà inclus dans le prix d’ingestion. Descendre en dessous ne vous fera donc économiser strictement rien.

Au-delà, il existe une rétention dite de long terme, nettement moins coûteuse, qui permet de conserver les données jusqu’à 12 ans. Les données ne sont alors plus directement interrogeables et nécessitent le lancement d’un search job pour redevenir accessibles.

Pour un besoin de conservation sur deux ans, la bonne approche consiste donc à configurer 90 jours en rétention interactive puis le reste en rétention de long terme, plutôt que 730 jours d’interactif. Ce réglage se fait table par table :

1. Dans votre workspace, cliquez sur Tables dans le menu de gauche.
2. Recherchez la table concernée, par exemple SigninLogs.
3. Cliquez sur les trois points à droite de la ligne, puis sur Gérer la table.
4. Renseignez la rétention interactive et la rétention totale souhaitées.
5. Cliquez sur Enregistrer.

Rassurez-vous, si vous réduisez la rétention par erreur, Azure Monitor patiente 30 jours avant de supprimer réellement les données. Vous avez donc le temps de revenir en arrière.

Enfin, surveillez vos volumes dès les premiers jours plutôt que de découvrir la facture à la fin du mois :

Usage
| where TimeGenerated > ago(7d)
| where IsBillable == true
| summarize GoFactures = round(sum(Quantity) / 1024, 3) by DataType, bin(TimeGenerated, 1d)
| order by TimeGenerated desc, GoFactures desc

Félicitations ! Vos journaux Entra ID sont désormais conservés bien au-delà de la limite native de 30 jours. Un dernier point à ne pas confondre cependant : cette configuration ne change rien à la rétention affichée dans le portail Entra ID. Les pages Journaux de connexion et Journaux d’audit resteront limitées à 7 ou 30 jours selon votre licence. Votre workspace devient donc votre seule source au-delà de cette période, ce qui justifie pleinement le verrou de suppression que nous avons posé plus haut.

N’hésitez pas à consulter la documentation officielle pour découvrir l’ensemble des catégories de journaux disponibles.