Microsoft AZ-801: Microsoft Sentinel et surveillance de la sécurité — Guide d'étude

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Fait partie du Microsoft Windows Server Hybrid Administrator Associate AZ-801 — 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 un SIEM et un SOAR natif du cloud qui unifie l’ingestion des journaux, l’analytique, la détection des menaces, la réponse aux incidents et la chasse proactive (hunting) sur des parcs de serveurs Windows hybrides. Pour les scénarios de l’AZ-801, la maîtrise implique de connecter à grande échelle les événements de sécurité Windows, les journaux Syslog de Linux et les sources CEF tierces, de concevoir des analyses avec une latence minimale, de mapper les alertes à des entités pour une investigation précise, et d’automatiser le confinement via des playbooks basés sur Logic Apps. Le succès dépend également d’une architecture d’espaces de travail Log Analytics rigoureuse, de règles de collecte de données (DCR) bien gouvernées pour l’Azure Monitor Agent (AMA), d’une stratégie de rétention solide et d’une compétence opérationnelle en matière d’UEBA, de listes de surveillance (watchlists), de chasse (hunting) et de classeurs (workbooks).

Connecteurs et ingestion de données

Les événements de sécurité Windows via AMA sont la source canonique pour les événements d’ouverture de session, de création de processus, de changement de politique et autres événements d’audit sur Windows Server. Activez le connecteur « Windows Security Events via AMA » dans Microsoft Sentinel et créez une DCR qui sélectionne les ensembles d’événements appropriés à votre profil de risque (Minimal, Common ou All, ou une sélection personnalisée par ID d’événement). Les données atterrissent principalement dans la table SecurityEvent ; les canaux Windows non liés à la sécurité (s’ils sont activés) atterrissent dans WindowsEvent. Associez cela à une stratégie de groupe (Group Policy) pour vous assurer que la base de référence de sécurité et les sous-catégories d’audit (par ex., Logon/Logoff, Account Logon, Object Access, DS Access) sont activées sur les serveurs sources afin de générer la télémétrie nécessaire.

Syslog via AMA collecte les données des serveurs Linux et des équipements réseau qui utilisent le protocole Syslog. Installez l’AMA sur les hôtes Linux (ou sur un collecteur Linux dédié) et configurez une DCR pour spécifier les installations (facilities) et les niveaux de gravité (severities) à ingérer. Les événements sont écrits dans la table Syslog. Pour les installations à volume élevé mais à faible valeur, envisagez une collecte sélective ou une transformation à la source pour maîtriser les coûts et le bruit.

CEF via AMA permet l’ingestion de journaux de sécurité normalisés provenant de produits de sécurité tiers (pare-feux, IDS/IPS, proxys, EDR). Déployez l’AMA sur un collecteur Linux et configurez vos fournisseurs pour transférer les journaux CEF au démon syslog local (rsyslog/syslog-ng) sur les ports typiques 514/UDP ou TCP. Dans Sentinel, activez le connecteur de données « CEF via AMA » et liez l’hôte via une DCR qui analyse le format CEF. Les données analysées sont insérées dans la table CommonSecurityLog avec un schéma cohérent (champs deviceVendor, deviceProduct, destination/source et attributs d’extension), ce qui simplifie l’analyse et la corrélation entre les différents fournisseurs.

Pour les serveurs Windows locaux (on-premises), utilisez des serveurs avec Azure Arc pour faire le pont vers Azure. Intégrez les machines avec l’agent Azure Connected Machine, puis déployez l’extension AMA via Azure Policy pour une mise à l’échelle. Créez des DCR ciblant des étendues de serveurs Arc pour acheminer les événements de sécurité Windows, les journaux du pare-feu Windows et, si vous utilisez Sysmon, une DCR personnalisée pour le canal Microsoft-Windows-Sysmon/Operational. Ce modèle centralise la configuration, le versioning et le ciblage basé sur l’étendue, garantissant une ingestion cohérente sans travail manuel sur chaque hôte.

Architecture de l’espace de travail et cycle de vie des données

Sentinel s’attache à un unique espace de travail Log Analytics par déploiement. La conception de l’espace de travail doit minimiser la latence et la sortie de données inter-régions : colocalisez les espaces de travail avec la majorité des producteurs de données et évitez une fragmentation excessive qui complique les requêtes, le tri des incidents et le RBAC. Les modèles courants sont un espace de travail de sécurité unique par locataire (tenant) ou un par grande région où la résidence des données et la latence exigent une séparation. Utilisez l’accès en contexte de ressource lorsque c’est possible pour garantir que les équipes peuvent interroger les journaux des ressources qu’elles possèdent sans autorisations étendues sur l’espace de travail, tandis que les rôles Sentinel (Reader, Responder, Contributor) régissent les opérations du SOC.

