Microsoft AZ-500: Microsoft Sentinel et opérations de sécurité — Guide d'étude

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Security Engineer Associate AZ-500 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Microsoft Sentinel est la plateforme SIEM et SOAR native du cloud d’Azure, construite sur Azure Monitor Log Analytics. Elle centralise la télémétrie de sécurité, applique des analyses pour détecter les menaces, génère des incidents pour le triage par les analystes et orchestre la réponse automatisée avec Logic Apps. Des opérations efficaces reposent sur une architecture d’espace de travail bien conçue, une intégration délibérée des données, une rétention soucieuse des coûts, des analyses et un mappage d’entités précis, ainsi qu’un régime d’automatisation et d’ajustement qui aligne les alertes sur les flux de travail du SOC et les risques métier.

Architecture et gestion des données de Sentinel

• Espaces de travail et considérations multi-locataires

  • Sentinel s’exécute par espace de travail Log Analytics. Choisissez les limites de l’espace de travail en fonction de la souveraineté des données, de la latence et de l’isolement administratif. Un espace de travail unique de type « SOC central » simplifie la corrélation et la gestion de contenu ; plusieurs espaces de travail peuvent être appropriés pour des modèles de résidence stricte, d’autonomie ou de MSSP/Lighthouse. Les requêtes inter-espaces de travail sont prises en charge mais ajoutent de la latence et des coûts ; préférez la consolidation lorsque la corrélation entre les entités est essentielle.
  • Utilisez le RBAC basé sur le contexte des ressources sur l’espace de travail pour séparer les tâches : Sentinel Reader pour les tableaux de bord, Responder pour la gestion des incidents, Contributor pour la gestion de contenu et Automation Contributor pour les playbooks.

• Chemins d’ingestion

  • Les données entrent dans les tables de l’espace de travail via des connecteurs natifs, des agents Azure Monitor ou des API. Préférez les connecteurs natifs pour les sources Microsoft (schéma optimisé, fiabilité) et AMA+DCR pour Windows/Syslog afin de bénéficier du filtrage et du contrôle du plan par table. Pour les appareils tiers, acheminez le CEF via Syslog vers la table CommonSecurityLog pour bénéficier des analyseurs et du contenu analytique intégrés.

• Rétention, archivage et recherche

  • Configurez la rétention par table pour conserver les données chaudes (analyses interactives) pendant la fenêtre de détection opérationnelle (généralement de 30 à 120 jours). Archivez les données plus anciennes dans le niveau Archive de Log Analytics jusqu’à 7 ans pour satisfaire la conformité à un coût considérablement réduit ; utilisez les Search Jobs ou la restauration (Restore) pour les investigations. Raisonnement opérationnel : ne conservez que ce sur quoi les analystes pivotent régulièrement ; archivez le reste pour répondre aux besoins d’audit/réglementaires sans gonfler les dépenses du chemin d’accès chaud.

• Contrôles des coûts

  • Les niveaux d’engagement (réservations de capacité) réduisent le coût d’ingestion de manière prévisible pour les volumes stables ; activez-les après avoir établi une base de référence de 30 à 60 jours pour éviter un engagement excessif.
  • Plans de facturation au niveau de la table : utilisez le mode Analytics pour les tables critiques pour la sécurité (SecurityEvent, SignInLogs, CommonSecurityLog). Utilisez les journaux de base (Basic Logs) pour les diagnostics verbeux et de faible valeur que vous interrogez rarement ; ne placez jamais de tables de sécurité à signal élevé en mode Basic car elles perdent les fonctionnalités de requête complètes et ne sont pas éligibles pour les alertes.
  • Les transformations au moment de l’ingestion avec les DCR permettent de supprimer ou de masquer des champs et des lignes (minimisation des PII, réduction du bruit) avant la facturation. Sur le plan opérationnel, l’élimination du bruit avant l’ingestion est le contrôle de coût et de fidélité le plus puissant.
  • Définissez des plafonds quotidiens pour l’espace de travail et des alertes sur les pics anormaux pour détecter les erreurs de configuration ou les attaques générant des tempêtes de journaux.

Connecteurs de données et ingestion

• Azure Activity

  • Utilisez le connecteur Azure Activity pour diffuser en continu les opérations du plan de contrôle au niveau de l’abonnement dans la table AzureActivity via les paramètres de diagnostic. Raisonnement : capture les changements de rôle, les mises à jour de stratégie et les déploiements — des indicateurs clés de l’escalade de privilèges ou de la falsification par un attaquant.

