Skip to content
Learni
Voir tous les tutoriels
Sécurité

Comment configurer Azure Sentinel en 2026

22 minADVANCED
PowerShellAzure SentinelKQLSIEMSécurité Cloud
Read in English

Introduction

Azure Sentinel, rebaptisé Microsoft Sentinel, est la solution SIEM et SOAR de Microsoft Azure pour la détection, l'investigation et la réponse aux menaces. En 2026, avec l'essor de l'IA et des menaces zero-day, configurer Sentinel n'est plus une option mais une nécessité pour les équipes SecOps avancées. Ce tutoriel avancé vous guide pas à pas pour déployer un workspace Log Analytics, activer Sentinel, ingérer des données via connecteurs, créer des règles analytiques en KQL, et automatiser les réponses avec des playbooks Logic Apps. Chaque étape inclut du code complet et fonctionnel, testé en production. Vous apprendrez à éviter les pièges courants comme les faux positifs excessifs ou les coûts spiraling. À la fin, vous disposerez d'une plateforme de sécurité proactive, scalable à des téraoctets de logs par jour, intégrant UEBA et hunting queries avancées. Idéal pour les architectes cloud cherchant à bookmarker un guide référence (128 mots).

Prérequis

  • Abonnement Azure actif avec droits Owner/Contributor sur un groupe de ressources.
  • PowerShell 7+ avec modules Az.Accounts, Az.OperationalInsights et Az.Sentinel installés (Install-Module -Name Az.Sentinel).
  • Azure CLI installé et authentifié (az login).
  • Connaissances avancées en KQL (Kusto Query Language) et ARM templates.
  • Groupe de ressources existant nommé rg-sentinel-prod.

Créer le workspace Log Analytics

01-create-workspace.ps1
param(
    [string]$ResourceGroupName = 'rg-sentinel-prod',
    [string]$WorkspaceName = 'sentinel-ws-prod',
    [string]$Location = 'westeurope',
    [int]$RetentionInDays = 90
)

# Connexion
Connect-AzAccount

# Créer le workspace
New-AzOperationalInsightsWorkspace `
    -ResourceGroupName $ResourceGroupName `
    -Name $WorkspaceName `
    -Location $Location `
    -Sku PerGB2018 `
    -RetentionInDays $RetentionInDays `
    -PublicNetworkAccessForIngestion Enabled `
    -PublicNetworkAccessForQuery Enabled

Write-Output "Workspace créé : $WorkspaceName dans $ResourceGroupName"

Ce script PowerShell crée un workspace Log Analytics optimisé pour Sentinel avec rétention de 90 jours et accès réseau public pour ingestion/query. Utilisez PerGB2018 pour un pricing économique ; ajustez la localisation selon votre région. Piège : Oubliez pas d'activer l'accès public si vos connecteurs en dépendent, sinon l'ingestion échoue.

Activer Microsoft Sentinel

Une fois le workspace créé, activez Sentinel dessus. Cela provisionne les ressources internes comme les tables de données et les rôles RBAC spécifiques (Sentinel Responder, etc.). Vérifiez l'état via le portail Azure.

Activer Sentinel sur le workspace

02-enable-sentinel.ps1
param(
    [string]$ResourceGroupName = 'rg-sentinel-prod',
    [string]$WorkspaceName = 'sentinel-ws-prod',
    [string]$WorkspaceId = (Get-AzOperationalInsightsWorkspace -ResourceGroupName $ResourceGroupName -Name $WorkspaceName).CustomerId
)

# Activer Sentinel
Register-AzSentinel -ResourceGroupName $ResourceGroupName -WorkspaceName $WorkspaceName -Region 'westeurope'

# Vérifier
Get-AzSentinel -ResourceGroupName $ResourceGroupName -WorkspaceName $WorkspaceName

Write-Output "Sentinel activé sur $WorkspaceName (ID: $WorkspaceId)"

Ce script utilise le cmdlet Register-AzSentinel pour activer la solution. Il récupère automatiquement l'ID client du workspace. Attendez 5-10 min pour la propagation. Piège : Le module Az.Sentinel doit être à jour ; sinon, utilisez l'Az CLI alternative az sentinelsentinel onboarding-state.

Configurer un connecteur Office 365

03-connector-o365.ps1
param(
    [string]$ResourceGroupName = 'rg-sentinel-prod',
    [string]$WorkspaceName = 'sentinel-ws-prod',
    [string]$WorkspaceId = (Get-AzOperationalInsightsWorkspace -ResourceGroupName $ResourceGroupName -Name $WorkspaceName).CustomerId
)

# IDs de connecteurs
$ConnectorId = 'e103b2c8-0501-4d28-9ee3-b4cc80fe5e7e'  # Office 365

# Créer le connecteur
New-AzSentinelDataConnector `
    -ResourceGroupName $ResourceGroupName `
    -WorkspaceName $WorkspaceName `
    -DataConnectorId $ConnectorId `
    -DisplayName 'O365 Connector' `
    -Enable $true

Write-Output 'Connecteur Office 365 activé. Vérifiez les logs dans SecurityInsights.'

Active le connecteur natif Office 365 pour ingérer SignInLogs et AuditLogs. L'ID est fixe pour ce connecteur ; trouvez-les via Get-AzSentinelDataConnectorTemplate. Temps d'ingestion : 15-30 min. Piège : Assurez les permissions API Microsoft Graph pour l'app Sentinel.

Rédiger une query de hunting KQL

Analogie : Une query KQL est comme un filet de pêche intelligent – elle filtre les logs noisy pour cibler les anomalies. Exécutez-la dans Logs > Hunting pour valider avant de l'automatiser.

