SC-200完全ガイド（前編）：Microsoft Security Operations Analyst試験対策2026 - 試験概要からセキュリティ運用環境・保護設定まで

はじめに

SC-200（Microsoft Security Operations Analyst）は、Microsoftのセキュリティ分野において中核となる認定資格です。クラウドおよびオンプレミス環境でのアクティブな攻撃への迅速な対応、脅威保護の改善提案、組織ポリシー違反の特定など、セキュリティ運用アナリストに求められる実践的なスキルを証明します。

本記事（前編）では、2026年1月22日更新版に対応した試験範囲のうち、**セクション1-2（セキュリティ運用環境の管理、保護と検出の構成）**を詳しく解説します。

後編はこちら: SC-200完全ガイド（後編）：インシデント対応・脅威管理編

1. SC-200試験とは - 資格の全体像

1.1 SC-200認定資格の位置づけ

SC-200は、Microsoftセキュリティ認定資格体系においてAssociate（中級）レベルに位置し、実務経験を持つセキュリティ運用アナリストを対象としています。

1.2 取得するメリット

キャリア面でのメリット

• セキュリティ運用アナリストとしての専門スキルの証明
• SOC（Security Operations Center）業務への従事機会の拡大
• 給与・待遇面での優位性

実務面でのメリット

• Microsoft 365 Defender、Sentinel、Defender for Cloudの体系的理解
• KQL（Kusto Query Language）スキルの習得
• インシデント対応能力の向上
• 脅威ハンティング能力の強化

組織面でのメリット

• Microsoftパートナー企業の認定要件を満たす
• セキュリティチームの能力向上

1.3 前提知識と推奨される前提資格

推奨される前提資格

• SC-900: Microsoft Security, Compliance, and Identity Fundamentals
• AZ-900: Microsoft Azure Fundamentals

必要な実務経験

• セキュリティ運用業務の実務経験（6ヶ月以上推奨）
• Microsoft 365、Azure環境の基本的な理解
• ネットワーク、OS、クラウドの基礎知識

2. 試験の基本情報

2.1 試験形式

2.2 試験範囲と配点比率（2026年1月22日更新版）

最重要セクション: **セクション3（インシデント対応の管理）**が最も配点が高く、実践的なスキルが問われます。

2.3 2026年1月22日更新版の変更点

主な変更点

• Microsoft Security Copilotの追加（インシデント対応セクションに統合）
• Exposure Managementの追加（アセット管理に統合）
• 「管理」および「構成」セクションに軽微な更新

新機能への対応

• GA（一般提供）機能が中心
• 広く使用されているPreview機能も含まれる可能性

3. 試験範囲の詳細解説

3-1. セキュリティ運用環境の管理（20-25%）

このセクションでは、セキュリティ運用の基盤となる環境の構築・管理スキルが問われます。

3-1-1. Microsoft Defender XDR設定の構成

アラートと脆弱性通知ルールの構成

アラート通知の重要性

• SOCチームへの迅速な通知
• 優先度に応じたエスカレーション
• 通知チャネルの適切な設定

構成可能な通知チャネル

• メール通知
• Microsoft Teams統合
• SIEM（Sentinelなど）への転送
• Webhook経由での外部システム連携

実践的な設定例

Microsoft Defender for Endpoint高度な機能の構成

エンドポイントルール設定

1. Attack Surface Reduction（ASR）ルール

• 実行可能コンテンツのブロック
• Office アプリケーションからの子プロセス作成のブロック
• スクリプトの難読化コードの実行ブロック
• PSExec/WMI経由のプロセス作成の制限

ASRルール展開のベストプラクティス

2. エンドポイント検出および応答（EDR）設定

• ブロックモード（EDR in block mode）の有効化
• 自動調査レベルの設定
• ファイル隔離の自動化

自動調査および対応（AIR）機能の管理

AIRの仕組み

Microsoft Defender XDRは、アラートをトリガーとして自動的に調査を開始し、影響範囲を特定、脅威を修復します。

