SC-200 頻出テーマ解説 TOP 10

okonomiyaki

最初に

SC-200（Microsoft Security Operations Analyst）の試験を受けようとしたとき、最初にぶつかる壁があります。

「範囲が広すぎて、何から手をつければいいかわからない」

Microsoft Sentinel、Defender for Cloud、Defender for Endpoint、KQL、UEBA、プレイブック……カバー範囲は広く、公式ドキュメントを端から読んでいたらいくら時間があっても足りません。

この記事はその問題をひとつ解決します。

この記事でわかること

別の記事でまとめたSC-200 の練習問題203 問を分析し、どのテーマが何回出題されているかを集計しました。その上位 10 テーマについて、「初心者でもイメージがつかめる」レベルの解説をまとめています。

SC-200 の練習問題203 問は以下になります。一部有料ですが、勉強したことのアウトプットに使ってもらえたらと思います。

合格のために深く理解すべきポイントが絞り込まれているので、勉強の優先順位をつけるための地図として使ってください。

対象読者

  • SC-200 の勉強を始めたばかりで、全体像が見えていない方

  • Microsoft Sentinel や Defender 製品の名前は知っているが、試験でどう問われるかがつかめていない方

  • 残り時間が限られており、出るところに集中して学習したい方

頻出ランキング（上位 10 テーマ）

203 問を分析した結果、以下のテーマが特に多く出題されていました。

  1. Sentinel - エンティティ / 調査グラフ（出現回数：30）

  2. Sentinel - KQL / ワークブックパラメーター（出現回数：29）

  3. Sentinel - ハンティングクエリ（出現回数：23）

  4. KQL - 集計・結合クエリ（出現回数：23）

  5. Sentinel - ワークブック（出現回数：18）

  6. KQL - 時系列・時間フィルター（出現回数：17）

  7. Defender for Cloud - セキュリティ推奨事項（出現回数：14）

  8. Sentinel - オートメーションルール（出現回数：13）

  9. Sentinel - データコネクタ（出現回数：12）

  10. Sentinel - プレイブック（インシデントトリガー）（出現回数：11）

こちらのリストをベースに、特定の項目について詳細な解説を加えました

各テーマの解説について

以下、各テーマごとに次の 4 点をまとめています。

  • ひとことで言うと — 一行でつかめる要約

  • 具体的なイメージ — 身近なたとえで理解するための説明

  • 試験で問われるポイント — 実際の問題に出やすい知識を箇条書きで整理

  • 参考リンク — 公式ドキュメントへの直リンク

順番通りに読む必要はありません。自分が弱いと感じるテーマから確認してください。

1. Sentinel - エンティティ / 調査グラフ（30回）

ひとことで言うと
エンティティ＝「事件の登場人物」。調査グラフ＝「登場人物の関係図」。

具体的なイメージ
不審なログインを検知したとき、「誰が（ユーザー）・どのPC（ホスト）・どのIP（IPアドレス）で」という情報がバラバラに存在します。Sentinel はこれらをエンティティという単位で自動抽出し、調査グラフで「このユーザーとこのIPは同じインシデントに関係している」という関係を地図のように見せてくれます。

エンティティの主な種類：ユーザー（Account）・デバイス（Host）・IPアドレス・URL・ファイル

試験で問われるポイント

  • 調査グラフはインシデントに対して使う（アラート単体では使えない）

  • 分析ルールで「エンティティマッピング」を設定しないと、グラフにエンティティが表示されない

  • エンティティページ：特定のユーザーやPCに関する過去のすべてのアラートをまとめて確認できる

  • UEBA（ユーザー行動分析）と連携すると、エンティティのリスクスコアも表示される

参考リンク
エンティティとは ／ インシデントの調査

2. Sentinel - KQL / ワークブックパラメーター（29回）

ひとことで言うと
ダッシュボードに「フィルタードロップダウン」を付けるための仕組み。

