Microsoft Sentinel : SIEM/SOAR Cloud Microsoft Azure 2026

Microsoft Sentinel est la plateforme SIEM (Security Information and Event Management) et SOAR (Security Orchestration, Automation and Response) cloud-native de Microsoft, déployée sur Azure et conçue pour collecter, analyser, détecter et répondre aux menaces de sécurité à l'échelle du cloud, de l'on-premise et des environnements hybrides. Lancé en 2019 sous le nom Azure Sentinel puis renommé Microsoft Sentinel en 2021, le produit s'appuie sur le moteur Azure Log Analytics et le langage de requête KQL (Kusto Query Language) pour ingérer plusieurs téraoctets de logs par jour, corréler des événements provenant de plus de 200 connecteurs natifs (Active Directory, Microsoft 365, AWS, GCP, syslog/CEF, Defender XDR), et orchestrer des réponses automatisées via Azure Logic Apps. En 2024, Microsoft a unifié Sentinel avec la suite Defender XDR au sein du portail security.microsoft.com, créant une plateforme unique de détection et de réponse couvrant identités, endpoints, e-mail, applications cloud et infrastructure. Sentinel sert aussi bien les PME via des MSSP qu'aux grands comptes en mode multi-tenant, avec un modèle de facturation à la consommation (Pay-As-You-Go) ou par paliers d'engagement (Commitment Tiers) à partir de 100 Go/jour. Ce guide détaille l'architecture, les Analytics Rules, le UEBA, le hunting, la tarification, les limites et le positionnement face à Splunk, Wazuh et IBM QRadar.

Définition : qu'est-ce que Microsoft Sentinel ?

Microsoft Sentinel est un SIEM cloud-native qui collecte des données de sécurité à partir de toutes les sources d'une organisation (utilisateurs, appareils, applications, infrastructures), les analyse en temps réel grâce à l'intelligence artificielle et au machine learning intégrés, détecte les menaces connues et inconnues, et orchestre la réponse via des playbooks automatisés. Contrairement aux SIEM traditionnels (Splunk Enterprise, IBM QRadar, ArcSight) qui exigent une infrastructure dédiée et une expertise opérationnelle élevée, Sentinel est fully managed : Microsoft assure le stockage, l'indexation, la haute disponibilité et les mises à jour. Le produit combine quatre fonctions clés : collecte (Data Connectors), détection (Analytics Rules + UEBA + Fusion), investigation (Workbooks, Hunting, Notebooks Jupyter), et réponse (Automation Rules, Logic Apps Playbooks). La donnée est stockée dans un Log Analytics Workspace Azure, interrogée en KQL, et conservée par défaut 90 jours (extensible jusqu'à 7 ans en archivage).

Sentinel se distingue par son architecture data lake-first : toutes les sources de logs convergent vers Azure Data Explorer (ADX), moteur columnar haute performance qui supporte des dizaines de milliards de lignes par jour avec une latence d'interrogation sub-seconde. Cette approche élimine les goulets d'étranglement classiques des SIEM legacy (indexation lente, contraintes hardware, sharding manuel) et permet à un analyste SOC d'écrire une requête KQL sur 90 jours de logs en quelques secondes, là où un Splunk on-prem mettrait plusieurs minutes. Sentinel n'est cependant pas un EDR : il ne déploie pas d'agents sur les endpoints (rôle dévolu à Microsoft Defender for Endpoint), mais consomme leurs alertes via les data connectors. C'est cette frontière qui définit son positionnement : Sentinel est la plateforme de corrélation et de réponse de niveau organisation, tandis que Defender XDR est la couche de détection telemétrique sur les charges Microsoft.

Historique : d'Azure Sentinel 2019 à Microsoft Sentinel 2026

Microsoft a annoncé Azure Sentinel en preview lors de la RSA Conference de février 2019, en réponse à la demande croissante des entreprises pour un SIEM cloud à l'échelle du Big Data. La GA (General Availability) a eu lieu en septembre 2019, avec une centaine de data connectors et des dizaines de playbooks préconfigurés. En novembre 2021, Microsoft renomme le produit en Microsoft Sentinel pour refléter sa portée multi-cloud (AWS, GCP) et hybride. En 2022-2023, l'éditeur introduit les Watchlists, le UEBA avancé, les règles Near-Real-Time (NRT) et les Notebooks Jupyter via Azure Machine Learning. La grande étape de 2024 est l'unification avec Defender XDR : depuis le portail security.microsoft.com, les analystes voient désormais incidents Sentinel et Defender côte-à-côte, avec corrélation automatique et hunting cross-platform. En 2025-2026, Microsoft a renforcé l'intégration Copilot for Security qui génère des requêtes KQL, résume des incidents et propose des actions de remédiation en langage naturel.

Architecture technique : composants et flux de données

L'architecture de Microsoft Sentinel s'articule autour de sept composants majeurs : (1) Log Analytics Workspace, le moteur de stockage et d'indexation des logs basé sur Azure Data Explorer ; (2) Data Connectors, qui ingèrent les flux via API, agents (AMA — Azure Monitor Agent), syslog/CEF, ou Logstash ; (3) Analytics Rules, moteurs de détection en KQL ; (4) Workbooks, dashboards interactifs JSON-based ; (5) Hunting Queries et Notebooks pour la recherche proactive ; (6) Incidents, agrégation des alertes corrélées ; (7) Automation Rules + Logic Apps Playbooks pour le SOAR. Les données circulent ainsi : sources → connecteur → workspace Log Analytics → table dédiée (SecurityEvent, SigninLogs, AzureActivity, etc.) → règle d'analyse → alerte → incident → playbook. Le tout est gouverné par Azure RBAC (Role-Based Access Control) avec des rôles spécifiques (Sentinel Reader, Responder, Contributor).

Le Log Analytics Workspace est l'unité d'isolation logique et de facturation : une organisation peut en déployer plusieurs (par région géographique, par filiale, par environnement prod/preprod), avec des stratégies de tarification distinctes (Pay-As-You-Go, Commitment Tier, Basic Logs, Auxiliary Logs en preview). La fonctionnalité Workspaces Manager permet à un MSSP ou un grand groupe de gérer une cinquantaine de workspaces depuis une console centrale, avec déploiement de règles et de Workbooks par template. Pour les architectures multi-tenant, Azure Lighthouse fédère plusieurs locataires (tenants) Azure AD/Entra ID sous une délégation contrôlée. Côté ingestion, les Data Collection Rules (DCR) introduites en 2022 permettent de filtrer, transformer et enrichir les logs avant stockage, ce qui réduit drastiquement les coûts (suppression des champs inutiles, conversion vers schéma ASIM, redirection vers Basic Logs pour les sources verboses comme firewall ou proxy). Cette stratégie de log pipeline shaping est la principale technique de maîtrise budgétaire en 2026.

KQL (Kusto Query Language) : bases et exemples

KQL est le langage de requête de Sentinel, dérivé de l'opérateur pipe-style d'Azure Data Explorer. Sa syntaxe est lisible, déclarative et optimisée pour les logs et séries temporelles. Une requête type commence par une table, suivie d'opérateurs chaînés par | (pipe). Exemples concrets :

// Connexions Azure AD échouées par utilisateur sur 24h
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| summarize FailedAttempts = count() by UserPrincipalName, IPAddress
| where FailedAttempts > 10
| order by FailedAttempts desc

// Détection brute-force RDP via SecurityEvent
SecurityEvent
| where EventID == 4625 and LogonType == 10
| summarize Count = count() by Account, IpAddress, bin(TimeGenerated, 5m)
| where Count > 20

KQL supporte les joins, unions, fonctions de fenêtre, agrégations summarize, parsing dynamique JSON, regex, géolocalisation IP (geo_info_from_ip_address), et machine learning intégré (series_decompose_anomalies). La maîtrise de KQL est indispensable pour exploiter pleinement Sentinel.

Au-delà des bases, KQL possède des opérateurs avancés rarement présents dans les autres langages SIEM : materialize() pour mémoriser un sous-ensemble dans une seule passe, iff() et case() pour la logique conditionnelle, extend pour calculer de nouvelles colonnes, mv-expand pour exploser les tableaux JSON, parse pour extraire des champs textuels, top-nested pour les hiérarchies, et render pour générer directement des graphiques (timechart, columnchart, scatterchart). La fonction basket() détecte automatiquement les patterns fréquents dans un dataset, utile pour identifier des comportements anormaux sans hypothèse préalable. Pour les analystes, l'environnement de développement KQL inclut le KQL playground Microsoft, l'extension Kusto pour Visual Studio Code (avec autocomplétion, linting, formatting), et l'outil kqlmagic pour exécuter des requêtes depuis Jupyter. Les requêtes peuvent être stockées en tant que Saved Functions dans le workspace, créant une bibliothèque réutilisable cross-règle.