自動化レベルの設定

AIR管理のポイント

• デバイスグループごとに自動化レベルを設定可能
• 誤検知の傾向を分析し、除外設定を最適化
• 定期的なレビューと調整

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

自動攻撃中断とは

ランサムウェアやBEC（Business Email Compromise）などの進行中の攻撃を、AIが自動的に検出し、攻撃チェーンを中断する機能です。

動作の流れ

設定のベストプラクティス

• 本番環境への適用前にパイロット運用
• 誤検知時の迅速な復旧手順の整備
• 自動中断アクションのログ監視

3-1-2. アセットと環境の管理

デバイスグループ、権限、オートメーションレベルの構成

デバイスグループの設計戦略

デバイスグループは、組織の構造、セキュリティ要件、自動化ニーズに応じて設計します。

設計パターン例

権限（RBAC）の設定

非管理デバイスの特定と対処

非管理デバイスのリスク

• セキュリティポリシーが適用されていない
• 脆弱性パッチが未適用
• 可視性の欠如

特定方法

1. Microsoft Defender for Endpointの検出機能
   • ネットワーク上の未登録デバイスを自動検出
2. Microsoft Entra ID（旧Azure AD）連携
   • 登録済みデバイスと照合
3. ネットワークスキャン
   • 定期的なネットワークスキャンで未管理デバイスを発見

対処方法

Defender for Cloudによる非保護リソースの検出

非保護リソースとは

• Defender for Cloudエージェントが未インストールのVM
• セキュリティポリシーが適用されていないリソース
• 脆弱性評価が未実施のリソース

検出方法

1. Defender for Cloudダッシュボード
   • 「Inventory」タブで保護状態を確認
2. セキュアスコア
   • 推奨事項から非保護リソースを特定
3. Azure Resource Graph クエリ
   • KQLで非保護リソースを抽出

実践的なKQLクエリ例

// Defender for Cloudエージェント未インストールのVMを検出
SecurityResources
| where type == "microsoft.security/assessments"
| where properties.displayName == "Log Analytics agent should be installed on virtual machines"
| where properties.status.code == "Unhealthy"
| project VMName = properties.resourceDetails.Id, Status = properties.status.code

Microsoft Defender Vulnerability Managementでのリスク端末の特定と修復

Defender Vulnerability Management（DVM）の役割

• 脆弱性の継続的な検出
• リスクベースの優先順位付け
• 修復推奨事項の提供

リスク端末の特定方法

1. エクスポージャースコア

• デバイスごとのリスクを数値化（0-1000）
• 未パッチの脆弱性、不適切な設定、アクティブな脅威を総合評価

2. セキュリティ推奨事項

• CVSSスコア、悪用の有無、影響範囲に基づいた優先順位

3. 脆弱性タイムライン

• CVE（Common Vulnerabilities and Exposures）の発見から修復までの追跡

修復プロセス

修復オプション

• 自動パッチ適用: Windows Update、Intuneポリシー経由
• 構成変更: セキュリティベースラインの適用
• 緩和策: パッチ適用が困難な場合、ASRルールやファイアウォールで対処
• 例外承認: ビジネス上の理由で修復できない場合

Microsoft Defender XDRのExposure Managementによるリスク軽減

Exposure Managementとは

組織全体の攻撃対象領域（Attack Surface）を可視化し、リスクを優先順位付けして軽減する機能です（2026年1月更新版で追加）。

主要機能

1. 攻撃パスの可視化

• 攻撃者が侵入した場合の影響範囲をシミュレーション
• クリティカルアセットへの経路を特定

2. セキュリティイニシアチブ

• リスク軽減のためのアクションプランを自動生成
• 効果の高い対策を優先的に提示

3. セキュリティメトリクス

• エクスポージャーレベルの数値化
• 経時的な改善状況のトラッキング

活用シナリオ

3-1-3. Microsoft Sentinelワークスペースの設計と構成

Microsoft Sentinelワークスペースの計画