具体的なイメージ
Sentinel のワークブック（ダッシュボード）で「ユーザーを選んだら、そのユーザーのログだけ表示される」という動的フィルターを実現します。KQL クエリの中に `{パラメーター名}` と書くと、ユーザーが選択した値に自動で置き換わります。

// Operations という名前のパラメーターで絞り込む例
// 「All」が選ばれたら全件、それ以外は選択値でフィルター
| where ("{Operations:label}" == "All" or Operation in ({Operations}))

試験で問われるポイント

  • パラメーターは `{パラメーター名}` で囲む（`(` `)` ではない）

  • 「すべて選択」に対応するには `{パラメーター名:label} == "All"` で判定する

  • 空白値を除外するには `| where FieldName != ''` を使う

  • 複数選択には `in ({パラメーター名})` の形式（`== {パラメーター名}` は誤り）

参考リンク
ワークブックのパラメーター

3. Sentinel - ハンティングクエリ（23回）

ひとことで言うと
アラートを待たず、自分から能動的に脅威を探しに行く機能。

具体的なイメージ
通常の分析ルールは「怪しい動きがあったら自動で通知してくれる番犬」です。それに対してハンティングは「自分で KQL クエリを書いて、ログの海の中から怪しいパターンを手動で探す探偵活動」です。

ハンティング機能の主なパーツ：

  • ハンティングクエリ：KQL で書いた「探索レシピ」。MITRE ATT&CK にタグ付け可能

  • ブックマーク：「これは怪しい」と思った結果を保存してインシデントに昇格できる

  • ライブストリーム：クエリをリアルタイムで回し続け、ヒットしたら即通知

試験で問われるポイント

  • クエリを「お気に入り」に追加 → ハンティングページを開くたびに自動実行される

  • ライブストリーム：アラートルールを作らなくてもリアルタイム監視ができる

  • ブックマーク：重要な発見を保存し、既存インシデントへの追加 or 新規インシデント作成ができる

  • ウォッチリストは KQL 内で `_GetWatchlist('リスト名')` と書いて参照できる

参考リンク
脅威ハンティング ／ ブックマーク

4. KQL - 集計・結合クエリ（23回）

ひとことで言うと
ログを「数える・まとめる・別テーブルと組み合わせる」ための演算子群。

具体的なイメージ
KQL（Kusto Query Language）は Sentinel・Log Analytics・Defender XDR で使うログ検索言語です。Excelの「ピボットテーブル」や「VLOOKUP」に相当する操作が、`summarize` と `join` で実現できます。

// ログイン失敗が10回超えたアカウントを探す（summarize の例）
SecurityEvent
| where EventID == 4625
| summarize 失敗回数 = count() by Account
| where 失敗回数 > 10

よく使う演算子：

  • `summarize`：グループごとに集計（COUNT, AVGなど）

  • `join`：2つのテーブルを列でくっつける

  • `union`：2つのテーブルを縦に積み上げる

  • `extend`：計算した新しい列を追加する

  • `render`：グラフとして表示する

試験で問われるポイント

  • `join kind=inner`（一致するものだけ）、`kind=leftouter`（左テーブルを全件残す）

  • `join kind=anti`：右テーブルに存在しない左テーブルの行を取り出す（「〜していないユーザー」の抽出に使う）

  • `summarize count() by UserName` のように `by` でグループを指定する

  • `union TableA, TableB` でスキーマが違うテーブルも縦に結合できる

参考リンク
KQL クイックリファレンス

5. Sentinel - ワークブック（18回）

ひとことで言うと
KQL の結果をグラフや表にして「セキュリティダッシュボード」を作る機能。

具体的なイメージ
ログをそのまま見るのは生データの羅列で辛いです。ワークブックは「ログをグラフ・円グラフ・マップに変換して、一画面でセキュリティ状況をひと目で把握できるボード」です。テンプレートが豊富に用意されており、すぐに使い始めることができます。

