SC-200完全ガイド（後編）：Microsoft Security Operations Analyst試験対策2026 - インシデント対応・脅威管理から合格戦略まで

はじめに

前編はこちら: SC-200完全ガイド（前編）：試験概要からセキュリティ運用環境・保護設定まで

本記事（後編）では、SC-200試験の最重要セクションである**インシデント対応の管理（25-30%）とセキュリティ脅威の管理（15-20%）**を詳しく解説します。さらに、KQL実践テクニック、効率的な学習方法、試験当日の攻略法まで網羅します。

3-2-3. Microsoft Sentinelでの検出の構成（続き）

エンティティを使用したデータの分類と分析

エンティティとは

エンティティは、アラートやインシデントに関連する具体的なオブジェクト（ユーザー、デバイス、IPアドレス、ファイルなど）を指します。

主要なエンティティタイプ

エンティティマッピングの実装

// カスタム分析ルールでのエンティティマッピング
SecurityEvent
| where EventID == 4625  // ログイン失敗
| where TimeGenerated > ago(1h)
| summarize FailureCount = count() by Account, IpAddress, Computer
| where FailureCount > 5
| extend
    AccountEntity = pack("Type", "Account", "Name", Account),
    IPEntity = pack("Type", "IP", "Address", IpAddress),
    HostEntity = pack("Type", "Host", "HostName", Computer)

エンティティ行動分析（Entity Behavior Analytics）

Sentinelは、エンティティの通常行動をベースラインとして学習し、異常を検出します。

分析例

ユーザーエンティティ: [email protected]
ベースライン:
- 通常ログイン時間: 9:00-18:00
- 通常ログイン場所: 東京
- 通常アクセスリソース: SharePoint, Exchange

異常検出:
- 深夜3:00にログイン（時間の異常）
- ログイン元: 中国（場所の異常）
- Azure Key Vaultへの初回アクセス（リソースの異常）
→ リスクスコア: High

分析ルールの構成と管理

分析ルールのタイプ

スケジュールクエリルールの詳細設計

1. クエリロジックの設計

// 例: ブルートフォース攻撃検出
SigninLogs
| where TimeGenerated > ago(5m)
| where ResultType != "0"  // ログイン失敗
| summarize
    FailureCount = count(),
    TargetAccounts = make_set(UserPrincipalName),
    SourceIPs = make_set(IPAddress)
    by bin(TimeGenerated, 5m)
| where FailureCount > 10
| extend Severity = case(
    FailureCount > 50, "High",
    FailureCount > 20, "Medium",
    "Low"
)

2. スケジュール設定

クエリスケジュールのパターン

【パターン1: リアルタイム検出】
頻度: 5分
ルックバック: 5分
用途: 緊急度の高い脅威（ランサムウェア、データ漏洩）

【パターン2: 通常検出】
頻度: 1時間
ルックバック: 1時間
用途: 一般的な脅威（ブルートフォース、スキャン）

【パターン3: バッチ検出】
頻度: 24時間
ルックバック: 24時間
用途: トレンド分析、統計的異常検出

3. アラート詳細の設計

【優れたアラート設計の要素】
- アラート名: 具体的で理解しやすい
  ❌ "Suspicious activity"
  ✅ "Brute force attack against Azure AD from China"

- 説明: 何が起きたか、なぜ重要か
  "10 failed login attempts from IP 203.0.113.50 (China) targeting [email protected] within 5 minutes"

- MITRE ATT&CK: 該当する戦術・技術
  Tactic: Credential Access
  Technique: T1110 - Brute Force

- 重大度: 影響度とビジネスコンテキスト
  High: 特権アカウント、重要システム
  Medium: 一般ユーザー、標準システム
  Low: テスト環境、低リスクアセット

4. アラートグルーピングの設定

グルーピング戦略:
- アカウントごとにグループ化:
  同一アカウントへの複数攻撃を1つのインシデントに

- タイムウィンドウ: 24時間
  24時間以内の関連アラートをグループ化

- 再オープン: 解決済みインシデントに新規アラートが発生した場合

ASIMパーサーを使用したMicrosoft Sentinelデータのクエリ

ASIM（Advanced Security Information Model）とは

ASIMは、異なるデータソースのログを統一されたスキーマに正規化し、ベンダー非依存のクエリを可能にするフレームワークです。

ASIMのメリット

【従来の課題】
Palo Altoのログ: src_ip
Fortinetのログ: srcip
Cisco ASAのログ: sourceAddress
→ ベンダーごとに異なるフィールド名

【ASIMによる解決】
全てのファイアウォールログ: SrcIpAddr（統一）
→ 1つのクエリで全ベンダーのログを分析可能

主要なASIMスキーマ

ASIM使用例

従来のクエリ（ベンダー固有）

// Palo Alto���み対象
CommonSecurityLog
| where DeviceVendor == "Palo Alto Networks"
| where SourceIP == "203.0.113.50"
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort

ASIMクエリ（全ベンダー対応）

// 全ファイアウォールベンダー対象
imNetworkSession
| where SrcIpAddr == "203.0.113.50"
| project TimeGenerated, SrcIpAddr, DstIpAddr, DstPortNumber, NetworkApplicationProtocol

カスタムログのASIM対応

// カスタムファイアウォールログをASIMに変換するパーサー関数
let CustomFirewallParser = () {
    CustomFirewallLog_CL
    | extend
        TimeGenerated = todatetime(EventTime_s),
        SrcIpAddr = SourceAddress_s,
        DstIpAddr = DestinationAddress_s,
        DstPortNumber = toint(DestPort_d),
        NetworkProtocol = Protocol_s,
        EventResult = iff(Action_s == "allow", "Success", "Failure"),
        DvcHostname = FirewallName_s
    | project-away *_s, *_d  // 元のフィールドを削除
};
CustomFirewallParser

ASIMベストプラクティス

1. 既存のASIMパーサーを活用

   • Content Hubからインストール
   • カスタマイズは必要最小限に

2. クエリにはASIM関数を使用

   // ❌ 直接テーブルクエリ
   CommonSecurityLog | where ...
   
   // ✅ ASIM関数使用
   imNetworkSession | where ...
   

3. カスタムログもASIM準拠に

   • 将来的なベンダー変更に対応可能
   • 分析ルールの再利用性向上

行動分析の実装

UEBA（User and Entity Behavior Analytics）の仕組み

ベースライン学習の要素

UEBA有効化手順

1. Sentinel > Entity behavior を開く
2. 「Settings」をクリック
3. データソースを選択:
   - Azure Active Directory
   - Office 365
   - Azure Activity
4. 「Apply」をクリック
5. 学習期間: 14日間（最低）

行動分析ベースの検出ルール例

