11 · Implémenter l'activité et la collecte d'événements dans Microsoft Sentinel

Version : 1.2 · Date : 2026-10-21 · Domaine 4 de l'examen : Gérer et surveiller la posture de sécurité (20 à 25 %)

En une phrase : Microsoft Sentinel est un SIEM et un SOAR posé sur un Log Analytics workspace : on y fait entrer les journaux (connecteurs, Azure Monitor Agent et Data Collection Rules, Logs Ingestion API), on choisit combien de temps et à quel coût on les garde (Analytics tier, data lake), on contrôle qui voit quoi (rôles Sentinel, RBAC par ressource ou par table) et on automatise la réponse (automation rules, playbooks Logic Apps), le tout désormais dans le portail Microsoft Defender.

Ce que l'examen demande#

Repris mot pour mot du guide d'étude SC-500 en anglais :

Les compléments de l'ancienne AZ-500 et de la culture SOC (analytics rules, incidents, UEBA, threat intelligence, ASIM) sont regroupés en 12.

1. Les bases à maîtriser avant tout#

1.1 SIEM, SOAR et XDR#

1.2 Sentinel est une solution posée sur un Log Analytics workspace#

Une instance Microsoft Sentinel s'appelle un workspace : c'est un Log Analytics workspace sur lequel on active la solution (ressource SecurityInsights). Toutes les capacités de Log Analytics restent disponibles (requêtes KQL, tables, rétention, transformations). Conséquences pratiques :

• tout ce qui est ingéré dans un espace où Sentinel est activé est facturé au tarif Sentinel, même les données d'exploitation ;
• un espace avec Sentinel conserve gratuitement les 90 premiers jours d'analytics retention (au lieu de 31 jours) ; mais la rétention par défaut d'un espace reste de 30 jours : il faut la porter à 90 jours pour en profiter ;
• une fois Sentinel déployé, l'espace ne peut plus être déplacé vers un autre resource group ou abonnement ;
• les espaces par défaut créés par Defender for Cloud ne peuvent pas recevoir Sentinel.

1.3 Le portail Microsoft Defender devient le seul portail#

À retenir : la documentation existe en deux variantes (portail Azure et portail Defender). Les nouveautés (data lake, Sentinel graph, SOC optimization, Security Copilot) n'arrivent que dans le portail Defender.

1.4 Le parcours d'une donnée#

flowchart LR
    A["Source<br/>Azure, Microsoft 365, serveurs, appareils"] --> B{"Comment la collecter ?"}
    B -- "Service Microsoft" --> C["Connecteur service à service<br/>(API ou diagnostic settings)"]
    B -- "Machine Windows ou Linux" --> D["Azure Monitor Agent<br/>+ Data Collection Rule (DCR)"]
    B -- "Application, tiers" --> E["Logs Ingestion API<br/>ou Codeless Connector Framework (CCF)"]
    C --> F["Table du Log Analytics workspace"]
    D --> F
    E --> F
    F --> G["Analytics rules : alertes et incidents"]
    G --> H["Automation rules et playbooks"]

2. Créer et connecter des workspaces#

2.1 Créer l'espace et activer Microsoft Sentinel#

Prérequis :

Étapes (portail Azure) : rechercher Microsoft Sentinel > Create > choisir un espace existant ou Create a new workspace (abonnement, resource group, nom, région) > Add. La rétention par défaut d'un espace est de 30 jours : Microsoft recommande de la porter à 90 jours (gratuits avec Sentinel) pour profiter de toutes les fonctions.

Création de l'espace en Azure CLI (l'activation de Sentinel se fait ensuite dans le portail ou par l'API Sentinel Onboarding States) :

az monitor log-analytics workspace create \
  --resource-group rg-sentinel-prd --workspace-name law-sentinel-prd-weu \
  --location westeurope --retention-time 90

En Terraform (fournisseur azurerm 5.x, arguments vérifiés dans le registre) :

resource "azurerm_log_analytics_workspace" "sentinel" {
  name                = "law-sentinel-prd-weu"
  location            = "westeurope"
  resource_group_name = "rg-sentinel-prd"
  sku                 = "PerGB2018"
  retention_in_days   = 90 # 90 jours inclus avec Sentinel
}

# Active Microsoft Sentinel sur l'espace (ressource Microsoft.SecurityInsights/onboardingStates)
resource "azurerm_sentinel_log_analytics_workspace_onboarding" "sentinel" {
  workspace_id = azurerm_log_analytics_workspace.sentinel.id
}

2.2 Connecter l'espace au portail Defender : primary workspace et secondaires#

Droits pour intégrer le primary workspace ou le changer : au minimum Security Administrator (Entra) et Owner (attribution sans condition) ou User Access Administrator sur l'abonnement, et Microsoft Sentinel Contributor. Pour un secondary workspace seul, le rôle Entra n'est pas nécessaire.

2.3 Un seul espace ou plusieurs ?#

Microsoft recommande de commencer par un seul espace et de n'en créer d'autres que pour une vraie raison :

flowchart TD
    A["Nouveau besoin d'espace Sentinel"] --> B{"Autre locataire Entra ?"}
    B -- Oui --> X["Un espace par locataire<br/>(Lighthouse pour le gérer)"]
    B -- Non --> C{"Données à garder dans<br/>une autre géographie ?"}
    C -- Oui --> Y["Espace secondaire<br/>dans la bonne région"]
    C -- Non --> D{"Entité qui doit rester<br/>propriétaire de ses données ?"}
    D -- Oui --> Y
    D -- Non --> Z["Rester sur un seul espace :<br/>RBAC ressource ou table, rétention par table"]

2.4 Plusieurs locataires : MSSP et Azure Lighthouse#

• Un fournisseur de services de sécurité managés (MSSP) ou un groupe multilocataire crée au moins un espace par locataire : les données, les coûts et la conformité restent chez chaque client.
• Azure Lighthouse délègue l'accès aux espaces des clients ; la multiple workspace view du portail Azure affiche jusqu'à 100 espaces à la fois ; le portail Defender a sa propre multitenant management.
• Si les espaces ne sont créés que dans les locataires clients, les fournisseurs de ressources Microsoft.SecurityInsights et Microsoft.OperationalInsights doivent aussi être inscrits sur un abonnement du locataire gestionnaire.
• Une requête peut viser plusieurs espaces avec l'opérateur workspace() :

union SecurityIncident, workspace("law-sentinel-filiale").SecurityIncident
| where TimeGenerated > ago(1d)
| summarize Incidents = count() by Severity

3. Attribuer des rôles dans Microsoft Sentinel#

3.1 Les rôles intégrés#

Rôles plus larges qu'on croise aussi : Owner, Contributor, Reader (Azure) et Log Analytics Contributor, Log Analytics Reader. Les attributions sont cumulatives : un utilisateur à la fois Microsoft Sentinel Reader et Contributor a les droits de Contributor.

Où attribuer ? De préférence au resource group qui contient l'espace : les playbooks et autres ressources liées sont couverts. Si on attribue directement sur l'espace, il faut attribuer les mêmes rôles à la ressource de solution SecurityInsights de cet espace.

3.2 Attributions recommandées#

# Donner le rôle Responder au groupe des analystes, à l'échelle du groupe de ressources Sentinel
az role assignment create --assignee-object-id <id-objet-groupe-analystes> --assignee-principal-type Group \
  --role "Microsoft Sentinel Responder" \
  --scope /subscriptions/<sub>/resourceGroups/rg-sentinel-prd

3.3 Restreindre l'accès aux données, sans tout l'espace#

Piège : le granular RBAC ne restreint pas les incidents, alertes, watchlists, UEBA ou le threat intelligence ; il ne porte que sur les données brutes. Et comme les rôles s'additionnent, un rôle Log Analytics Reader au-dessus annule la restriction.

3.4 Dans le portail Defender : Unified RBAC et data lake#

• Le Microsoft Defender Unified RBAC (URBAC) peut gérer Sentinel : Reader → Security data basics (read), Responder → + gérer alertes et réponse, Contributor → + Detection tuning (manage). Playbook Operator, Automation Contributor et Workbook Contributor n'existent pas en URBAC : ils restent gérés dans le portail Azure.
• Le Microsoft Sentinel data lake utilise des rôles Microsoft Entra pour un accès global : lecture avec Global Reader, Security Reader, Security Operator, Security Administrator ou Global Administrator ; écriture et travaux (jobs) avec Security Operator, Security Administrator ou Global Administrator.

4. Le Content hub et les repositories#

4.1 Ce que contient le hub#

Le contenu est livré sous deux formes :

• Solutions : paquets de bout en bout pour un produit, un domaine ou un secteur (par exemple Azure Activity, Windows Security Events, Syslog, Common Event Format), avec gestion du cycle de vie dans le hub ;
• Standalone content : un contenu isolé, mis à jour automatiquement.

Chaque élément affiche son modèle de support : Microsoft, partenaire (contact du partenaire) ou communauté (problèmes déposés sur GitHub). Sa source est Solution, Autonome, Personnalisé ou Repositories.

4.2 Installer et utiliser une solution#

1. Microsoft Sentinel > Content hub > rechercher la solution (par exemple Azure Activity) > Install (rôle Microsoft Sentinel Contributor sur le resource group).
2. Manage la solution installée pour voir ses composants : connecteur à configurer, modèles d'analytics rules à activer (Create rule depuis le modèle), workbooks à enregistrer, modèles de playbooks à déployer.
3. Les mises à jour du contenu prêt à l'emploi se font dans le hub (une étiquette signale qu'une nouvelle version existe).

Piège : installer une solution n'active pas ses règles. Un modèle d'analytics rule doit être transformé en règle active.

4.3 Repositories : le contenu personnalisé en tant que code#

• Content management > Repositories > Add : connexion à un dépôt GitHub ou Azure DevOps (pas d'autre fournisseur).
• Contenus déployables : analytics rules, automation rules, custom detection rules (préversion), hunting queries, parsers, playbooks, workbooks, en ARM ou Bicep (Bicep recommandé).
• Prérequis : rôle Owner sur le resource group de l'espace ; compte du locataire de base (pas d'invité B2B) ; Collaborator sur GitHub ou Project Administrator sur Azure DevOps.
• À la connexion, un workflow GitHub ou un pipeline Azure DevOps est généré dans le dépôt : chaque commit déploie le contenu. Le dépôt devient la seule source de vérité : il écrase les modifications faites dans le portail.

5. Les data connectors Microsoft et Azure#

5.1 Les trois familles#

Points communs : la plupart des connecteurs arrivent par une solution du Content hub ; il faut au minimum le droit d'écriture sur l'espace ; chaque connecteur ajoute ses propres prérequis.

5.2 Connecteur Microsoft Entra ID#

Tables principales : SigninLogs, AuditLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs, AADManagedIdentitySignInLogs, AADProvisioningLogs, MicrosoftGraphActivityLogs, AADUserRiskEvents, AADRiskyUsers.

// Connexions refusées par Conditional Access ces dernières 24 heures
SigninLogs
| where TimeGenerated > ago(24h)
| where ConditionalAccessStatus == "failure"
| summarize Echecs = count() by UserPrincipalName, AppDisplayName, IPAddress
| order by Echecs desc

5.3 Connecteur Azure Activity (diagnostic settings par Azure Policy)#

1. Installer la solution Azure Activity depuis le Content hub.
2. Data connectors > Azure Activity > Open connector page > Launch Azure Policy Assignment wizard.
3. Scope : abonnement (ou management group) ; Parameters : l'espace Sentinel comme primary workspace ; Remediation : cocher Create a remediation task pour appliquer la stratégie aux ressources existantes.
4. Il faut le rôle Owner sur l'étendue de l'attribution (le managed identity de la stratégie reçoit des droits).

// Qui a supprimé des ressources cette semaine ?
AzureActivity
| where TimeGenerated > ago(7d)
| where OperationNameValue endswith "/DELETE" and ActivityStatusValue == "Success"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, _ResourceId

Piège : l'ancienne méthode de connexion de l'Azure Activity doit être déconnectée (bouton Disconnect All) avant de configurer le connecteur par diagnostic settings.

