Microsoft Sentinel (Azure SIEM) : guide de déploiement et de configuration 2026

Microsoft Sentinel est le SIEM (Security Information and Event Management) cloud-native de Microsoft Azure. Contrairement aux SIEM on-premise traditionnels (Splunk, IBM QRadar), Sentinel est entièrement opéré dans Azure et s'intègre nativement avec Microsoft 365, Azure AD (Entra ID), et l'ensemble de l'écosystème Microsoft. Pour les entreprises utilisant M365 ou Azure, Sentinel est souvent le choix naturel. Voici comment le déployer et le configurer efficacement.

Architecture de Microsoft Sentinel

Sentinel est construit sur Azure Log Analytics (Workspace). Tous les logs ingérés sont stockés dans un workspace Log Analytics, sur lequel Sentinel ajoute ses capacités d'analyse, de détection et de réponse.

• Log Analytics Workspace : La fondation de Sentinel. Stocke tous les logs, permet les requêtes KQL (Kusto Query Language). La rétention est configurable (30 jours à 2 ans, avec archivage long terme).
• Connecteurs de données : 200+ connecteurs disponibles pour ingérer des données de sources Microsoft (M365, Entra ID, Azure) et tierces (AWS CloudTrail, Palo Alto, Cisco).
• Règles analytiques : Règles de détection (Scheduled, NRT, Fusion, Anomaly) qui créent des incidents à partir d'événements ou de patterns suspects.
• SOAR Playbooks : Automatisations de réponse basées sur Azure Logic Apps, déclenchées automatiquement ou manuellement sur les incidents.
• UEBA : User Entity Behavior Analytics — baseline comportemental des utilisateurs pour détecter les anomalies.
• Threat Intelligence : Intégration des IOC (Indicators of Compromise) — Microsoft Defender TI, STIX/TAXII feeds externes.

Connecteurs prioritaires à configurer

Sources Microsoft (connecteurs natifs)

• Microsoft 365 Defender : Alertes et incidents de l'ensemble de la suite Defender (Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps). Le connecteur M365D est bi-directionnel : les incidents Sentinel apparaissent dans la console M365D.
• Microsoft Entra ID (Azure AD) : Logs de connexion (SignInLogs), logs d'audit (AuditLogs), activité de provisioning (ProvisioningLogs). Essentiel pour la détection des compromissions de compte (impossible travel, connexions depuis Tor, brute force).
• Azure Activity : Toutes les opérations sur les ressources Azure (création/suppression VM, modification NSG, accès Key Vault). Détection des abus de permissions cloud.
• Microsoft Defender for Cloud : Alertes de sécurité sur les ressources Azure (VM vulnérables, mauvaises configurations).
• Office 365 : Logs d'audit Exchange Online, SharePoint, Teams. Détection des règles de transfert malveillantes, téléchargements massifs SharePoint.

Sources tierces importantes

• AWS CloudTrail : Connecteur natif pour ingérer les logs CloudTrail. Permet une vision multi-cloud dans Sentinel.
• Pare-feu réseau : Palo Alto (via CEF), Cisco ASA, Fortinet, Check Point — via le connecteur Common Event Format (CEF/Syslog).
• Linux/Windows servers : Via l'agent AMA (Azure Monitor Agent) qui remplace MMA/OMS.
• GitHub/Azure DevOps : Pour la détection des menaces dans les pipelines CI/CD.

KQL (Kusto Query Language) : les requêtes essentielles

KQL est le langage de requête de Sentinel et Log Analytics. Voici quelques requêtes de détection essentielles :

Détection des connexions suspectes Entra ID

• Connexions depuis des pays inhabituels pour l'organisation
• Impossible travel (connexion depuis Paris puis Tokyo en 30 minutes)
• Connexions depuis des adresses IP dans les listes de menaces (Microsoft TI)
• MFA bypassed or downgraded (connexions sans MFA sur des comptes qui l'ont activé)

Détection des abus de privilèges Azure

• Élévation de privilèges inattendues (nouveau rôle Owner assigné)
• Création de comptes de service avec des permissions larges
• Accès au Key Vault par des entités non habituelles
• Bulk deletion d'objets Azure (préparation d'un ransomware cloud)

Détection des anomalies M365