// 異常なファイルダウンロード検出
BehaviorAnalytics
| where TimeGenerated > ago(1h)
| where ActivityType == "FileDownload"
| where InvestigationPriority > 5  // 優先度スコア（1-10）
| extend
    Baseline = UserBaseline.AvgFileDownloadCount,
    Current = ActivityCount,
    Deviation = (ActivityCount - UserBaseline.AvgFileDownloadCount) / UserBaseline.StdDevFileDownloadCount
| where Deviation > 3  // 標準偏差の3倍以上
| project TimeGenerated, UserPrincipalName, ActivityCount, Baseline, Deviation, SourceIPAddress

UEBAアラートの調査

インシデント画面 > Entity タブ
↓
ユーザーエンティティをクリック
↓
表示情報:
- タイムライン: 全アクティビティの時系列表示
- Insights: AIが特定した異常パターン
- 関連アラート: 同一ユーザーの他のアラート
- Peer分析: 同じ部門の他ユーザーとの比較

3-3. インシデント対応の管理（25-30%）★最重要セクション

このセクションは最も配点が高く（25-30%）、実践的なスキルが問われます。

3-3-1. Microsoft Defenderポータルでのアラートとインシデントへの対応

Microsoft Defender for Office 365を使用した脅威の調査と修復

フィッシングメール調査のワークフロー

【Step 1: アラート確認】
Defender Portal > Incidents & alerts > Incidents
↓
【Step 2: メールエンティティの詳細確認】
- 送信者アドレス（実際のアドレス vs 表示名）
- 件名、本文、添付ファイル
- 配信場所（受信トレイ、迷惑メール、隔離）
- 受信者数
↓
【Step 3: 脅威インテリジェンス確認】
- URLレピュテーション
- 添付ファイルのマルウェアスキャン結果
- 送信者ドメインのSPF/DKIM/DMARC検証結果
↓
【Step 4: 影響範囲の特定】
- 同じ送信者からの他のメール
- 同じURLを含む他のメール
- ユーザーがクリック・開封したか
↓
【Step 5: 修復アクション】
- メールの削除（ソフト削除/ハード削除）
- ユーザーへの通知
- URLブロックリスト追加
- 送信者ドメインのブロック

脅威エクスプローラー（Threat Explorer）の活用

検索クエリ例

【1. 特定送信者からの全メールを検索】
Sender domain: evil.com
Time range: Last 7 days
→ 配信されたメール数、隔離数、ユーザークリック数を確認

【2. 特定URLを含む全メールを検索】
URL: http://phishing-site.com
→ 影響を受けたユーザーを特定

【3. マルウェア添付ファイルの伝播調査】
Malware family: Emotet
→ 感染経路と拡散範囲を追跡

修復アクション

一括修復の手順

1. Threat Explorer で脅威メールを検索
2. 対象メールを選択（最大1000件）
3. 「Actions」 > 「Move to deleted items」または「Hard delete」
4. 修復ジョブの進行状況を確認
5. アクションログで結果を検証

自動攻撃中断で特定されたランサムウェアとBECインシデント

自動攻撃中断（Automatic Attack Disruption）の動作

ランサムウェア攻撃の検出と中断

【検出シグナル】
1. 大量のファイル暗号化（DeviceFileEvents）
2. ランサムウェアプロセスの実行（DeviceProcessEvents）
3. ボリュームシャドウコピーの削除（vssadmin.exe delete shadows）
4. バックアップサービスの停止
↓
【AI分析】
複数シグナルの相関分析 → ランサムウェア攻撃と判定
↓
【自動中断アクション】
- 感染デバイスのネットワーク隔離
- 悪意のあるプロセスの停止
- ユーザーアカウントの無効化（侵害された場合）
- C2（Command and Control）サーバーへの通信ブロック

BEC（Business Email Compromise）攻撃の検出と中断

【検出シグナル】
1. 異常な場所からのログイン（Impossible travel）
2. 受信トレイルール作成（メールの自動転送・削除）
3. 大量のメール送信
4. 送金依頼メールの送信
↓
【AI分析】
攻撃チェーンの特定
↓
【自動中断アクション】
- 侵害されたアカウントのサインイン無効化
- 作成された受信トレイルールの削除
- 送信メールの隔離
- MFA（多要素認証）の強制

インシデント対応の実践例

ランサムウェアインシデントの対応

【初動対応（15分以内）】
1. 自動中断アクションの確認
   - 隔離されたデバイス数
   - 停止されたプロセス
   - 無効化されたアカウント

2. 影響範囲の特定
   - 感染デバイスの特��
   - 暗号化されたファイルの範囲
   - ラテラルムーブメントの有無

【封じ込め（30分以内）】
3. 追加の隔離措置
   - 同一ネットワークセグメントの高リスクデバイス
   - 侵害されたアカウントでアクセスされたデバイス

4. バックアップの確保
   - クリーンなバックアップの特定
   - オフラインバックアップの保護

【根絶（24時間以内）】
5. マルウェアの完全除去
   - Microsoft Defender Antivirusによるフルスキャン
   - 必要に応じてOSの再インストール

6. 初期侵入経路の特定と封鎖
   - フィッシングメール、脆弱性、RDP経由など

【復旧】
7. デバイスの復旧
   - バックアップからのリストア
   - アプリケーションの動作確認

8. アカウントの復旧
   - パスワードリセット
   - MFAの再登録

Microsoft Purview DLPポリシーで特定された侵害されたエンティティ

DLP（Data Loss Prevention）アラートの調査

典型的なDLP違反シナリオ

【シナリオ1: 機密情報の外部共有】
検出内容:
- ファイル: "Q4_Financial_Report.xlsx"
- 機密ラベル: 極秘
- アクション: 外部ユーザーとSharePointで共有
- ユーザー: [email protected]
- 共有先: [email protected]

調査ステップ:
1. 共有されたファイルの内容確認
2. ユーザーの意図確認（意図的 vs 誤操作）
3. 共有先の確認（正当な業務か）
4. 過去の類似行動の確認

修復アクション:
- ファイル共有の取り消し
- ファイルへのアクセス権削除
- ユーザーへのセキュリティ教育
- 必要に応じて人事部門へエスカレーション

DLP Alertの対応フロー

// DLPアラートの調査クエリ（Sentinel）
SecurityAlert
| where ProviderName == "Office 365"
| where AlertName has "DLP"
| extend
    UserPrincipalName = tostring(parse_json(ExtendedProperties)["User Account"]),
    FileName = tostring(parse_json(ExtendedProperties)["File Name"]),
    SensitivityLabel = tostring(parse_json(ExtendedProperties)["Sensitivity Label"])
| project TimeGenerated, AlertName, UserPrincipalName, FileName, SensitivityLabel, AlertSeverity

Microsoft Purview インサイダーリスクポリシーで特定された脅威

インサイダーリスクの検出パターン

調査ワークフロー