ワークスペース設計の選択肢

1. 単一ワークスペース設計

2. 複数ワークスペース設計

設計時の考慮事項

Microsoft Sentinelロールの構成

組み込みロール

カスタムロールの作成例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "Name": "Sentinel Analyst - Limited",
  "Description": "インシデント対応とハンティングのみ許可",
  "Actions": [
    "Microsoft.SecurityInsights/incidents/read",
    "Microsoft.SecurityInsights/incidents/write",
    "Microsoft.OperationalInsights/workspaces/query/read"
  ],
  "NotActions": [
    "Microsoft.SecurityInsights/alertRules/write"
  ]
}

Azure RBACロールの指定

Log Analytics Workspaceとの統合

Sentinelは、Log Analyticsワークスペース上���構築されるため、以下のAzure RBACロールも考慮が必要です。

リソースレベルとテーブルレベルのRBAC

• リソースレベル: ワークスペース全体へのアクセス制御
• テーブルレベル: 特定のログテーブル（例: SecurityEvent）のみアクセス許可

データストレージ、ログタイプ、ログ保持期間の設計と構成

データストレージ設計

1. ログ取り込み量の見積もり

2. ログタイプの選定

3. ログ保持期間の最適化

段階的保持戦略

コスト最適化のポイント

• Basic Logs: 調査頻度の低いログを低コストで保存
• Archive: 長期保存が必要なログをアーカイブ化（取り込みコストの約15%）
• データ収集ルール（DCR）: 不要なログフィールドを除外

実践的な設定例

3-1-4. Microsoft Sentinelのデータソース取り込み

取り込むデータソースの特定

データソース選定の戦略

1. 必須データソース（優先度: 高）

• Microsoft 365 Defender（Endpoint、Office 365、Identity、Cloud Apps）
• Azure Active Directory（サインインログ、監査ログ）
• Azureアクティビティログ
• Windows Securityイベント（ドメインコントローラー、重要サーバー）

2. 推奨データソース（優先度: 中）

• ファイアウォール（Palo Alto、Cisco、Fortinet等）
• プロキシ/Webゲートウェイ
• VPNログ
• DNSログ

3. オプショナルデータソース（優先度: 低）

• アプリケーションログ
• データベース監査ログ
• IoTデバイスログ

データソース選定のチェックリスト

• MITRE ATT&CKカバレッジ（検出できる攻撃手法の範囲）
• コンプライアンス要件（GDPR、PCI-DSS等）
• コスト対効果（取り込み量vs検出価値）
• 運用負荷（ログの正規化、パーサー開発）

Content Hubソリューションの実装と使用

Content Hubとは

Content Hubは、Sentinelのマーケットプレイスであり、すぐに使えるソリューション（データコネクタ、分析ルール、ワークブック、プレイブック）をパッケージで提供します。

主要なContent Hubソリューション

実装手順

ベストプラクティス

• 全てのルールを有効化せず、組織に適したものを選定
• カスタマイズ前にコピーを作成（アップデート時の上書き防止）
• 定期的にContent Hubの更新を確認

Azureリソース用Microsoftコネクタの構成

主要なMicrosoftコネクタ

1. Microsoft 365 Defender

構成手順

2. Azure Active Directory

3. Azure Activity

4. Microsoft Defender for Cloud

Syslog およびCEF（Common Event Format）イベント収集の計画と構成

Syslog vs CEF

Syslog収集の構成

アーキテクチャ

構成手順

1
2
3
4
5
6
7
8
9

# 1. Linux VMにLog Analytics Agentをインストール
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh
sh onboard_agent.sh -w <WorkspaceID> -s <WorkspaceKey>

# 2. Syslog設定ファイルを編集
sudo vi /etc/rsyslog.d/95-omsagent.conf

# 3. Syslogデーモンを再起動
sudo systemctl restart rsyslog

Sentinel側の設定

CEF収集の構成

CEF形式の例

構成手順

