Retour au tableau de bord
09
MODULE 09 · COURS

Supervision & Logs

Sign-in / audit / provisioning logs, export Log Analytics, KQL, alertes.

3hdurée
11sections
10questions
OBJECTIFS

Ce que vous saurez faire

5 objectifs · ~5 min

  • Distinguer sign-in logs, audit logs et provisioning logs, et savoir où chacun répond.
  • Configurer l'export des logs Entra vers Log Analytics (diagnostic settings).
  • Écrire des requêtes KQL de base pour investiguer (SigninLogs, AuditLogs).
  • Mettre en place une alerte / un rapport automatisé.
  • Situer Microsoft Sentinel comme à connaître, non déployable en l'état, avec son alternative.

Compétences transférées depuis l'AD classique

L'admin AD réutiliseL'admin AD doit désapprendre
Lecture des journaux d'événements, analyse d'incidents« Les logs sont sur le DC (Event Viewer) » — ici, logs cloud, requêtables en KQL
Corrélation d'événementsGrep / Event Viewer → KQL (langage de requête)
Notion de rétentionLa rétention par défaut est limitée — l'export est nécessaire pour conserver
COURS

Voir et investiguer dans Entra

4 sections · lecture ~30 min

1. Les journaux Entra

Contexte Un utilisateur signale un accès inhabituel à sa boîte mail. Vous ouvrez le portail Entra — où regarder ? Sign-in logs pour la connexion, audit logs pour les modifications d'annuaire, provisioning logs pour les apps. Chaque question a son journal.

Trois journaux principaux, à ne pas confondre :

JournalRépond à la questionExemples
Sign-in logsQui s'est connecté, d'où, comment, avec quel résultat ?Connexion réussie / échouée, MFA, CA appliqué, IP, appareil
Audit logsQui a fait quoi dans l'annuaire ?Création d'utilisateur, ajout à un groupe, changement de rôle, modif de politique CA
Provisioning logsLe provisioning (SCIM) a-t-il bien fonctionné ?Compte créé / mis à jour / désactivé dans une app SaaS
AD CLASSIQUE

Événements de sécurité dans l'Event Viewer de chaque DC (4624, 4625, 4740…), à corréler manuellement.

ENTRA

Journaux centralisés, filtrables au portail, requêtables en KQL après export.

PIÈGE

Croire que la rétention est illimitée. Par défaut : 7 à 30 jours selon la licence. Pour conserver, il faut exporter.

2. Export vers Log Analytics / Sentinel

Pour conserver, corréler et alerter au-delà de la rétention native, on exporte les logs via les Diagnostic settings d'Entra vers :

  • Log Analytics workspace (Azure Monitor) : stockage requêtable en KQL, rétention configurable, base des alertes et classeurs (workbooks). Coût Azure (ingestion + rétention).
  • Un compte de stockage (archivage long terme, peu coûteux, non requêtable directement).
  • Event Hub (streaming vers un SIEM tiers).
Chargement du schéma…
Chaîne d'export des logs Entra. Sentinel (en pointillés) = hors E3+P2 ; alternative = Log Analytics seul + KQL + alertes Azure Monitor.

3. KQL de base

KQL (Kusto Query Language) interroge les tables de Log Analytics (SigninLogs, AuditLogs, AADProvisioningLogs…). Structure : on part d'une table, on enchaîne des opérateurs avec |.

Opérateurs essentiels :

OpérateurRôleAnalogie
whereFiltrerWHERE SQL / Where-Object
projectSélectionner des colonnesSELECT / Select-Object
summarizeAgréger (count, dcount, avg…)GROUP BY
sort byTrierORDER BY
ago(x)Fenêtre temporelle—

Exemple 1 — Connexions échouées des dernières 24h, par utilisateur

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0                     // 0 = succès ; != 0 = échec
| summarize Echecs = count() by UserPrincipalName
| sort by Echecs desc

Exemple 2 — Détecter un possible password spraying

Beaucoup d'échecs « mauvais mot de passe » (50126), peu de comptes ciblés, une IP.

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == 50126               // mauvais mot de passe
| summarize Tentatives = count(), Comptes = dcount(UserPrincipalName) by IPAddress
| where Tentatives > 20
| sort by Tentatives desc

Exemple 3 — Qui a modifié des politiques CA cette semaine ?

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has "conditional access policy"
| project TimeGenerated, InitiatedBy, OperationName, TargetResources
Question rapide

Vous écrivez votre première requête KQL sur SigninLogs. Quel filtre mettez-vous toujours en premier ?

La fenêtre temporelle avec ago().

Toujours borner le temps en premier filtre (where TimeGenerated > ago(24h)). Sans ça, la requête scanne toute la table depuis le début de la rétention (parfois des mois), consomme des ressources et facture de l'ingestion inutile. Après le filtre temporel, on affine avec les autres critères.

