最終確認: 2026年5月
SC-200 試験の対象となる AWS サービスを、プレーンな Terraform を使用して構築します。1 ブロックずつ、それぞれ試験ドメインに関連付けられています。同じコードが OpenTofu でも動作します。
このラボを完了すると、プレーンなTerraformを使用して、SC-200 SOCリファレンス基盤(データプレーンとしてのLog Analyticsワークスペース、そのワークスペースにオンボードされたMicrosoft Sentinel、サンプルのKQLパターンでインシデントをトリガーするスケジュールされた分析ルール、およびインシデントが作成されるたびに実行される自動化ルール)をプロビジョニングできます。これは、あらゆるSC-200のハンティング + レスポンスワークフローが実行される基盤です。
これらのスニペットを単一の main.tf にドロップし、terraform init を実行してから、terraform apply をステップバイステップで実行してください。
>= 1.5 または OpenTofu >= 1.6。az login)。destroyが正しく機能します。Sentinelの料金体系が主なコストの要因です。
ラボのデータ量では約$0/月です。Sentinelは大規模になると高価になります — 複数サーバーのCloudTrail相当(Defender XDRコネクタ、M365コネクタ)をオンボーディングすると、実際の組織では簡単に月額$10,000に達します。
標準的な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はLog Analyticsワークスペースの上の層であり、独自のデータプレーンを持っていません。SC-200の「Microsoft Sentinel環境の管理」ドメインは、この依存関係を強調しています。Sentinelのすべての機能はワークスペースから読み書きし、すべてのデータコネクタはデータを受け入れ、すべての分析ルールはそれに対してKQLを実行します。
Log AnalyticsワークスペースをPerGB2018 SKUでプロビジョニングし、azurerm_sentinel_log_analytics_workspace_onboarding リソースを使用してSentinelをアタッチします。この後、データソース(Azure Activity、Microsoft Entra IDサインイン、Defender XDRコネクタ)をポータル経由で接続します — これらはカバー範囲が広く、TerraformよりもGUIの方が簡単です。
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
}分析ルールは、Sentinelが生のログイベントをインシデントに変換する方法です。SC-200では、ルールタイプの認識がテストされます:スケジュール済み(KQLベース、最も一般的)、Microsoftインシデント(Defender XDRアラートを転送)、異常(MLベース)、脅威インテリジェンス(TIマッチング)。
スタブKQLクエリ(5分ごとに、過去5分間を遡る — SC-200のニアリアルタイムの形式)を持つスケジュールされたルールを作成します。ここでのクエリはプレースホルダー(SecurityEvent | take 1)です。本番環境では、KQLがルールの実際のロジック(ありえない移動のログイン、パスワードスプレーパターン、異常な特権昇格などのテスト)になります。
tacticsフィールドは、ルールをMITRE ATT&CKフレームワークにマッピングします — これはDefender XDR統合や戦術でピボットするハンティングワークフローに必要です。
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]
}自動化ルールは、SC-200の「インシデント管理のためにMicrosoft Sentinel環境を構成する」というプリミティブです。これらはインシデントが作成、更新、またはクローズされたときにトリガーされ、一連のアクション(インシデントをユーザーに割り当てる、重大度を変更する、タグを追加する、Logic Appプレイブックを呼び出す)を実行します。
いずれかのインシデントが作成されるたびに実行されるルールを作成します。この例のアクションは、重大度を「高」に変更し、インシデントにタグを付けるだけです。本番環境では、Teamsへの投稿、Jiraチケットの作成、脅威インテリジェンスによるエンリッチ、または修復ランブックのトリガーを行うLogic Appプレイブックをここで呼び出すことになります。SC-200は、このトリガーされる自動化の形式を標準的なL1 SOCパターンとしてテストします。
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 ですべてを削除します。Sentinelのオンボーディングはワークスペースからデタッチされます。ワークスペースは別途削除されるまで残ります(Terraformは両方を正しく処理します)。分析ルールの実行は直ちに停止します。Logic Appプレイブック(このラボではプロビジョニングされません)は、もし追加した場合は別途削除する必要があります。
SC-200は、このラボでは扱いきれないより多くのSecOps領域をカバーします — Microsoft Defender for Endpoint(エンドポイントEDR)、Defender for Identity(オンプレミスADの脅威)、Defender for Office 365(メールフロー保護)、Defender for Cloud Apps(CASB)、完全なDefender XDR統合ポータル、詳細なKQLハンティング、Microsoft Sentinelデータコネクタ(Azure Activity、M365、AWS CloudTrail、GCP Audit、サードパーティコネクタ)、ダッシュボード用のSentinel Workbooks、脅威インテリジェンスインジケーター、ウォッチリスト、ユーザーおよびエンティティ行動分析(UEBA)、高度なハンティング用Notebooks、レスポンスオーケストレーション用Logic Appプレイブックなどです。
このラボではワークスペース + Sentinel + スケジュールされたルール + 自動化ルールに限定します。なぜなら、これらがすべてのSC-200パターンが構成される基盤だからです。データコネクタはワークスペースにデータを供給し、分析ルールはデータをクエリし、自動化ルールはインシデントに対応し、プレイブック(Logic Apps)は自動化ルールを拡張します。基本を正しく理解し、データソースごとにレイヤーを追加してください。
上記の領域については、この認定ページにある閲覧、プレイブック、Editorialセクションを参照してください。