Dernière révision : mai 2026
Configurez les services AWS figurant à l'examen SC-200 avec Terraform simple — un bloc à la fois, chacun étant lié à un domaine de l'examen. Le même code fonctionne sur OpenTofu.
À la fin de ce labo, vous aurez provisionné, avec du Terraform simple, le substrat de référence SOC SC-200 — un espace de travail Log Analytics comme plan de données, Microsoft Sentinel intégré à cet espace de travail, une règle d'analyse planifiée qui déclenche un incident sur un modèle KQL exemple, et une règle d'automatisation qui s'exécute à chaque création d'incident. C'est le substrat sur lequel s'exécute chaque flux de travail de chasse + réponse SC-200.
Déposez les extraits dans un unique fichier main.tf, exécutez terraform init, puis terraform apply étape par étape.
>= 1.5 ou OpenTofu >= 1.6.az login).terraform destroy fonctionne correctement via Terraform.La tarification de Sentinel est la principale considération de coût :
Environ 0 $/mois au volume du labo. Sentinel devient coûteux à l'échelle — l'intégration d'un équivalent CloudTrail multi-serveurs (connecteurs Defender XDR, connecteurs M365) peut facilement atteindre 10 000 $/mois pour une organisation réelle.
Début standard Azure.
terraform {
required_version = ">= 1.5"
required_providers {
azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
}
}
provider "azurerm" {
features {}
}
locals {
tags = {
Project = "certlabpro-sc-200"
ManagedBy = "terraform"
}
}
resource "azurerm_resource_group" "main" {
name = "certlabpro-sc-200-rg"
location = "eastus"
tags = local.tags
}Microsoft Sentinel est une couche au-dessus d'un espace de travail Log Analytics — il n'a pas son propre plan de données. Le domaine Gérer un environnement Microsoft Sentinel du SC-200 insiste sur cette dépendance : chaque fonctionnalité Sentinel lit/écrit depuis l'espace de travail, chaque connecteur de données y dépose des données, chaque règle d'analyse exécute du KQL contre celui-ci.
Nous provisionnons l'espace de travail avec le SKU PerGB2018 + la ressource azurerm_sentinel_log_analytics_workspace_onboarding pour attacher Sentinel. Après cela, vous connecteriez des sources de données (Activité Azure, connexions Microsoft Entra ID, connecteurs Defender XDR) via le portail — elles sont complexes en termes de surface et plus faciles à gérer via l'interface graphique que via Terraform.
resource "azurerm_log_analytics_workspace" "main" {
name = "log-sc200"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
sku = "PerGB2018"
retention_in_days = 30
tags = local.tags
}
resource "azurerm_sentinel_log_analytics_workspace_onboarding" "main" {
workspace_id = azurerm_log_analytics_workspace.main.id
}Les règles d'analyse sont la manière dont Sentinel transforme les événements de journal bruts en incidents. Le SC-200 teste la reconnaissance des types de règles : Planifiée (basée sur KQL, la plus courante), Incident Microsoft (transmet les alertes Defender XDR), Anomalie (basée sur le ML), Renseignement sur les menaces (correspondance TI).
Nous créons une règle planifiée avec une requête KQL factice (toutes les 5 minutes, en remontant sur 5 minutes — la forme quasi-temps réel du SC-200). La requête ici est un espace réservé (SecurityEvent | take 1) ; en production, le KQL est la logique réelle de la règle — testant les connexions de voyage impossible, les modèles d'attaques par pulvérisation de mots de passe, les escalades de privilèges inhabituelles, etc.
Le champ tactics mappe la règle au framework MITRE ATT&CK — requis pour l'intégration de Defender XDR et pour les flux de travail de chasse qui pivotent par tactique.
resource "azurerm_sentinel_alert_rule_scheduled" "stub" {
name = "certlabpro-sc-200-stub-rule"
log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
display_name = "Stub rule — lab demonstration"
description = "Sample scheduled analytic rule for the SC-200 lab. Replace KQL with a real hunting pattern."
severity = "Medium"
enabled = true
query = "SecurityEvent | take 1"
query_frequency = "PT5M" # run every 5 minutes
query_period = "PT5M" # look back 5 minutes
trigger_operator = "GreaterThan"
trigger_threshold = 0
tactics = ["InitialAccess"]
techniques = ["T1078"] # Valid Accounts (MITRE ATT&CK)
incident {
create_incident_enabled = true
grouping {
enabled = true
}
}
depends_on = [azurerm_sentinel_log_analytics_workspace_onboarding.main]
}Les règles d'automatisation sont la primitive du SC-200 pour Configurer votre environnement Microsoft Sentinel pour la gestion des incidents — elles se déclenchent lorsqu'un incident est créé, mis à jour ou fermé, et exécutent un ensemble d'actions : assigner l'incident à un utilisateur, changer sa gravité, ajouter des étiquettes ou invoquer un playbook Logic App.
Nous créons une règle qui s'exécute à chaque création d'incident. L'action d'exemple change simplement la gravité à Élevée et étiquette l'incident — en production, vous invoqueriez ici un playbook Logic App qui publierait sur Teams, créerait un ticket Jira, enrichirait avec des informations sur les menaces ou déclencherait un runbook de remédiation. Le SC-200 teste cette forme d'automatisation déclenchée comme le modèle SOC L1 standard.
resource "azurerm_sentinel_automation_rule" "tag_and_escalate" {
name = "0e84e57b-8b8a-4c8b-a0a8-1d3f3e6f9a01" # GUID required
log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
display_name = "Tag-and-escalate every new incident"
order = 1
enabled = true
triggers_on = "Incidents"
triggers_when = "Created"
action_incident {
order = 1
severity = "High"
}
action_incident {
order = 2
labels = ["lab-auto-tagged"]
}
depends_on = [azurerm_sentinel_log_analytics_workspace_onboarding.main]
}terraform destroy supprime tout. L'intégration de Sentinel se détache de l'espace de travail ; l'espace de travail reste jusqu'à ce qu'il soit détruit séparément (Terraform gère correctement les deux). Les exécutions des règles d'analyse s'arrêtent immédiatement. Les playbooks Logic App (non provisionnés dans ce labo) devraient être détruits séparément si vous les aviez ajoutés.
Le SC-200 couvre davantage de surfaces SecOps que ce labo ne peut contenir — Microsoft Defender for Endpoint (l'EDR de point de terminaison), Defender for Identity (menaces AD sur site), Defender for Office 365 (protection du flux de courrier), Defender for Cloud Apps (CASB), le portail unifié complet de Defender XDR, la chasse KQL approfondie, les connecteurs de données Microsoft Sentinel (Azure Activity, M365, AWS CloudTrail, GCP Audit, connecteurs tiers), les classeurs Sentinel pour la création de tableaux de bord, les indicateurs de renseignement sur les menaces, les listes de surveillance, l'analyse du comportement des utilisateurs et des entités (UEBA), les notebooks pour la chasse avancée et les playbooks Logic App pour l'orchestration de la réponse.
Nous nous en tenons à l'espace de travail + Sentinel + règle planifiée + règle d'automatisation car ils constituent le substrat sur lequel se compose chaque modèle SC-200. Les connecteurs de données déposent les données dans l'espace de travail ; les règles analytiques interrogent les données ; les règles d'automatisation répondent aux incidents ; les playbooks (Logic Apps) étendent les règles d'automatisation. Maîtrisez la base ; puis ajoutez des couches par source de données.
Pour les surfaces mentionnées ci-dessus, consultez les sections Parcourir, Guide et Editorial de cette page de certification.