【Step 1: アラートトリアージ】
Purview Portal > Insider risk management > Alerts
- リスクスコア: 75/100（High）
- ユーザー: [email protected]
- リスクカテゴリ: Data theft
↓
【Step 2: ユーザーアクティビティの確認】
Activity explorer:
- 過去7日間で500個のファイルをダウンロード（通常の10倍）
- 大量のファイルを個人OneDriveに同期
- 人事システムにアクセス（通常はアクセスしない）
↓
【Step 3: コンテキスト情報の収集】
- 退職予定: 2週間後に退職申請済み
- アクセスしたファイル: 顧客リスト、製品ロードマップ
- 過去の行動: 初めての異常行動
↓
【Step 4: 対応判断】
高リスクと判定 → 即時対応が必要
↓
【Step 5: 修復アクション】
- アカウントの一時停止
- アクセス権の削除
- 法務・人事部門へのエスカレーション
- フォレンジック調査の実施

その他のMicrosoft統合サービスでのアラート対応

Microsoft Defender for Cloud ワークロード保護

VM侵害アラートの例

アラート: Suspicious PowerShell execution detected
重大度: High
説明: VM "WebServer01" でBase64エンコードされたPowerShellコマンドが実行されました

調査手順

// 該当VMの全PowerShellアクティビティを調査
DeviceProcessEvents
| where DeviceName == "WebServer01"
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has "EncodedCommand"
| project TimeGenerated, AccountName, ProcessCommandLine
| extend DecodedCommand = base64_decode_tostring(extract(@"-EncodedCommand\s+(\S+)", 1, ProcessCommandLine))

Microsoft Defender for Cloud Apps セキュリティリスク

異常なアプリアクティビティ

アラート: Mass download by a single user
ユーザー: [email protected]
アプリ: SharePoint Online
詳細: 1時間以内に200個のファイルをダウンロード（通常の20倍）

Microsoft Entra ID 侵害されたアイデンティティ

リスク検出タイプ

対応アクション

低リスク: MFAを要求
中リスク: パスワード変更を要求
高リスク: サインインをブロック

Microsoft Defender for Identity セキュリティアラート

ドメイン侵害アラートの例

アラート: Suspected DCSync attack (replication of directory services)
重大度: High
説明: ユーザー "[email protected]" がドメインコントローラーに対してDCSyncを実行し、
      パスワードハッシュをレプリケートしようとしました

対応手順

1. 該当アカウントの即時無効化
2. ドメインコントローラーのログ確認
3. 特権アカウントのパスワード変更
4. Kerberos TGT（チケット許可チケット）の無効化
5. フォレンジック調査

3-3-2. Microsoft Defender for Endpointで特定されたアラートとインシデントへの対応

デバイスタイムラインの調査

タイムライン調査の目的

• 初期侵入ベクトルの特定
• 攻撃の時系列把握
• ラテラルムーブメントの追跡
• データ持ち出しの検出

タイムライン表示の要素

Defender Portal > Devices > [デバイス選択] > Timeline

フィルタリング:
- イベントタイプ: Process, File, Network, Registry, Logon
- 時間範囲: 過去24時間、7日間、30日間、カスタム
- 重大度: High, Medium, Low, Informational

実践的な調査例

シナリオ: マルウェア感染の根本原因調査

【Step 1: 感染確認時刻を起点に遡る】
Timeline: 2026-01-01 14:35:22 - マルウェア検出
    ↓
【Step 2: 数分前のイベントを確認】
14:32:15 - FileCreated: C:\Users\john\Downloads\invoice.exe
14:32:18 - ProcessCreated: invoice.exe
14:32:20 - NetworkConnection: invoice.exe → 203.0.113.50:443
14:32:25 - ProcessCreated: powershell.exe (親: invoice.exe)
    ↓
【Step 3: ファイルのダウンロード元を特定】
14:31:50 - NetworkConnection: outlook.exe → mail.contoso.com
14:32:00 - FileCreated: invoice.zip (メール添付ファイル)
14:32:10 - FileCreated: invoice.exe (ZIPから展開)
    ↓
【結論】
初期侵入ベクトル: フィッシングメール（invoice.zipを含む）
実行ファイル: invoice.exe
C2サーバー: 203.0.113.50

タイムラインクエリ（Advanced Hunting）

// デバイスタイムライン全体を取得
DeviceEvents
| where DeviceName == "DESKTOP-ABC123"
| where Timestamp between (datetime(2026-01-01 14:00) .. datetime(2026-01-01 15:00))
| project Timestamp, ActionType, FileName, ProcessCommandLine, RemoteIP
| order by Timestamp asc

ライブレスポンスと調査パッケージ収集を含むデバイスアクション

ライブレスポンス（Live Response）とは

侵害されたデバイスに対して、リアルタイムでコマンドを実行し、フォレンジック調査を行う機能です。

ライブレスポンスのアクセス

Defender Portal > Devices > [デバイス選択] > ... > Initiate Live Response Session

利用可能なコマンド

実践的な調査フロー

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 1. 実行中プロセスの確認
> processes
[出力] PID: 1234, Name: suspicious.exe, User: SYSTEM

# 2. 該当プロセスのネットワーク接続確認
> connections
[出力] PID: 1234, Remote: 203.0.113.50:443, State: ESTABLISHED

# 3. 実行ファイルの情報取得
> fileinfo "C:\Windows\Temp\suspicious.exe"
[出力]
MD5: 5d41402abc4b2a76b9719d911017c592
SHA256: 6ca13d52ca70c883e0f0bb101e425a89e8624de51db2d2392593af6a84118090
Creation Time: 2026-01-01 14:32:15

# 4. ファイルの取得（フォレンジック分析用）
> getfile "C:\Windows\Temp\suspicious.exe"
[出力] File downloaded successfully to library

# 5. プロセスの停止
> remediate process 1234
[出力] Process terminated successfully

# 6. ファイルの隔離
> remediate file "C:\Windows\Temp\suspicious.exe"
[出力] File quarantined successfully

調査パッケージの収集

調査パッケージに含まれる情報

• Prefetch files（実行履歴）
• Registry hives（レジストリスナップショット）
• Event logs（イベントログ）
• Memory dump（メモリダンプ）※オプション
• Network capture（ネットワークキャプチャ）

収集手順

1. Defender Portal > Devices > [デバイス選択]
2. ... > Collect investigation package
3. パッケージ収集完了を待つ（5-30分）
4. Action center > Completed actions > [Download package]
5. ダウンロードしたZIPファイルを解析ツール（Autopsy、FTK等）で分析

その他のデバイスアクション

証拠およびエンティティの調査

証拠（Evidence）の種類

ファイル証拠の深掘り調査

Incident > Evidence and Response タブ > Files

ファイル詳細画面:
- ファイル名: invoice.exe
- SHA256: 6ca13d52...
- 署名: 署名なし（Unsigned）
- VirusTotal: 45/70 検出（Trojan.Generic）
- 初出現: 2026-01-01 14:32:15
- 出現デバイス数: 5台（感染拡大を示唆）