• Microsoft Entra ID (Azure AD)

  • Activez les connecteurs AuditLogs et SignInLogs. Ingestez éventuellement les journaux enrichis d’Azure AD si vous disposez de la licence. Raisonnement : l’identité est la principale surface d’attaque ; les anomalies de connexion et les modifications d’annuaire sont à la base de la plupart des détections et de l’UEBA.

• Produits Microsoft Defender

  • Les connecteurs Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps et Defender for Cloud apportent des alertes et une télémétrie de haute fidélité. Raisonnement : les alertes de sécurité Microsoft sont profondément corrélées et augmentent la qualité des incidents ; ingérez-les pour alimenter Fusion et les règles de sécurité Microsoft avec un minimum d’ajustements.

• Événements Windows

  • Utilisez l’agent Azure Monitor (AMA) avec une DCR : les événements de sécurité Windows (Windows Security Events) vers la table SecurityEvent (Common, Minimal ou All) pour les contrôleurs de domaine et les serveurs critiques ; les canaux d’événements Windows généraux vers la table WindowsEvent selon les besoins. Raisonnement : SecurityEvent est la colonne vertébrale de l’audit d’authentification et de processus ; le filtrage par DCR réduit le bruit (par exemple, exclure l’événement 4688 sans CommandLine).

• Syslog et CEF

  • Pour Linux, une DCR Syslog pour l’AMA sélectionne les installations/sévérités dans la table Syslog. Pour les pare-feu/IDS/EDR tiers, transférez le CEF au redirecteur basé sur l’agent Log Analytics ou à l’ingestion basée sur l’AMA qui aboutit dans CommonSecurityLog ; utilisez le contenu de l’analyseur du fournisseur. Raisonnement : le CEF maintient des champs normalisés et réduit la charge d’analyse ; CommonSecurityLog débloque des détections préconfigurées.

• Hygiène opérationnelle

  • Synchronisation de l’heure (NTP) et fuseaux horaires cohérents sur les appareils pour une corrélation précise.
  • Dédoublonnez les sources qui se chevauchent (par exemple, n’ingérez pas à la fois les doublons bruts et normalisés).
  • Validez le schéma avec des listes de surveillance (Watchlists) ou des exemples de requêtes avant d’activer les analyses pour éviter les faux positifs.

Analyse, Détection et Investigation

• Types de règles d’analyse

  • Règles planifiées : KQL sur des données historiques à une cadence définie (par ex., toutes les 5 minutes, avec une analyse rétrospective d’une heure). À utiliser pour la plupart des détections ; ajustez la période d’analyse rétrospective pour qu’elle dépasse la latence typique des données afin d’éviter les oublis.
  • Quasi-temps réel (NRT) : détection en moins d’une minute avec un KQL restreint et une courte période d’analyse rétrospective fixe. À utiliser avec parcimonie pour les schémas à haute urgence où les secondes comptent (par ex., attribution de rôles en masse). Fonctionne avec un minimum de jointures et des filtres simples pour de meilleures performances.
  • Fusion : corrélation multi-étapes basée sur le ML à travers les signaux Microsoft (Defender, Entra, Cloud Apps). Raisonnement : réduit considérablement la fatigue des alertes en produisant un seul incident pour une chaîne d’attaque complète.
  • Règles d’anomalie : lignes de base utilisateur/entité avec des seuils dynamiques. Fournissent des gains rapides pour des schémas inhabituels de géolocalisation, de volume ou de processus ; maintenez des listes d’exclusion pour les anomalies autorisées (par ex., fenêtres de maintenance).
  • Règles de sécurité Microsoft : créent automatiquement des incidents à partir des alertes Defender. Gardez-les activées et ajustez les règles d’automatisation pour le routage/la sévérité ; elles fournissent des signaux de haute confiance avec un faible effort d’ajustement.

• Mappage d’entités et incidents

  • Mappez les colonnes de sortie KQL aux entités (Account, Host, IP, URL, File) dans la configuration de la règle pour alimenter les graphes d’incidents et l’UEBA. Un mauvais mappage dégrade la fidélité de l’investigation.
  • La politique de regroupement des alertes influence le volume et le contexte des incidents. Regroupez par entités/fenêtre temporelle pour combiner les alertes associées, réduisant ainsi le bruit tout en préservant le fil conducteur.

• Investigation et UEBA

  • Les incidents présentent une chronologie, des preuves et des entités associées ; le graphe d’investigation construit automatiquement les relations à partir du mappage d’entités et des recherches de données.
  • Activez l’UEBA pour enrichir les entités avec des lignes de base de pairs, des rôles d’appareils et des signaux de risque. Raisonnement : le contexte raccourcit le temps de triage et éclaire la portée de la réponse.