試験で問われるポイント

  • ワークブックには「読み取りモード」と「編集モード」がある

  • ファイル共有サービスのアクティビティを見たい場合は `OfficeActivity` テーブルを使う

  • パラメーターを使うと「ユーザーや期間をドロップダウンで切り替え」できる（テーマ2と関連）

  • ワークブックは Log Analytics ワークスペースに保存される

  • 「個人用（My Workbooks）」と「チーム共有（Shared Workbooks）」の保存先がある

参考リンク
ワークブックでデータを視覚化

6. KQL - 時系列・時間フィルター（17回）

ひとことで言うと
「直近24時間」「1時間ごとに集計」など、時間に関する絞り込みと集計。

具体的なイメージ
ログ分析で最もよく使うのが「いつからいつまでのログを見るか」という時間指定です。KQL では `ago()` 関数を使って「今から〇〇前」を簡単に書けます。また `bin()` を使うと「1時間ごとの件数」のような時系列グラフ用の集計ができます。

// 過去7日間のログイン失敗を1時間ごとにグラフ化
SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(7d)
| summarize 失敗数 = count() by bin(TimeGenerated, 1h)
| render timechart

よく使う時間関数：

  • `ago(24h)`：24時間前

  • `ago(7d)`：7日前

  • `bin(TimeGenerated, 1h)`：1時間単位に丸める

  • `render timechart`：時系列折れ線グラフで表示

試験で問われるポイント

  • `ago(7d)` は「直近7日間」、`ago(1h)` は「直近1時間」

  • `bin()` は時系列グラフの X 軸の粒度を決める

  • `render timechart` で折れ線グラフ、`render barchart` で棒グラフになる

  • 分析ルールの「クエリ実行頻度」は「参照期間」以下に設定する必要がある

参考リンク
bin 関数

7. Defender for Cloud - セキュリティ推奨事項（14回）

ひとことで言うと
「このリソースの設定が甘い、こう直せばセキュリティが上がる」という改善提案一覧。

具体的なイメージ
Defender for Cloud（旧 Azure Security Center）は Azure リソースの設定を自動でスキャンして「MFA が無効になっているアカウントがあります」「仮想マシンの管理ポートが外部に開いています」といった具体的な問題点と修正方法を提示してくれます。問題を修正するほど「セキュアスコア」が上昇します。

推奨事項とアラートの違い：

  • 推奨事項：設定の問題（まだ攻撃されてはいないが、危ない状態）

  • アラート：実際の脅威の検出（攻撃や異常が起きている）

試験で問われるポイント

  • 推奨事項への対応 → セキュアスコアが上がる

  • 推奨事項は「Defender for Cloud」の推奨事項ページで一覧確認

  • 「免除（Exempt）」設定：組織の事情で対応不要な場合に除外できる

  • 修復の優先度は重要度（高・中・低）と「スコアへの貢献度」で判断する

  • 特定リソースの推奨事項は、そのリソースの Defender for Cloud ブレードからも確認できる

参考リンク
セキュリティ推奨事項とは ／ セキュアスコア

8. Sentinel - オートメーションルール（13回）

ひとことで言うと
「インシデントが来たら自動でこう処理して」という自動化の仕組み。

具体的なイメージ
大量のインシデントを毎回手動で処理するのは大変です。オートメーションルールは「重要度が低いインシデントは自動でクローズ」「特定の分析ルールのインシデントは担当者Aに自動割り当て」のような仕分け作業を自動化してくれます。プログラムを書かず、GUI だけで設定できます。

オートメーションルール vs プレイブック（どちらを使う？）：

オートメーションルール：

  • 向いていること：タグ付け・割り当て・クローズなどシンプルな処理

  • 設定の簡単さ：簡単（GUIのみ）

プレイブック：

  • 向いていること：外部システム通知・複雑な条件分岐

  • 設定の簡単さ：やや複雑（Logic Apps）