Les DCR régissent les types de télémétrie, les canaux et les ensembles d’événements qui sont collectés et leur destination. Traitez les DCR comme du code : standardisez les conventions de nommage, le contrôle de version et les étendues (abonnements, groupes de ressources, balises). Regroupez les sources et destinations associées, et préférez plusieurs DCR ciblées à une seule règle monolithique pour simplifier le rayon d’impact (blast radius) et la gestion du cycle de vie. Lorsque les volumes de syslog et de CEF sont élevés, envisagez des DCR distinctes pour ajuster indépendamment l’installation/la gravité et pour prendre en charge les tests par étapes.

La rétention et les coûts sont contrôlés au niveau de la table. Définissez la rétention par défaut de l’espace de travail pour répondre à la politique (par ex., 90 à 180 jours pour la recherche active), puis surchargez la rétention par table si nécessaire. Les tables à haute valeur (SecurityEvent, CommonSecurityLog, SecurityAlert) ont généralement une rétention plus longue ; les tables verbeuses (Syslog avec le niveau DEBUG) peuvent avoir une rétention plus courte. Utilisez l’archive pour un stockage à long terme et à faible coût avec des travaux de recherche (search jobs) ; promouvez les données en stockage chaud (hot) au besoin pour les investigations. Le cas échéant, déplacez certaines tables verbeuses (comme Syslog) vers les journaux de base (Basic Logs) pour réduire les coûts, en reconnaissant les limitations de requêtes et le fait que certaines tables de sécurité (par ex., SecurityEvent) ne sont pas éligibles pour le niveau Basic. Examinez régulièrement les plafonds de données (data caps), les niveaux d’engagement (commitment tiers) et les tendances d’ingestion pour éviter la limitation (throttling) et optimiser les coûts.

Analyse, incidents et automatisation de la réponse

Les règles d’analyse sont le moteur de la détection. Les règles de requête planifiées exécutent KQL selon une planification (par ex., toutes les 5 minutes) sur une période d’analyse rétrospective (par ex., 30 minutes), prenant en charge les agrégations, les jointures, les enrichissements par watchlist et les fenêtres de suppression. Elles sont idéales pour les schémas bien compris comme les échecs de connexion multiples suivis d’une réussite, les heuristiques de mouvement latéral ou les lignages de processus suspects. Les règles en quasi-temps réel (NRT) minimisent la latence de détection en traitant continuellement les nouvelles données avec des exécutions environ toutes les minutes et en alertant en deux minutes environ ; concevez les règles NRT pour qu’elles soient concises et s’appuient sur ingestion_time() ou des fenêtres étroites pour éviter les analyses historiques lourdes. Les règles de fusion utilisent les analyses d’attaques multi-étapes de Microsoft pour corréler des alertes à faible signal provenant de plusieurs produits (par ex., Defender for Endpoint, Defender for Identity, Entra ID Protection, CEF tiers) en incidents de haute fidélité pour des campagnes comme le vol d’identifiants ou les ransomwares. Les règles d’anomalie exploitent des modèles ML intégrés qui apprennent des lignes de base (par ex., des lieux de connexion inhabituels, l’exécution de processus rares) et émettent des déviations ; celles-ci lisent généralement depuis BehaviorAnalytics et d’autres sources normalisées.

Les incidents unifient plusieurs alertes, entités et preuves au sein d’un seul dossier d’investigation. La gravité est attribuée par la règle d’analyse (ou dynamiquement par Fusion) et peut être augmentée ou réduite via des règles d’automatisation. Le mappage d’entités est essentiel à l’efficacité de l’investigation : dans l’assistant de règle, mappez les colonnes de la requête aux types d’entités (Account, Host, IP, URL, File, Process, CloudApplication, AzureResource). Un mappage correct peuple le graphe d’investigation, qui visualise les relations entre les alertes, les événements et les entités, permettant de pivoter sur les comptes, les hôtes, les processus et les adresses IP. Utilisez les commentaires, les tags, le propriétaire et la classification pour capturer la conclusion de l’analyste et pour entraîner les workflows d’ajustement.

