Microsoft Sentinel custom graphに関する今回の案内は、既存環境へ強制的な変更を加えるものではなく、Sentinel data lake、Visual Studio Code、GitHub Copilot、Graph Query Languageを使って脅威ハンティングを高度化するための実践ガイドと捉えるのが適切です。Microsoft Sentinelを利用している組織は、すぐに設定変更を急ぐというより、データレイクの有効化状況、権限、課金、Graph Jobの運用ルール、SOCで使えるハンティングシナリオを確認することが重要です。
A guide to innovating threat hunting with Microsoft Sentinel custom graph は何が変わった？
2026年6月24日ごろにMicrosoft Sentinel Blogで公開・更新された「A guide to innovating threat hunting with Microsoft Sentinel custom graph」は、分類としてはNoticeです。つまり、サービス終了や破壊的変更の告知ではなく、Microsoft Sentinelのcustom graphを使った脅威ハンティング手法を紹介する技術解説に近い内容です。
ポイントは、Microsoft Sentinelのログを従来の「表形式のクエリ」だけで追うのではなく、ユーザー、端末、メール、URL、IPアドレス、アプリケーションなどの関係をノードとエッジとして扱い、攻撃経路や影響範囲をたどりやすくする点です。Microsoftの説明では、Sentinel graphはMicrosoft Sentinel data lake内のデータを関係性ベースで整理・照会する仕組みとして紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
今回の案内で特に重要なのは、次の3点です。
| 確認項目 | 内容 | 利用者への影響 |
|---|---|---|
| custom graphの位置づけ | Microsoft Sentinel data lakeのデータを使って、組織ごとの攻撃シナリオに合わせたグラフを作成する | KQLだけでは追いにくい多段階の攻撃経路を可視化しやすくなる |
| 作成方法 | VS Code、Microsoft Sentinel拡張機能、Jupyter Notebook、GitHub Copilotを使う | SOCアナリストだけでなく、検出エンジニアやセキュリティエンジニアの関与が必要になる |
| 運用面 | Graph Jobで保存・更新し、Defenderポータルから照会する | 権限、スケジュール、課金、共有範囲の設計が必要になる |
Microsoft Learnでも、custom graphはSentinel data lakeやMicrosoft以外のデータソースを使って、隠れたパターンや攻撃経路を可視化するプレビュー機能として説明されています。(Microsoft Learn)
既存のMicrosoft Sentinel環境にすぐ影響はある？
今回のNoticeだけで、既存の分析ルール、インシデント、Playbook、KQLクエリが自動的に変更されるわけではありません。すでにMicrosoft Sentinelを運用している組織でも、custom graphを使わなければ日々のアラート処理や検出ルールが急に変わるものではありません。
ただし、次のような環境では影響確認を始める価値があります。
- Microsoft Sentinel data lakeをすでに有効化している
- Microsoft Defenderポータル上でSentinel運用を進めている
- 脅威ハンティングで複数テーブルのjoinが増えている
- フィッシング、ID侵害、OAuth権限昇格、C2通信などの調査に時間がかかっている
- GitHub CopilotやVS Codeをセキュリティ運用に取り入れたい
特に、アカウント侵害後の「どの端末にログオンしたか」「どのアプリにアクセスしたか」「どのIPや場所からサインインしたか」「同じ端末を使った別ユーザーは誰か」といった調査は、表形式のログだけでは追跡が複雑になりがちです。今回のガイドでは、こうしたblast radius、つまり侵害時の影響範囲をcustom graphで追う例が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
対象者は誰か
今回の内容は、Microsoft Sentinelを「ログを集めるSIEM」としてだけ使っている担当者よりも、脅威ハンティングや調査プロセスを改善したいチームに向いています。
| 対象者 | 確認すべきこと |
|---|---|
| SOCアナリスト | フィッシング、ID侵害、端末侵害などでcustom graphを使う場面があるか |
| 検出エンジニア | 既存のKQLハンティングをグラフ構造に置き換える価値があるか |
| Microsoft Sentinel管理者 | data lake、権限、VS Code拡張、Graph Jobの利用可否 |
| セキュリティ運用責任者 | 課金、プレビュー機能の扱い、運用標準化、教育計画 |
| MSSP・運用代行事業者 | 顧客ごとの調査テンプレートやGraph Jobの標準化 |
逆に、まだMicrosoft Sentinel data lakeを使っていない組織や、日常運用がアラート確認中心で高度なハンティングまで手が回っていない組織では、いきなり本番運用に組み込むより、検証環境で1つのシナリオに絞って試す方が安全です。
すぐ確認したい設定と前提条件
custom graphを使うには、Microsoft Sentinel側だけでなく、VS Codeや権限の準備も必要です。Microsoftのドキュメントでは、Microsoft Sentinel拡張機能、Jupyter拡張機能、適切な権限を持つSentinel data lakeが前提として示されています。(Microsoft Learn)
| 確認項目 | 見る場所・観点 | 注意点 |
|---|---|---|
| Sentinel data lake | Microsoft Defenderポータル、Sentinel設定 | data lakeが未構成だとcustom graphの前提が満たせない |
| データソース | SignInLogs、EmailEvents、DeviceNetworkEventsなど | グラフ化したい調査シナリオに必要なテーブルが存在するか確認する |
| 権限 | Microsoft Defender XDR unified RBAC、Microsoft Entra IDロール | 読み取り権限がないデータはグラフに含まれない |
| VS Code環境 | Microsoft Sentinel拡張、Jupyter拡張、GitHub Copilot拡張 | SOC端末で利用できるか、社内の拡張機能ポリシーに合うか確認する |
| Graph Job | オンデマンド実行、スケジュール実行 | 保存期間、更新頻度、共有範囲を決めてから使う |
| 課金 | Sentinel graph meter、data lake関連メーター | 検証段階からコスト監視を入れる |
重要なのは、権限を広く与えすぎないことです。custom graphでは複数データソースの関係を横断的に扱うため、ユーザー、端末、アプリケーション、メール、IPアドレスなどの情報が一画面でつながって見える可能性があります。調査効率は上がりますが、アクセス制御を雑にすると、必要以上のセキュリティ情報を閲覧できる状態になりかねません。
運用で変わるポイント
KQLだけではなくGQLを使う場面が増える
従来のMicrosoft Sentinel運用では、KQLでテーブルを結合しながら調査する場面が中心でした。custom graphでは、グラフ化したデータに対してGraph Query Language、つまりGQLを使います。
たとえば、フィッシングメールの調査では、メール、添付ファイル、プロセス、端末を順番に追う必要があります。従来はEmailEvents、EmailUrlInfo、UrlClickEvents、EmailAttachmentInfo、DeviceFileEvents、DeviceProcessEventsなどを複数回joinする必要がありました。今回のガイドでは、Phishing Email Kill Chainの例として、メールから添付ファイル、プロセス、端末までを1つのグラフ traversalで追う考え方が紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
つまり、KQLが不要になるわけではありません。初期検出や集計はKQL、関係性の深掘りはGQLという使い分けが現実的です。
GitHub Copilotは便利だが、出力レビューは必須
今回のガイドでは、GitHub Copilot ChatとSentinelのgraph authoring機能を使い、自然言語でcustom graph作成を支援する流れが示されています。Microsoft Learnでも、GitHub Copilotを使ってcustom graphの作成、修正、デバッグ、クエリ作成を支援できると説明されています。(GitHub)
ただし、Copilotが生成したNotebookやグラフ定義をそのまま本番利用するのは避けるべきです。特に確認したいのは次の点です。
- 想定していないテーブルを読みに行っていないか
- NULLや空文字がキーに使われていないか
- 配列やJSON値をそのままノードキーにしていないか
- 時間範囲が広すぎてコストや処理時間が増えないか
- 個人情報や機微情報を含むプロパティを過剰に表示していないか
- ノードとエッジの意味がSOC内で説明できるか
特に「とりあえず全データをつなぐ」という設計は失敗しやすいです。最初は「侵害ユーザーのblast radius」「フィッシングURLのクリック者」「OAuth権限昇格の経路」など、1つの調査目的に絞る方が成功しやすくなります。
custom graphで使いやすいシナリオ
custom graphは、すべての調査を置き換える機能ではありません。効果が出やすいのは、複数のエンティティをまたぐ調査です。
| シナリオ | custom graphが向く理由 | 最初に確認したいデータ |
|---|---|---|
| 侵害アカウントの影響範囲調査 | ユーザー、IP、端末、アプリ、リソースをつなげて追える | SignInLogs、IdentityInfo、DeviceLogon系ログ |
| フィッシング調査 | メール、URL、クリック、添付ファイル、端末実行を一連の流れで見られる | EmailEvents、UrlClickEvents、EmailAttachmentInfo、DeviceProcessEvents |
| DNS C2ビーコン調査 | 端末、ドメイン、解決先IP、脅威インテリジェンスを関連付けられる | DeviceNetworkEvents、DNSログ、ThreatIntelIndicators |
| OAuth権限昇格 | サービスプリンシパル、同意、権限、サインインを関係として追える | EntraServicePrincipals、AADServicePrincipalSignInLogs |
| Databricksなど外部基盤の調査 | Microsoft以外のデータも含めた関係性を設計できる | 対象サービスの監査ログ、ID情報、権限情報 |
Microsoftのガイドでも、VS CodeのSentinel拡張機能に複数のGraphサンプルが用意されていることが紹介されています。例として、Phishing Email Killchain、Behavioral Attack Chain、Databricks Outbound Exfiltration、DNS C2 Beaconing、OAuth Privilege Escalationなどが挙げられています。(TECHCOMMUNITY.MICROSOFT.COM)
課金面で見落としやすい注意点
custom graphは「可視化できるから便利」で終わらせず、コストも確認する必要があります。Microsoftの課金ドキュメントでは、custom graphの作成やクエリ実行はSentinel graph meterに基づいて課金されると説明されています。さらに、ノードやエッジを作成するためのNotebook/Sparkコンピュート、data lake storage、Advanced Data Insightsなどは別メーターで課金される場合があります。(Microsoft Learn)
運用上は、次のように管理すると安全です。
| リスク | 対策 |
|---|---|
| グラフ作成時に処理対象期間が広すぎる | まず7日または14日など短い期間で検証する |
| Graph Jobを高頻度で実行しすぎる | 調査目的に応じて日次、週次、オンデマンドを使い分ける |
| 誰がどのグラフを作ったか分からない | 命名規則、所有者、目的、更新頻度を記録する |
| 使われないグラフが残る | 定期的に利用状況とGraph Jobを棚卸しする |
| 検証コストが見えない | Microsoft Cost ManagementやSentinelのコスト管理でmeterを確認する |
特に検証段階では、Graph Jobをスケジュール実行にする前に、オンデマンドで結果、処理時間、コスト傾向を確認するのがおすすめです。
管理者が今日確認すべきチェックリスト
Microsoft Sentinel custom graphをすぐ本番導入しない場合でも、以下は確認しておくと後で慌てずに済みます。
- Microsoft Sentinel data lakeを有効化しているか
- custom graphを使えるリージョン、テナント、ライセンス条件を満たしているか
- Microsoft DefenderポータルでSentinelを運用できる状態か
- VS CodeとMicrosoft Sentinel拡張機能を社内端末で利用できるか
- GitHub Copilotの利用可否と社内ポリシーを確認済みか
- SOCアナリストにGraph Query Languageを学ぶ時間を確保できるか
- 最初に試すハンティングシナリオを1つに絞っているか
- Graph Jobの所有者、更新頻度、削除ルールを決めているか
- custom graph関連の課金メーターを監視できるか
- プレビュー機能として、本番依存しすぎない運用設計になっているか
この中で最も重要なのは、技術検証よりも「何を調査したいのか」を先に決めることです。custom graphは多機能ですが、目的が曖昧なまま始めると、見た目は派手でも運用で使われないグラフになりがちです。
実務ではどう進めるべきか
最初の一歩としては、既存のハンティングクエリの中から「joinが多く、毎回調査に時間がかかるもの」を1つ選び、custom graph化できるか検討するのが現実的です。
おすすめは、次のような進め方です。
| ステップ | 作業内容 | 成果物 |
|---|---|---|
| 目的を決める | 例：侵害ユーザーの影響範囲を調べる | 調査シナリオ |
| 必要なデータを洗い出す | SignInLogs、IdentityInfo、DeviceLogonなど | 利用テーブル一覧 |
| ノードとエッジを設計する | User、Device、IPAddress、Applicationなど | グラフ設計メモ |
| VS Codeで試作する | NotebookとCopilotを使ってグラフ作成 | 試作Notebook |
| GQLで確認する | 代表的な調査クエリを作る | GQLテンプレート |
| Graph Jobを検討する | オンデマンドか定期更新か決める | 運用ルール |
| SOCでレビューする | 実際の調査に使えるか確認する | 改善点リスト |
この進め方なら、既存のMicrosoft Sentinel運用を壊さず、段階的にcustom graphを試せます。
まとめ：今回のNoticeで確認すべきこと
「A guide to innovating threat hunting with Microsoft Sentinel custom graph」は、Microsoft Sentinel利用者に対して、custom graphを使った新しい脅威ハンティングの進め方を示すNoticeです。既存環境にすぐ破壊的な影響が出るものではありませんが、Sentinel data lake、Defenderポータル、VS Code、GitHub Copilot、GQLを組み合わせた運用に進むための準備が求められます。
まず確認すべきなのは、data lakeの有効化、必要テーブルの有無、権限、VS Code拡張機能、Graph Jobの扱い、課金メーターです。そのうえで、フィッシング調査や侵害アカウントのblast radius分析など、効果が見えやすいシナリオから小さく始めるのが安全です。
Microsoft Sentinel custom graphは、KQLを置き換えるものではなく、KQLでは追いにくい「関係性」を補うための選択肢です。SOCの調査時間を短縮したい組織は、まず1つの調査シナリオを選び、検証環境でcustom graphの有効性とコストを確認するところから始めるとよいでしょう。
コメント