CEFパーサーのカスタマイズ

// Palo Alto Networks用カスタムパーサー
CommonSecurityLog
| where DeviceVendor == "Palo Alto Networks"
| extend
    SourceIP = coalesce(SourceIP, DeviceCustomIPv6Address2),
    ThreatName = DeviceCustomString1,
    URLCategory = DeviceCustomString4
| project TimeGenerated, SourceIP, DestinationIP, ThreatName, URLCategory

Windows Event Forwarding（WEF）を使用したWindows Securityイベント収集の計画と構成

WEFとは

Windows Event Forwardingは、複数のWindowsデバイスからイベントログを中央のコレクターサーバーに転送する機能です。Sentinelへの取り込み前に、WEFで集約することでエージェント数を削減できます。

アーキテクチャ

WEF構成手順

1. コレクターサーバーの準備

1
2
3
4
5

# WinRMサービスの有効化
winrm quickconfig

# Event Collectorサービスの開始
wecutil qc

2. サブスクリプションの作成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<!-- subscription.xml -->
<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
  <SubscriptionId>Security Events</SubscriptionId>
  <Query>
    <QueryList>
      <Query Id="0">
        <Select Path="Security">
          *[System[(EventID=4624 or EventID=4625 or EventID=4672)]]
        </Select>
      </Query>
    </QueryList>
  </Query>
</Subscription>

1
2

# サブスクリプションの作成
wecutil cs subscription.xml

3. ソースデバイスの構成

1
2
3

# グループポリシーで設定
Computer Configuration > Policies > Administrative Templates > Windows Components > Event Forwarding
- Configure target Subscription Manager: Server=http://collector.domain.com:5985/wsman/SubscriptionManager/WEC

4. Sentinel連携

推奨イベントID

カスタムログテーブルの作成

カスタムログが必要なシナリオ

• サードパーティアプリケーションのログ
• カスタム開発アプリケーション
• 既存コネクタでサポートされていないデータソース

作成方法

1. Data Collection Rule（DCR）を使用した方法（推奨）

1
2
3
4
5
6
7

# サンプルログファイル（JSON形式）
{
  "TimeGenerated": "2026-01-01T12:00:00Z",
  "Application": "CustomApp",
  "EventLevel": "Error",
  "Message": "Database connection failed"
}

構成手順

2. Log Analytics HTTP Data Collector APIを使用した方法

 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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

import requests
import json
import hashlib
import hmac
import base64
from datetime import datetime

workspace_id = 'your-workspace-id'
shared_key = 'your-shared-key'
log_type = 'CustomAppLog'

def build_signature(date, content_length, method, content_type, resource):
    x_headers = f'x-ms-date:{date}'
    string_to_hash = f'{method}\n{content_length}\n{content_type}\n{x_headers}\n{resource}'
    bytes_to_hash = bytes(string_to_hash, encoding="utf-8")
    decoded_key = base64.b64decode(shared_key)
    encoded_hash = base64.b64encode(hmac.new(decoded_key, bytes_to_hash, digestmod=hashlib.sha256).digest()).decode()
    return f'SharedKey {workspace_id}:{encoded_hash}'

def post_data(body):
    method = 'POST'
    content_type = 'application/json'
    resource = '/api/logs'
    rfc1123date = datetime.utcnow().strftime('%a, %d %b %Y %H:%M:%S GMT')
    content_length = len(body)
    signature = build_signature(rfc1123date, content_length, method, content_type, resource)
    uri = f'https://{workspace_id}.ods.opinsights.azure.com{resource}?api-version=2016-04-01'

    headers = {
        'content-type': content_type,
        'Authorization': signature,
        'Log-Type': log_type,
        'x-ms-date': rfc1123date
    }

    response = requests.post(uri, data=body, headers=headers)
    return response.status_code

# ログデータの送信
log_data = [{
    "Application": "CustomApp",
    "EventLevel": "Error",
    "Message": "Database connection failed"
}]

body = json.dumps(log_data)
post_data(body)