4. Alertes & rapports automatisés

  • Alertes Azure Monitor — déclenchées sur une requête KQL planifiée (ex : « alerter si un compte break-glass se connecte » — signal fort à surveiller).
  • Workbooks — tableaux de bord visuels (connexions, échecs MFA, application des politiques CA).
  • Rapports Entra natifs — usage MFA, application des politiques CA, connexions à risque (Identity Protection).

Sources Microsoft Learn

Rappel : en cas d'écart entre ce support et le portail, le portail fait foi.

LAB

Export, KQL, alerte break-glass

3 parties · TP guidé ~2h · Portail : entra + portal.azure.com

Partie A — Configurer l'export vers Log Analytics (30 min)

  1. Créer un workspace Log Analytics : portal.azure.com > Log Analytics workspaces > Create. Région et resource group cohérents avec votre tenant Azure.
  2. Configurer les diagnostic settings : Entra admin center > Monitoring & health > Diagnostic settings > Add diagnostic setting.
  3. Cocher SignInLogs, AuditLogs (au minimum ; ajouter les autres selon besoin). Destination : le workspace créé.
  4. Attendre 15-30 min qu'un premier lot arrive dans le workspace.

Partie B — Écrire vos premières requêtes KQL (45 min)

Portail : Log Analytics workspace > Logs.

  1. Comptez les connexions réussies aujourd'hui : SigninLogs | where TimeGenerated > ago(1d) | where ResultType == 0 | count.
  2. Top 10 des utilisateurs par nombre de connexions : ajoutez | summarize N=count() by UserPrincipalName | top 10 by N.
  3. Recherchez les modifications de politiques CA de la semaine : AuditLogs | where TimeGenerated > ago(7d) | where OperationName has "conditional access policy" | project TimeGenerated, InitiatedBy, OperationName.
  4. Reproduisez la requête spraying de la section 3 et adaptez le seuil Tentatives > 20 à votre volume.

Partie C — Alerte « break-glass utilisé » (45 min)

Portail : Log Analytics workspace > Alerts > New alert rule.

  1. Signal : Custom log search, requête : 
    SigninLogs
| where TimeGenerated > ago(5m)
| where UserPrincipalName in ("break-glass-01@votretenant.onmicrosoft.com", "break-glass-02@votretenant.onmicrosoft.com")
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
  2. Threshold : Number of results > 0. Evaluation : toutes les 5 min sur 5 min.
  3. Action group : notification e-mail + SMS à l'équipe sécurité.
  4. Severity : Sev 1 (haute).
PIÈGES CLASSIQUES

5 pièges de supervision

Lecture ~10 min

ÉVALUATION

Testez vos acquis

10 questions QCM · cas pratique · ~30 min

Une évaluation interactive qui vous donne le badge Acquis (≥60%) ou Maîtrisé (≥80%).

Évaluation non tentée.

Cas pratique — Tentative d'intrusion signalée

Contexte : après une tentative d'intrusion signalée, la direction veut « savoir ce qui se passe » et être alertée à l'avenir. SI en E3 + P2, pas de budget pour un SIEM complet.

Questions :

  1. Où regardez-vous en premier, et pour chercher quoi ?
  2. Écrivez (en français ou en KQL) la logique pour détecter un password spraying.
  3. Quelle architecture de supervision proposez-vous, compte tenu du budget ?
  4. Quelles 2-3 alertes mettez-vous en place en priorité ?

Démarche attendue

  1. Sign-in logs en premier : connexions échouées, IP inhabituelles, pays inattendus, MFA contournée, politiques CA appliquées. Puis audit logs pour vérifier qu'aucun changement suspect (rôle, politique CA, ajout d'app) n'a suivi.
  2. Spraying : sur une fenêtre courte, chercher une IP générant beaucoup d'échecs « mauvais mot de passe » (50126) répartis sur peu de comptes distincts. En KQL : 
    SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == 50126
| summarize Tentatives=count(), Comptes=dcount(UserPrincipalName) by IPAddress
| where Tentatives > 20
  3. Architecture E3+P2 (sans SIEM) : export des SignInLogs / AuditLogs vers un Log Analytics workspace (coût Azure maîtrisé), KQL + workbooks pour l'investigation, alertes Azure Monitor + rapports Entra natifs. Sentinel est écarté (coût / complexité) mais connu comme évolution possible.
  4. Alertes prioritaires : (a) connexion d'un compte break-glass, (b) password spraying (règle ci-dessus), (c) modification d'un rôle à privilèges ou d'une politique CA. Peu d'alertes, à forte valeur, sur lesquelles on agit réellement.

Grille d'auto-évaluation