調査アクション

1. 「Go hunt」をクリック → Advanced Huntingで該当ファイルハッシュを検索
2. 「Deep analysis」をクリック → サンドボックス分析
3. 「Add indicator」をクリック → ファイルハッシュをブロックリストに追加

Deep Analysis（詳細分析）の活用

サンドボックス実行結果:
- ドロップされたファイル: C:\ProgramData\update.exe
- レジストリ変更: HKLM\...\Run に永続化
- ネットワーク接続: 203.0.113.50:443（C2サーバー）
- 実行されたコマンド:
  - whoami
  - net user
  - ipconfig /all
  - vssadmin delete shadows /all

3-3-3. Microsoft 365アクティビティの調査

統合監査ログ（Unified Audit Log）を使用した脅威調査

統合監査ログとは

Microsoft 365全体（Exchange、SharePoint、OneDrive、Teams、Azure AD等）のユーザーおよび管理者アクティビティを記録するログです。

アクセス方法

Microsoft Purview Portal > Audit > Search
または
PowerShell: Search-UnifiedAuditLog コマンドレット

主要なアクティビティタイプ

実践的な調査クエリ例

1. BEC攻撃調査: 受信トレイルール作成の検出

検索条件:
- Activities: New-InboxRule, Set-InboxRule
- Date range: Past 30 days
- Users: [All users] または [侵害された可能性のあるユーザー]

検索結果の分析:
- ルール名: "."（隠蔽を意図した名前）
- アクション: ForwardTo [email protected]
- 作成日時: 深夜3:00（異常な時間帯）

PowerShellでの検索

1
2
3
4
5
6

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
    -Operations "New-InboxRule","Set-InboxRule" -ResultSize 5000 |
    Select-Object -ExpandProperty AuditData |
    ConvertFrom-Json |
    Where-Object {$_.Parameters.ForwardTo -ne $null} |
    Select-Object CreationTime, UserId, ClientIPAddress, Parameters

2. データ持ち出し調査: 大量ファイルダウンロード

検索条件:
- Activities: FileDownloaded
- Date range: Past 7 days
- Users: [email protected]（退職予定者）

集計:
- ダウンロード数: 500個（通常の50倍）
- ダウンロードサイト: 顧客管理SharePoint、製品開発OneDrive

3. 特権昇格調査: 管理者ロール追加

1
2
3
4
5
6

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
    -Operations "Add member to role" -ResultSize 5000 |
    Select-Object -ExpandProperty AuditData |
    ConvertFrom-Json |
    Where-Object {$_.ModifiedProperties.Role_DisplayName -match "Admin"} |
    Select-Object CreationTime, UserId, ModifiedProperties

Content Searchを使用した脅威調査

Content Searchとは

Microsoft 365全体（メールボックス、SharePointサイト、Teamsチャット）から特定のコンテンツを検索し、証拠収集やeDiscoveryに活用する機能です。

アクセス方法

Microsoft Purview Portal > Content search > New search

検索の設計

1. フィッシングメールの全社検索

検索名: Phishing Campaign Investigation - Jan 2026
検索対象:
- All Exchange mailboxes

KQL クエリ:
from:[email protected] OR
subject:"Urgent: Verify your account" OR
received>=2026-01-01 AND received<=2026-01-02

結果:
- 150個のメールボックスで検出
- 合計200通のメール

アクション

1. Preview results（プレビュー）
2. Export results（証拠としてエクスポート）
3. Delete messages（全社から削除）※要注意

2. 機密情報漏洩調査

検索名: Confidential Data Leak Investigation
検索対象:
- Specific user: [email protected]
- All SharePoint sites
- All OneDrive accounts

KQL クエリ:
(filename:"confidential" OR filename:"secret") AND
(shared:external OR sharedwith:*@external.com)

結果:
- 外部共有された機密ファイル: 15個

3. インサイダー脅威調査

KQL クエリ:
from:[email protected] AND
to:[email protected] AND
hasattachment:true AND
sent>=2026-01-01

結果:
- 個人メールアドレスに送信された添付ファイル付きメール: 50通

Content Searchのベストプラクティス

• 段階的な絞り込み: 広い検索から始め、徐々に条件を追加
• 並列検索: 複数の検索を同時実行して効率化
• 権限管理: eDiscovery Managerロールを適切に割り当て
• 監査ログ: Content Search自体もログ記録される

Microsoft Graph アクティビティログを使用した脅威調査

Microsoft Graph アクティビティログとは

Microsoft Graph API経由でのアクセス（アプリケーション、スクリプト経由）を記録するログです。

調査が必要なシナリオ

• 不正なアプリによるデータアクセス
• 過剰な権限を持つアプリの検出
• APIを悪用した大量データ抽出

調査方法

1. Azure AD Sign-in Logsでのアプリ認証確認

SigninLogs
| where TimeGenerated > ago(7d)
| where AppDisplayName == "Suspicious App"
| summarize count() by UserPrincipalName, IPAddress, Location

2. Microsoft Graph アクティビティの確認

統合監査ログでの検索:
- Activities: ApplicationConsent
- Date range: Past 30 days

検出例:
- アプリ名: "Free PDF Converter"
- 要求された権限: Mail.Read, Files.Read.All, User.ReadBasic.All
- 同意したユーザー: [email protected]

3. アプリの権限確認

Azure Portal > Azure Active Directory > Enterprise applications
> [Suspicious App] > Permissions

過剰な権限の例:
- Mail.ReadWrite.All（全ユーザーのメール読み書き）
- Files.ReadWrite.All（全ファイル読み書き）
- Directory.ReadWrite.All（ディレクトリ全体の読み書き）

修復アクション

1. アプリの無効化:
   Azure AD > Enterprise applications > [App] > Properties > Enabled for users to sign-in? No

2. アプリの削除:
   Azure AD > Enterprise applications > [App] > Delete

3. 該当アプリでアクセスされたデータの確認:
   統合監査ログでApplicationIdでフィルタリング

3-3-4. Microsoft Sentinelでのインシデントへの対応

Microsoft Sentinelでのインシデントの調査と修復

Sentinelインシデント画面の構成

インシデント詳細画面:
├─ Overview: インシデント概要、タイムライン
├─ Entities: 関連エンティティ（ユーザー、デバイス、IP等）
├─ Evidence: アラート、ログエビデンス
├─ Investigation: 調査グラフ（関連性の可視化）
├─ Activity Log: インシデント対応履歴
└─ Comments: 調査メモ、チーム間コミュニケーション

調査ワークフロー

Step 1: トリアージ（優先度判定）

判定基準:
- 重大度: High/Medium/Low
- 影響範囲: 特権アカウント > 一般ユーザー
- アセット重要度: 本番環境 > 開発環境
- ビジネスインパクト: 顧客影響あり > 内部のみ

ステータス設定:
- New → Active（調査開始）
- Active → Resolved（解決済み）
- Active → Closed - False Positive（誤検知）