• Fondamentaux de KQL pour l’ingénierie de détection

  • Filtrage et projection

    SignInLogs
    | where TimeGenerated > ago(24h) and ResultType != 0
    | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
    ```

  - Analyse syntaxique et normalisation

CommonSecurityLog
| extend Url = extract(@"request=([^;\s]+)", 1, AdditionalExtensions)
| parse DeviceCustomString1 with * "cmd=" CommandLine
```

• Jointure

    SecurityEvent
    | where EventID == 4624 and AccountType == "User"
    | summarize logons = count() by Account, bin(TimeGenerated, 1h)
    | join kind=inner (
        SignInLogs
        | summarize aad_logons = count() by UserPrincipalName, bin(TimeGenerated, 1h)
    ) on $left.Account == $right.UserPrincipalName, TimeGenerated
    ```

  - Synthèse et analyse par fenêtre temporelle

SignInLogs
| where TimeGenerated between (ago(1d) .. now())
| summarize attempts = count(), byIP = dcount(IPAddress) by UserPrincipalName
| where attempts > 50 or byIP > 10
```

Chasse, automatisation, renseignement sur les menaces, reporting et ajustement du SOC

• Flux de travail de la chasse aux menaces (Threat Hunting)

  • Requêtes de chasse : partez des modèles Sentinel ; faites-les évoluer avec des listes blanches spécifiques à l’environnement. Sauvegardez les pistes prometteuses en tant que requêtes personnalisées pour les réutiliser.
  • Signets (Bookmarks) : capturez les preuves et les points de pivot pendant les chasses ; attachez-les plus tard aux incidents pour préserver le contexte de l’analyste.
  • Livestream : exécutez un filtre KQL en continu pour repérer les événements à leur arrivée ; idéal lors d’incidents actifs pour confirmer le confinement.
  • Listes de surveillance (Watchlists) : chargez des ensembles d’autorisation/refus/priorité basés sur des CSV (utilisateurs VIP, IP sanctionnées, niveaux d’actifs). Référencez-les avec la fonction _GetWatchlist pour l’enrichissement et la suppression.

• Règles d’automatisation et playbooks

  • Les règles d’automatisation effectuent le tri à la création de l’incident/alerte : définir la gravité, assigner un propriétaire, ajouter des étiquettes, clore avec une classification, ou déclencher des playbooks selon des conditions (nom de la règle, tactiques, entités).
  • Les Playbooks (Logic Apps) implémentent le SOAR : enrichir avec VirusTotal/MDTI, notifier dans Teams, ouvrir des tickets (ServiceNow/Jira), isoler des points de terminaison (MDE), ou désactiver des comptes (Entra). Utilisez des identités managées et un RBAC de moindre privilège (rôle Sentinel Responder sur le workspace ; rôles à portée limitée pour les systèmes cibles). Raisonnement : des actions codifiées et répétables réduisent le MTTR et les erreurs manuelles.

• Renseignement sur les menaces (Threat Intelligence/TI)

  • Ingérez les indicateurs de TI via les fournisseurs intégrés, le chargement manuel, l’automatisation GitHub, ou les collecteurs TAXII (STIX 2.0/2.1). Normalisez les champs (type d’indicateur, modèle, confiance, TLP) et définissez une expiration pour éviter les correspondances obsolètes.
  • Correspondance d’indicateurs : activez les règles d’analyse basées sur la TI pour faire correspondre les IP/domaines/URL/hachages avec la télémétrie (CommonSecurityLog, DNS, Proxy, SignInLogs). Utilisez des seuils de confiance et des exceptions de listes de surveillance pour réduire le bruit. Raisonnement : la TI réduit l’espace de recherche aux menaces connues, mais doit être curée pour éviter les faux positifs.

• Classeurs (Workbooks) et reporting

  • Construisez des tableaux de bord opérationnels avec Azure Monitor Workbooks. Paramétrez par abonnement, workspace ou plage de temps ; résumez les données en amont (summarize, make-series) pour maintenir l’efficacité des requêtes.
  • Fournissez des vues à plusieurs niveaux : posture exécutive (incidents par gravité/SLA), opérations du SOC (ouverts vs fermés, vieillissement de la file d’attente, charge des analystes), santé des détections (état des connecteurs, latence des données), et couverture des contrôles (mappage MITRE). Raisonnement : des vues spécifiques aux rôles aident à la prise de décision sans noyer les utilisateurs sous les événements bruts.