データ取り込みの監視と最適化

監視のポイント

1. 取り込み量の監視

// 日次の取り込み量（GB単位）
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize IngestedGB = sum(Quantity) / 1000 by bin(TimeGenerated, 1d), DataType
| render timechart

2. 取り込み遅延の監視

// データソース別の取り込み遅延
Heartbeat
| extend IngestionDelay = ingestion_time() - TimeGenerated
| summarize avg(IngestionDelay), max(IngestionDelay) by Computer
| where max_IngestionDelay > 5m  // 5分以上の遅延

3. コネクタのヘルスチェック

// データコネクタの最終受信時間
union SecurityEvent, Syslog, CommonSecurityLog, AzureActivity
| summarize LastReceived = max(TimeGenerated) by $table
| extend TimeSinceLastEvent = now() - LastReceived
| where TimeSinceLastEvent > 1h  // 1時間以上データ受信なし

最適化テクニック

1. 不要なログフィールドの除外

// Data Collection Ruleでの変換例
SecurityEvent
| where EventID in (4624, 4625, 4672)  // 必要なイベントIDのみ
| project TimeGenerated, Computer, Account, EventID, LogonType  // 必要なフィールドのみ

2. サンプリング

// 高頻度ログのサンプリング（10%のみ取り込み）
CommonSecurityLog
| where DeviceVendor == "Palo Alto Networks"
| where rand() < 0.1  // 10%サンプリング

3. Basic Logsの活用

3-2. 保護と検出の構成（15-20%）

このセクションでは、脅威を未然に防ぎ、検出するための各種ポリシーとルールの構成方法が問われます。

3-2-1. Microsoft Defenderセキュリティテクノロジーでの保護の構成

Microsoft Defender for Cloud Appsポリシー

Defender for Cloud Appsの役割

• SaaS アプリケーションの可視化と制御
• シャドーIT検出
• データ漏洩防止
• 脅威保護

主要なポリシータイプ

1. アクセスポリシー

実践的な設定例

2. アクティビティポリシー

3. ファイルポリシー

設定例

4. 異常検出ポリシー

Microsoft Defender for Office 365ポリシー

Defender for Office 365の役割

• メール経由の脅威（フィッシング、マルウェア）からの保護
• 悪意のあるリンク・添付ファイルの検出
• 内部脅威の検出

主要なポリシー

1. Safe Attachments（安全な添付ファイル）

動作モード

実践的な設定例

2. Safe Links（安全なリンク）

保護の仕組み

設定項目

3. Anti-phishing（フィッシング対策）

保護レイヤー

偽装保護の設定

4. Anti-spam（スパム対策）

スパムフィルタリングレベル

アクション設定

Microsoft Defender for Endpointセキュリティポリシー（ASRルール含む）

Attack Surface Reduction（ASR）ルール詳細

ASRルールは、一般的な攻撃手法をブロックすることで、攻撃対象領域を縮小します。

主要なASRルール

ASRルール展開戦略

段階的展開の4ステップ

除外設定の例

1
2
3
4
5

# ファイルパス除外
Add-MpPreference -AttackSurfaceReductionOnlyExclusions "C:\TrustedApp\app.exe"

# ルール単位の除外（特定ルールを無効化）
Set-MpPreference -AttackSurfaceReductionRules_Ids <RuleID> -AttackSurfaceReductionRules_Actions Disabled

その他のEndpointセキュリティポリシー

1. Endpoint Detection and Response（EDR）

2. Next-generation protection（次世代保護）

3. Web保護

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

Defender for Cloudの保護対象

主要な保護設定

1. Just-In-Time（JIT） VM Access

動作の仕組み

設定例

2. ファイル整合性監視（FIM）

監視対象

• レジストリキーの変更
• システムファイルの変更
• 構成ファイルの変更

設定例

3. 適応型アプリケーション制御（AAC）

動作の仕組み

3-2-2. Microsoft Defender XDRでの検出の構成