Data Connectors : 200+ intégrations natives

Sentinel propose plus de 200 connecteurs natifs, classés en cinq familles : (1) Microsoft (Azure AD/Entra ID, Microsoft 365, Defender for Endpoint/Identity/Cloud Apps/Office 365, Azure Activity, Azure Resource, Microsoft Purview) ; (2) Multi-cloud (AWS CloudTrail, AWS S3, GCP Audit Logs, GCP Pub/Sub) ; (3) Network/Endpoint (Cisco ASA/Meraki/Umbrella, Palo Alto PAN-OS, Fortinet FortiGate, Check Point, Zscaler, CrowdStrike, SentinelOne) ; (4) Threat Intelligence (MDTI Microsoft Defender Threat Intelligence, MISP, ThreatConnect, Anomali, OTX) ; (5) Custom via syslog/CEF, Common Event Format, REST API, Azure Functions, ou Logstash output plugin. Chaque connecteur dépose les données dans une table KQL spécifique avec un schéma normalisé (ASIM — Advanced SIEM Information Model) qui permet d'écrire des règles cross-vendor.

Analytics Rules : Scheduled, NRT, Anomaly, Fusion

Les règles d'analyse de Sentinel se déclinent en cinq types : (1) Scheduled — exécution KQL toutes les 5 minutes à 14 jours, base de la majorité des détections ; (2) Near-Real-Time (NRT) — exécution chaque minute pour cas critiques (compromise impossible travel, mass file deletion) ; (3) Microsoft Security — relais des alertes Defender XDR vers Sentinel ; (4) Anomaly — détection statistique basée sur ML, sans règle écrite (UEBA powered) ; (5) Fusion — corrélation multi-stage propriétaire Microsoft, qui combine signaux faibles entre Defender, Sentinel et 365 pour détecter des kill-chains complets (kill-chain ransomware, golden ticket, etc.). Le Content Hub propose plus de 500 règles prêtes à l'emploi, mappées sur MITRE ATT&CK.

Chaque règle Scheduled définit une query frequency (5 min à 14 jours), une lookup period (intervalle de données analysées), un seuil (nombre minimal de résultats pour déclencher), une logique d'agrégation d'alertes (groupement par entité ou explosion en alertes individuelles), et une suppression optionnelle pour éviter le bruit. Les règles sont versionnables via Azure DevOps ou GitHub avec le Sentinel Repositories connector, qui synchronise un dépôt Git vers le workspace : pratique pour les équipes Detection Engineering qui appliquent des principes Detection-as-Code. Les outputs des règles incluent obligatoirement les Entity Mappings (User, Host, IP, FileHash, URL, Mailbox) qui alimentent le graphe d'investigation, et les Custom Details (champs propres exposés dans l'alerte). Microsoft introduit en 2025 les Summary Rules qui pré-agrègent les volumes massifs (ex: tous les logs DNS de la journée → 1 ligne par domaine), permettant des détections à coût d'ingestion bas.

Workbooks et dashboards : visualisation custom

Les Workbooks Sentinel sont des dashboards interactifs définis en JSON, combinant texte Markdown, requêtes KQL, paramètres dynamiques, graphiques (timeline, bar, pie, heatmap, map) et tableaux pivotables. Microsoft fournit plus de 100 templates : Investigation Insights, Identity & Access, Threat Intelligence, Azure Activity, AWS Network Activities, MITRE ATT&CK Workbook. Chaque workbook peut être customisé via l'éditeur visuel ou édition JSON directe, exporté en template ARM/Bicep et versionné dans Git. C'est l'équivalent des dashboards Splunk ou Kibana, avec une intégration native aux paramètres Azure et aux variables KQL.

Incidents et SOAR : automation rules et playbooks

Quand une Analytics Rule génère une alerte, Sentinel crée ou regroupe un Incident (entité centrale d'investigation) avec sévérité, statut, propriétaire, tags et entités liées (utilisateurs, IP, hôtes, fichiers). Les analystes triagent depuis l'interface ou le portail Defender unifié. La couche SOAR repose sur deux constructions : Automation Rules (orchestration légère : auto-assignation, fermeture, tagging, suppression de doublons) et Playbooks (Logic Apps complets, déclenchant des actions externes : isoler un endpoint via Defender, désactiver un compte AD, créer un ticket ServiceNow, envoyer un message Teams, bloquer une IP sur Palo Alto, lancer un scan VirusTotal). Les Playbooks sont écrits dans le designer Logic Apps, en code-first ou no-code, avec plus de 600 connecteurs Azure disponibles. Pour approfondir le hunting et la détection proactive, voir notre guide Threat Hunting avec Microsoft 365 et Sentinel.

L'Investigation Graph de Sentinel offre une vue interactive du périmètre d'un incident : pivot par entité, expansion des relations (utilisateur → endpoint → IP → fichier), timeline événementielle et accès direct aux requêtes KQL associées. Il accélère significativement le triage en réduisant le temps moyen de qualification (Mean Time To Triage, MTTT). En complément, la fonctionnalité Tasks permet de définir des playbooks d'investigation manuelle (checklist d'actions analyste) que l'on attache aux incidents par sévérité. Les Playbooks Logic Apps peuvent être déclenchés automatiquement sur création d'incident, mise à jour d'incident, ou alerte individuelle, ou manuellement via un bouton dans l'interface incident. Cette double modalité permet d'implémenter à la fois des SOAR full-auto (containment ransomware en 30 secondes) et des SOAR human-in-the-loop (validation analyste avant désactivation d'un compte VIP).

UEBA : User and Entity Behavior Analytics

Le module UEBA de Sentinel applique des modèles de machine learning aux logs d'identité (Azure AD, AD on-prem, signin, audit) pour établir une baseline comportementale par utilisateur et entité (host, IP, device). Toute déviation significative — connexion depuis un pays inhabituel, escalade soudaine de privilèges, accès massif à des fichiers — génère un UEBA Insight. Les données enrichies sont disponibles via deux tables : BehaviorAnalytics (événements scorés) et IdentityInfo (profil enrichi : titre, manager, groupes). UEBA est facturé séparément (~$2/utilisateur actif/mois) et requiert l'activation explicite et un workspace Log Analytics avec des connecteurs identité. Pour explorer le sujet plus largement, consultez Threat Hunting et Détection Proactive MITRE ATT&CK.

Concrètement, UEBA produit pour chaque utilisateur un investigation priority score de 0 à 100, recalculé en continu en fonction des comportements détectés (anomalies de localisation, de device, de volume, de privilèges) et des alertes Defender associées. Les analystes peuvent ainsi trier proactivement les utilisateurs à risque, sans attendre qu'une règle se déclenche. Le module exploite quatre catégories d'algorithmes : peer group analysis (comparaison avec groupes pairs RH), time series anomaly (déviation par rapport au profil temporel personnel), rare event detection (action statistiquement rare), et graph analysis (relations entre entités). UEBA s'intègre nativement avec Microsoft Defender for Identity (anciennement Azure ATP) pour enrichir le profil des comptes Active Directory et détecter les attaques classiques : pass-the-hash, golden ticket, DCSync, kerberoasting, password spray.

Threat Intelligence : MDTI, MISP, STIX/TAXII

Sentinel intègre nativement plusieurs feeds de Threat Intelligence : Microsoft Defender Threat Intelligence (MDTI) (gratuit pour les indicateurs Microsoft, payant pour le portail premium), STIX/TAXII 2.x (compatible avec MISP, OpenCTI, ThreatConnect, EclecticIQ), TAXII Server Microsoft Graph Security, et imports manuels via API ou CSV. Les indicateurs (IoC) sont stockés dans la table ThreatIntelligenceIndicator et automatiquement matchés contre les logs entrants pour produire des alertes. Sentinel génère également des Threat Intelligence Maps géographiques et permet le tagging des indicateurs par campagne, acteur (APT28, FIN7, Lazarus) ou TTP MITRE. Pour les organisations qui exploitent un MISP, l'intégration via le TAXII data connector est plug-and-play.

Hunting : queries, Notebooks Jupyter, livestream

Le module Hunting permet la recherche proactive de menaces non détectées par les règles. Sentinel embarque plus de 200 hunting queries officielles, mappées MITRE ATT&CK, classées par tactique (Initial Access, Execution, Persistence, Lateral Movement, Exfiltration). Chaque hunt peut être livestreamed (exécution continue avec notification immédiate) ou converti en bookmark pour investigation ultérieure. Pour le hunting avancé, Sentinel s'intègre avec Azure ML Notebooks Jupyter via MSTICPy (bibliothèque Python open-source Microsoft Threat Intelligence Center) qui fournit pivot tables, géolocalisation IP, lookup VirusTotal, modélisation graphique et timeline analysis. Les analystes peuvent ainsi mener des investigations complexes en Python tout en consommant les données Sentinel via REST API. Voir aussi Audit avancé Microsoft 365 et corrélation de logs.

Conformité : NIS2, ISO 27001, GDPR, MITRE ATT&CK

Microsoft Sentinel est conforme à plus de 90 standards : ISO 27001/27017/27018, SOC 2 Type II, PCI DSS, HIPAA, FedRAMP High, HDS (hébergement données de santé France), NIS2 (Directive UE 2022/2555 sur la cybersécurité). Le mappage MITRE ATT&CK est natif : chaque Analytics Rule et hunting query référence des techniques (T1078 Valid Accounts, T1059 Command and Scripting Interpreter, T1486 Data Encrypted for Impact) et permet de visualiser la couverture défensive sur la matrice complète via le MITRE ATT&CK Workbook. Pour le RGPD, Sentinel offre la rétention configurable, l'export Azure Data Lake, le pseudonymisation, et l'audit des accès aux données via les Activity Logs Azure.

Pricing : Pay-As-You-Go, Commitment Tiers, Azure benefits

Le pricing Sentinel se compose de deux couches superposées : (1) ingestion Log Analytics (~2,30€/Go) et (2) analyse Sentinel (~1,80€/Go), soit ~4€/Go en Pay-As-You-Go. Les Commitment Tiers offrent jusqu'à 65% de réduction : 100 Go/jour à -50%, 500 Go/jour à -60%, 1000 Go/jour à -65%, 5000 Go/jour à un prix sur devis. Microsoft inclut 5 Go/mois gratuits sur les logs Azure AD audit/sign-in, ainsi que 31 jours de rétention gratuits (90 jours si MDE/Defender activé). Les logs Microsoft 365 E5 (Office 365, Defender XDR) sont gratuits à ingérer pendant 90 jours via les E5 benefits. La rétention longue (jusqu'à 7 ans) est facturée séparément en Archive tier (~0,02€/Go/mois). Pour estimer les coûts, voir le calculateur officiel Azure.

Microsoft a introduit en 2024-2025 plusieurs leviers d'optimisation budgétaire majeurs. Les Basic Logs permettent d'ingérer des sources verboses à coût réduit (~0,50€/Go) avec une rétention courte (8 jours) et des limitations sur les requêtes analytiques. Les Auxiliary Logs (en GA fin 2025) descendent encore plus bas (~0,10€/Go) pour les logs de bas signal : firewall, DNS, proxy. La fonctionnalité Search Jobs permet de requêter des logs archivés sur 7 ans avec une facturation à la requête. Enfin, l'export vers Azure Data Lake Storage via Continuous Export libère des données du workspace tout en conservant la requêtabilité via Azure Data Explorer ou Synapse. Pour une organisation à 200 Go/jour, une stratégie optimisée mélange Analytics Logs (logs critiques EDR, identité, AD), Basic Logs (firewall, proxy), et Auxiliary Logs (NetFlow, DNS), permettant de diviser la facture par 3 à 4 par rapport à un déploiement naïf full Analytics.

Comparatif : Sentinel vs Splunk vs Wazuh vs IBM QRadar

Pour un comparatif détaillé avec une alternative open-source, consultez Wazuh SIEM/XDR : déploiement et détection.

Limites et contraintes

Malgré ses atouts, Microsoft Sentinel présente plusieurs limites : (1) Coût d'ingestion rapidement élevé pour les organisations à fort volume (>500 Go/jour), nécessitant une stratégie de filtrage en amont (Data Collection Rules, Basic Logs tier, Auxiliary Logs en preview) ; (2) Courbe d'apprentissage KQL non négligeable, surtout pour les équipes habituées à SPL ou AQL ; (3) Dépendance Azure — bien que multi-cloud, le moteur tourne exclusivement sur Azure, posant des questions de souveraineté pour certains secteurs (défense, OIV) ; (4) Latence d'ingestion variable (1-15 minutes typiques), peu adaptée aux cas ultra-temps-réel ; (5) Quota d'API (Log Analytics workspace : 200 req/min, search jobs limités) ; (6) Rétention : au-delà de 90 jours, les coûts archive s'accumulent rapidement. Pour la souveraineté, alternatives à considérer : Wazuh (open-source) ou OpenSearch + ELK SIEM. Voir notre comparatif sur IA et détection de menaces : SIEM augmenté.

Cas d'usage : PME via MSSP, ETI, grands comptes XDR