• Ajustement du SOC et procédures

  • Réduction des faux positifs : affinez les prédicats KQL, ajoutez des lignes de base (seuils dynamiques), utilisez des listes d’autorisation d’entités (watchlists), et excluez les sources bénignes. Validez chaque suppression avec un contrôle compensatoire.
  • Normalisation de la gravité : mappez la gravité de la règle à l’impact et à la confiance, pas à la fréquence. Élevée doit impliquer un réveil de l’astreinte ; Moyenne un tri rapide ; Faible pour la chasse en backlog.
  • Escalade et transfert : définissez les états d’incident, les propriétaires et les SLAs ; enrichissez et routez automatiquement vers la bonne file d’attente ; ouvrez des tickets ITSM via des playbooks avec des mises à jour bidirectionnelles. Documentez les étapes de confinement pour chaque tactique (désactiver l’utilisateur, isoler le point de terminaison, révoquer les jetons, bloquer les indicateurs).

Scénario de problème pratique

Contoso Ltd. subit une fatigue liée aux alertes et une lenteur de réponse après avoir intégré de multiples sources de données dans Microsoft Sentinel. Les incidents sont nombreux, mal regroupés et manquent d’automatisation. Le RSSI exige une réduction de 50 % du temps moyen de réponse (MTTR) sans perdre la fidélité de la détection.

1. Ré-architecturer l’ingestion des données avec le filtrage DCR et les plans de table

• Action : Déplacer les Événements de Sécurité Windows vers AMA+DCR avec le préréglage « Common » sur les contrôleurs de domaine ; basculer les tables de diagnostic verbeuses en Logs Basiques ; activer 90 jours de rétention à chaud et 1 an d’archivage.
• Raisonnement : Réduit le bruit et le coût du chemin d’accès chaud tout en préservant les données de sécurité exploitables, libérant ainsi des cycles d’analyse et du budget pour des détections de plus haute fidélité.

2. Activer les connecteurs Microsoft Defender et Fusion

• Action : Connecter MDE, MDI, MDO, MDC et Cloud Apps ; s’assurer que les analyses de sécurité Microsoft et Fusion sont activés.
• Raisonnement : Les alertes de haute confiance et la corrélation par ML regroupent les alertes en double en un seul incident enrichi, réduisant la charge de tri.

3. Standardiser le mappage d’entités et le regroupement d’alertes

• Action : Mettre à jour les règles planifiées pour mapper Account, Host, IP et URL ; configurer le regroupement par Account et une fenêtre de 4 heures pour les alertes associées.
• Raisonnement : Un mappage correct alimente les graphes d’investigation et l’UEBA ; le regroupement diminue le volume d’incidents tout en préservant le contexte pour les chaînes d’attaque.

4. Implémenter des règles d’automatisation pour le tri et des playbooks ciblés

• Action : Créer des règles d’automatisation pour étiqueter automatiquement par tactique, définir la gravité selon la confiance, assigner aux files d’attente et déclencher des playbooks : enrichir les indicateurs (MDTI), ouvrir des tickets ServiceNow, isoler les appareils (MDE) et suspendre les utilisateurs à risque (Entra) avec approbation.
• Raisonnement : Le tri déterministe et les actions SOAR raccourcissent le MTTR et standardisent les réponses ; les approbations appliquent des garde-fous pour les étapes à fort impact.

5. Introduire les listes de surveillance (watchlists) et la correspondance de TI avec curation

• Action : Construire des listes de surveillance pour les utilisateurs VIP et les services sanctionnés ; ajouter un flux TAXII curé avec une confiance >= 70 et une expiration de 7 jours ; activer les règles de correspondance de TI sur le proxy/DNS.
• Raisonnement : Priorise les cibles de grande valeur et utilise une TI fraîche et fiable pour concentrer les investigations et réduire les faux positifs.

6. Publier des classeurs (workbooks) basés sur les rôles et des SLAs

• Action : Créer des classeurs pour les dirigeants, les opérations du SOC et la santé des détections ; définir des SLAs pour les incidents (Élevée 4h, Moyenne 24h, Faible 3j) et signaler les dépassements.
• Raisonnement : La visibilité et la responsabilisation favorisent la discipline opérationnelle ; des tableaux de bord ciblés évitent le changement de contexte et les efforts inutiles.

7. Établir une cadence d’ajustement continu

• Action : Revue hebdomadaire des incidents clos comme faux positifs ; ajuster les règles, les suppressions et les exclusions avec des justifications documentées ; surveiller les anomalies d’ingestion et la performance des requêtes.
• Raisonnement : Les opérations de sécurité dérivent sans boucles de rétroaction ; un affinement continu maintient la qualité du signal à mesure que l’environnement évolue.

En exécutant ces étapes, Contoso aligne les détections sur le risque métier, réduit le bruit à la source et automatise les tâches répétitives, obtenant ainsi une réponse aux incidents plus rapide et plus cohérente sans sacrifier la couverture.

← Gestion de la posture de sécurité et gouvernance · Tous les domaines · Sécurité des applications et DevSecOps →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →