Microsoft Sentinel custom graph は、従来のKQL検索を置き換えるものではなく、ユーザー、端末、IP、メール、アプリ、クラウド資産などの「関係性」をたどって脅威ハンティングを強化するための機能です。管理者がまず確認すべきことは、機能そのものの有効化よりも、Sentinel data lake の準備、権限設計、監査ログ、コスト影響、SOCメンバーへの周知です。特に、カスタムグラフの作成・永続化・参照では必要なロールが異なるため、検証環境で権限と監査を確認してから本番運用に広げるのが安全です。
2026年6月24日ごろに確認された Microsoft Sentinel Blog の「A guide to innovating threat hunting with Microsoft Sentinel custom graph」は、分類としては Notice にあたる情報です。廃止や強制移行の告知として受け取るより、Microsoft Sentinel の脅威ハンティングをグラフ型の調査へ広げるために、管理者が運用準備を始めるべき案内として読むのが現実的です。公式ブログでは、Sentinel graph を「関係性を中心にデータを整理・検索する方法」と位置づけ、複雑なJOINで証拠をつなぐのではなく、複数ステップのつながりをたどって影響範囲や見落としやすい攻撃経路を把握する考え方が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Sentinel custom graphで管理者が最初に確認すべきこと
Microsoft Sentinel custom graph の確認ポイントは、単に「使えるかどうか」ではありません。実務では、誰がグラフを作成できるのか、どのデータを参照できるのか、作成・実行・削除が監査できるのか、既存のKQLハンティングやインシデント対応手順にどう組み込むのかが重要です。
Microsoft Learn では、custom graphs は Sentinel data lake と非Microsoftソースのデータを使い、接続されたデータを構築・検索・可視化して、攻撃経路や隠れた関係性を発見するための機能として説明されています。AIエージェントによる調査体験の文脈でも、グラフが知識コンテキストとして機能する点が示されています。(Microsoft Learn)
| 確認領域 | 管理者が見るべきこと | 放置した場合のリスク |
|---|---|---|
| 影響範囲 | Sentinel data lake、Defender portal、既存ワークスペース、データ保持設定 | 想定外のデータ参照、コスト増、SOC手順の混乱 |
| 権限 | 作成、永続化、検索、監査に必要なロールの分離 | 過剰権限、Scoped userの操作不可、監査不備 |
| データ | Entra ID、Microsoft 365、端末、メール、IP、外部ログの取り込み状況 | グラフに必要なノード・エッジが欠け、誤った調査結果になる |
| 監査 | Purview監査ログでグラフ操作を追えるか | 誰が何を検索・作成・削除したか説明できない |
| 移行 | 既存のKQL、ノートブック、ハンティング手順との役割分担 | グラフ化が目的化し、実運用に定着しない |
| 周知 | SOC、管理者、監査部門、ヘルプデスクへの説明 | 「新しい画面が増えた」だけで使われない |
今回のNoticeをどう受け止めるべきか
今回のポイントは、Microsoft Sentinel の脅威ハンティングが「ログの表を検索する」だけでなく、「エンティティ同士の関係をたどる」方向へ広がっていることです。
従来のKQLは、特定条件の抽出、集計、時系列分析に強い手段です。一方、custom graph は、複数のテーブルやデータソースにまたがる関係性を、ノードとエッジとして扱う調査に向いています。たとえば、あるフィッシングメールを起点に、受信者、クリック、URL、プロキシ許可、ダウンロード、プロセス実行、端末までをつなげて見るような調査です。Microsoft Learn でも、フィッシングメールのキルチェーンや業務コンテキストを加えた分析が代表的なシナリオとして示されています。(Microsoft Learn)
KQLとcustom graphの使い分け
| 用途 | KQLが向いている場面 | custom graphが向いている場面 |
|---|---|---|
| 初動調査 | 特定アラートやログの絞り込み | アラートに関係するユーザー、端末、IP、メールのつながりを把握 |
| 脅威ハンティング | IOC、時間帯、イベントID、失敗回数などの条件検索 | 攻撃者の移動経路、横展開、影響範囲の探索 |
| 報告 | 件数、傾向、時系列の説明 | 攻撃経路や影響範囲を図で説明 |
| 自動化 | 定型検知、集計、通知 | 関係性をもとにした調査支援やAIエージェント連携 |
| 移行判断 | 既存のKQLを継続利用 | 複雑なJOINが多く、調査に時間がかかるユースケースから導入 |
重要なのは、KQLをすべてグラフへ置き換えようとしないことです。まずは「複数のエンティティをたどらないと判断できない調査」に絞って、custom graph の効果を検証するのが現実的です。
影響範囲の確認：Sentinel data lakeが前提になる
Microsoft Sentinel custom graph を検討する前に、Sentinel data lake の状態を確認します。Microsoft Learn では、Microsoft Sentinel data lake はセキュリティ関連データを収集・保存・管理するテナント単位のリポジトリとして説明されています。また、data lake と graph は Microsoft Defender XDR、Microsoft Purview Data Security Investigations、Microsoft Purview Insider Risk Management などのソリューションで利用されるとされています。(Microsoft Learn)
管理者が最初に見るべき項目は次のとおりです。
| 確認項目 | 確認内容 | 判断基準 |
|---|---|---|
| Defender portal連携 | Microsoft Sentinel のプライマリワークスペースが Defender portal に接続されているか | 接続済みでなければ、graph関連機能の検証前に整備する |
| リージョン | data lake がプライマリ Sentinel ワークスペースと同じリージョンに作成される前提を理解しているか | データ所在地や社内ポリシーと矛盾しないか確認 |
| CMK | Customer-Managed Keys を使うワークスペースがあるか | 公式情報では、data lake のデータにCMKがサポートされない点が注意点として示されている |
| 課金 | Azureサブスクリプションとリソースグループの責任者が明確か | 検証前に課金管理者とSOC責任者で合意する |
| 既存データ | 既存ログがそのまま過去分までグラフ化されると誤解していないか | data lake有効化後の取り込みや保持設定を確認する |
| 取り込み遅延 | 初回有効化やティア切り替え後のデータ反映時間を見込んでいるか | 検証当日の結果だけで失敗と判断しない |
Sentinel data lake のオンボードでは、同じリージョンのワークスペースがdata lakeに関連付けられること、Microsoft 365データのリージョンに関する同意が必要になる場合があること、初回有効化や取り込みティアの切り替え後にデータ表示まで時間がかかることなどが公式ドキュメントに記載されています。(Microsoft Learn)
権限確認：作成・永続化・検索で必要ロールが違う
custom graph の管理で最も失敗しやすいのが、権限を「Sentinelの閲覧権限があれば十分」と考えてしまうことです。Microsoft Learn では、Microsoft Sentinel SIEM へのアクセスは Azure RBAC、Microsoft Sentinel data lake には Defender XDR unified RBAC のカスタムロールを使うという整理が示されています。(Microsoft Learn)
custom graph の操作では、作成、永続化、検索で必要な権限が分かれます。公式ドキュメントでは、ノートブックでグラフをモデル化・構築するには Microsoft Sentinel data collection に対する data manage 権限を持つ Microsoft Defender XDR unified RBAC のカスタムロール、永続化には Security operator、Security administrator、Global administrator のいずれか、永続化済みグラフの検索には security data basics read 権限を持つカスタムロールが必要とされています。(Microsoft Learn)
| 操作 | 主な対象者 | 必要な権限の考え方 | 管理者の確認事項 |
|---|---|---|---|
| グラフを設計・構築する | 脅威ハンター、検知エンジニア | Defender XDR unified RBAC の data manage 権限 | 本当に作成権限が必要なメンバーだけに絞る |
| グラフをテナントに永続化する | SOCリード、Sentinel管理者 | Security operator、Security administrator、Global administrator など | 変更申請やレビューを通してから永続化する |
| 永続化済みグラフを検索する | SOCアナリスト | security data basics read 権限 | 調査に必要な範囲だけ読めるか確認する |
| 監査ログを見る | 監査担当、セキュリティ管理者 | Purview監査ログを参照できるロール | 操作証跡を定期的に確認できる体制にする |
また、公式ドキュメントでは、グラフで使うデータを読む権限がなければそのデータはグラフに含まれないこと、Sentinel scope に制限されたユーザーは custom graph を作成できないことも明記されています。(Microsoft Learn)
権限設計で避けるべきパターン
避けたいのは、検証を急ぐあまり Global administrator や Security administrator をSOCメンバーへ広く付与することです。高権限ロールは便利ですが、調査、開発、監査、運用の責任分界が曖昧になります。
実務では、次のように分けると管理しやすくなります。
| 役割 | 推奨する運用 |
|---|---|
| グラフ作成者 | 検証用ワークスペースでスキーマを作成し、レビュー後に本番へ反映 |
| グラフ公開者 | 永続化やスケジュール実行を承認済み手順で実施 |
| グラフ利用者 | 既存インシデント対応手順に沿って検索・可視化のみ実行 |
| 監査担当 | Purview監査ログで作成、削除、クエリ実行を確認 |
| 課金管理者 | data lake、ジョブ、保持期間、取り込み量の変化を確認 |
監査確認：Purviewでグラフ操作を追跡できるか
custom graph は、セキュリティ調査に使う強力な機能です。そのため、誰がどのグラフを作成し、どのクエリを実行し、何を削除したのかを説明できる状態にしておく必要があります。
Microsoft Learn では、Microsoft Sentinel data lake と graph のアクティビティは Microsoft Purview の監査ログで検索・確認できると説明されています。監査対象には、data lake へのKQLアクセス、ノートブック実行、ジョブの作成・編集・実行・削除、グラフクエリ実行、MCPツールの作成や実行などが含まれます。(Microsoft Learn)
| 監査対象 | 代表的な確認内容 | 管理者が決めるべきこと |
|---|---|---|
| グラフクエリ実行 | 誰が、いつ、どのグラフを検索したか | 調査目的外の利用をどう検知するか |
| グラフ作成・削除 | 誰がグラフシナリオを作成・削除したか | 変更申請やレビュー記録と突合できるか |
| ノートブック実行 | どのデータを読み、何を書き出したか | 検証用と本番用の扱いを分けるか |
| ジョブ実行 | スケジュール実行や手動実行の履歴 | 失敗時の通知先、再実行ルールを決める |
| データ読み取り | どのテーブルが参照されたか | 高機密データの扱いを監査できるか |
Purview の監査ログに記録される Microsoft Sentinel graph 関連イベントとして、GraphScenarioCreated、GraphScenarioDeleted、GraphQueryRun が公開情報に含まれています。監査ログを確認する担当者には、Exchange Online の View-Only Audit Logs または Audit Logs ロールが必要です。(Microsoft Learn)
監査で最低限チェックしたい観点
本番利用前に、次の3点はテストしておくべきです。
| テスト | 確認方法 | 合格基準 |
|---|---|---|
| グラフ検索の記録 | テストユーザーでグラフクエリを実行し、Purview監査ログで確認 | 実行ユーザー、時刻、操作種別を追跡できる |
| グラフ作成・削除の記録 | 検証用グラフを作成・削除し、イベントを確認 | 変更作業の証跡として利用できる |
| 権限不足時の挙動 | 読み取り権限の違うユーザーで同じ調査を実行 | 見えるデータの差を管理者が説明できる |
監査ログが残ることと、監査として使えることは別です。SOCや内部監査部門が後から読めるように、グラフ名、用途、所有者、変更理由を命名規則や台帳で管理しておくと、監査対応が楽になります。
データとコストの確認：グラフ化する前に取り込み設計を見る
custom graph は、データがそろって初めて効果を発揮します。たとえば、フィッシング調査をしたいのにメール、URLクリック、プロキシ、端末プロセス、ユーザー情報の一部が欠けていれば、グラフは途中で途切れます。逆に、必要以上に何でもdata lakeへ送ると、保持期間やジョブ実行の管理が難しくなります。
Microsoft Learn では、Sentinel data lake のコネクタ設定により、データを analytics tier と data lake tier の両方に送る、または data lake tier のみに送る構成が説明されています。data lake 有効化後、既存コネクタはanalytics tierへ送信しつつdata lake tierへミラーされる構成が基本となり、同じ保持期間でミラーされたdata lakeデータには追加課金が発生しないと説明されています。ただし、有効化前の既存データはミラーされない点に注意が必要です。(GitHub)
| 確認項目 | 実務上の見方 |
|---|---|
| どのテーブルが必要か | ユースケースごとに、ユーザー、端末、IP、メール、URL、クラウド資産など必要なノードを洗い出す |
| 関係性を作れるか | 「ユーザーが端末にサインイン」「メールがURLを含む」「端末がIPへ接続」など、エッジにできる項目を確認 |
| 保持期間は足りるか | 攻撃の初期侵入から検知までの期間を考え、調査に必要な履歴を保持する |
| analytics tierとの役割分担 | 高速検知が必要なデータはanalytics tier、長期分析はdata lake tierなどに分ける |
| 外部データの扱い | CMDB、ID管理台帳、資産重要度、拠点情報などを加える場合はデータ所有者を決める |
| コスト管理 | 取り込み量、保持期間、ジョブ実行、検証用データの扱いを定期レビューする |
データ設計で大切なのは、最初から全社の完全なセキュリティグラフを作ろうとしないことです。まずは「フィッシング」「侵害端末の横展開」「特権IDの悪用」「重要サーバーへの到達経路」など、調査目的を1つに絞ると設計しやすくなります。
移行確認：既存の脅威ハンティングをどう整理するか
custom graph の導入は、既存のMicrosoft Sentinel運用を捨てる話ではありません。むしろ、既存のKQL、分析ルール、ブック、プレイブック、ノートブックを整理し、「関係性を見ると効果が大きい調査」をcustom graphへ寄せるのが適切です。
Microsoft Learn では、custom graph の作成に Visual Studio Code の Microsoft Sentinel 拡張機能と Jupyter 拡張機能、Sentinel data lake の権限が必要とされています。作成手順として、ノートブックでグラフをモデル化し、グラフジョブとして永続化し、Microsoft Sentinel のグラフ画面で表示・管理する流れが示されています。(Microsoft Learn)
移行前チェックリスト
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 既存調査の棚卸し | よく使うKQL、ハンティングクエリ、インシデント対応手順を一覧化 | 移行候補リスト |
| ユースケース選定 | JOINが複雑、関係性の説明が難しい調査を抽出 | 初回パイロットテーマ |
| データ確認 | 必要なテーブル、保持期間、外部データ、権限を確認 | データ要件表 |
| スキーマ設計 | ノード、エッジ、プロパティ、命名規則を決める | グラフ設計書 |
| 検証 | 過去インシデントやテストデータで再現性を確認 | 検証結果、改善点 |
| 本番化 | 永続化、ジョブ化、監査、運用手順を整える | 運用手順書 |
| 教育 | SOCメンバーに使い方と制限を説明 | ハンティング手順、FAQ |
移行対象に向いているユースケース
次のような調査は、custom graph の効果を検証しやすい領域です。
| ユースケース | グラフ化で見たい関係性 |
|---|---|
| フィッシング対応 | メール、受信者、クリックURL、プロキシ、端末、プロセス |
| 侵害端末の横展開 | 端末、ユーザー、認証、リモート接続、管理共有、接続先IP |
| 特権IDの悪用 | 管理者アカウント、ロール、サインイン元、操作対象、重要資産 |
| クラウド資産の露出 | サブスクリプション、リソース、ID、権限、ネットワーク経路 |
| インシデント報告 | アラート、エンティティ、影響範囲、復旧対象、残存リスク |
反対に、単純なログ抽出や件数集計だけのクエリは、無理にグラフ化する必要はありません。既存のKQLで短く正確に書けるものは、そのまま残す方が運用負荷を抑えられます。
Visual Studio CodeとDefender portalの確認
custom graph の作成は、主に Visual Studio Code の Microsoft Sentinel 拡張機能と Jupyter ノートブックを使います。Microsoft Learn では、VS Code上でMicrosoft Sentinel拡張機能にサインインし、ノートブックを作成し、Spark compute poolを選択して作業する流れが説明されています。(Microsoft Learn)
一方、作成済みのグラフの可視化や対話的な調査は、Microsoft Defender portal の Microsoft Sentinel > Graphs から行う構成です。グラフ画面では、作成済みのcustom graphを一覧し、スキーマを確認し、Graph Query Languageを使ってクエリ・可視化できます。(Microsoft Learn)
| 領域 | 確認すること |
|---|---|
| VS Code | Microsoft Sentinel拡張機能、Jupyter拡張機能、サインイン、ノートブック保存場所 |
| 実行環境 | Spark compute pool、接続先data lake、実行権限 |
| Defender portal | Microsoft Sentinel > Graphs が表示されるか |
| スキーマ | ノード、エッジ、プロパティがSOCメンバーに理解できるか |
| エクスポート | 調査結果を既存の報告書やチケット運用に載せられるか |
| 制限ユーザー | Sentinel Scope のユーザーが期待どおりアクセス制限されるか |
公式ドキュメントでは、Sentinel Scope のユーザーは、Security Reader、Security Operator、Security Admin、Global Admin のようなスコープを上書きする高権限ロールを持たない限り、Sentinel Graphsへアクセスできない旨が示されています。スコープ設計を使っている組織では、ここが問い合わせの原因になりやすいため、事前にヘルプデスク向けFAQへ入れておくとよいでしょう。(Microsoft Learn)
API利用を想定する場合の確認
将来的に、custom graph を自動化パイプラインや社内ポータル、調査支援ツールから利用する場合は、Graph REST API の確認も必要です。Microsoft Learn では、Graph REST APIs により、Microsoft Sentinel data lake 内のcustom graphを一覧・検索でき、任意のHTTPクライアント、自動化パイプライン、カスタムアプリから操作できると説明されています。認証には Microsoft Entra ID の OAuth 2.0 bearer token を使います。(GitHub)
API利用時は、次の点を管理者側で決めておきます。
| 確認項目 | 管理者の判断 |
|---|---|
| アプリ登録 | 誰がアプリを登録し、所有者を誰にするか |
| 認証方式 | ユーザー委任か、アプリケーション権限か |
| シークレット管理 | 証明書、Managed Identity、Key Vaultなどの利用方針 |
| 呼び出し元 | 自動化基盤、SOCツール、社内ポータルを許可リスト化するか |
| 監査 | API経由の利用をPurview監査やアプリログで追跡できるか |
| データ持ち出し | グラフ結果を外部システムへ保存する場合の承認ルール |
API連携は便利ですが、調査データの自動取得や外部保存につながりやすい領域です。最初の段階では、SOC内部の検証環境に限定し、本番の自動化は監査とデータ保護の確認後に進めるのが安全です。
管理者向けチェックリスト
事前確認
| チェック | 確認内容 |
|---|---|
| Microsoft Sentinel のプライマリワークスペースを把握している | data lakeとgraphの基準になるワークスペースを確認 |
| Defender portal 連携が完了している | Microsoft SentinelをDefender portal側で運用できる状態にする |
| data lake のリージョンとデータ所在地を確認した | Microsoft 365や外部データの所在地要件を確認 |
| CMK利用ワークスペースの扱いを確認した | data lakeでの暗号化要件と社内ポリシーを照合 |
| 課金責任者を決めた | Azureサブスクリプション、リソースグループ、保持期間を確認 |
| 対象データソースを決めた | Entra ID、Microsoft 365、端末、メール、外部ログなどを整理 |
権限確認
| チェック | 確認内容 |
|---|---|
| 作成者と利用者を分けた | グラフ設計者、公開者、閲覧者を同じ権限にしない |
| Defender XDR unified RBAC を確認した | data lake向けのread/manage権限を整理 |
| 高権限ロールを最小化した | Security administrator や Global administrator の常用を避ける |
| Sentinel Scope の影響を確認した | スコープ付きユーザーが作成・参照できないケースを把握 |
| データ読み取り権限を検証した | 権限不足でグラフにデータが欠けないか確認 |
監査確認
| チェック | 確認内容 |
|---|---|
| Purview監査ログを有効にしている | 監査ログ検索の前提を確認 |
| 監査担当者に必要ロールを付与した | View-Only Audit Logs または Audit Logs ロールを確認 |
| GraphQueryRun を確認できる | グラフクエリ実行履歴を追跡 |
| GraphScenarioCreated / Deleted を確認できる | 作成・削除の証跡を追跡 |
| ノートブックとジョブの実行履歴を確認できる | 本番運用後の説明責任を確保 |
移行・運用確認
| チェック | 確認内容 |
|---|---|
| 初回ユースケースを1つに絞った | フィッシング、横展開、特権IDなどから選定 |
| 既存KQLを棚卸しした | グラフ化するもの、残すものを分ける |
| スキーマ命名規則を決めた | ノード、エッジ、プロパティ名を統一 |
| 変更管理に載せた | 永続化やジョブ化をレビュー対象にする |
| 障害時の切り戻しを決めた | 既存KQL手順に戻れるようにする |
| SOC向け手順を更新した | インシデント対応手順、教育資料、FAQへ反映 |
SOCと関係部門へ周知すべき内容
custom graph は、SOCアナリストだけでなく、Sentinel管理者、ID管理者、ネットワーク担当、監査部門、場合によっては個人情報保護やコンプライアンス部門にも影響します。特に、複数データソースをつないで可視化するため、これまで別々に見ていた情報が1つの調査画面に集約される可能性があります。
周知では、機能紹介よりも「運用上どう変わるか」を伝えると混乱を減らせます。
| 対象 | 伝える内容 |
|---|---|
| SOCアナリスト | KQLを置き換えるものではなく、関係性調査に使うこと |
| Sentinel管理者 | 権限、監査、ジョブ、data lake保持期間を管理すること |
| ID管理者 | Entra IDや特権ロールの情報が調査文脈で使われること |
| ネットワーク担当 | IP、プロキシ、通信ログがグラフ調査に使われる可能性 |
| 監査部門 | Purview監査ログで作成、削除、クエリ実行を確認できること |
| 経営・管理職 | 攻撃経路や影響範囲を説明しやすくなる一方、運用準備が必要なこと |
社内周知文の例
Microsoft Sentinel の脅威ハンティング強化として、Microsoft Sentinel custom graph の検証を開始します。
本機能は、ユーザー、端末、IP、メール、クラウド資産などの関係性を可視化し、攻撃経路や影響範囲を把握しやすくするものです。
既存のKQL検索や分析ルールを直ちに置き換えるものではありません。まずは検証環境で、フィッシング対応や侵害端末の横展開調査など、関係性分析が有効なユースケースに限定して確認します。
作成、永続化、検索、監査に必要な権限は分けて管理し、操作履歴は Microsoft Purview の監査ログで確認します。
本番展開前に、対象データ、権限、監査、コスト、運用手順をレビューします。
よくある失敗と回避策
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| グラフを作ったが調査に使われない | SOCの既存手順に組み込んでいない | インシデント対応手順のどの場面で使うか明記する |
| 権限不足でデータが欠ける | グラフ作成者や利用者の読み取り範囲が不十分 | 検証時に複数ロールで同じ調査を実行して差分を見る |
| 権限を広く付けすぎる | 作成・検索・監査を同じ担当者に任せている | ロールを分離し、高権限ロールは承認制にする |
| コスト影響が後から問題になる | data lake保持期間やジョブ実行を管理していない | パイロット段階から課金管理者を入れる |
| 監査ログが使いにくい | グラフ名や所有者が不明確 | 命名規則、台帳、変更申請番号を運用に入れる |
| 既存KQLを無理に置き換える | グラフ化の目的が曖昧 | 複雑なJOINや影響範囲調査だけを優先する |
| プレビュー機能を本番前提で広げる | 制限や変更可能性を考慮していない | 検証範囲、サポート方針、切り戻し手順を決める |
管理者が次に取るべき行動
まずは、Microsoft Sentinel custom graph を全社展開の計画としてではなく、1つの脅威ハンティング改善テーマとして扱うのがよい進め方です。最初の2週間程度で、フィッシング対応や侵害端末の横展開など、関係性分析の効果が見えやすいユースケースを1つ選びます。
次に、必要なデータがSentinel data lakeにそろっているか、作成者・利用者・監査担当者の権限を分けられるか、Purview監査ログで操作を追跡できるかを確認します。そのうえで、VS Codeのノートブックで小さくグラフを作成し、既存KQLでの調査時間や説明しやすさと比較します。
Microsoft Sentinel custom graph の価値は、「新しい機能を使うこと」ではなく、複雑な攻撃経路や影響範囲を、SOCが短時間で説明・判断できるようにすることです。管理者は、機能検証より先に、権限、監査、データ、コスト、周知の5点を整え、既存の脅威ハンティング運用に無理なく組み込む準備を進めましょう。
コメント