カスタム検出ルールの構成と管理

カスタム検出ルールとは

組み込みの検出ルールでカバーされない、組織固有の脅威を検出するためのKQLベースのルールです。

ルール作成の基本構造

// 例: 夜間の機密ファイルアクセス検出
CloudAppEvents
| where Timestamp > ago(1h)
| where ActionType == "FileAccessed"
| where FileName has_any ("confidential", "secret", "restricted")
| extend Hour = hourofday(Timestamp)
| where Hour >= 22 or Hour <= 6  // 22時～6時
| where AccountObjectId != "exclude-service-account-id"
| summarize FileAccessCount = count() by AccountDisplayName, FileName, bin(Timestamp, 5m)
| where FileAccessCount > 10  // 5分間に10回以上

ルール設定項目

KQLクエリのベストプラクティス

// ❌ 悪い例: パフォーマンスが悪い
DeviceEvents
| where Timestamp > ago(1h)
| where FileName contains "powershell"  // contains は遅い
| where DeviceName contains "DESKTOP"   // 曖昧すぎる条件

// ✅ 良い例: 最適化済み
DeviceEvents
| where Timestamp > ago(1h)
| where FileName in~ ("powershell.exe", "pwsh.exe")  // in~ は高速
| where DeviceName startswith "DESKTOP-"
| where ProcessCommandLine has_any ("EncodedCommand", "bypass", "hidden")
| summarize count() by DeviceName, AccountName
| where count_ > 5  // 閾値設定

アラートの管理（チューニング、抑止、相関）

アラートチューニングの目的

• 誤検知（False Positive）の削減
• アラート疲労（Alert Fatigue）の防止
• SOCチームの効率化

1. アラート抑止（Suppression）

抑止ルールの例

設定場所

2. アラート相関

インシデントへの自動グルーピング

Microsoft 365 Defenderは、以下の基準で関連アラートを自動的に1つのインシデントにグループ化します。

カスタム相関ルール

// 例: フィッシングメール受信後のマルウェア実行を1つのインシデントに
EmailEvents
| where ThreatTypes has "Phish"
| join kind=inner (
    DeviceEvents
    | where ActionType == "ProcessCreated"
    | where ProcessCommandLine has_any ("powershell", "cmd")
) on $left.RecipientEmailAddress == $right.AccountUpn
| where (DeviceEvents_Timestamp - EmailEvents_Timestamp) between (0min .. 60min)

3. アラートチューニングのプロセス

KPI（重要業績評価指標）

• 検出率（Detection Rate）: 実際の攻撃を検出した割合
• 誤検知率（False Positive Rate）: 誤検知の割合（目標: 5%以下）
• MTTD（Mean Time To Detect）: 攻撃検出までの平均時間
• MTTR（Mean Time To Respond）: 対応完了までの平均時間

Microsoft Defender XDRでの詐欺ルールの構成

詐欺（Fraud）ルールとは

ビジネスメール詐欺（BEC）、請求書詐欺、CEO詐欺などの金銭的被害を狙った攻撃を検出するルールです。

主要な詐欺パターン

1. CEO詐欺（Whaling）

2. 請求書詐欺

カスタム詐欺検出ルールの例

// BEC検出: 役員を装った外部メール
EmailEvents
| where Timestamp > ago(1h)
| where EmailDirection == "Inbound"
| extend SenderDisplayNameLower = tolower(SenderDisplayName)
| where SenderDisplayNameLower has_any ("ceo", "cfo", "president", "director")
| where SenderFromDomain != "contoso.com"  // 組織ドメイン
| where Subject has_any ("urgent", "wire transfer", "payment", "invoice")
| project Timestamp, SenderFromAddress, SenderDisplayName, RecipientEmailAddress, Subject, DeliveryAction

Defender for Office 365での詐欺対策ポリシー

これで前編（セクション1-2）が完成しました。後編では、最も配点の高い「インシデント対応の管理」と「セキュリティ脅威の管理」を解説します。