• Règles de forwarding d'emails vers des domaines externes créées récemment
• Téléchargement massif depuis SharePoint/OneDrive (exfiltration)
• Accès à des boîtes mail par un compte admin non autorisé (e-discovery abuse)
• Envoi d'emails en masse depuis un compte interne (compromission BEC)

Règles analytiques : scheduled vs. NRT vs. Fusion

Sentinel propose plusieurs types de règles analytiques avec des caractéristiques différentes :

• Scheduled (planifiées) : Requêtes KQL exécutées à intervalles réguliers (toutes les 5 minutes à 24 heures). La plupart des règles de détection sont de ce type. Elles permettent une logique de corrélation complexe.
• NRT (Near Real-Time) : Exécutées en quasi-temps réel (délai ~1 minute). Idéales pour les détections critiques nécessitant une réponse rapide (détection d'un Golden Ticket Kerberos, compromission d'un compte admin).
• Fusion : Détection par IA multiétape — corrèle automatiquement des signaux de faible fidélité provenant de sources multiples pour détecter des attaques complexes. Exemples : détection de mouvements latéraux, attaques APT multi-étapes.
• Anomaly : Détection basée sur le machine learning (UEBA) — identifie les comportements déviants par rapport au baseline de l'entité (utilisateur, machine, IP).
• Threat Intelligence : Comparaison automatique des indicateurs de menace (IOC) avec les logs ingérés — détecte les connexions vers des IPs malveillantes, les domaines de C2, etc.

SOAR : automatiser la réponse aux incidents

Les playbooks Sentinel (basés sur Azure Logic Apps) permettent d'automatiser les actions de réponse. Exemples de playbooks utiles :

• Auto-blocage compte compromis : Détection d'un compte Entra ID compromis → désactivation automatique du compte + révocation des sessions + notification Teams/Slack
• Enrichissement automatique des incidents : Ajout automatique d'informations de threat intelligence (VirusTotal, Shodan, MaxMind GeoIP) aux incidents
• Isolation de machine infectée : Détection de malware sur endpoint via Defender for Endpoint → isolation automatique de la machine du réseau
• Notification et escalade : Création automatique de tickets ITSM (ServiceNow, Jira) pour les incidents de haute sévérité + notification on-call via PagerDuty
• Blocage IP malveillante : Détection d'une IP dans la TI feed → ajout automatique à la Named Location Entra ID pour bloquer les connexions

Coûts et optimisation

Sentinel est facturé à l'ingestion de données (Go/jour) et à la rétention. Les coûts peuvent surprendre si mal configurés :

• Sources gratuites : Microsoft 365 Defender, Azure Activity, Entra ID (Audit + SignIn), Microsoft Defender for Cloud — aucun coût d'ingestion Sentinel
• Sources payantes : Logs serveurs, pare-feu, sources tierces — facturés au Go ingéré (tarification par palier)
• Commitment tiers : Engagement de volume journalier (100 Go/j, 200 Go/j...) pour réduire les coûts de 30-65% vs. pay-as-you-go
• Filtrage des logs : Ne pas tout ingérer — filtrer les logs volumineux et peu utiles (logs debug, logs de navigation web sauf si nécessaires) via les DCR (Data Collection Rules)
• Basic Logs : Pour les logs à fort volume et faible valeur investigative, utiliser le niveau de log "Basic" (moins cher, requêtes limitées)

Intégration avec Microsoft Defender XDR

Microsoft a unifié Sentinel et Defender XDR dans une console unifiée (Microsoft Unified SOC Platform). En activant l'intégration :

• Les incidents de Defender XDR apparaissent automatiquement dans Sentinel
• Les analystes travaillent dans une seule interface pour les incidents cross-workload
• Les capacités de chasse aux menaces (Threat Hunting) de Defender sont disponibles dans Sentinel via les tables Advanced Hunting
• Les playbooks SOAR Sentinel peuvent déclencher des actions Defender (isoler un endpoint, bloquer un fichier)

Conclusion

Microsoft Sentinel est un SIEM cloud-native puissant, particulièrement adapté aux organisations ayant déjà investi dans l'écosystème Microsoft. Son intégration native avec M365, Azure et la suite Defender en fait un choix naturel pour les PME françaises. CyberSecure accompagne le déploiement de Sentinel : architecture, connecteurs, règles de détection KQL personnalisées, playbooks SOAR, et formation des équipes SOC.