Microsoft DefenderでMicrosoft Sentinelを運用している管理者にとって、「Custom graphs in Microsoft Sentinel-Overview (preview)」の要点はシンプルです。これは、Sentinel data lake上のセキュリティデータやMicrosoft以外のデータを使い、組織独自のセキュリティグラフを作成・検索・可視化できるプレビュー機能です。
従来のようにログやアラートを個別に追うだけでなく、ユーザー、デバイス、IPアドレス、URL、プロセス、サービスプリンシパルなどの関係性を「点と線」でたどれるようになります。特に、侵害範囲の把握、フィッシング調査、C2通信の追跡、権限昇格経路の確認といった調査で効果を発揮します。Microsoft Learnの該当ページは2026年5月14日に更新されており、機能はpreviewとして案内されています。(Microsoft Learn)
ただし、Custom graphsは「有効にすれば自動で検知精度が上がる機能」ではありません。Sentinel data lakeのオンボード、Microsoft Defenderポータル側の構成、RBAC権限、Visual Studio Code環境、グラフジョブのスケジュール設計まで含めて、管理者と開発者が事前に確認すべき項目があります。
まず押さえるべき結論
Custom graphs in Microsoft Sentinelは、Microsoft Defenderポータル内のMicrosoft Sentinelで、組織固有の調査シナリオに合わせたセキュリティグラフを作るための機能です。
主な変化は、次の3点です。
| 変更点 | 実務上の意味 |
|---|---|
| Sentinel data lakeのデータをグラフ化できる | ログを単体で見るのではなく、ユーザー、端末、IP、URL、権限、プロセスなどの関係を追跡できる |
| Jupyter NotebookとPySparkでグラフを作成できる | セキュリティ分析者だけでなく、検知エンジニアやデータエンジニアの関与が重要になる |
| Microsoft Defenderポータルでグラフを可視化・検索できる | SOCアナリストが調査画面上で関係性をたどり、影響範囲を確認しやすくなる |
Microsoftの公式説明では、Custom graphsはSentinel data lakeとMicrosoft以外のソースを含むデータを使い、隠れたパターンや攻撃経路を見つけるための機能とされています。また、作成したグラフはAIを活用したエージェント体験にも知識コンテキストを提供し、調査の高速化やblast radiusの把握に役立つと説明されています。(Microsoft Learn)
Microsoft Defenderとの関係
Custom graphsはMicrosoft Sentinelの機能ですが、運用上はMicrosoft Defenderポータルとの関係を無視できません。
Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、Microsoft Defender XDRを利用していない顧客やE5ライセンスを持たない顧客でも、Microsoft SentinelをDefenderポータルで利用できると案内されています。また、Microsoft Sentinelは2027年3月31日以降、Azureポータルではサポートされず、Microsoft Defenderポータルのみで利用される予定です。(Microsoft Learn)
そのため、Custom graphsを検証する企業は、単に新機能を試すだけでなく、Sentinel運用全体をDefenderポータル中心に移行する流れの中で位置付ける必要があります。
特に確認すべきなのは、次の点です。
| 確認項目 | なぜ重要か |
|---|---|
| SentinelワークスペースがDefenderポータルに接続されているか | Custom graphsの可視化やSentinel graph体験はDefenderポータル側で利用するため |
| プライマリワークスペースの設計 | data lakeのリージョンや複数ワークスペース構成に影響するため |
| Defender XDR連携の有無 | インシデント、Advanced Hunting、Sentinelデータの統合表示に影響するため |
| Azureポータル中心の運用手順 | 将来的なDefenderポータル移行に合わせて手順書を更新する必要があるため |
Custom graphsで何ができるのか
Custom graphsでは、セキュリティデータをノードとエッジで表現します。
たとえば、フィッシング調査であれば、次のような関係をグラフ化できます。
| ノードの例 | エッジの例 |
|---|---|
| メール、受信者、URL、端末、プロセス | 受信した、クリックした、許可された、実行された |
| ユーザー、IPアドレス、MITRE ATT&CKの技術 | 利用した、関連した、複数技術に該当した |
| サービスプリンシパル、権限、ディレクトリロール | 付与した、昇格した、到達した |
公式ドキュメントでは、フィッシングメールのkill chain、DNS C2 beaconの調査、MITRE技術にまたがる行動分析、OAuth権限昇格の追跡などが代表的なシナリオとして示されています。(Microsoft Learn)
実務では、次のような問いに答えたいときに向いています。
| 調査したいこと | Custom graphsが有効な理由 |
|---|---|
| あるURLをクリックしたユーザーと、その後に影響を受けた端末を知りたい | メール、URL、ユーザー、端末、プロセスの関係をたどれる |
| あるIPアドレスに関連するユーザーや端末を横断的に見たい | IPを起点に複数データソースの関係を追跡できる |
| 権限昇格がどのアカウントやロールを経由したか確認したい | サービスプリンシパル、権限、ロールの連鎖をモデル化できる |
| アラート単体では見えない攻撃経路を把握したい | ノード間の複数ホップ関係を検索できる |
ポイントは、すべてのログをグラフ化することではありません。調査したい問いを先に決め、その問いに必要なエンティティと関係だけをモデル化することが重要です。
作成から可視化までの基本フロー
Custom graphsの作成は、主にVisual Studio Code上のJupyter Notebookを使って行います。Microsoft Sentinel Visual Studio Code拡張機能により、Sentinel data lakeのデータをPySparkで扱い、ノードとエッジを定義してグラフを作成します。(Microsoft Learn)
基本的な流れは次のとおりです。
| 手順 | 内容 | 管理上の確認ポイント |
|---|---|---|
| グラフを設計する | ノード、エッジ、利用するテーブル、更新頻度を決める | 目的が曖昧なまま作り始めない |
| Notebookで作成する | VS CodeのJupyter NotebookでPySparkコードを実行する | 実行権限、Sparkプール、対象テーブルを確認する |
| 対話的に検証する | Notebookセッション内でグラフを作成・確認する | この段階のグラフは一時的なものとして扱う |
| グラフジョブをスケジュールする | 定期実行してグラフをmaterializeする | 更新頻度、ジョブ失敗時の監視、コストを確認する |
| Defenderポータルで可視化する | Microsoft Sentinel > Graphsから検索・可視化する | 利用者にクエリ権限があるか確認する |
公式ドキュメントでは、Notebookの対話セッション中に作成されたグラフは一時的であり、チームで共有して継続利用するにはグラフジョブをスケジュールしてmaterializeする必要があると説明されています。materializeされたグラフは、Microsoft Defenderポータル内のSentinel graph体験、VS Code Notebook、Graph query APIsから利用できます。(Microsoft Learn)
管理者が確認すべき前提条件
Custom graphsを使う前に、Microsoft Sentinel data lakeとMicrosoft Sentinel graphの前提条件を確認する必要があります。
Microsoft Sentinel data lakeは、テナント全体のセキュリティ関連データを収集・保存・管理するリポジトリとして説明されています。data lakeとgraphのオンボードには、Microsoft DefenderとMicrosoft Sentinelの構成、Azureサブスクリプションとリソースグループ、Defenderポータルに接続されたSentinelのプライマリワークスペースなどが必要です。(Microsoft Learn)
特に重要な確認点は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| Defenderポータル接続 | SentinelのプライマリワークスペースがMicrosoft Defenderポータルに接続されているか |
| data lakeのオンボード | System > Settings > Microsoft Sentinel > Data lake から状態を確認する |
| リージョン | data lakeはプライマリSentinelワークスペースと同じリージョンにプロビジョニングされる |
| 暗号化ポリシー | Customer-Managed Keysを使う組織では、Sentinel data lakeの制約を事前確認する |
| 課金 | data lakeの利用により、検索ジョブ、クエリ、補助ログ、長期保持などの課金メーターが変わる可能性がある |
| 管理ID | msg-resources-<guid> 形式のマネージドIDが作成されるため、削除や権限剥奪をしない |
公式ドキュメントでは、Customer-Managed KeysはMicrosoft Sentinel data lakeに保存されるデータではサポートされず、CMKを適用しているSentinelワークスペースはdata lake体験からアクセスできないと説明されています。また、data lakeの有効化後、同一リージョンでDefenderに接続されたワークスペースがdata lakeに自動的に関連付けられる点にも注意が必要です。(Microsoft Learn)
権限設計で確認すべきポイント
Custom graphsでは、作成、永続化、検索で必要な権限が異なります。ここを曖昧にすると、「Notebookでは見えるがDefenderポータルでは検索できない」「データが欠けたグラフになる」「スコープ制限により作成できない」といった問題が起きます。
公式ドキュメントでは、Custom graphsの操作に必要な権限として、Microsoft Defender XDR unified RBACやMicrosoft Entra IDロールが示されています。(Microsoft Learn)
| 操作 | 必要な権限の考え方 |
|---|---|
| Notebookでグラフをモデル化・作成する | Microsoft Sentinel data collectionに対するdata manage権限を持つカスタムMicrosoft Defender XDR unified RBACロール |
| グラフをテナントに永続化する | Security operator、Security administrator、Global administratorのいずれか |
| 永続化されたグラフを検索する | Microsoft Sentinel data collectionに対するsecurity data basics read権限を持つカスタムMicrosoft Defender XDR unified RBACロール |
さらに、グラフに使うデータセットを読み取る権限がない場合、そのデータはグラフに含まれません。Sentinelスコープで制限されたユーザーはCustom graphを作成できない点も重要です。(Microsoft Learn)
運用では、次のように分けて権限を設計すると安全です。
| 役割 | 推奨される権限設計 |
|---|---|
| SOCアナリスト | 永続化されたグラフの検索・可視化に必要な読み取り権限 |
| 検知エンジニア | Notebookでのグラフ作成、検証に必要なdata manage権限 |
| Sentinel管理者 | data lake、ワークスペース、ジョブ、ロール割り当てを管理する権限 |
| セキュリティ責任者 | 本番利用するグラフの承認、データ範囲、アクセス範囲の確認 |
最小権限の原則を守り、作成者と閲覧者の権限を分けることが現実的です。
開発者が知っておくべき実装ポイント
Custom graphsの実装では、Notebook上でグラフスキーマ、データ変換、ノード、エッジを定義します。Graph Builder API Referenceでは、Sentinel graphを扱うクラスにより、グラフスキーマの定義、Sentinel data lakeからのノード・エッジ変換、グラフの公開、クエリ、 advanced graph algorithmsの実行ができると説明されています。(Microsoft Learn)
開発時に特に注意したいのは、GraphBuilderではなくGraphSpecBuilderを新しいコードで使う点です。公式リファレンスでは、GraphBuilderエイリアスは非推奨で、将来のバージョンで削除される予定とされています。(Microsoft Learn)
実装時の判断基準は次のとおりです。
| 判断項目 | 推奨 |
|---|---|
| ノード設計 | ユーザー、端末、IP、URL、メール、サービスプリンシパルなど、調査の起点になりやすいものを選ぶ |
| エッジ設計 | 「クリックした」「接続した」「実行した」「付与した」など、調査で意味を持つ関係を定義する |
| プロパティ | すべての列を入れず、検索・絞り込み・説明に必要な属性を優先する |
| データ量 | まずは限定期間・限定テーブルで検証し、性能と費用を確認してから拡張する |
| 更新頻度 | 調査用途なら数時間〜日次、準リアルタイムに近い用途ならジョブ負荷と費用を慎重に確認する |
| バージョン管理 | Notebook、グラフスキーマ、GQLクエリをリポジトリで管理する |
「何でもノード化する」設計は失敗しやすいです。関係が多すぎるグラフは見た目が複雑になり、アナリストが判断しにくくなります。最初は、1つの調査シナリオに絞って小さく始めるのが安全です。
GQLでグラフを検索する
Custom graphsでは、Graph Query Language、つまりGQLを使ってグラフを検索します。
たとえば、グラフ構造をざっくり確認する初期クエリとして、公式ドキュメントでは次のような1ホップ接続を取得する例が示されています。(Microsoft Learn)
MATCH (x)-[y]->(z)
RETURN *
LIMIT 100このクエリは、任意のソースノード、関係、ターゲットノードを取得するため、作成したグラフの構造を把握する最初の確認に向いています。
ただし、GQLサポートはpreviewです。公式リファレンスでも、GQLの機能や構文はフィードバックと継続開発に基づいて変更される可能性があると明記されています。(Microsoft Learn)
本番運用に近い形で使う場合は、次の対策を取るとよいでしょう。
| リスク | 対策 |
|---|---|
| 構文変更で既存クエリが動かなくなる | 重要なGQLクエリはリポジトリ管理し、変更履歴を残す |
| クエリが重くなる | LIMIT、期間条件、ノードラベル、プロパティ条件で絞り込む |
| 分析者ごとにクエリ品質がばらつく | よく使う調査クエリをテンプレート化する |
| 結果の解釈が属人化する | ノードやエッジの意味をドキュメント化する |
Microsoft Defenderポータルでの可視化
作成・永続化されたCustom graphは、Microsoft DefenderポータルのMicrosoft Sentinel > Graphsからアクセスできます。グラフ体験では、GQLクエリの実行、スキーマ確認、グラフの可視化、表形式での結果確認、ノードをクリックして次のホップへたどる操作ができます。(Microsoft Learn)
可視化で便利なのは、単に図として眺めることではありません。SOCアナリストが調査中に「この端末から次にどのIPへつながったか」「このURLをクリックしたユーザーは誰か」「このサービスプリンシパルがどのロールに到達したか」をその場で確認できる点です。
Defenderポータルでの活用例は次のとおりです。
| 活用シーン | 使い方 |
|---|---|
| インシデント調査 | アラートの対象ユーザーや端末を起点に、関連するIP、URL、プロセスをたどる |
| 侵害範囲の確認 | 影響を受けたユーザー、端末、クラウドリソースの広がりを可視化する |
| 脅威ハンティング | 既知のIoCや不審な振る舞いを起点に、関連エンティティを探索する |
| 調査結果の共有 | 表形式の結果やJSONデータを確認し、既存のワークフローに取り込む |
AI支援でできることと注意点
Custom graphsは、GitHub Copilotを使ったAI支援の作成にも対応しています。公式ドキュメントでは、Visual Studio Code上のJupyter NotebookでGitHub Copilotを使い、自然言語で作りたいグラフを説明し、生成されたNotebookをレビューして修正する流れが紹介されています。(Microsoft Learn)
AI支援でできることは、主に次の4つです。
| AI支援の用途 | 例 |
|---|---|
| グラフ作成Notebookの生成 | 「EmailEventsを使って送信者、受信者、URLの関係を作る」 |
| 既存グラフの修正 | 「UserからIPAddressへのエッジを追加する」 |
| デバッグ | 「特定セルのエラー原因を確認する」 |
| GQL作成 | 「直近7日間の失敗サインインに関係するユーザーを検索する」 |
ただし、AIが生成したNotebookをそのまま本番ジョブにするのは避けるべきです。生成されたコードが組織のデータ構造、命名規則、権限、データ保持方針、コスト制約に合っているとは限りません。
実務では、AI支援は「最初のひな形作成」や「クエリ作成の補助」に使い、最終的なレビューは人間が行うべきです。
展開時に注意すべき制限
Custom graphsはpreview機能であり、周辺機能にも制限があります。Notebook実行やジョブにはタイムアウト、同時実行数、サポートライブラリなどの制約があります。
公式ドキュメントでは、VS Code Notebook利用時のサービスパラメーターとして、グラフクエリタイムアウト7.5分、Notebookジョブタイムアウト8時間、同時Notebookジョブ最大3件、サポートされるライブラリはAzure Synapse libraries 3.4とMicrosoft Sentinel Provider libraryなどと示されています。(Microsoft Learn)
展開前に確認すべき制限は次のとおりです。
| 制限・注意点 | 実務上の対策 |
|---|---|
| グラフクエリタイムアウト | 大きなグラフを一度に検索せず、ラベルや期間で絞り込む |
| Notebookジョブの同時実行数 | 複数グラフの更新時間をずらす |
| Sparkセッション起動時間 | 検証時に数分の起動時間を見込む |
| ライブラリ制限 | 任意のpip installに依存した実装を避ける |
| 表示行数の制限 | 大量結果を画面表示せず、調査目的に応じて絞る |
| プレビュー仕様 | 重要クエリやNotebookを定期的に再検証する |
Sparkプールも用途に応じて選ぶ必要があります。Smallは開発や軽量な探索、Mediumは結合や集計を含むETL、Largeは大規模なデータシャッフルや時間重視の処理に向くと説明されています。選択したプールは性能、コスト、実行時間に影響します。(Microsoft Learn)
移行・展開で失敗しやすいポイント
Custom graphsの導入で失敗しやすいのは、機能そのものよりも、周辺設計を軽視するケースです。
| 失敗しやすいポイント | 何が起きるか | 対策 |
|---|---|---|
| 目的を決めずにグラフ化する | ノードとエッジが増えすぎて調査に使えない | 1つの調査シナリオから始める |
| 権限設計を後回しにする | 作成者しか見えない、閲覧者にデータが欠ける | 作成、永続化、検索の権限を分けて設計する |
| data lakeのリージョンを確認しない | データ所在地や社内ポリシーと衝突する | プライマリワークスペースのリージョンを事前確認する |
| CMK要件を見落とす | data lake体験を利用できない可能性がある | 暗号化ポリシーをセキュリティ部門と確認する |
| ジョブ更新頻度を高くしすぎる | コストやジョブ待ちが増える | 調査に必要な鮮度から逆算する |
| Preview機能を唯一の本番調査基盤にする | 仕様変更時の影響が大きい | 既存のAnalytics rules、Advanced Hunting、Workbookと併用する |
| Azureポータル前提の運用手順を残す | Defenderポータル移行時に手順が崩れる | 手順書をDefenderポータル前提に更新する |
Microsoft Sentinel data lakeのオンボードでは、指定したAzureサブスクリプションとリソースグループにdata lakeがプロビジョニングされます。Defenderポータルからのオンボード手順では、一度プロビジョニングしたdata lakeを別のサブスクリプションやリソースグループへ移行できないと説明されています。(Microsoft Learn)
この点は特に重要です。検証環境のつもりで本番と異なるサブスクリプションを選ぶと、後から管理や課金の整理が難しくなる可能性があります。
最初に試すべきユースケース
最初の検証では、ログ量が多すぎず、関係性をたどる価値が分かりやすいユースケースを選ぶのが効果的です。
おすすめは、次の4つです。
| ユースケース | なぜ最初に向いているか |
|---|---|
| フィッシングメール調査 | メール、URL、ユーザー、端末の関係が分かりやすい |
| Entra IDグループのネスト確認 | ユーザー、グループ、サービスプリンシパルの関係を可視化しやすい |
| 不審IPアドレスの横断調査 | IPを起点に複数ユーザーや端末との関係を見られる |
| OAuth権限昇格の調査 | サービスプリンシパル、権限、ロールの連鎖を追跡できる |
公式のCustom graph作成ガイドでは、Microsoft Entraのグループメンバーシップをたどり、ネストされたグループ関係を理解するサンプルが紹介されています。Sentinel data lakeで利用可能な任意のテーブルからグラフを作成できる点も示されています。(Microsoft Learn)
最初のパイロットでは、次の流れで進めると失敗しにくくなります。
| ステップ | 実施内容 |
|---|---|
| 目的を決める | 「フィッシングURLをクリックしたユーザーと端末を追跡する」など、1つの問いに絞る |
| 必要なデータを確認する | EmailEvents、URLクリック、端末イベント、Entra IDなど必要なテーブルを洗い出す |
| ノードとエッジを定義する | User、Device、URL、Emailなどのノードと、clicked、received、executedなどの関係を決める |
| Notebookで検証する | 少ない期間・少ない件数でグラフを作る |
| GQLで確認する | 代表的な1ホップ、2ホップのクエリを作る |
| ジョブ化する | 調査で使える頻度でmaterializeする |
| SOCに渡す | Defenderポータルでの見方、クエリ例、注意点を手順化する |
既存機能との使い分け
Custom graphsは便利ですが、既存のMicrosoft Sentinel機能を置き換えるものではありません。
| 機能 | 向いている用途 |
|---|---|
| Analytics rules | 条件に一致したイベントを検知し、インシデント化する |
| Advanced Hunting | KQLで横断的にデータを検索する |
| Workbooks | ダッシュボードや定点監視を行う |
| Automation rules / Playbooks | インシデント対応や通知を自動化する |
| Custom graphs | エンティティ間の関係、攻撃経路、影響範囲をたどる |
たとえば、検知はAnalytics rules、初動調査はAdvanced Hunting、状況把握はWorkbooks、関係性の深掘りはCustom graphs、対応自動化はPlaybooksというように役割を分けると、運用に組み込みやすくなります。
管理者と開発者が今すぐ確認すべきチェックリスト
Custom graphs in Microsoft Sentinelを検証する前に、次の項目を確認してください。
| 対象 | 確認項目 |
|---|---|
| Microsoft Defender管理者 | SentinelワークスペースがDefenderポータルに接続されているか |
| Sentinel管理者 | data lakeとgraphのオンボード状態を確認したか |
| セキュリティ責任者 | データ所在地、CMK、課金、権限方針を確認したか |
| RBAC管理者 | 作成、永続化、検索の権限を分けて設計したか |
| 開発者 | VS Code、Microsoft Sentinel拡張機能、Jupyter拡張機能を準備したか |
| 検知エンジニア | Notebook、GraphSpecBuilder、GQLクエリを管理するリポジトリを用意したか |
| SOCアナリスト | DefenderポータルのMicrosoft Sentinel > Graphsで検索・可視化できるか |
| 運用担当 | グラフジョブの実行頻度、失敗時の確認手順、コスト監視を決めたか |
Custom graphsは、セキュリティ調査を「ログの一覧」から「関係性の探索」へ広げる機能です。まずは1つの調査シナリオに絞り、少量データでNotebookを作成し、Defenderポータルで可視化できるところまで検証しましょう。そのうえで、権限、更新頻度、コスト、手順書を整備してから本番のSOC運用に段階的に展開するのが現実的です。
コメント