Le même mécanisme (Azure Policy + remediation task) sert pour Key Vault, Azure Firewall (tables AZFW* structurées), Azure Storage (pour un storage account, configurer la ressource parente et chaque sous-service blob, fichier, file d'attente, table) et d'autres services. Un connecteur par diagnostic settings apparaît connecté si des données sont arrivées dans les 14 derniers jours.

Piège d'examen : un connecteur par diagnostic settings ne peut pas viser un espace d'un autre locataire que celui de la ressource (Azure Firewall, Azure Storage, Azure Activity, Entra ID).

5.4 Connecteurs Defender for Cloud et Defender XDR#

Les alertes Defender for Cloud arrivent dans SecurityAlert :

SecurityAlert
| where ProductName == "Azure Security Center"
| summarize count() by AlertSeverity, AlertName

Piège : le connecteur Defender for Cloud ne synchronise pas les alertes des abonnements d'autres locataires, même avec Lighthouse. Avec l'intégration Defender XDR, les règles de création d'incidents Microsoft Security ne sont plus disponibles : c'est le moteur de corrélation de Defender XDR qui crée les incidents.

6. Collecter Syslog et CEF avec l'Azure Monitor Agent#

6.1 Syslog et CEF en deux mots#

• Syslog : protocole standard d'envoi de messages (priorité, horodatage, hôte, application, texte), sur UDP, TCP ou TLS. L'agent accepte les formats RFC 3164 (BSD) et RFC 5424 (IETF).
• CEF (Common Event Format) : extension de Syslog pour les SIEM, avec un en-tête normalisé (fournisseur, produit, version, classe, gravité, ID d'événement) et des extensions (adresses IP, utilisateur, fichier, action). Utilisé par les pare-feu, proxys, IDS, EDR.

6.2 L'architecture avec un redirecteur de journaux#

1. Les appareils envoient leurs messages sur le port 514 (UDP ou TCP) au démon Syslog (rsyslog ou syslog-ng) d'une VM Linux dédiée, le redirecteur (dans Azure, en local ou dans un autre cloud).
2. Le démon transmet à l'Azure Monitor Agent local : sur le port TCP 28330 pour AMA 1.28.11 et plus, par un socket de domaine Unix pour les versions antérieures.
3. L'agent envoie en HTTPS 443 sortant vers l'espace, selon la DCR (facilités et niveaux).

Prérequis du redirecteur : système Linux pris en charge par AMA ; Python 2.7 ou 3 ; démon rsyslog ou syslog-ng ; Azure Arc (agent Connected Machine) s'il n'est pas une VM Azure ; disque suffisant (un disque plein arrête l'agent : ne pas stocker les journaux inutiles localement) ; derrière un Virtual Machine Scale Set, un équilibreur de charge en tourniquet.

Rôles pour configurer : Virtual Machine Contributor ou Azure Connected Machine Resource Administrator (déployer l'agent), une action Microsoft.Resources/deployments/* (déployer les modèles), Monitoring Contributor (créer la DCR).

6.3 Mise en œuvre#

1. Installer la solution du hub (celle de l'appareil, sinon Syslog ou Common Event Format).
2. Page du connecteur Syslog via AMA ou CEF via AMA > + Create data collection rule : nom, abonnement, resource group > Resources : choisir le redirecteur (l'agent s'installe) > Collect : le niveau minimal par facilité (choisir LOG_ERR collecte aussi LOG_CRIT, LOG_ALERT, LOG_EMERG).
3. Sur le redirecteur, lancer le script d'installation copié depuis la page du connecteur : il configure le démon, ouvre le port 514 en UDP et TCP et redémarre le démon.

sudo wget -O Forwarder_AMA_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Forwarder_AMA_installer.py && sudo python Forwarder_AMA_installer.py
sudo systemctl status azuremonitoragent.service   # agent
netstat -lnptv                                    # le démon écoute sur 514

4. Configurer l'appareil pour envoyer au redirecteur, puis tester :

logger -p local4.warn -P 514 -n 127.0.0.1 --rfc3164 -t CEF "0|Mock-test|MOCK|common=event-format-test|end|TRAFFIC|rt=$common=event-formatted-receive_time"

CommonSecurityLog
| where TimeGenerated > ago(1d)
| where DeviceProduct == "MOCK"

Les journaux peuvent mettre jusqu'à 20 minutes à apparaître.

Par l'API (plus souple : on choisit les niveaux un par un, mais il faut installer l'agent soi-même puis créer l'association DCR-machine, la DCRA), extrait de DCR qui sépare CEF et Syslog :

"dataSources": {
  "syslog": [
    { "name": "CEFStream", "streams": [ "Microsoft-CommonSecurityLog" ],
      "facilityNames": [ "authpriv", "mark" ],
      "logLevels": [ "Info", "Notice", "Warning", "Error", "Critical", "Alert", "Emergency" ] },
    { "name": "SyslogStream", "streams": [ "Microsoft-Syslog" ],
      "facilityNames": [ "kern", "local0" ],
      "logLevels": [ "Critical", "Alert", "Emergency" ] }
  ]
}

6.4 Éviter les doublons#

Utiliser la même facilité pour Syslog et CEF envoie les messages dans les deux tables. Deux parades :

• configurer les sources pour que les facilités CEF et Syslog soient différentes ;
• sinon, ajouter une transformation au flux Syslog qui écarte les messages CEF (depuis AMA 1.41, vérifier aussi SyslogMessage) :

"transformKql": "source | where ProcessName !contains \"CEF\" and SyslogMessage !contains \"CEF:0\""

Retrait de l'ancien agent : le Log Analytics agent (MMA/OMS) est retiré depuis le 31 août 2024 ; l'envoi de données par cet agent peut s'arrêter à tout moment après le 2 mars 2026. Garder les deux agents sur la même source double l'ingestion et la facture.

7. Windows Security Events, Data Collection Rules et WEF#

7.1 Le connecteur « Windows Security Events via AMA »#

• Prérequis : lecture et écriture sur l'espace ; pour toute machine hors Azure (physique, VM locale, autre cloud), Azure Arc installé et activé avant d'activer le connecteur.
• La DCR est créée depuis la page du connecteur : + Add data collection rule > Resources (VM Azure et serveurs Arc ; l'agent s'installe) > Collect. La DCR n'a pas besoin d'être dans le même resource group ou abonnement que les machines, mais dans le même locataire.
• Les événements arrivent dans la table SecurityEvent, lue par de nombreuses analytics rules intégrées.

7.2 Filtrer avec XPath#

Format : NomDuJournal!RequêteXPath. L'agent ne prend en charge que XPath 1.0 (fonctions comme starts-with ou contains non prises en charge) ; 20 expressions par champ, 100 champs par règle. Les canaux Analytic et Debug ne peuvent pas être collectés.

Tester une requête sur la machine avant de l'ajouter :

$XPath = '*[System[(EventID=4624 or EventID=4625)]]'
Get-WinEvent -LogName 'Security' -FilterXPath $XPath -MaxEvents 5

Extrait de DCR (flux Microsoft-SecurityEvent) :

"dataSources": {
  "windowsEventLogs": [ {
    "name": "eventLogsDataSource",
    "streams": [ "Microsoft-SecurityEvent" ],
    "xPathQueries": [ "Security!*[System[(EventID=4624 or EventID=4625 or EventID=4688 or EventID=1102)]]" ]
  } ]
},
"dataFlows": [ { "streams": [ "Microsoft-SecurityEvent" ], "destinations": [ "centralWorkspace" ] } ]

Piège : une DCR d'Azure Monitor « classique » qui collecte le journal Sécurité (flux Microsoft-Event) envoie les événements dans la table Event, pas dans SecurityEvent. Pour Sentinel, passer par le connecteur Windows Security Events via AMA.

7.3 Windows Event Forwarding (WEF)#

WEF (Windows Event Forwarding) fait remonter les événements des postes et serveurs vers un collecteur WEC (Windows Event Collector) par des abonnements (souvent poussés par GPO). Minimum côté client : URI du collecteur, service WinRM démarré, compte Network Service dans le groupe Event Log Readers pour lire le journal Sécurité. En domaine, le transport est chiffré et mutuellement authentifié par Kerberos, que l'on choisisse HTTP ou HTTPS.

Le connecteur Windows Forwarded Events de Sentinel :

• exige que la collecte WEC soit activée et que l'Azure Monitor Agent soit installé sur le serveur WEC ;
• écrit les événements transférés, y compris ceux du journal Sécurité, dans la table WindowsEvent, pas dans SecurityEvent ;
• recommande d'installer les parsers ASIM WindowsEvent pour la normalisation.

Piège d'examen : des règles intégrées (dont certaines quasi temps réel) interrogent SecurityEvent et ne voient pas les données de WindowsEvent. Si ces règles doivent fonctionner sans modification, utiliser Windows Security Events via AMA ; sinon adapter les requêtes ou utiliser les parsers ASIM.

// Échecs de connexion vus par les deux chemins
union
  (SecurityEvent | where EventID == 4625 | project TimeGenerated, Computer, Compte = TargetAccount, Source = "SecurityEvent"),
  (WindowsEvent  | where EventID == 4625 | project TimeGenerated, Computer, Compte = tostring(EventData.TargetUserName), Source = "WindowsEvent")
  // EventData est une colonne dynamic : les champs de l'événement (ici TargetUserName du 4625) s'y lisent par leur nom
| summarize Echecs = count() by Compte, Source

8. Data Collection Rules, transformations et tables personnalisées#

8.1 Anatomie d'une Data Collection Rule (DCR)#

Une DCR est indépendante de l'espace et de la machine : on la définit une fois et on l'associe (DCRA) à de nombreuses machines.

8.2 Les transformations à l'ingestion#

Une transformation est une requête KQL appliquée à chaque enregistrement avant l'écriture dans la table : filtrer des lignes, supprimer ou masquer des colonnes, en calculer d'autres.

source
| where SeverityLevel in ("err", "crit", "alert", "emerg")
| extend Utilisateur = extract("user=(\\S+)", 1, SyslogMessage)
| project-away HostIP

• Pour les flux qui n'utilisent pas encore de DCR (journaux de ressources des diagnostic settings), il existe une seule DCR de transformation d'espace par espace, avec une transformation par table.
• Coût : pour les tables Analytics ou Basic, une transformation qui supprime plus de 50 % des données est facturée sur l'excédent ; avec Microsoft Sentinel activé sur l'espace, la transformation des tables Analytics est gratuite, quel que soit le volume filtré. Pour les tables Auxiliary, tout le volume traité est facturé.
• Filtrer à la source (XPath, facilités) reste le moyen le plus efficace.
• Les transformations à plusieurs étapes (côté agent puis à l'ingestion, processeurs filter, map, parse, aggregate…) sont en préversion (API 2025-05-11 ou plus).

8.3 Créer une table personnalisée#

• Une table personnalisée porte le suffixe _CL (le portail l'ajoute ; ailleurs, l'ajouter soi-même) et doit avoir une colonne TimeGenerated (ajoutée par la transformation si elle manque).
• Plan à la création : Analytics (défaut), Basic ou Auxiliary / Data lake. Le nom de table sert à la facturation : n'y mettre aucune information sensible.
• Droit requis : Microsoft.OperationalInsights/workspaces/* sur l'espace (par exemple Log Analytics Contributor).
• Portail : Log Analytics workspace > Tables > Create > nom, plan, DCR (nouvelle ou existante), Data Collection Endpoint si demandé > échantillon JSON > Transformation editor > Create.

az monitor log-analytics workspace table create \
  --resource-group rg-sentinel-prd --workspace-name law-sentinel-prd-weu \
  --name AppSecu_CL --plan Analytics \
  --columns TimeGenerated=datetime Utilisateur=string Action=string RawData=string

8.4 Le Logs Ingestion API#

Pour envoyer des données d'une application ou d'un script :

1. Créer une app registration Entra (ou utiliser une managed identity).
2. Créer la table personnalisée et une DCR « directe » ("kind": "Direct") avec son flux Custom-<Table>_CL.
3. Donner le rôle Monitoring Metrics Publisher (action Microsoft.Insights/Telemetry/Write) sur la DCR à cette identité (propagation jusqu'à 30 minutes, sinon erreur 403).
4. Envoyer en JSON vers le logs ingestion endpoint de la DCR ; un Data Collection Endpoint (DCE) n'est obligatoire qu'avec Private Link (ou pour une ancienne DCR sans point de terminaison).

Depuis le 1er mars 2026, le Logs Ingestion API exige TLS 1.2 ou plus. Pour des sources SaaS, le Codeless Connector Framework (CCF) permet de construire des connecteurs sans code qui utilisent ces mêmes DCR et DCE.

9. Automation rules et playbooks#

9.1 Les automation rules#

Une automation rule gère de façon centrale le tri et la réponse, pour une ou plusieurs analytics rules à la fois.

Cas d'usage typiques : suppression des faux positifs connus (fermeture automatique, depuis la page de l'incident), affectation automatique par plateforme, étiquetage, tâches d'enquête normalisées, escalade, synchronisation avec un outil de tickets via le déclencheur de mise à jour.

Incident ou alerte ? L'automatisation par incident est à privilégier (l'incident est le « dossier » qui évolue). L'automatisation par alerte sert pour les règles qui ne créent pas d'incident, notamment dans le portail Defender, où la création d'incidents est faite par Defender XDR. Dans le portail Defender, les alertes créées par Defender XDR ne peuvent pas déclencher ce type d'automatisation (utiliser le déclencheur d'alerte amélioré).

Après l'intégration au portail Defender, si plusieurs modifications touchent un incident en 5 à 10 minutes, une seule mise à jour (la dernière) est envoyée à Sentinel.

9.2 Les playbooks#

Un playbook est un workflow Azure Logic Apps (ressource Azure séparée, facturée par Logic Apps) qui utilise le connecteur Microsoft Sentinel.

9.3 Les permissions, point d'examen classique#

sequenceDiagram
    participant R as Analytics rule
    participant I as Incident
    participant AR as Automation rule
    participant SA as Compte de service Sentinel
    participant PB as Playbook (Logic Apps)
    participant E as Entra ID / Teams
    R->>I: Crée l'incident (alertes + entités)
    I->>AR: Déclencheur « When incident is created »
    AR->>AR: Conditions vérifiées, actions dans l'ordre
    AR->>SA: Action « Run playbook »
    Note over SA: Automation Contributor sur le resource group du playbook
    SA->>PB: Lance le workflow
    PB->>E: Désactive le compte, notifie le SOC (managed identity)
    PB->>I: Ajoute un commentaire (rôle Responder)

1. Microsoft Sentinel (compte de service, application Azure Security Insights) doit avoir le rôle Microsoft Sentinel Automation Contributor sur le resource group du playbook : Settings > Settings > Playbook permissions > Configure permissions, ou le lien Manage playbook permissions (playbooks grisés sinon). Une fois donné, toute automation rule peut lancer tout playbook de ce groupe.
2. Pour accorder ce rôle, il faut être Owner (ou User Access Administrator) du resource group.
3. Pour attacher un playbook à une règle : Microsoft Sentinel Contributor ; pour l'exécuter manuellement : Playbook Operator ; pour le créer : Logic App Contributor (Consumption) ou les rôles Logic Apps Standard.
4. Par défaut, un playbook n'est utilisable que dans son abonnement, sauf autorisation explicite de Sentinel sur son groupe de ressources.
5. Multilocataire (MSSP) : les autorisations se donnent dans le locataire où se trouve le playbook ; si la règle est dans le locataire client et le playbook aussi, ajouter dans la délégation Lighthouse l'application Azure Security Insights avec le rôle Automation Contributor (GUID f4c81013-99ee-4d62-a7ee-b3f1f648599a).

Durée d'un playbook dans une règle : moins d'une seconde → action suivante immédiate ; moins de 2 minutes → jusqu'à 10 secondes après la fin ; plus de 2 minutes → la règle continue au bout de 2 minutes, que le playbook soit fini ou non.

Les automation rules et d'analyse s'exportent et s'importent en modèles ARM (JSON indépendant de l'espace) : base du « Sentinel as code » avec les repositories.

10. Niveaux de données et rétention#

10.1 Deux niveaux dans le portail Defender#

• Total retention : les données du Analytics tier sont mises en miroir dans le lac ; au-delà de l'analytics retention, elles restent interrogeables dans le lac jusqu'à la total retention (≤ 12 ans). Le miroir à rétention égale n'est pas facturé en plus.
• Data lake tier seul : pour les données secondaires volumineuses (NetFlow, proxy, pare-feu, journaux d'accès au stockage, certificats TLS, IoT) ; pas d'analytics rules en temps réel. Les summary rules permettent d'en extraire des agrégats.
• Données XDR : l'advanced hunting garde 30 jours gratuits ; on peut étendre jusqu'à 90 jours dans l'analytique (ingestion facturée, stockage gratuit) ou ingérer dans le lac seul.

Effets d'un changement (portail Defender : Microsoft Sentinel > Configuration > Tables > Manage table) :

• passer une table d'Analytics à Data lake arrête ses analytics rules et hunting queries en temps réel ;
• réduire la total retention : Microsoft attend 30 jours avant de supprimer (pour revenir en arrière) ;
• augmenter la total retention s'applique aux données déjà ingérées et pas encore supprimées ;
• modifier l'analytics retention d'une table avec données prend effet immédiatement.

La vue Table insights (volume par niveau, variations, coût estimé, anomalies) aide à choisir, mais n'est pas un outil de facturation ou d'alerte.

10.2 Les plans de table d'Azure Monitor (vision portail Azure)#

• Les plans Basic et Auxiliary ne sont pas disponibles pour les espaces aux anciens niveaux tarifaires ; un changement de plan par table et par semaine ; passer en Auxiliary arrête les alertes sur la table.
• La rétention se règle par table (plus besoin de plusieurs espaces pour des durées différentes).

# Rétention analytique 180 jours, rétention totale 2 ans pour la table SecurityEvent
az monitor log-analytics workspace table update \
  --resource-group rg-sentinel-prd --workspace-name law-sentinel-prd-weu \
  --name SecurityEvent --retention-time 180 --total-retention-time 730

Bornes de la CLI : --retention-time de 4 à 730 jours, --total-retention-time de 4 à 2 556 jours (7 ans) ; pour aller jusqu'à 12 ans, passer par le portail, l'API REST ou Update-AzOperationalInsightsTable. La valeur -1 revient au réglage de l'espace. Droit requis : Log Analytics Contributor (écriture sur l'espace et ses tables).

10.3 Retrouver des données anciennes : recherche et restauration#

Coût : on paie les Go analysés par la recherche (en rétention long terme pour l'Analytics, sur toute la période pour Basic et Auxiliary), plus l'ingestion des résultats.

11. Interroger Microsoft Purview Audit dans Defender XDR#

11.1 L'unified audit log#

Microsoft Purview Audit enregistre des milliers d'opérations utilisateurs et administrateurs dans des dizaines de services (Entra ID, Exchange, SharePoint, OneDrive, Teams, Power BI, Copilot, Defender XDR…). Il est activé par défaut pour les organisations entreprise.

Les enregistrements d'entités non utilisateur (service principals, événements système) sont gardés un an, sans personnalisation possible.

11.2 Rechercher l'audit dans le portail Defender#

1. Prérequis : l'audit doit être activé dans Purview, et l'utilisateur doit avoir le rôle Audit Logs ou View-Only Audit Logs (Exchange Online ou Purview ; attribué par défaut aux groupes Compliance Management et Organization Management).
2. Portail Defender > Audit (https://security.microsoft.com/auditlogsearch) ou portail Purview > Audit.
3. New search : dates, activités, utilisateurs, charge de travail > Search > exporter les résultats.

Le journal d'audit trace aussi les actions dans Defender XDR : modifications de rétention, isolation d'appareils, indicateurs, rôles, custom detection rules, affectation d'incidents.

Vérifier l'état de l'audit (Exchange Online PowerShell, module moderne) :

Connect-ExchangeOnline
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled   # True = audit activé
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) -RecordType SharePointSharingOperation -ResultSize 100

11.3 Corréler en KQL : CloudAppEvents et OfficeActivity#

• Dans l'advanced hunting de Defender XDR, la table CloudAppEvents contient les événements enrichis des applications cloud, dont Exchange, SharePoint, Teams, Power BI. Elle est alimentée par Defender for Cloud Apps : il faut le connecteur d'application Microsoft 365 avec la case Microsoft 365 activities (Settings > Cloud apps > App connectors).
• Dans Sentinel, le connecteur Microsoft 365 (Office 365) alimente la table OfficeActivity, conservée selon la rétention de l'espace (au-delà des 180 jours d'Audit Standard).

// Fichiers partagés à l'extérieur ces 7 derniers jours (chasse avancée)
CloudAppEvents
| where Timestamp > ago(7d)
| where Application == "Microsoft SharePoint Online"
| where ActionType in ("SharingSet", "AnonymousLinkCreated", "AddedToSecureLink")
| project Timestamp, AccountDisplayName, ActionType, ObjectName, IPAddress, CountryCode

// Activités d'administration Exchange inhabituelles (Sentinel)
OfficeActivity
| where TimeGenerated > ago(1d)
| where OfficeWorkload == "Exchange" and RecordType == "ExchangeAdmin"
| summarize Operations = make_set(Operation) by UserId, ClientIP

SharingSet, AnonymousLinkCreated et AddedToSecureLink sont les noms d'opérations du journal d'audit Purview (partage interne, lien « Tout le monde », lien « Personnes spécifiques »). Vérifier qu'ils apparaissent tels quels dans ActionType avec CloudAppEvents | summarize count() by Application, ActionType.

12. Compléments AZ-500, détecter et enquêter#

Hors des compétences listées, mais indispensables pour comprendre Sentinel (et présents dans l'ancienne AZ-500).

12.1 Les types d'analytics rules#

Les custom detections de Defender XDR sont désormais la méthode recommandée pour créer de nouvelles règles dans le portail Defender. Une règle inter-locataire s'exécute avec les identifiants de son créateur : elle s'arrête s'il perd l'accès.

12.2 Le reste de la boîte à outils du SOC#

• Incidents : regroupent alertes, entités, preuves ; tâches d'incident ; enquête graphique ; raisons de fermeture.
• UEBA (analyse du comportement des utilisateurs et des entités) : profils de comportement, priorisation des anomalies (sources : Entra ID, Windows Security Events 4624, 4625, 4648, 4672, 4688…).
• Chasse : hunting queries, bookmarks, livestream, notebooks Jupyter ; dans le data lake, notebooks et travaux.
• Threat Intelligence : indicateurs (TAXII, API d'importation), règles de correspondance ; l'offre autonome MDTI a pris fin le 1er août 2026, ses fonctions sont incluses dans Defender et Sentinel.
• Watchlists : listes CSV référencées en KQL (_GetWatchlist('VIP')).
• ASIM : modèle de normalisation (parsers) pour écrire une règle une fois, quelles que soient les sources.
• Workbooks : tableaux de bord ; SOC optimization : recommandations de couverture et de coût.
• MITRE ATT&CK : tactiques et techniques associées aux règles et incidents.

13. Labs conseillés#

Dans un abonnement de test : l'essai gratuit de Sentinel couvre les 10 premiers Go par jour ingérés (plan Analytics) pendant 31 jours (20 espaces au plus par locataire) ; Logic Apps et le data lake restent facturés. Supprimer le groupe de ressources à la fin.

Lab 1 · Espace, rôles et portail Defender

1. Créer un Log Analytics workspace, activer Microsoft Sentinel, porter la rétention à 90 jours.
2. L'intégrer au portail Defender comme primary workspace.
3. Donner Microsoft Sentinel Responder à un compte de test sur le resource group.
4. Résultat attendu : ce compte voit et modifie les incidents, mais ne peut ni installer de solution ni créer de règle.

Lab 2 · Content hub et connecteurs Azure

1. Installer les solutions Azure Activity et Microsoft Entra ID depuis le Content hub.
2. Connecter l'Azure Activity par l'Azure Policy Assignment wizard avec une remediation task ; connecter les journaux de connexion Entra (licence P1 requise).
3. Activer une analytics rule depuis un modèle de la solution.
4. Résultat attendu : AzureActivity et SigninLogs se remplissent ; la règle apparaît dans Active rules.

Lab 3 · Windows et Syslog avec l'AMA

1. Créer une VM Windows et une VM Linux (redirecteur).
2. Connecteur Windows Security Events via AMA : DCR Custom en XPath Security!*[System[(EventID=4624 or EventID=4625)]].
3. Connecteur CEF via AMA : DCR sur la VM Linux, script Forwarder_AMA_installer.py, puis la commande logger de test.
4. Résultat attendu : seuls les 4624 et 4625 dans SecurityEvent, le message de test dans CommonSecurityLog.

Lab 4 · Table personnalisée et transformation

1. Créer une table AppSecu_CL depuis un échantillon JSON avec une transformation qui retire une colonne.
2. Changer la total retention de SecurityEvent à 2 ans (portail ou CLI).
3. Résultat attendu : la table reçoit les données sans la colonne retirée ; la table SecurityEvent affiche la nouvelle rétention.

Lab 5 · Automatisation

1. Créer un playbook (Logic App Consumption, déclencheur incident, action Add comment to incident) avec une managed identity qui a Microsoft Sentinel Responder.
2. Donner Automation Contributor à Sentinel sur le resource group du playbook (Playbook permissions).
3. Créer une automation rule « When incident is created » qui lance le playbook et ajoute une étiquette, avec une date d'expiration.
4. Résultat attendu : à l'incident suivant (générer une alerte de test), le commentaire et l'étiquette apparaissent.

Lab 6 · Audit Purview

1. Créer un lien de partage « Tout le monde » sur un fichier SharePoint de test.
2. Portail Defender > Audit : rechercher l'activité Created an anonymous link.
3. Résultat attendu : l'événement AnonymousLinkCreated apparaît (délai possible de plusieurs dizaines de minutes).

14. Les pièges d'examen#

15. Scénarios d'entraînement#

1. Contoso a un seul locataire, des données en Europe uniquement et une équipe d'exploitation qui doit lire les événements Windows de ses serveurs. Combien d'espaces Sentinel ?

Un seul. L'équipe d'exploitation lit ses journaux par le resource-context RBAC (ou le RBAC par table pour une table précise). On peut placer les données purement opérationnelles dans un espace Azure Monitor séparé, sans Sentinel, pour ne pas les payer au tarif Sentinel.

2. Un MSSP gère dix clients, chacun dans son locataire. Quelle architecture ?

Un espace Sentinel dans chaque locataire client (données, coûts et conformité chez le client), géré depuis le locataire du MSSP par Azure Lighthouse et la multitenant management du portail Defender. Inscrire Microsoft.SecurityInsights et Microsoft.OperationalInsights dans un abonnement du MSSP si celui-ci n'a pas d'espace.

3. Les analystes N1 trient les incidents et doivent pouvoir lancer le playbook « Isoler la machine » ; les ingénieurs écrivent les règles et les playbooks. Quels rôles ?

N1 : Microsoft Sentinel Responder sur le resource group Sentinel + Playbook Operator sur celui des playbooks. Ingénieurs : Microsoft Sentinel Contributor + Logic App Contributor. Le compte de service Sentinel : Automation Contributor sur le resource group des playbooks, donné par un Owner.

4. Vingt pare-feu envoient des journaux CEF. La configuration est faite, mais rien n'arrive. Que vérifier ?

Sur le redirecteur : netstat -lnptv (le démon écoute-t-il sur 514 ?), tcpdump sur 514 et 28330, l'état de azuremonitoragent et de rsyslog, l'espace disque ; que les pare-feu envoient bien au redirecteur ; que la DCR est associée au redirecteur avec les bonnes facilités et niveaux ; attendre jusqu'à 20 minutes ; puis interroger CommonSecurityLog.

5. Le RSSI veut réduire le coût des événements Windows sans perdre la détection des compromissions.

Passer l'ensemble All Events à Minimal (ou Common si une piste d'audit complète est exigée), ou à un ensemble Custom XPath ; puis compléter, si besoin, par une transformation. Avec Sentinel activé, la transformation des tables Analytics est gratuite.

6. L'entreprise centralise déjà les journaux de ses postes sur un collecteur WEC. Comment les envoyer à Sentinel, et quel piège ?

Installer l'AMA sur le serveur WEC (Arc s'il est en local) et configurer le connecteur Windows Forwarded Events (DCR sur le journal ForwardedEvents). Piège : les données arrivent dans WindowsEvent ; les règles intégrées qui lisent SecurityEvent ne les voient pas : installer les parsers ASIM ou adapter les règles.

7. Une application métier produit des événements de sécurité en JSON. Comment les stocker dans Sentinel avec une durée de 3 ans, interrogés rarement ?

Créer une table AppSecu_CL (plan Auxiliary ou Analytics avec total retention de 3 ans dans le lac), une DCR directe avec la transformation adaptée, une identité Entra avec Monitoring Metrics Publisher sur la DCR, puis envoyer par le Logs Ingestion API (logs ingestion endpoint de la DCR ; DCE seulement avec Private Link).

8. Une équipe pentest attaque l'environnement du 3 au 14 novembre depuis une plage IP connue. Comment éviter de noyer le SOC ?

Automation rule déclenchée à la création d'incident, condition sur l'entité IP (plage du prestataire), action fermer avec la raison Benign Positive et une étiquette « pentest », date d'expiration au 14 novembre. Elle peut être créée depuis la page d'un des incidents.

9. La conformité exige de garder les journaux d'authentification 5 ans, mais l'équipe n'en interroge que 90 jours. Quelle configuration ?

Rétention analytique de 90 jours (incluse avec Sentinel) et total retention de 5 ans sur les tables concernées : les données de plus de 90 jours restent dans le data lake à faible coût, interrogeables en KQL, avec recherche ou restauration pour une enquête.

10. Un auditeur demande qui a créé des liens de partage anonymes sur SharePoint ces 30 derniers jours.

Portail Defender > Audit (rôle View-Only Audit Logs), activité Created an anonymous link (opération AnonymousLinkCreated, catégorie Sharing and access request activities), ou en advanced hunting la table CloudAppEvents (si Microsoft 365 est connecté à Defender for Cloud Apps), ou OfficeActivity dans Sentinel.

11. Après l'intégration au portail Defender, une automation rule basée sur le titre d'incident ne se déclenche plus. Pourquoi ?

Avec Defender XDR, c'est son moteur de corrélation qui crée et nomme les incidents : le titre n'est plus prévisible. Utiliser d'autres conditions, par exemple des étiquettes ou l'analytics rule.

12. Le connecteur Azure Firewall doit couvrir tous les pare-feu présents et futurs de trois abonnements.

Ouvrir la page du connecteur, lancer l'Azure Policy Assignment wizard à l'échelle du management group ou de chaque abonnement (rôle Owner), choisir l'espace et les catégories, cocher la remediation task pour les pare-feu existants. Les tables structurées AZFW* recevront les journaux.

16. Pour aller plus loin (au-delà de l'examen)#

• Sentinel en tant que code : repositories, export ARM des règles, ou Terraform (azurerm_sentinel_*) pour versionner l'espace, les connecteurs, les règles et les automation rules.
• Customer-managed key pour Sentinel : à prévoir avant l'activation (customer_managed_key_enabled dans Terraform ne peut plus être désactivé ensuite).
• Résidence des données : les données restent dans la géographie de l'espace, avec des exceptions (certaines détections par apprentissage automatique de Microsoft).
• Coût : commitment tiers (remise sur l'ingestion), summary rules, Data lake tier pour les journaux secondaires, filtrage à la source ; l'avantage d'ingestion de Defender for Servers P2 couvre une partie de SecurityEvent (voir chapitre 08).
• Microsoft Sentinel graph et agents Security Copilot : enquête assistée dans le portail Defender (chapitre 12).
• Azure Data Explorer ou export vers le stockage : solutions historiques de très longue rétention, moins utiles depuis le lac de données.

17. Fiche à retenir#

• Sentinel = solution SecurityInsights sur un Log Analytics workspace ; défaut 30 jours, 90 jours gratuits avec Sentinel (à configurer) ; espace non déplaçable après activation.
• Activer : Contributor de l'abonnement ; utiliser : Sentinel Reader / Contributor sur le resource group.
• Portail Azure : fin le 31 mars 2027 ; nouveaux clients intégrés au portail Defender depuis juillet 2025.
• Portail Defender : un primary workspace par locataire (corrélé avec XDR), secondary workspaces illimités sans incidents XDR.
• Un seul espace par défaut ; plusieurs pour souveraineté, autre locataire, propriété des données, facturation.
• Rôles : Reader (voir) < Responder (incidents) < Contributor (contenu, règles, hub) ; Playbook Operator (lancer) ; Logic App Contributor (créer) ; Automation Contributor = compte de service Sentinel sur le resource group des playbooks.
• Accès partiel : resource-context RBAC, granular RBAC par table, tables protégées.
• Hub : solutions (cycle de vie) et standalone content ; installer ≠ activer les règles ; repositories GitHub ou Azure DevOps (Owner), le dépôt fait foi.
• Connecteurs : service à service, diagnostic settings (Azure Policy + correction, même locataire), AMA + DCR.
• Entra ID : P1/P2 pour les connexions, Security Administrator.
• Syslog/CEF : redirecteur Linux, 514 → démon → 28330 → AMA → HTTPS 443 ; tables Syslog / CommonSecurityLog ; facilités distinctes contre les doublons ; Arc hors Azure.
• Windows : All Events, Common, Minimal, Custom (XPath 1.0, 20 expressions par champ) → SecurityEvent ; WEF : AMA sur le WEC → WindowsEvent.
• DCR : streamDeclarations, dataSources, destinations, dataFlows + transformKql ; une workspace transformation DCR pour les flux sans DCR.
• Table personnalisée _CL, TimeGenerated, plan Analytics / Basic / Auxiliary ; Logs Ingestion API : Monitoring Metrics Publisher sur la DCR, DCE seulement avec Private Link.
• Automation rules : incident créé, incident mis à jour, alerte créée ; conditions, actions, ordre, expiration ; exécution séquentielle.
• Playbooks : Logic Apps Consumption ou Standard (avec état) ; déclencheurs incident, alerte, entité ; managed identity avec Reader ou Responder.
• Rétention : analytique 30 j à 2 ans, totale jusqu'à 12 ans dans le lac ; par table ; recherche → _SRCH, restauration → _RST.
• Purview Audit : Standard 180 jours, Premium 1 an (10 ans avec licence) ; portail Defender > Audit avec Audit Logs / View-Only Audit Logs ; KQL : CloudAppEvents (Defender for Cloud Apps) ou OfficeActivity (Sentinel).

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Guide d'étude de l'examen SC-500
• Qu'est-ce que Microsoft Sentinel ? (calendrier de retrait du portail Azure)
• Microsoft Sentinel dans le portail Microsoft Defender
• Intégrer Microsoft Sentinel à un Log Analytics workspace
• Plusieurs workspaces Microsoft Sentinel dans le portail Defender
• Préparer plusieurs workspaces et locataires
• Concevoir une architecture de Log Analytics workspace
• Gérer les espaces Microsoft Sentinel à grande échelle (Azure Lighthouse)
• Travailler avec les incidents de plusieurs workspaces
• Rôles et autorisations dans la plateforme Microsoft Sentinel
• Gérer l'accès aux données Microsoft Sentinel par ressource
• granular RBAC dans Azure Monitor
• Gérer l'accès au niveau des tables
• Correspondance des rôles Sentinel avec le Defender Unified RBAC
• Vue d'ensemble du contenu prêt à l'emploi de Microsoft Sentinel
• Gérer le contenu en tant que code avec les repositories
• Déployer du contenu depuis un référentiel
• Connecteurs basés sur les diagnostic settings
• Connecteur de données Microsoft Entra ID
• Ingérer les alertes Microsoft Defender for Cloud
• Intégration de Microsoft Defender XDR avec Microsoft Sentinel
• Syslog et CEF via les connecteurs AMA
• Ingérer des messages Syslog et CEF avec l'Azure Monitor Agent
• Connecteurs basés sur l'agent Windows (Windows Forwarded Events)
• Ensembles de Windows Security Events
• Collecter les événements Windows avec Azure Monitor (requêtes XPath)
• Utiliser le transfert d'événements Windows pour la détection d'intrusion
• Migration vers l'Azure Monitor Agent pour Microsoft Sentinel
• Structure d'une Data Collection Rule
• Transformations dans Azure Monitor
• Ajouter ou supprimer des tables et des colonnes dans Azure Monitor Logs
• Logs Ingestion API dans Azure Monitor
• Data Collection Endpoints
• Automatiser la réponse aux menaces avec des automation rules
• Automatiser la réponse aux menaces avec des playbooks
• Créer et gérer des playbooks
• Authentifier les playbooks auprès de Microsoft Sentinel
• Exécuter des playbooks (autorisations, multilocataire)
• Gérer les niveaux de données et la rétention dans Microsoft Sentinel
• Configurer les paramètres des tables dans Microsoft Sentinel
• Qu'est-ce que le Microsoft Sentinel data lake ?
• Vue d'ensemble d'Azure Monitor Logs : plans de table
• Calculs et options de coût d'Azure Monitor Logs
• Planifier les coûts de Microsoft Sentinel (essai gratuit, 90 jours de rétention gratuits)
• Gérer la rétention des données d'un Log Analytics workspace
• az monitor log-analytics workspace table (Azure CLI)
• Activités du journal d'audit (partage et demandes d'accès)
• Table WindowsEvent (référence)
• Rechercher des événements dans de grands jeux de données
• Restaurer des journaux archivés
• Solutions d'audit dans Microsoft Purview
• Rechercher dans le journal d'audit dans Microsoft Defender XDR
• Rechercher dans le journal d'audit (Purview)
• Table CloudAppEvents (advanced hunting)
• Détection des menaces dans Microsoft Sentinel
• Annonces partenaires de février 2026 (report au 31 mars 2027)
• Registre Terraform : azurerm_sentinel_log_analytics_workspace_onboarding