Step 2: Entitiesタブでの調査

例: ブルートフォース攻撃インシデント

エンティティ:
1. Account: [email protected]
   - リスクスコア: 8/10（High）
   - 異常行動: 深夜ログイン、海外からのアクセス
   - 関連アラート: 5件

2. IP Address: 203.0.113.50
   - 地理的位置: 中国
   - レピュテーション: 悪意のあるIP（Threat Intelligenceで確認）
   - 他の攻撃対象: 10アカウント

3. Host: なし（クラウドサービスへの攻撃）

Step 3: Investigationグラフでの関連性分析

グラフ表示:
[攻撃元IP: 203.0.113.50]
    ↓
[ログイン試行] → [Account 1] → [成功]
    ↓              [Account 2] → [失敗]
    ↓              [Account 3] → [失敗]
    ↓
[MFAチャレンジ] → [Account 1] → [バイパス成功？]
    ↓
[メール転送ルール作成]
    ↓
[外部メール送信]

調査の深掘り: ログクエリ

// 該当IPアドレスの全アクティビティ
union SigninLogs, OfficeActivity, AzureActivity
| where TimeGenerated > ago(7d)
| where IPAddress == "203.0.113.50"
| summarize Activities = make_set(Activity), count() by bin(TimeGenerated, 1h)
| render timechart

Step 4: 修復アクション

実行済みアクション:
1. アカウント無効化（自動プレイブックで実行済み）
2. MFAリセット
3. 作成された受信トレイルールの削除
4. 攻撃元IPのブロック（Firewallに追加）

追加アクション:
5. 同じIPからアクセスを受けた他のアカウントのパスワードリセット
6. セキュリティチームへのエスカレーション
7. インシデントレポートの作成

Step 5: インシデントクローズ

ステータス: Resolved - True Positive
分類: Initial Access - Valid Accounts
コメント:
"中国のIPアドレスからのブルートフォース攻撃により、[email protected]が侵害された。
自動プレイブックによりアカウントを無効化し、手動でMFAリセットと受信トレイルール削除を実施。
攻撃元IPをファイアウォールでブロック済み。
推奨: 全特権アカウントに条件付きアクセスポリシー（地理的制限）を適用"

オートメーションルールの作成と構成

オートメーションルールとは

インシデントが作成されたときに、自動的にアクションを実行するルールです。プレイブック（Logic Apps）よりも軽量で、トリアージに適しています。

主要なユースケース

1. 自動トリアージ

ルール名: Auto-Triage Low Severity Alerts
トリガー: インシデント作成時
条件:
- 重大度 = Low
- データソース = Microsoft Defender for Cloud
アクション:
- 所有者を割り当て: [email protected]
- タグを追加: "AutoTriaged"
- ステータスを変更: Active

2. 誤検知の自動クローズ

ルール名: Auto-Close Known False Positives
トリガー: ��ンシデント作成時
条件:
- アラート名に次を含む: "Suspicious PowerShell"
- アカウント名に次を含む: "BackupService"
アクション:
- ステータスを変更: Closed
- 分類: False Positive - Incorrect alert logic
- コメント追加: "Known false positive from backup service"

3. 高重大度アラートのエスカレーション

ルール名: Escalate High Severity Incidents
トリガー: インシデント作成時
条件:
- 重大度 = High
- エンティティに次を含む: VIPユーザーリスト
アクション:
- 所有者を割り当て: [email protected]
- プレイブック実行: Send-TeamsNotification
- タグを追加: "VIP", "Urgent"

4. 時間ベースのSLA管理

ルール名: SLA Reminder for Active Incidents
トリガー: インシデント更新時
条件:
- ステータス = Active
- 作成からの経過時間 > 4時間
アクション:
- コメント追加: "SLA Warning: This incident has been open for 4+ hours"
- タグを追加: "SLA-Risk"

オートメーションルールの設計パターン

【段階的オートメーション戦略】
レベル1: 自動タギング、所有者割り当て
    ↓
レベル2: 既知の誤検知の自動クローズ
    ↓
レベル3: 簡単な修復アクション（プレイブック実行）
    ↓
レベル4: 完全自動修復（高度なプレイブック）

Microsoft Sentinelプレイブックの作成と構成

プレイブック（Playbook）とは

Azure Logic Appsベースの自動化ワークフローで、複雑な修復アクションやエンリッチメントを実行します。

主要なコネクタ

プレイブック例1: 侵害されたアカウントの自動無効化

トリガー: Microsoft Sentinel incident
    ↓
[条件] インシデントタイトルに "Compromised account" を含む
    ↓ Yes
[Parse JSON] インシデントからAccountエンティティを抽出
    ↓
[Azure AD - Revoke sign-in sessions] サインインセッション無効化
    ↓
[Azure AD - Update user] AccountEnabled = false
    ↓
[Microsoft Sentinel - Add comment to incident]
コメント: "Account @{AccountUPN} has been disabled automatically"
    ↓
[Send email] セキュリティチームに通知

プレイブック例2: フィッシングメールの自動削除

トリガー: Microsoft Sentinel incident
    ↓
[条件] データソース = Microsoft Defender for Office 365
    ↓ Yes
[Parse JSON] インシデントからEmailエンティティを抽出
変数:
- Subject: @{EmailSubject}
- Sender: @{EmailSender}
    ↓
[Office 365 - Search messages]
検索クエリ: from:@{EmailSender} AND subject:"@{EmailSubject}"
    ↓
[For each] 検出されたメールごとに
    ↓
    [Office 365 - Delete message] ハード削除
    ↓
[Microsoft Sentinel - Update incident]
コメント: "Deleted @{MessagesCount} phishing emails from all mailboxes"

プレイブック例3: 脅威インテリジェンスエンリッチメント

トリガー: Microsoft Sentinel incident
    ↓
[Parse JSON] インシデントからIPエンティティを抽出
    ↓
[VirusTotal - Get IP report] IPレピュテーション取得
    ↓
[AbuseIPDB - Check IP] 悪用報告確認
    ↓
[変数] リスクスコア計算
RiskScore = (VTDetections * 10) + (AbuseIPDB_ConfidenceScore)
    ↓
[条件] RiskScore > 50
    ↓ Yes
    [Microsoft Sentinel - Update incident]
    - 重大度: High
    - タグ追加: "MaliciousIP"
    - コメント: "VirusTotal: @{VTDetections} detections, AbuseIPDB: @{AbuseScore}% confidence"

プレイブック設計のベストプラクティス

1. エラーハンドリング

各アクションに「Configure run after」を設定:
- Is successful
- Has failed → エラー通知アクションを実行
- Is skipped
- Has timed out

2. 並列実行

独立したアクション（VirusTotalとAbuseIPDBクエリ等）は並列実行して高速化

3. マネージドアイデンティティの使用

プレイブックからAzure ADやSentinelへのアクセスには、
接続情報のハードコードではなくマネージドアイデンティティを使用

4. プレイブックのテスト

1. テスト用インシデントを手動作成
2. プレイブックを手動実行
3. Run historyでエラーを確認
4. 本番適用

オンプレミスリソースでのプレイブック実行

オンプレミス統合の課題

Logic Appsはクラウドサービスのため、オンプレミスリソース（Active Directory、ファイルサーバー等）への直接アクセスができません。

解決方法: オンプレミスデータゲートウェイ

アーキテクチャ

Azure Logic Apps
    ↓ (HTTPS)
Azure Relay Service
    ↓ (アウトバウンド接続)
オンプレミスデータゲートウェイ（Windows Server）
    ↓ (ローカルネットワーク)
オンプレミスリソース（AD、SQL Server、ファイルサーバー）

構成手順

1. オンプレミスデータゲートウェイのインストール

1. Windows Server上でインストーラー実行
   https://aka.ms/on-premises-data-gateway
2. Azureテナントでサインイン
3. ゲートウェイ名、リカバリキーを設定
4. Azure Portalで接続を確認

2. Logic AppsでのコネクタPowershell設定

例: オンプレミスActive Directoryでユーザー無効化

トリガー: Microsoft Sentinel incident
    ↓
[Parse JSON] Accountエンティティ抽出
    ↓
[オンプレミスデータゲートウェイ - Run PowerShell script]
ゲートウェイ: OnPrem-Gateway-01
スクリプト:
Disable-ADAccount -Identity "@{AccountSAMAccountName}"
    ↓
[Microsoft Sentinel - Add comment]
コメント: "On-premises AD account @{AccountSAMAccountName} disabled"

セキュリティ考慮事項

• ゲートウェイサーバーはドメイン参加済みであること
• サービスアカウントに最小権限を付与
• ゲートウェイサーバーへのアクセスを制限
• ログ監視の実装

3-3-5. Microsoft Security Copilot活用（2026年1月更新で追加）

Microsoft Security Copilotとは

生成AIを活用したセキュリティ運用支援ツールで、自然言語でのクエリ、インシデント調査の自動化、脅威分析を支援します。

プロンプトブックの作成と使用

プロンプトブックとは

再利用可能なプロンプト（質問・コマンド）のテンプレート集です。

組み込みプロンプトブックの例

【インシデント調査プロンプトブック】
1. "Summarize incident <IncidentID>"
   → インシデントの概要を自然言語で生成

2. "Show me the attack timeline for this incident"
   → 攻撃の時系列を可視化

3. "What is the blast radius of this attack?"
   → 影響範囲を分析

4. "Suggest remediation actions"
   → 修復アクションを推奨

カスタムプロンプトブックの作成

プロンプト名: "Analyze phishing campaign"
プロンプト内容:
"Analyze the phishing campaign with sender {{SenderEmail}}.
1. How many users received the email?
2. How many users clicked the malicious link?
3. Were any accounts compromised?
4. What remediation actions have been taken?
5. Suggest additional actions to prevent similar attacks."

変数:
- {{SenderEmail}}: 送信者アドレス（ユーザー入力）

ソースの管理（プラグインとファイル）

プラグイン（Plugins）の種類

プラグインの有効化

Security Copilot > Sources > Plugins
↓
必要なプラグインを「Enable」
例:
- Microsoft Sentinel: 有効
- Microsoft Defender XDR: 有効
- VirusTotal: 有効

ファイルアップロード

ユースケース: カスタム脅威インテリジェンスの取り込み

アップロード手順:
1. Security Copilot > Sources > Files
2. 「Upload file」
3. ファイル形式: CSV, JSON, TXT
4. 例: IoC リスト（IPアドレス、ドメイン、ファイルハッシュ）

プロンプト例:
"Check if any of the IPs in the uploaded file have been seen in our environment in the past 30 days"

コネクタの実装による統合

サードパーティサービスとの統合

統合可能なサービス:
- SIEM/SOAR: Splunk、QRadar
- Threat Intelligence: Recorded Future、Anomali
- ITSM: ServiceNow、Jira
- Communication: Slack、Microsoft Teams

カスタムコネクタの作成例（ServiceNow統合）

目的: インシデント調査時に自動的にServiceNowチケットを作成

コネクタ設定:
1. Security Copilot > Sources > Connectors > Custom
2. API エンドポイント: https://instance.service-now.com/api/now/table/incident
3. 認証: OAuth 2.0
4. アクション定義:
   - Create Incident
   - Update Incident
   - Get Incident

プロンプト例:
"Create a ServiceNow ticket for this incident with priority P1"

権限とロールの管理

Security Copilotロール

データアクセス制御

Copilotは、ユーザーの既存の権限を尊重:
- Sentinelへのアクセス権がないユーザーは、Copilot経由でもSentinelデータにアクセス不可
- RBAC設定を適切に管理することが重要

容量とコストの監視

Security Copilot容量単位（SCU: Security Copilot Unit）

1 SCU = 1時間あたりの処理能力
料金: プロビジョニングされたSCU数に応じた従量課金

例:
- 小規模組織（10-50ユーザー）: 1-2 SCU
- 中規模組織（50-200ユーザー）: 3-5 SCU
- 大規模組織（200+ユーザー）: 5-10 SCU

使用状況の監視

Security Copilot > Settings > Usage
↓
表示情報:
- プロンプト実行数（日次、月次）
- SCU消費量
- ピーク使用時間帯
- ユーザー別使用状況

コスト最適化の戦略

1. プロンプトブックの活用で効率化
2. 不要なプラグインの無効化
3. ピーク時間帯以外の利用推奨
4. 大量データクエリの最適化

脅威とリスクの特定

Copilotを使用した脅威分析

プロンプト例

【1. IoC（侵害指標）の分析】
"Analyze the IP address 203.0.113.50. Is it malicious? Has it been seen in our environment?"

応答例:
"IP 203.0.113.50 is flagged as malicious by VirusTotal (45/70 engines).
It is associated with APT29 (Cozy Bear) infrastructure.
This IP has been detected in your environment:
- 15 connections from 5 devices in the past 7 days
- Primary target: Exchange Online
Recommended action: Block this IP immediately."

【2. ファイルハッシュの分析】
"What can you tell me about file hash SHA256:6ca13d52...?"

応答例:
"This file hash is identified as Emotet malware (Trojan.Emotet.A).
First seen: 2025-12-15
Distribution: Phishing emails with malicious attachments
Behavior: Downloads additional payloads, credential theft
In your environment: Detected on 3 devices, all quarantined successfully."

【3. ドメインレピュテーション】
"Is the domain 'micros0ft-login.com' legitimate?"

応答例:
"This domain is a typosquatting attempt (legitimate: microsoft.com).
WHOIS: Registered 2026-01-01 (recently created)
Purpose: Phishing (credential harvesting)
Blocked: Yes, added to block list on 2026-01-01."

インシデント調査

Copilotによる自動調査支援

プロンプト例

【1. インシデントサマリー生成】
"Summarize incident #12345 for executive briefing"

応答例:
"Incident #12345: Brute Force Attack Against Azure AD
Severity: High
Status: Resolved
Timeline: 2026-01-01 14:00 - 16:30

What happened:
An attacker from China (IP: 203.0.113.50) launched a brute force attack
targeting 50 admin accounts. One account ([email protected]) was compromised
after 200 failed attempts.

Impact:
- 1 compromised admin account
- 5 unauthorized mailbox forwarding rules created
- 20 sensitive emails forwarded to external address

Response:
- Account disabled automatically (14:35)
- Mailbox rules deleted (14:40)
- IP blocked (14:45)
- All admin accounts reset and MFA enforced (16:30)

Root cause: Weak password policy
Recommendation: Implement password less authentication for all admin accounts."

【2. 根本原因分析】
"What was the initial access vector for incident #12345?"

応答例:
"Initial access was gained through a phishing email.
Timeline:
1. 2026-01-01 13:45 - User [email protected] received phishing email
2. 13:47 - User clicked malicious link
3. 13:48 - User entered credentials on fake login page
4. 14:00 - Attacker used stolen credentials to log in from China
5. 14:05 - Attacker created mailbox forwarding rule"

【3. 影響範囲分析】
"Show me all affected users and systems for this ransomware incident"

応答例:
"Ransomware Incident #67890 - Blast Radius Analysis:

Affected Users: 15
- 3 admin accounts
- 12 standard users

Affected Devices: 25
- 20 Windows workstations (encrypted files)
- 3 file servers (partially encrypted)
- 2 domain controllers (no encryption, lateral movement only)

Encrypted File Count: ~50,000 files
Estimated Data Loss: 2TB

Network Spread:
Finance VLAN → IT VLAN → Executive VLAN

Recommendation: Isolate all devices in affected VLANs immediately."

4. KQL（Kusto Query Language）実践ガイド

KQLは、SC-200試験で最も重要なスキルの一つです。

4.1 KQL基礎構文

基本構造

テーブル名
| 演算子1
| 演算子2
| 演算子3

主要な演算子

4.2 SC-200試験で頻出するKQLパターン

パターン1: ブルートフォース攻撃検出

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != "0"  // ログイン失敗
| summarize FailureCount = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 5m)
| where FailureCount > 10
| project TimeGenerated, UserPrincipalName, IPAddress, FailureCount
| sort by FailureCount desc

パターン2: データ持ち出し検出

OfficeActivity
| where TimeGenerated > ago(1d)
| where Operation == "FileDownloaded"
| summarize DownloadCount = count(), Files = make_set(OfficeObjectId) by UserId
| where DownloadCount > 100
| extend Severity = case(
    DownloadCount > 500, "Critical",
    DownloadCount > 200, "High",
    "Medium"
)

パターン3: ラテラルムーブメント検出

DeviceNetworkEvents
| where TimeGenerated > ago(1h)
| where RemotePort in (445, 135, 139)  // SMB, RPC
| where InitiatingProcessFileName !in ("System", "services.exe")  // 正規プロセス除外
| summarize UniqueDestinations = dcount(RemoteIP) by DeviceName, InitiatingProcessFileName
| where UniqueDestinations > 5

パターン4: 特権昇格検出

SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4672  // 特権ログオン
| where AccountType == "User"  // サービスアカウント除外
| join kind=inner (
    SecurityEvent
    | where EventID == 4624  // ログオン成功
) on $left.SubjectUserName == $right.TargetUserName
| project TimeGenerated, Account = SubjectUserName, PrivilegeList, LogonType, IpAddress

パターン5: C2通信検出

DeviceNetworkEvents
| where TimeGenerated > ago(1h)
| where RemoteIPType == "Public"
| summarize ConnectionCount = count(),
            TotalBytesSent = sum(SentBytes),
            TotalBytesReceived = sum(ReceivedBytes)
            by DeviceName, RemoteIP, RemotePort, bin(TimeGenerated, 10m)
| where ConnectionCount > 10 and (TotalBytesSent > 1000000 or TotalBytesReceived > 1000000)
| extend Severity = "High"

4.3 パフォーマンス最適化のTips

1. フィルターを早期に適用

// ❌ 遅い
SecurityEvent
| project TimeGenerated, EventID, Account
| where TimeGenerated > ago(1h)
| where EventID == 4625

// ✅ 速い
SecurityEvent
| where TimeGenerated > ago(1h)  // 最初にフィルタリング
| where EventID == 4625
| project TimeGenerated, EventID, Account

2. 適切な演算子を使用

// ❌ 遅い: contains（部分一致）
| where FileName contains "powershell"

// ✅ 速い: == （完全一致）または has（単語一致）
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has "EncodedCommand"

3. summarizeの最適化

// ❌ 遅い: 複数のsummarize
| summarize count() by Account
| summarize TotalAccounts = dcount(Account)

// ✅ 速い: 1回のsummarizeで集計
| summarize TotalAccounts = dcount(Account), EventCount = count()

5. 実践的な学習方法

5.1 ハンズオン環境の構築

Microsoft 365 E5試用版の活用

1. https://www.microsoft.com/ja-jp/microsoft-365/enterprise/e5 にアクセス
2. 「無料試用版」をクリック（90日間無料）
3. テストユーザー、デバイスを作成
4. Defender for Office 365、Defender for Endpoint、Defender for Cloud Appsを有効化
5. 攻撃シミュレーション機能を活用

Azure無料アカウントでのSentinel環境構築

1. https://azure.microsoft.com/ja-jp/free/ でアカウント作成
2. リソースグループ作成
3. Log Analytics ワークスペース作成
4. Microsoft Sentinel有効化
5. サンプルデータの取り込み（GitHub: Azure-Sentinel サンプルデータ）
6. Content Hubからソリューションをインストール

Defender for Endpoint評価ラボ

Microsoft Defender Portal > Evaluation & tutorials > Evaluation lab
- 仮想デバイスが自動プロビジョニング
- 攻撃シミュレーション実行可能
- 無料で利用可能

5.2 推奨学習パス

Microsoft Learn学習モジュール

必須モジュール:
1. SC-200: セキュリティ運用環境を管理する
2. SC-200: 保護と検出を構成する
3. SC-200: インシデント対応を管理する
4. SC-200: セキュリティ脅威を管理する

推奨所要時間: 40-60時間

ドキュメント活用法

重点的に読むべきドキュメント:
- Microsoft Sentinel ドキュメント
- Microsoft 365 Defender ドキュメント
- Defender for Cloud ドキュメント
- KQLリファレンス

コミュニティリソース

- Microsoft Q&A: https://learn.microsoft.com/answers/
- Microsoft Tech Community: セキュリティフォーラム
- GitHub: Azure-Sentinel リポジトリ（サンプルクエリ、分析ルール）