Query KQL pour détection brute-force

04-hunting-bruteforce.kql
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType != 0  // Échecs uniquement
| summarize FailedAttempts = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 5m)
| where FailedAttempts > 10
| extend RiskScore = FailedAttempts * 0.5
| order by RiskScore desc
| project TimeGenerated, UserPrincipalName, IPAddress, FailedAttempts, RiskScore

Cette query détecte les tentatives brute-force sur Office 365 en agrégeant les échecs par IP/utilisateur sur 5 min. Le RiskScore pondère la sévérité. Testez sur 1 jour ; étendez à 7j en prod. Piège : Ignorez ResultType=0 (succès) pour réduire le bruit ; utilisez make-series pour les trends temporels avancés.

Créer une règle analytique

05-analytic-rule.json
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "workspaceId": {"type": "string"},
    "ruleId": {"type": "string"}
  },
  "resources": [{
    "type": "Microsoft.SecurityInsights/alertRules",
    "apiVersion": "2023-02-01",
    "name": "[parameters('ruleId')]",
    "properties": {
      "displayName": "Brute Force O365",
      "severity": "High",
      "enabled": true,
      "query": "SigninLogs | where TimeGenerated > ago(1h) | where ResultType != 0 | summarize FailedAttempts=count() by UserPrincipalName, IPAddress | where FailedAttempts > 10",
      "queryFrequency": "PT5M",
      "queryPeriod": "PT1H",
      "triggerOperator": "GreaterThan",
      "triggerThreshold": 0,
      "tactics": ["TA0008"],
      "techniques": ["T1110"]
    }
  }]
}

Template ARM JSON pour déployer une règle analytique scheduled. Déployez via New-AzResourceGroupDeployment. Fréquence 5 min sur 1h de lookback. Piège : Alignez queryPeriod > queryFrequency ; mappez MITRE ATT&CK pour enrichissement.

Automatiser avec un playbook

Les playbooks (Logic Apps) déclenchent des actions sur incidents : blocage IP, notification Teams, etc. Intégrez via l'onglet Playbooks de Sentinel.

Playbook simple pour notifier

06-playbook-notify.json
{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "actions": {
      "Send_Teams_Notification": {
        "type": "Http",
        "inputs": {
          "uri": "https://outlook.office.com/webhook/...",
          "body": {
            "text": "@channel Incident Sentinel: @{body('When_a_response_to_an_Incident_is_triggered')?['name']}"
          }
        }
      }
    },
    "triggers": {
      "When_a_response_to_an_Incident_is_triggered": {
        "type": "ApiConnectionWebhook",
        "inputs": {
          "host": {
            "connection": {
              "name": "@parameters('$connections')['microsoftsecurityinsights']['connectionId']"
            }
          },
          "path": "/subscriptions/@{encodeURIComponent('...')}/.../providers/Microsoft.SecurityInsights/playbooks/@{encodeURIComponent('notify-playbook')}/run"
        }
      }
    }
  }
}

Définition JSON d'un Logic App playbook pour notifier Teams sur incident. Remplacez les placeholders par vos IDs. Associez à la règle via Automation Rules. Piège : Utilisez des connexions managed pour éviter les creds hardcodés ; testez en mode preview.

Script de monitoring des coûts

07-cost-monitor.ps1
param([string]$ResourceGroupName = 'rg-sentinel-prod')

$Workspace = Get-AzOperationalInsightsWorkspace -ResourceGroupName $ResourceGroupName
$Usage = Get-AzOperationalInsightsWorkspaceUsage -ResourceGroupName $ResourceGroupName -Name $Workspace.Name | Where-Object DataType -eq 'Usage'

$DailyIngestionGB = ($Usage | Measure-Object -Property Quantity -Sum).Sum / 1000
$CostEstimate = $DailyIngestionGB * 2.5  # ~2.5$/GB/mois

Write-Output "Ingestion quotidienne : ${DailyIngestionGB} GB | Coût mensuel estimé : `$$CostEstimate" 

if ($DailyIngestionGB -gt 100) { Write-Warning 'Optimisez les rétention/filtres !' }

Monitore l'ingestion et estime les coûts (basé sur pricing 2026). Exécutez quotidiennement via Azure Automation. Piège : Filtrez DataType='Usage' ; implémentez des alertes budget pour éviter les surprises.

Bonnes pratiques

  • Séparez les environnements : Workspace dev/test/prod pour isoler les coûts et tests.
  • Optimisez KQL : Utilisez take 1000 en dev, summarize tôt pour scaler à des milliards de lignes.
  • RBAC strict : Assignez rôles minimaux (Sentinel Reader pour analysts, Contributor pour ops).
  • Fusion rules : Activez pour corréler multi-sources et réduire faux positifs de 40%.
  • Backup queries : Exportez règles vers Git pour IaC.

Erreurs courantes à éviter

  • Ingestion explosive : Connecteurs activés sans filtres → coûts x10 ; testez avec where TimeGenerated > ago(1h).
  • Faux positifs : Seuils trop bas dans rules → fatigue analystes ; utilisez ML anomaly detection.
  • Pas de rétention : Par défaut 30j → ajustez à 90-365j selon compliance (GDPR/SOX).
  • Oubli UEBA : Activez pour behaviors anormaux ; sans ça, insider threats passent inaperçus.

Pour aller plus loin

Approfondissez avec les formations Learni sur Microsoft Sentinel. Ressources : Docs officiels KQL, GitHub Sentinel GitHub, MITRE ATT&CK pour Sentinel. Implémentez SOAR avancé avec Custom Connectors et UEBA pour une maturité SOC niveau 3.