Microsoft Sentinel s'adresse à trois segments majeurs. (1) PME (10-250 employés) : adoption typique via un MSSP (Managed Security Service Provider) en mode multi-tenant, qui mutualise un ou plusieurs workspaces Sentinel pour une dizaine de clients. Coût mensuel ~500-2000€/client. (2) ETI / mid-market hybride (250-5000 employés) : déploiement direct, souvent en cohabitation avec un SOC interne ou un MSSP. Volume typique 50-200 Go/jour. Cas d'usage : couverture Microsoft 365, AD hybride, endpoints Defender, infrastructures Azure et AWS. (3) Grands comptes (>5000 employés) : Sentinel comme couche XDR centrale, fédérant plusieurs workspaces régionaux (Lighthouse multi-tenant), intégrant des sources legacy (mainframes, OT, ICS via syslog/CEF), avec automation avancée et équipe Threat Hunting dédiée. Volume >1 To/jour. Pour les organisations Microsoft 365, voir Audit Microsoft 365 et Pentest Microsoft 365 pour évaluer votre posture avant déploiement Sentinel.

FAQ Microsoft Sentinel

Combien coûte Microsoft Sentinel ?

Le tarif Pay-As-You-Go est ~2,30€/Go ingéré + ~1,80€/Go analysé, soit ~4€/Go au total. Avec les Commitment Tiers, on descend à ~1,40€/Go pour 500 Go/jour. Pour une ETI à 100 Go/jour, compter ~120 000€/an en PAYG ou ~60 000€/an en CT 100. Les logs Microsoft 365 E5 sont gratuits 90 jours via les E5 benefits.

Sentinel vs Defender XDR : quelle différence ?

Defender XDR est une plateforme XDR (Extended Detection and Response) couvrant identités, endpoints, e-mail et apps cloud Microsoft. Sentinel est un SIEM/SOAR qui ingère tous les logs (Microsoft + tiers). Depuis 2024, ils sont unifiés dans security.microsoft.com : Defender alimente Sentinel, et Sentinel oriente le hunting cross-domain. En pratique, on les déploie ensemble.

Microsoft Sentinel est-il gratuit pour les PME ?

Non, Sentinel n'a pas d'offre gratuite native, contrairement à Wazuh. Cependant, les 5 Go/mois Azure AD audit/sign-in gratuits et les E5 benefits couvrent une grande partie des besoins d'une PME équipée Microsoft 365 E5. Pour les budgets limités, l'option MSSP en mode mutualisé est généralement plus économique qu'un déploiement en direct.

KQL est-il difficile à apprendre ?

KQL est plus facile que SPL ou regex : sa syntaxe pipe-style et lisible permet aux analystes d'écrire des requêtes utiles en quelques heures. Microsoft propose un KQL Learn gratuit, des labs interactifs et plus de 1000 exemples sur GitHub Azure-Sentinel. Maîtriser le KQL avancé (joins, ML functions, ASIM) prend 3-6 mois de pratique régulière.

Peut-on créer des connecteurs custom ?

Oui, via plusieurs méthodes : Data Collection Rules (DCR) + agent AMA pour fichiers logs custom, Logs Ingestion API REST pour push direct depuis n'importe quelle source, Codeless Connector Platform (CCP) pour API SaaS sans code, Azure Functions pour transformations complexes, ou Logstash output plugin Microsoft. Le repo GitHub Azure/Azure-Sentinel contient plus de 50 templates de connecteurs custom.

Sentinel supporte-t-il les environnements multi-cloud ?

Oui, Sentinel intègre AWS (CloudTrail, GuardDuty, S3 logs, VPC Flow), GCP (Audit Logs, Pub/Sub, Cloud Logging), OCI Oracle Cloud et environnements hybrides via syslog/CEF. La normalisation ASIM permet d'écrire des règles KQL communes à travers les fournisseurs cloud, réduisant la complexité opérationnelle.

Pour aller plus loin

• Threat Hunting Microsoft 365 + Sentinel : guide opérationnel
• Threat Hunting et Détection Proactive avec MITRE ATT&CK
• Audit avancé Microsoft 365 : corrélation des journaux et logs
• Wazuh SIEM/XDR : alternative open-source à Sentinel
• IA et SIEM augmenté : détection de menaces nouvelle génération
• Glossaire : SIEM (Security Information and Event Management)
• Notre offre d'audit Microsoft 365 et pentest Microsoft 365
• Documentation officielle : learn.microsoft.com/azure/sentinel
• Repository GitHub : github.com/Azure/Azure-Sentinel
• Site éditeur : microsoft.com/security/sentinel