試験で問われるポイント

  • トリガーは「インシデントが作成されたとき」または「更新されたとき」の2種類

  • アクションで「プレイブックを実行」を選ぶとプレイブックを呼び出せる（プレイブックを直接呼ぶのではなく、オートメーションルール経由で呼ぶのが推奨）

  • 複数のオートメーションルールがある場合、「実行順序（数字）」が小さいほど先に実行される

  • 特定の分析ルールのインシデントだけ対象にしたい → 「条件」で分析ルール名を指定する

参考リンク
オートメーションルール

9. Sentinel - データコネクタ（12回）

ひとことで言うと
データコネクタ＝「ログを Sentinel に取り込むための接続口（USBケーブルのようなもの）」。

具体的なイメージ
Sentinel はログを分析するツールですが、そのログをどこから集めるかを定義するのがデータコネクタです。「Microsoft Entra ID のサインインログを取り込む」「ファイアウォールの Syslog を取り込む」など、ソースごとにコネクタを有効化します。コネクタを有効にして初めて、分析ルールやハンティングが機能します。

よく出るコネクタとテーブルの対応：

  • Microsoft Entra ID → `SigninLogs`・`AuditLogs`

  • Microsoft 365 (Office) → `OfficeActivity`

  • Windows セキュリティイベント → `SecurityEvent`

  • Azure アクティビティ → `AzureActivity`

  • Syslog（Linux） → `Syslog`

試験で問われるポイント

  • コネクタを有効化しないとテーブルが空 → 分析ルールが動かない

  • MMA（旧エージェント）は非推奨。新環境では AMA（Azure Monitor Agent） を使う

  • CEF コネクタ：ネットワーク機器など Linux エージェント経由で Syslog を取り込む形式

  • Defender for Cloud のアラートを Sentinel に送るには「Microsoft Defender for Cloud」コネクタを有効化する

  • コネクタの接続状態（接続済み・切断）は「データコネクタ」ページで確認できる

参考リンク
データコネクタとは

10. Sentinel - プレイブック（インシデントトリガー）（11回）

ひとことで言うと
プレイブック＝「インシデント発生時に自動で動くロボット手順書」。インシデントトリガーはその起動条件。

具体的なイメージ
セキュリティインシデントが起きたとき「Teams に通知する」「怪しいユーザーを無効化する」「ServiceNow にチケットを起票する」といった対応を自動化するのがプレイブックです。裏側は Azure Logic Apps（ノーコードのワークフローツール）で動いています。

インシデントトリガー型の動作例：

インシデント作成
  → 関係するユーザーを自動特定
  → Entra ID でそのユーザーを無効化
  → Teams チャンネルに「インシデントXXXが発生しました」と投稿

インシデントトリガー vs アラートトリガー：

インシデントトリガー：

  • いつ動くか：インシデント作成・更新時

  • 使えるデータ：インシデント全体（複数アラート・エンティティ含む）

  • 推奨度：Microsoft 推奨

  • 呼び出し方：オートメーションルールから

アラートトリガー：

  • いつ動くか：アラート生成時

  • 使えるデータ：単一アラートのみ

  • 推奨度：旧方式

  • 呼び出し方：分析ルールの「自動応答」タブ

試験で問われるポイント

  • インシデントトリガー型はオートメーションルールから呼び出すのが標準（テーマ8と関連）

  • アラートトリガー型は分析ルールの「自動応答」タブで設定する（旧来の方式）

  • プレイブックが失敗したときのログは Logic Apps の「実行履歴」で確認する

  • プレイブックを手動で実行するには「Microsoft Sentinel Playbook Operator」ロールが必要

参考リンク
プレイブックで脅威に自動対応

あわせて読みたい

本記事は「テーマ理解」に特化していますが、実際の試験形式に慣れるためには問題演習も欠かせません。

下記の記事では、SC-200 の実践問題を 203 問（日本語解説・参考資料付き）収録しています。最初の 50 問は無料で読めます。

いいなと思ったら応援しよう！