L’automatisation combine les règles d’automatisation et les Playbooks. Les règles d’automatisation évaluent les métadonnées des incidents à leur création ou mise à jour pour assigner des propriétaires, changer la gravité, ajouter des tags, clore les faux positifs ou invoquer des playbooks. Les Playbooks sont des Azure Logic Apps construites avec les connecteurs Microsoft Sentinel. Les playbooks déclenchés par incident réagissent aux événements du cycle de vie de l’incident (par ex., lorsqu’un incident est créé) et sont adaptés aux actions limitées à la portée de l’incident, comme la notification d’une équipe, l’enrichissement de toutes les entités ou la création d’un ticket ServiceNow. Les playbooks déclenchés par alerte se déclenchent sur des alertes uniques avant qu’elles ne soient regroupées dans un incident — utile pour les enrichissements spécifiques à un fournisseur ou le pré-tri. Adoptez l’identité managée pour les playbooks, accordez le moindre privilège via Azure RBAC et les permissions API, et paramétrez les ID de l’espace de travail, les points de terminaison de ticketing et les chemins des listes de blocage pour favoriser la réutilisation. Lorsque le confinement est justifié, incluez des actions qui mettent en quarantaine les points de terminaison (Defender for Endpoint), désactivent les comptes (Entra ID), bloquent les adresses IP (pare-feux) ou révoquent les sessions (Conditional Access) uniquement après que les seuils de confiance sont atteints.

Opérations de sécurité proactives (Chasse, UEBA, Listes de surveillance, Classeurs)

La chasse aux menaces (threat hunting) dans Sentinel repose sur la maîtrise de KQL et sur le panneau de chasse. Commencez avec les requêtes de chasse intégrées, organisées par tactique ; personnalisez-les pour votre environnement en référençant des tables comme SecurityEvent (audit Windows), les tables Device* de Defender, CommonSecurityLog (CEF) et SigninLogs (Entra). Utilisez les signets pour capturer des enregistrements intéressants, les annoter et partager le contexte avec l’équipe ; plusieurs signets peuvent être promus en un incident nouveau ou existant. Livestream exécute en continu un modèle KQL pour détecter de nouveaux événements correspondants en quasi-temps réel, ce qui est idéal pour les enquêtes à durée limitée ou les scénarios de pic d’activité rapide. Convertissez les requêtes de chasse matures en règles d’analyse planifiées pour opérationnaliser les détections.

L’UEBA (User and Entity Behavior Analytics) enrichit la détection avec des bases de référence comportementales et une notation des anomalies. Activez l’UEBA depuis la configuration de Sentinel et assurez-vous que les sources de données d’identité et d’activité (connexions Microsoft Entra, Defender for Endpoint, Defender for Identity, activité M365) sont connectées. Les pages d’entité pour les utilisateurs et les hôtes affichent des chronologies, des comparaisons avec les pairs, des activités anormales (géolocalisation de connexion rare, processus inhabituel) et des scores de risque agrégés. Les analystes peuvent pivoter des incidents vers les pages d’entité pour évaluer si une action est typique pour cette identité ou cet appareil ; les scores et les séquences d’anomalies aident à prioriser le tri et à corroborer ou réfuter rapidement les hypothèses.

Les listes de surveillance (watchlists) fournissent des données de référence rapides, gérées par les analystes. Créez des listes de surveillance à partir de chargements de CSV ou d’un chemin de compte de stockage, définissez un alias et sélectionnez une colonne clé pour des recherches efficaces. Utilisez la fonction watchlist() en KQL pour les jointures — les usages courants incluent les listes d’autorisation/refus de comptes administratifs, d’hôtes sensibles, de domaines approuvés ou d’utilisateurs VIP. Incorporez les listes de surveillance dans les règles d’analyse pour supprimer l’activité bénigne connue (réduire les faux positifs) ou pour augmenter la gravité lorsqu’une correspondance implique un actif critique. Intégrez avec le renseignement sur les menaces (threat intelligence) en joignant les listes de surveillance à la table ThreatIntelligenceIndicator pour le contexte (par ex., enrichir les IP détectées avec une gravité interne ou des notes de cas), ou en convertissant des flux de TI sélectionnés en une liste de surveillance pour une référence rapide et des dérogations.

Les classeurs (workbooks) alimentent la surveillance et la visibilité pour la direction. Commencez avec les modèles intégrés tels que Security Operations Efficiency, Active Directory Sign-ins, Fusion Detections et UEBA insights. Créez des classeurs personnalisés en utilisant des requêtes KQL, des paramètres et des visualisations pour créer des tableaux de bord SOC pour la santé de l’ingestion, la performance des règles, les SLA des incidents et les menaces émergentes. Appliquez le RBAC sur la ressource du classeur et paramétrez les abonnements, les espaces de travail et les plages de temps afin que le même classeur puisse servir différentes équipes. Combinez des vignettes de plusieurs tables pour corréler la posture (Defender for Cloud), les détections (Sentinel) et les métriques de réponse en une seule vue.

Scénario de problème pratique

Spotify doit centraliser la surveillance de la sécurité pour 2 000 serveurs Windows répartis entre Azure et des datacenters sur site, ainsi que pour des pare-feux et des proxys tiers. Ils ont besoin de détections à faible latence pour l’abus d’identifiants, d’une billetterie et d’un confinement automatisés, ainsi que de tableaux de bord clairs et de workflows de chasse pour le SOC.

Intégrer les serveurs hybrides avec Azure Arc et l’AMA

