Microsoft Defender環境でMicrosoft Sentinelを運用している管理者は、2026年5月14日に更新された公式情報「Get started with custom graphs in Microsoft Sentinel (preview)」を確認しておくべきです。ポイントは、Microsoft Sentinelのデータレイク上のセキュリティデータを、攻撃経路やID・資産・権限の関係としてグラフ化し、調査や脅威ハンティングに使えるようになることです。特に、Microsoft Defenderポータル、Visual Studio Code、Jupyter Notebook、Microsoft Sentinel data lakeを組み合わせて使うため、権限、データ取り込み、コスト、ジョブスケジュールの確認が欠かせません。(Microsoft Learn)
この機能はプレビュー段階のため、本番展開では「便利そうだからすぐ全社展開する」のではなく、SOCやセキュリティ運用チームが扱うシナリオを絞って検証するのが現実的です。たとえば、Microsoft Entra IDの入れ子グループ、サービスプリンシパル、権限昇格の経路、フィッシングメールから端末侵害までの流れを可視化したい組織では、早めに検証する価値があります。
Microsoft Defenderで使うMicrosoft Sentinel custom graphsとは
Microsoft Sentinel custom graphsは、Microsoft Sentinel data lakeにあるセキュリティデータを、ノードとエッジで表現するカスタムグラフ機能です。ノードはユーザー、グループ、端末、IPアドレス、URL、サービスプリンシパルなどの「対象」を表し、エッジは「所属している」「アクセスした」「通信した」「クリックした」といった関係を表します。(Microsoft Learn)
従来のログ分析では、KQLでテーブルを結合しながら調査することが多くなります。一方、グラフでは「このユーザーが侵害された場合、どの重要資産へ到達できるか」「このURLを踏んだユーザーから、どの端末やプロセスへつながるか」といった関係性の追跡に向いています。
Microsoftの公式情報では、カスタムグラフを使うことで、攻撃パターンのモデル化、脅威調査、高度なグラフアルゴリズムの実行、デジタル環境内の隠れた関係の発見に役立つと説明されています。作成には、Microsoft Sentinel Visual Studio Code拡張機能上のJupyter Notebookを使います。(Microsoft Learn)
2026年5月14日更新で押さえるべき変更点
今回の公式情報で重要なのは、Microsoft Sentinelのカスタムグラフ作成が「概念紹介」だけでなく、実際の作成、永続化、管理、クエリ、可視化までを含む運用手順として整理されている点です。
| 確認項目 | 内容 | 管理者・開発者への影響 |
|---|---|---|
| 作成方法 | VS CodeのMicrosoft Sentinel拡張機能とJupyter Notebookでグラフを作成 | セキュリティ運用だけでなく、Python/PySparkを扱える担当者の関与が必要 |
| データ基盤 | Microsoft Sentinel data lakeが前提 | 事前オンボード、データ取り込み、テーブル権限の確認が必要 |
| サンプル | Microsoft Entraのユーザー、グループ、サービスプリンシパル、メンバーシップを使った例 | ID基盤の権限調査や入れ子グループ分析に応用しやすい |
| 永続化 | Notebookの対話セッションで作ったグラフは一時的。共有・再利用にはgraph jobのスケジュールが必要 | 本番運用ではジョブ化と更新頻度の設計が必須 |
| 利用場所 | 永続化後はDefenderポータル配下のSentinel、VS Code Notebook、Graph query APIsからアクセス可能 | SOC、調査担当、開発者で利用経路を分けられる |
| 状態 | プレビュー | 構文や仕様変更を前提に、検証環境から始めるべき |
最も見落としやすいのは、Notebook内で作ったグラフがそのままチーム共有用の資産になるわけではない点です。公式情報では、対話的なNotebookセッションで作成したグラフは一時的で、セッション終了時に削除されると説明されています。継続利用や共有には、graph jobをスケジュールしてグラフを再構築する必要があります。(Microsoft Learn)
対象となる管理者・開発者
この機能の対象は、単にMicrosoft Defenderを管理している担当者だけではありません。Microsoft Sentinel、Microsoft Defender XDR、Microsoft Entra ID、データレイク、ノートブック分析に関わる複数の担当者が影響を受けます。
| 対象者 | 確認すべきこと |
|---|---|
| セキュリティ管理者 | Microsoft Sentinel data lakeの有効化、Microsoft Defenderポータルでの利用範囲、RBAC |
| SOCアナリスト | どの調査シナリオをグラフ化するか、GQLクエリの使い方 |
| ID管理者 | Entra IDコネクタ、グループ、ユーザー、サービスプリンシパルのデータ可視性 |
| データエンジニア | PySpark、DataFrame、ノード・エッジ設計、ジョブスケジュール |
| 開発者 | Notebookの保守、GraphSpecBuilder、Graph API、クエリAPIの利用 |
| コスト管理者 | data lake、Notebook、カスタムグラフ操作に関する課金影響 |
実務では、SOCだけで完結させるよりも、ID管理者とデータ分析担当を巻き込んだ小さな検証チームを作る方が失敗しにくくなります。特に、Microsoft Entra IDのグループ構造やサービスプリンシパルの権限関係は、セキュリティ担当だけでは意味を誤読しやすい領域です。
利用前に確認すべき前提条件
Microsoft Sentinel custom graphsを始めるには、次の準備が必要です。
| 前提条件 | 確認内容 |
|---|---|
| Microsoft Sentinel data lake | テナントでオンボード済みか |
| Visual Studio Code | Microsoft Sentinel拡張機能を導入しているか |
| Jupyter拡張機能 | VS CodeでNotebookを実行できるか |
| Microsoft Entra ID connector | サンプルで使うEntra資産テーブルを取り込めているか |
| Spark compute pool | Notebook実行用のプールを選択できるか |
| 権限 | 作成、永続化、クエリに必要な権限が付与されているか |
Microsoft Sentinel data lakeのオンボードはMicrosoft Defenderポータルから行います。オンボード時にはAzureサブスクリプションとリソースグループを指定しますが、公式情報では、プロビジョニング後に別のサブスクリプションやリソースグループへ移行できないと説明されています。検証用の一時的なサブスクリプションを安易に選ぶと、後で運用設計をやり直す可能性があります。(Microsoft Learn)
また、データレイクの有効化直後やテーブルを有効化した直後は、データがすぐに利用できるとは限りません。公式情報では、新しく有効化されたテーブルや階層移動したテーブルのデータが利用可能になるまで、オンボード完了後90〜120分かかる場合があるとされています。検証時に「テーブルが見えない」「データが空」と判断する前に、時間差を考慮してください。(Microsoft Learn)
権限設計で注意すべきポイント
カスタムグラフでは、作成、永続化、クエリで必要な権限が異なります。ここを曖昧にすると、ある担当者はNotebookで作成できるが、別の担当者はグラフを参照できない、といった問題が起きます。
| 操作 | 必要な権限の考え方 |
|---|---|
| Notebookでグラフをモデル化・構築 | Microsoft Sentinel data collectionに対するMicrosoft Defender XDR unified RBACのdata manage権限 |
| テナント内にグラフを永続化 | Security operator、Security administrator、Global administratorのいずれかのMicrosoft Entra IDロール |
| 永続化されたグラフをクエリ | Microsoft Sentinel data collectionに対するsecurity data basics read権限 |
さらに重要なのは、グラフに使う元データへの読み取り権限です。公式情報では、ユーザーが特定のデータセットにアクセスできない場合、そのデータはグラフに含まれないと説明されています。また、Sentinel scopeで制限されたユーザーはカスタムグラフを作成できません。(Microsoft Learn)
これは調査結果の信頼性に直結します。たとえば、あるアナリストがグループメンバーシップのグラフを作ったとしても、必要なEntra資産テーブルにアクセスできていなければ、表示される関係は不完全になります。権限不足のまま作ったグラフを「攻撃経路がない」と判断するのは危険です。
作成から運用までの基本フロー
Microsoft Sentinel custom graphsの作成は、大きく分けて「モデル化」「永続化」「管理・可視化」の3段階です。公式情報でも、カスタムグラフを作成して扱う手順として、グラフのモデル化、graph jobによる永続化、表示と管理が示されています。(Microsoft Learn)
| ステップ | 実施内容 | 実務上の判断ポイント |
|---|---|---|
| モデル化 | Notebookでデータを読み込み、ノードとエッジを設計する | 調査したい問いを先に決める |
| スキーマ定義 | GraphSpecBuilderでノード、エッジ、キー、表示名を定義する | IDやキーの重複を避ける |
| 検証 | show_schema()などで定義を確認する | 想定外の列欠落や型の違いを確認 |
| ビルド | Graph.buildなどでグラフを構築する | 処理時間とコストを確認 |
| 永続化 | graph jobを作成し、オンデマンドまたは定期実行にする | 更新頻度と保持期間を決める |
| 可視化・クエリ | DefenderポータルのSentinel > GraphsやNotebook、APIから利用する | 利用者ごとのアクセス経路を設計 |
公式サンプルでは、Microsoft Entraのグループ、ユーザー、サービスプリンシパルをノードにし、グループがユーザー、グループ、サービスプリンシパルを含む関係をエッジとして定義しています。これにより、入れ子グループやサービスプリンシパルを含む権限関係をたどれるようになります。(Microsoft Learn)
サンプルから考える実用シナリオ
最初の検証では、複雑な攻撃シナリオをいきなり作るより、Microsoft Entra IDの関係分析から始めるのがおすすめです。理由は、ユーザー、グループ、サービスプリンシパル、ロール、権限といった関係が、グラフの価値を理解しやすいからです。
たとえば、次のような問いに答えるグラフを設計できます。
- 特定のユーザーは、どの入れ子グループを経由して重要グループに所属しているか
- 無効化されていないサービスプリンシパルが、どのグループに含まれているか
- 特権グループに到達できる経路が、何段階のメンバーシップで成立しているか
- 部署や利用地域などの属性で、危険な権限経路を絞り込めるか
公式サンプルのGQLでは、入れ子グループ関係を最大8階層までたどる例が示されています。GQLのリファレンスでも、可変長パスのクエリでは無制限指定が最大8ホップに制限されると説明されています。過度に深い探索を前提にした設計ではなく、調査に必要な深さを明確にすることが大切です。(Microsoft Learn)
Defenderポータルでの可視化と調査
永続化されたカスタムグラフは、Microsoft DefenderポータルのMicrosoft Sentinel配下にあるGraphsから利用できます。グラフ管理ページでは、作成済みのカスタムグラフを選び、GQLクエリを実行して可視化できます。(Microsoft Learn)
可視化画面では、ノードの種類ごとに色分けされた表示、凡例、ノード詳細、表形式の結果表示などを利用できます。ノードを選択してメタデータを確認し、地域、部署、更新日時などの属性をもとに次のクエリを絞り込む運用ができます。(Microsoft Learn)
実務では、最初から巨大なグラフを全面表示するより、次のような流れが扱いやすくなります。
| 調査段階 | 使い方 |
|---|---|
| 初期確認 | MATCH (x)-[y]->(z) RETURN * LIMIT 100のような基本クエリで構造を確認 |
| 仮説検証 | 特定ユーザー、端末、URL、グループ名で絞り込む |
| 影響範囲調査 | 1〜3ホップ程度から探索し、必要に応じて深さを広げる |
| 報告・連携 | 表形式結果やJSONデータを既存ワークフローに取り込む |
グラフは「見た目が分かりやすい」ことが利点ですが、可視化だけで判断すると誤解が生まれます。重要なのは、グラフスキーマで何をノード・エッジとして定義したか、どのテーブルを読み込んだか、どの権限で実行したかを記録しておくことです。
GQLでできることと学習すべき基本
Microsoft Sentinel custom graphsのクエリにはGraph Query Language、つまりGQLを使います。GQLはプレビュー段階であり、公式リファレンスでは機能や構文がフィードバックと開発状況に応じて変更される可能性があると明記されています。(Microsoft Learn)
最低限、次の書き方は理解しておくと実務で使いやすくなります。
| 目的 | GQLの考え方 | 例 |
|---|---|---|
| 任意のノードを探す | (n) | すべてのノードを対象にする |
| 特定種類のノードを探す | (n:EntraUser) | EntraUserノードだけを対象にする |
| 関係をたどる | (a)-[r]->(b) | aからbへの有向エッジを探す |
| 条件で絞る | WHERE | 表示名や部署で絞る |
| 複数ホップをたどる | {1,3}など | 1〜3段階の関係を調べる |
| 結果を返す | RETURN | ノード、エッジ、パスを返す |
GQLを学ぶときは、最初から複雑な攻撃グラフを作るより、既存サンプルのノード名とエッジ名を自社データに合わせて少しずつ変える方が安全です。特に、エッジの向きは結果に大きく影響します。「Group contains User」と「User belongs to Group」は見た目が似ていても、クエリの方向が逆になります。
コスト面で確認すべきこと
Microsoft Sentinel custom graphsは、検証時にもコスト確認が必要です。公式の課金情報では、カスタムグラフの操作は消費ベースで、グラフ操作がコンピュート時間単位で課金されると説明されています。対象には、VS Code Notebookでのグラフ作成、Notebookでのグラフクエリ、DefenderポータルのSentinel graphs experienceからのクエリ、Graph Query APIsでのクエリなどが含まれます。(Microsoft Learn)
また、グラフのノードやエッジを構築するためのNotebook/Sparkコンピュートやデータ変換、データレイクストレージは、既存のSentinel data lakeメーターに基づいて別途課金されるとされています。(Microsoft Learn)
コストを抑えるには、次の点を決めてから検証しましょう。
| 項目 | 推奨される考え方 |
|---|---|
| 対象テーブル | 最初はEntra、メール、端末など1〜2領域に絞る |
| データ期間 | 直近7日、30日など検証目的に合わせて限定する |
| 更新頻度 | リアルタイム性が不要なら日次や週次から始める |
| Spark pool | 開発・軽量検証はSmall、結合や集計が多い場合はMedium以上を検討 |
| クエリ | LIMITを使い、広すぎる探索を避ける |
| ジョブ | 不要な定期実行を放置しない |
VS Code NotebookのランタイムプールにはSmall、Medium、Largeがあり、用途や性能、コストに影響します。公式情報では、Smallは開発・テスト・軽量分析、MediumはETLや結合・集計・機械学習、Largeは大規模で時間が重要な処理向けと整理されています。(Microsoft Learn)
移行・展開時の注意点
Microsoft Sentinel custom graphsを展開する際は、機能の有効化よりも「運用設計」が重要です。特に次の点は、後から修正しづらい部分です。
data lakeのオンボード先を慎重に選ぶ
Microsoft Sentinel data lakeは、オンボード時に指定したAzureサブスクリプションとリソースグループに紐づきます。プロビジョニング後の移行ができないため、検証環境と本番環境の境界、課金管理、管理責任者を先に決めてください。(Microsoft Learn)
一時グラフと永続グラフを混同しない
Notebookで対話的に作ったグラフは、セッション終了時に消える前提で扱います。チームで再利用するグラフは、graph jobとして保存し、オンデマンドまたはスケジュール実行で再構築します。オンデマンドスケジュールで作成したグラフは、公式情報では既定の保持期間が30日で、期限切れ後に削除されると説明されています。(Microsoft Learn)
スケジュール更新の頻度を決める
毎分、毎時、毎週、毎日、毎月といった繰り返し頻度を選べますが、調査シナリオに対して過剰な頻度は避けるべきです。IDグループ構造の棚卸しであれば日次や週次、進行中のインシデント調査に近い用途なら手動実行や短い間隔を検討するなど、目的に合わせて設計します。(Microsoft Learn)
プレビュー機能として変更に備える
GQLサポートはプレビューで、構文や機能が変更される可能性があります。運用Notebookやクエリは、属人化しないようにGitなどで管理し、変更履歴を残しましょう。特に、SOCの手順書にGQLを組み込む場合は、「プレビュー機能のため定期的に公式ドキュメントを確認する」運用を入れておく必要があります。(Microsoft Learn)
失敗しやすいポイントと対策
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| データ権限を確認せずにグラフを作る | 一部データが欠けた不完全なグラフになる | 使うテーブルごとに読み取り権限を確認する |
| 目的を決めずに大きなグラフを作る | 見づらく、コストも増える | 「何を調査したいか」を1文で定義してから設計する |
| エッジ方向を曖昧にする | クエリ結果が想定と逆になる | Group contains Userなど関係名を明確にする |
| Notebookだけで運用する | セッション終了でグラフが消える | 共有用はgraph jobで永続化する |
| 更新頻度を高くしすぎる | 不要なコストやジョブ混雑が発生する | 日次・週次から始め、必要時だけ頻度を上げる |
| プレビュー仕様を固定前提で使う | 将来の変更でクエリやNotebookが動かなくなる | 公式更新日と検証結果を運用メモに残す |
| 結果を可視化だけで判断する | 欠落や偏りに気づきにくい | 表形式結果、JSON、元テーブルを併せて確認する |
特に「グラフに表示されない＝存在しない」と判断するのは危険です。表示されない理由には、権限不足、データ未取り込み、スナップショット時点の違い、クエリ条件、エッジ定義の誤りなどがあります。インシデント対応で使う場合は、必ず元ログやKQL調査と突き合わせてください。
まず検証するならこの順番がおすすめ
Microsoft Defender環境でMicrosoft Sentinel custom graphsを試すなら、次の順番で進めると安全です。
| 順番 | 作業 | 完了条件 |
|---|---|---|
| 1 | Microsoft Sentinel data lakeのオンボード状況を確認 | Defenderポータルでdata lake設定を確認できる |
| 2 | VS CodeにMicrosoft Sentinel拡張機能とJupyter拡張機能を導入 | Sentinel拡張機能にサインインできる |
| 3 | Entra IDコネクタと対象テーブルを確認 | EntraUsers、EntraGroups、EntraMembersなどを読み込める |
| 4 | サンプルに近いNotebookを作成 | ノード・エッジのスキーマを表示できる |
| 5 | 小さなGQLクエリで確認 | 100件程度の結果を可視化できる |
| 6 | graph jobでオンデマンド保存 | DefenderポータルのSentinel Graphsで見える |
| 7 | 更新頻度とコストを評価 | 運用に必要な頻度と権限を決められる |
最初のゴールは「きれいなグラフを作ること」ではありません。自社のセキュリティ運用で、どの問いに対してグラフがKQLや通常のアラート調査より有効かを見極めることです。
Microsoft Defender管理者が今すぐ確認すべきこと
Microsoft Sentinel custom graphsは、Microsoft Defenderポータル上の調査体験を強化する機能として注目できます。ただし、効果を出すには、データレイク、権限、Notebook、GQL、ジョブ、コストをまとめて設計する必要があります。
まず確認すべき項目は次の4つです。
- Microsoft Sentinel data lakeが有効化され、適切なサブスクリプションとリソースグループに紐づいているか
- カスタムグラフに使うデータテーブルを、対象ユーザーが読み取れるか
- Notebookで作る一時グラフと、graph jobで永続化する共有グラフを分けて運用できるか
- 検証シナリオを、Entra IDの入れ子グループやサービスプリンシパル調査など具体的な用途に絞れているか
結論として、Microsoft Defender環境でMicrosoft Sentinelを使っている組織は、今回の「Get started with custom graphs in Microsoft Sentinel (preview)」を、単なる新機能紹介ではなく、グラフベース調査を運用に組み込むための準備資料として扱うべきです。まずは小さなID関係グラフから検証し、効果、権限、コスト、更新頻度を確認したうえで、フィッシング、OAuth権限昇格、攻撃経路分析などの高度なシナリオへ広げていくのが現実的です。
コメント