5.3 模擬試験とPractice Assessment

Microsoft公式Practice Assessment

https://learn.microsoft.com/credentials/certifications/exams/sc-200/practice/assessment

特徴:
- 無料
- 本試験形式
- 解説付き
- 何度でも受験可能

サードパーティ模擬試験

- MeasureUp: 公式推奨
- Udemy: 日本語対応あり
- ExamTopics: コミュニティ提供（精度に注意）

5.4 効率的な学習スケジュール例

3ヶ月学習プラン（週10時間想定）

【1ヶ月目: 基礎固め】（40時間）
Week 1-2: Microsoft Learn モジュール1-2（セキュリティ運用環境、保護と検出）
Week 3-4: ハンズオン環境構築、Defender for Endpoint/Office 365

【2ヶ月目: 実践スキル】（40時間）
Week 5-6: Microsoft Learn モジュール3-4（インシデント対応、脅威管理）
Week 7-8: Sentinel構築、KQL練習、分析ルール作成

【3ヶ月目: 試験対策】（40時間）
Week 9: 模擬試験、弱点分析
Week 10: 弱点分野の復習、ドキュメント精読
Week 11: 模擬試験（2回目）、最終チェック
Week 12: 試験直前復習、受験

6. 試験当日の攻略法

6.1 時間配分の戦略

試験時間: 120分

推奨配分:
- 問題40-60問（形式により変動）
- 1問あたり: 2-3分
- ケーススタディ（ある場合）: 15-20分/ケース
- 見直し: 15-20分

タイムマネジメント

0-60分: 前半問題（約30問）
    ↓
60-90分: 後半問題（約20問）+ ケーススタディ
    ↓
90-105分: 見直し（フラグ付き問題）
    ↓
105-120分: 最終確認

6.2 問題形式別の解答テクニック

単一選択問題

戦略:
1. 明らかに間違っている選択肢を除外
2. 残った選択肢から「最も適切」なものを選択
3. キーワード（"最も", "最適", "推奨"）に注意

例:
Q: ブルートフォース攻撃を防ぐ「最も効果的な」方法は？
A: アカウントロックアウトポリシー
B: 複雑なパスワードポリシー
C: 多要素認証（MFA） ← 正解（最も効果的）
D: ログ監視

複数選択問題

注意点:
- 「2つ選択」など、選択数が明示されている
- 全ての正解を選ばないと不正解

戦略:
1. 各選択肢を個別に評価
2. 選択数を必ず確認
3. 部分点はないため、確実なものから選択

ケーススタディ問題

構成:
- シナリオ説明（組織の状況、要件）
- 複数の小問（5-10問）

戦略:
1. シナリオを精読（要件、制約を把握）
2. メモを取る（タブ間の移動でシナリオが見えなくなる場合あり）
3. 各小問は独立しているため、わからない問題は飛ばす

ドラッグ&ドロップ問題

形式:
- 手順の並び替え
- カテゴリへの分類

戦略:
1. 全選択肢を確認
2. 明らかなものから配置
3. 残りを消去法で判断

6.3 見直しのポイント

優先順位

高優先度:
1. フラグを付けた問題（自信がない問題）
2. 複数選択問題（選択数の確認）
3. ドラッグ&ドロップ（順序の確認）

低優先度:
4. 単一選択問題（自信がある問題）

チェックリスト

□ 全ての問題に回答したか（未回答がないか）
□ 複数選択問題の選択数は正しいか
□ ドラッグ&ドロップの順序は論理的か
□ ケーススタディで見落とした要件はないか

6.4 よくある落とし穴と対策

落とし穴1: “最も適切"を見逃す

問題文に「最も」「推奨」「ベストプラクティス」がある場合、
複数の選択肢が技術的には正しいが、1つだけが「最も適切」

対策: 問題文を2回読み、キーワードを見逃さない

落とし穴2: ベンダー固有の知識不足

例: 「ASRルールで防げる攻撃は？」
→ Defender for Endpointの詳細知識が必要

対策: 各製品の機能を実際に触って理解

落とし穴3: KQLクエリの読み間違い

例: `where` と `summarize` の順序、演算子の意味

対策: KQLを実際に書いて実行し、結果を確認する練習

落とし穴4: ロール・権限の混同

例: 「Microsoft Sentinel Contributor」と「Microsoft Sentinel Responder」の違い

対策: ロール一覧表を暗記

7. まとめ

7.1 SC-200試験のキーポイント総まとめ

セクション1: セキュリティ運用環境の管理（20-25%）

• Defender XDR設定（ASR、AIR、自動攻撃中断）
• Sentinelワークスペース設計（単一vs複数、データ保持戦略）
• データソース取り込み（CEF、Syslog、WEF、カスタムログ）

セクション2: 保護と検出の構成（15-20%）

• 各Defenderポリシー（Cloud Apps、Office 365、Endpoint、Cloud）
• カスタム検出ルール（KQL）
• ASIM、UEBA

セクション3: インシデント対応の管理（25-30%）★最重要

• Defenderポータルでの調査（フィッシング、ランサムウェア、BEC）
• ライブレスポンス、調査パッケージ
• Sentinelインシデント対応、オートメーションルール、プレイブック
• Security Copilot活用

セクション4: セキュリティ脅威の管理（15-20%）

• KQL脅威ハンティング
• MITRE ATT&CK活用
• Sentinelワークブック

7.2 各セクションの重要度マトリックス

7.3 最後のチェックリスト

技術知識

• 各Defenderサービスの機能を説明できる
• ASRルール、ASIMを理解している
• オートメーションルールとプレイブックの違いを説明できる
• KQLで脅威ハンティングクエリを書ける
• MITRE ATT&CKフレームワークを理解している

実践スキル

• Sentinelでインシデント調査を実施できる
• ライブレスポンスを使用できる
• プレイブックを作成できる
• 統合監査ログで調査できる

試験準備

• 模擬試験で70%以上取得
• 弱点分野を復習済み
• 試験当日の時間配分を理解している

8. 参考リソース

公式Microsoft Learn学習ガイド

• SC-200学習ガイド
• SC-200試験ページ

公式ドキュメント

• Microsoft Sentinel ドキュメント
• Microsoft 365 Defender ドキュメント
• Microsoft Defender for Cloud ドキュメント
• KQLリファレンス

コミュニティリソース

• Microsoft Q&A - Security
• Microsoft Tech Community - Security
• GitHub: Azure-Sentinel

推奨トレーニング

• Microsoft Learn: SC-200ラーニングパス（無料）
• Microsoft公式トレーニング: SC-200T00（有料）
• Udemy: SC-200模擬試験（日本語対応）

前編はこちら: SC-200完全ガイド（前編）：試験概要からセキュリティ運用環境・保護設定まで

幸運を祈ります！試験頑張ってください！