Déployez l’intégration des serveurs avec Azure Arc à grande échelle en utilisant Azure Policy, puis assignez la politique d’extension AMA à la portée Arc. Créez des DCR pour « Windows Security Events via AMA » (ensemble commun), le pare-feu Windows, et une DCR personnalisée pour Sysmon là où il est installé. Cette approche assure une collecte cohérente et gérée de manière centralisée sans script par hôte et garantit que SecurityEvent est peuplé pour l’analyse des identités et des processus.

Ingérer la télémétrie des appliances réseau et de sécurité via Syslog et CEF

Mettez en place une VM collectrice Linux avec l’AMA. Configurez « Syslog via AMA » pour les facilities pertinentes, et activez « CEF via AMA » pour analyser le CEF des pare-feux et des proxys dans CommonSecurityLog. L’utilisation de CEF normalise les données multi-fournisseurs, permettant la portabilité des règles et des jointures faciles entre les sources.

Concevoir des analyses pour la vitesse et la fidélité

Activez Fusion pour capturer les attaques multi-étapes avec un réglage minimal. Créez des règles NRT pour les rafales de connexions échouées suivies d’une réussite sur des comptes à privilèges en utilisant SecurityEvent et ingestion_time(), offrant une détection en moins de deux minutes. Élaborez des règles planifiées pour les schémas de mouvement latéral (par ex., la création de processus de net.exe sur des serveurs jointe à des comptes administrateurs inhabituels) et pour les anomalies de sortie de proxy jointes aux listes de surveillance des VIP et des hôtes critiques. Ce mélange minimise le MTTR tout en maîtrisant les faux positifs.

Mapper les entités et façonner les incidents

Dans chaque règle planifiée, mappez les entités Account, Host, IP et Process à partir des colonnes de la requête. Utilisez des règles d’automatisation pour assigner les incidents par unité commerciale (dérivée des tags d’hôte), standardiser la gravité, ajouter des tags MITRE et fermer automatiquement les signaux de test connus. Un mappage correct permet au graphe d’investigation de montrer des relations que les analystes de Spotify peuvent parcourir rapidement.

Automatiser l’enrichissement, la billetterie et le confinement avec des playbooks

Créez un playbook déclenché par incident qui enrichit tous les comptes et hôtes (recherches graph, risque de l’appareil), publie sur Teams et ouvre un ticket Jira. Un playbook distinct déclenché par alerte enrichit des alertes CEF spécifiques avec les API des fournisseurs. Utilisez des identités managées avec un RBAC du moindre privilège et des branchements conditionnels qui n’isolent les appareils (via Defender for Endpoint) ou ne désactivent les utilisateurs (via Entra ID) que lorsque des seuils de confiance (par ex., plusieurs alertes corroborantes et un score UEBA élevé) sont atteints. Cela préserve la continuité des activités tout en permettant une réponse rapide et gouvernée.

Activer l’UEBA et opérationnaliser la chasse

Activez l’UEBA et validez les sources de données (SigninLogs, activité M365, signaux Defender). Formez les analystes à pivoter des incidents vers les pages d’entité pour les scores d’anomalie et les comparaisons avec les pairs. Convertissez deux requêtes de chasse à haute valeur — « Nouveaux outils d’administration à distance sur les serveurs » et « Schémas rares d’exfiltration par IP externe » — en analyses planifiées une fois validées via les signets et livestream. L’UEBA, combiné à une chasse disciplinée, resserre la détection des techniques nouvelles.

Gouverner le cycle de vie des données et visualiser la posture

Définissez la rétention à 180 jours pour SecurityEvent et CommonSecurityLog, 30 jours pour le Syslog verbeux avec archivage sur 1 an, et surveillez les coûts avec des niveaux d’engagement. Publiez un classeur SOC personnalisé qui suit la santé de l’ingestion, les règles les plus bruyantes, les MTTA/MTTR, les files d’attente d’incidents par gravité et les anomalies UEBA au fil du temps. Cela offre une transparence à la direction et favorise l’ajustement continu.

Chaque outil a été choisi pour ses atouts spécifiques : Arc et AMA+DCR fournissent une ingestion évolutive et pilotée par les politiques ; CEF assure la normalisation des journaux de sécurité multi-fournisseurs ; Fusion et NRT réduisent la latence de détection sans réglage excessif ; le mappage d’entités et le graphe d’investigation accélèrent le tri ; les playbooks offrent une automatisation gouvernée et basée sur l’identité ; l’UEBA fournit un contexte comportemental ; les outils de chasse font mûrir les détections ; et les classeurs rendent les opérations mesurables et visibles.

← Microsoft Defender for Cloud et sécurité des points de terminaison · Tous les domaines · Sécurité des services de domaine Active Directory →

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