Microsoft Sentinelの脅威ハンティングで「ポータルの検索だけでは足りない」と感じる場面では、Jupyter notebooksが有力な選択肢になります。2026年4月22日に更新されたMicrosoft Learnの「Jupyter notebooks with Microsoft Sentinel hunting capabilities」では、Jupyter notebooksを使うべき場面、Azure Machine Learning上での実行、MSTICPyの活用、アクセス権限の整理が改めて示されています。結論として、security admins、identity teams、compliance teamsが見るべきポイントは、Defenderポータル移行を見据えながら、Notebookを高度な調査・可視化・外部データ連携の実行基盤として標準化できるかです。 (Microsoft Learn)
Microsoft Sentinelの最新動向: Jupyter notebooks with Microsoft Sentinel hunting capabilitiesで何が変わったか
今回取り上げる「Jupyter notebooks with Microsoft Sentinel hunting capabilities」は、Microsoft SentinelでJupyter notebooksを使ってセキュリティ調査や脅威ハンティングを行うための公式解説です。Jupyter notebooksは、KQLだけで完結しない分析、Pythonによるデータ処理、機械学習、視覚化、外部データとの突き合わせを1つの作業ノートとしてまとめられる点が強みです。 (Microsoft Learn)
特に重要なのは、このページが単なる「Notebookの紹介」ではなく、Microsoft Sentinelの運用担当者が次のような実務判断をするための材料になっていることです。
| 確認すべき観点 | 実務での意味 |
|---|---|
| いつJupyter notebooksを使うか | ポータル標準機能では足りない分析・可視化・外部データ連携に使う |
| どこで実行するか | Microsoft SentinelではAzure Machine Learningプラットフォーム上で実行する |
| どの権限が必要か | SentinelワークスペースとAzure Machine Learningワークスペースの両方の権限を確認する |
| どのライブラリを使うか | MSTICPyを中心に、調査・エンリッチメント・可視化を効率化する |
| 今後の移行影響 | 2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defenderポータルでの利用に移行する |
「Jupyter notebooksが便利そうだから試す」ではなく、SOC運用、ID調査、監査対応の中でどの調査パターンをNotebook化するかを決めることが、今回の更新を読むうえでの実践的なポイントです。
2026年4月更新で押さえるべき要点
Azure portal前提の運用を見直す必要がある
公式ページでは、2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされなくなり、Microsoft Defenderポータルでのみ利用可能になると明記されています。Azure portalでMicrosoft Sentinelを使っている組織は、Defenderポータルへの移行計画を始めることが推奨されています。 (Microsoft Learn)
これは、Notebookを使うチームにとっても重要です。理由は、調査手順、権限設計、教育資料、画面キャプチャ付きの社内手順書がAzure portal前提になっていると、移行時に混乱が起きやすいからです。
たとえば、現在の社内手順書に「Azure portalでMicrosoft Sentinelを開き、Threat managementからNotebooksを選択」とだけ書かれている場合、Defenderポータル移行後に新人アナリストや監査担当者が迷う可能性があります。今後作る手順書では、Defenderポータルでの操作を主軸にして、Azure portalの記述は移行期間中の補足にとどめるのが安全です。
Jupyter notebooksは「高度な調査を再現可能にする道具」として位置付ける
Microsoft Learnでは、Jupyter notebooksを使う場面として、Microsoft Sentinel標準では提供されない分析、カスタムタイムラインやプロセスツリーなどの可視化、オンプレミスデータセットなど外部データソースとの統合が挙げられています。 (Microsoft Learn)
この点は、security adminsやidentity teamsにとって実務上の価値が大きい部分です。ポータル上のハンティングクエリは素早い調査に向いていますが、複数の手順を組み合わせる調査では属人化しやすくなります。
たとえば、次のような調査はNotebook化に向いています。
| 調査シナリオ | Notebook化するメリット |
|---|---|
| 不審なサインインの深掘り | Entra IDログ、端末情報、IPレピュテーションを順に確認できる |
| 資格情報漏えいの調査 | Credential Scan系のテンプレートや外部脅威インテリジェンスと組み合わせやすい |
| インシデント後の時系列整理 | タイムラインを可視化し、報告書作成に使いやすい |
| 監査向けの証跡確認 | 実行したクエリ、判断理由、結果をNotebook内に残せる |
| 独自の異常検知 | Pythonの機械学習・統計処理を使って標準検出を補完できる |
Notebookの価値は「Pythonが使えること」だけではありません。Markdownで調査目的や判断理由を書き、コードセルでKQLやPythonを実行し、結果を同じファイルに残せる点にあります。つまり、調査を一回限りの作業ではなく、再利用できる分析手順に変えられます。
Jupyter notebooksを使うべきケース、使わなくてよいケース
Microsoft SentinelのJupyter notebooksは強力ですが、すべての調査で使う必要はありません。むしろ、簡単な確認までNotebook化すると運用が重くなります。
使うべきケース
Jupyter notebooksを使うべきなのは、次のような条件に当てはまる場合です。
- 複数のKQLクエリを順番に実行する必要がある
- Sentinel外のデータと突き合わせたい
- 結果をグラフ、タイムライン、プロセスツリーなどで見たい
- 調査手順を他のアナリストにも再現してほしい
- 機械学習、統計処理、スコアリングを使いたい
- 監査やレビューのために、調査過程を残したい
たとえば、あるユーザーの不審なログインを調べる場合、単に直近のサインインログを見るだけならポータルやKQLで十分です。しかし、サインイン元IP、端末、アプリ、地理情報、過去の振る舞い、脅威インテリジェンスを順に見て判断するなら、Notebookのほうが調査品質を安定させやすくなります。
使わなくてよいケース
一方、次のような作業はNotebookにしないほうが効率的です。
| 作業 | おすすめの方法 |
|---|---|
| 単発のログ検索 | Microsoft SentinelのLogsやHunting |
| 定型的な検出 | Analytics rules |
| インシデント対応の自動化 | Playbooks、Automation rules |
| ダッシュボード表示 | Workbooks |
| 簡単なアラート確認 | Incidents画面 |
Notebookは、分析の自由度が高いぶん、実行環境、権限、依存パッケージ、コード管理が必要です。日常的な検知や単純な検索までNotebookに寄せると、かえって運用負荷が増えます。
Azure Machine Learning上で実行する点を理解する
Microsoft SentinelのNotebookは、JupyterLabやJupyter classicでも実行できますが、Microsoft Sentinel内ではAzure Machine Learningプラットフォーム上で実行されます。NotebookのカーネルはAzure仮想マシン上で動作し、複数のNotebookを同時に実行できるVMインスタンスを利用します。複雑な機械学習モデルを扱う場合は、より高性能なVMを検討する必要があります。 (Microsoft Learn)
この仕組みを理解していないと、次のようなトラブルが起きます。
| よくある問題 | 原因 | 対策 |
|---|---|---|
| Notebookを開けない | Azure Machine Learningワークスペース権限が不足 | SentinelとAzure MLの両方の権限を確認する |
| コードセルが実行できない | Compute instanceが停止している | 実行前にComputeを起動する |
| パッケージが見つからない | インストールまたはimport不足 | Notebook冒頭で依存関係を明記する |
| 実行結果が前回と違う | セルの実行順序が変わった | 上から順番に実行する設計にする |
| コストが増える | 高性能Computeを起動したままにする | 利用後に停止する運用ルールを作る |
特にコスト管理は見落とされがちです。セキュリティ調査用のNotebookは、必要なときだけComputeを起動し、調査後に停止する運用を徹底しましょう。SOCで共用する場合は、「誰が、いつ、どのComputeを使うか」をチーム内で明確にしておくと無駄な稼働を避けられます。
権限設計はSentinelとAzure Machine Learningの両方を見る
Jupyter notebooksをMicrosoft Sentinelで使うには、Microsoft Sentinelワークスペースへの権限だけでなく、Azure Machine Learningワークスペースへの権限も必要です。公式ページでは、Microsoft Sentinel側ではReader、Responder、ContributorのいずれかがNotebookブレードへのアクセスに必要とされ、Azure Machine Learning側でもワークスペースに対する適切なロールが必要とされています。 (Microsoft Learn)
実務では、役割ごとに権限を分けて考えると整理しやすくなります。
| 役割 | 必要になりやすい権限の考え方 | 注意点 |
|---|---|---|
| Security admin | Sentinel全体とAzure ML環境の管理 | 過剰権限にならないよう職務分掌を確認 |
| SOCアナリスト | Notebookの閲覧・実行・保存 | Compute操作やNotebook保存先の権限も必要 |
| Identity team | ID関連ログの分析、Notebook実行 | Entra ID関連ログへのアクセス範囲を確認 |
| Compliance team | 調査結果や証跡の確認 | 実行権限が必要か、閲覧だけでよいかを分ける |
| Platform team | Azure ML、ネットワーク、Key Vault管理 | セキュリティチームと責任境界を決める |
失敗しやすいのは、「SentinelのContributorだからNotebookも問題なく使える」と考えてしまうことです。実際には、Azure Machine Learningワークスペース、Compute、Storage、Key Vaultなど、Notebook実行に関わるAzureリソース側の権限も確認する必要があります。
MSTICPyはNotebook活用の中核になる
Microsoft Sentinel notebooksでは、MSTICPyというPythonパッケージが使われます。MSTICPyは、データ取得、分析、エンリッチメント、可視化のためのサイバーセキュリティ向けツール群として説明されています。 (Microsoft Learn)
MSTICPyを使うと、Notebook内で次のような作業を効率化できます。
- Microsoft Sentinelのデータ取得
- 脅威インテリジェンスとの突き合わせ
- IPアドレスやアカウントなどのエンティティ調査
- 時系列分析
- 可視化
- 調査用クエリの再利用
ただし、MSTICPyは「入れれば自動で調査が完了するツール」ではありません。設定ファイル、認証、外部データプロバイダー、APIキー管理を正しく整える必要があります。
公式のGetting Started Guideでは、Microsoft Sentinel ML Notebooksの基本構成、サンプルクエリ、MSTICPyの初期化、Microsoft Sentinelへの接続確認、VirusTotalやMaxMind GeoLite2など外部データプロバイダーの設定例が説明されています。 (Microsoft Learn)
APIキーやシークレット管理に注意する
脅威インテリジェンスやGeoIP連携を使う場合、APIキーをNotebookに直接書くのは避けるべきです。公式ページでも、VirusTotalのエンタープライズキーを使う場合は、msticpyconfig.yamlではなくAzure Key Vaultに保存することが案内されています。 (Microsoft Learn)
実務では、次のルールを決めておくと安全です。
| 管理対象 | 推奨する扱い |
|---|---|
| APIキー | Azure Key Vaultなどで管理する |
| Notebookファイル | GitやAzure ML上で変更履歴を管理する |
| msticpyconfig.yaml | 環境固有情報を含むため共有範囲に注意する |
| 調査結果 | 個人情報・機密情報を含む可能性を前提に保存先を決める |
| 外部サービス連携 | 利用規約、データ送信範囲、監査要件を確認する |
Compliance teamsが関わる場合は、Notebookの実行結果に個人情報、IPアドレス、端末名、ユーザーID、メールアドレスが含まれる点にも注意が必要です。調査に必要な範囲を超えて保存・共有しない運用が求められます。
GitHubリポジトリのNotebookは「そのまま本番適用」しない
Microsoft Learnでは、Microsoftやコミュニティが提供するNotebookをMicrosoft Sentinel GitHubリポジトリから利用できること、Sample-NotebooksやHowTosのディレクトリがあることも紹介されています。 (Microsoft Learn)
サンプルNotebookは非常に便利ですが、実務では必ず自社環境に合わせて確認しましょう。特に次の点はそのまま使うと問題になりやすいです。
| 確認項目 | 理由 |
|---|---|
| 対象データテーブル | 自社のSentinelに同じログが取り込まれているとは限らない |
| KQLの時間範囲 | 広すぎるとコストや実行時間が増える |
| 外部API連携 | データ送信先やAPIキー管理の確認が必要 |
| 可視化の前提 | データ量やスキーマが違うと表示が崩れることがある |
| 権限 | アナリスト全員が同じ操作を実行できるとは限らない |
| 保存先 | 調査結果に機密情報が含まれる可能性がある |
おすすめは、GitHubのNotebookを「完成品」ではなく「調査テンプレート」として扱うことです。最初に検証用ワークスペースで動かし、KQL、データソース、権限、保存ルールを調整してから本番運用に入れましょう。
security adminsが確認すべきポイント
Security adminsは、Jupyter notebooksを個人の分析ツールとしてではなく、SOC全体の調査基盤として整備する立場です。見るべきポイントは、環境、権限、コスト、標準化です。
まず整備したいチェックリスト
| 項目 | 確認内容 |
|---|---|
| ポータル移行 | Defenderポータル前提の手順になっているか |
| Azure MLワークスペース | Sentinelと同じサブスクリプション・リージョン方針で管理されているか |
| Compute | サイズ、停止ルール、利用者の責任範囲が決まっているか |
| RBAC | SentinelとAzure MLの権限が過不足なく割り当てられているか |
| Key Vault | APIキーやシークレットの保存場所が決まっているか |
| Notebook管理 | テンプレート、レビュー、更新手順が決まっているか |
| ログと監査 | 誰がNotebookを実行し、何を保存したか追跡できるか |
セキュリティ部門でNotebookを広げるときは、まず「利用ルールのない自由な実行環境」を避けることが大切です。調査の自由度は必要ですが、権限やシークレット管理が曖昧なまま広げると、セキュリティ調査基盤自体がリスクになります。
identity teamsが活用できるシナリオ
Identity teamsにとって、Microsoft SentinelのJupyter notebooksは、Entra IDやMicrosoft 365関連ログを横断して調査する場面で役立ちます。特に、アカウント侵害や条件付きアクセスの例外確認では、単一画面のログ確認だけでは判断しにくいことがあります。
Notebook化しやすいID調査の例
| シナリオ | Notebookで確認する流れ |
|---|---|
| 不審な国・地域からのサインイン | サインインログを抽出し、ユーザー、IP、時刻、アプリを可視化 |
| MFA疲労攻撃の疑い | 複数回の認証要求、失敗回数、成功イベントの時系列を確認 |
| 退職者・休職者アカウントの利用 | アカウント状態と利用ログを突き合わせる |
| 特権アカウントの異常操作 | 管理操作ログ、サインイン、端末情報を組み合わせて確認 |
| OAuthアプリの不審な同意 | アプリ権限、同意ユーザー、操作履歴を追跡 |
Notebookにすると、調査手順をMarkdownで説明しながら、KQL実行、集計、可視化を順番に並べられます。経験の浅い担当者でも、セルを上から実行しながら判断ポイントを追えるため、チーム内の調査品質をそろえやすくなります。
compliance teamsが見るべきポイント
Compliance teamsにとっての価値は、Notebookが「調査手順と結果を残せる」点です。インシデント対応後の説明、内部監査、規制対応では、何を調べ、どのデータを見て、どう判断したかが重要になります。
ただし、Notebookを証跡として使う場合は、次の点に注意が必要です。
| 注意点 | 実務上の対策 |
|---|---|
| 実行結果が後から変わる | 実行日時、対象期間、クエリ条件をNotebook内に明記する |
| 個人情報が含まれる | 保存先と共有範囲を制限する |
| セルの実行順序で結果が変わる | 上から順に実行できる構成にする |
| 誰が実行したか分からない | Azure側の監査ログや変更履歴と組み合わせる |
| 外部APIへデータが送られる | 利用する外部サービスと送信データを事前に確認する |
監査向けには、Notebookの冒頭に「目的」「対象期間」「対象ワークスペース」「実行者」「使用した外部データソース」「判断基準」を記載するテンプレートを作ると実用的です。調査結果だけでなく、調査の前提が残るため、後からレビューしやすくなります。
Microsoft Sentinel Notebook導入の実践手順
これからMicrosoft SentinelでJupyter notebooksを使い始める場合は、いきなり高度な機械学習や外部連携に進むより、公式のGetting Started Guideを使って基本構成を確認するのが安全です。公式手順では、TemplatesタブからGetting Started Guide for Microsoft Sentinel ML Notebooksを作成し、Azure Machine Learningワークスペースに保存して起動する流れが説明されています。 (Microsoft Learn)
最初の導入ステップ
| ステップ | 作業内容 | 完了の目安 |
|---|---|---|
| 目的を決める | どの調査をNotebook化するか決める | 例: 不審サインイン調査 |
| 権限を確認する | SentinelとAzure MLのRBACを確認 | 実行者がNotebookを起動できる |
| Azure ML環境を準備する | ワークスペースとComputeを用意 | Notebookが起動できる |
| Getting Started Guideを実行する | サンプルNotebookを上から順に実行 | Sentinel接続とサンプルクエリが成功する |
| MSTICPy設定を確認する | msticpyconfig.yamlや外部プロバイダーを整理 | 必要な設定が保存されている |
| テンプレートを作る | 自社向けの調査Notebookを作成 | 手順、KQL、判断基準が入っている |
| 運用ルールを決める | 保存、共有、レビュー、Compute停止を決める | チームで再利用できる |
公式手順でも、Notebookのコードセルは順番に実行すること、セルを飛ばしたり順不同に実行したりすると後続のエラーにつながる可能性があることが説明されています。Notebookを社内テンプレート化する場合は、各セルの前に「このセルで何を確認するか」「成功時の期待結果」「失敗時の確認ポイント」を短く書いておくと、運用で使いやすくなります。 (Microsoft Learn)
運用で失敗しやすいポイント
Notebookを作った人しか理解できない
もっとも多い失敗は、Notebookが個人のメモになってしまうことです。変数名、KQL、出力結果だけが並んでいて、何を判断すればよいか分からないNotebookは、チーム運用に向きません。
対策は、Markdownセルを増やすことです。各セクションに「目的」「見るべき値」「異常と判断する条件」「次のアクション」を書きましょう。
KQLの対象期間が広すぎる
調査用Notebookでは、ago(90d)やtake 100000のような広い条件を安易に使うと、実行時間やコストが増える可能性があります。最初は短い期間で動作確認し、必要に応じて期間を広げる設計にしましょう。
外部API連携の扱いが曖昧
VirusTotalやGeoIPサービスなどを使うと調査の精度は上がりますが、外部に送るデータやAPIキー管理を確認しないまま使うのは危険です。特にグローバル企業では、地域ごとのデータ保護要件や社内ポリシーに抵触しないか確認が必要です。
Compute停止ルールがない
Azure Machine LearningのComputeを起動したままにすると、不要なコストが発生する可能性があります。Notebook利用後の停止、長時間未使用時の停止、利用者への通知ルールを決めておきましょう。
Defenderポータル移行を後回しにする
2027年3月31日以降のAzure portalサポート終了を考えると、今から作るNotebook手順はDefenderポータル前提にするべきです。Azure portalの画面に依存した教育資料やスクリーンショットを増やすと、後で作り直しが必要になります。 (Microsoft Learn)
実務で使えるNotebookテンプレートの構成例
チームで再利用できるNotebookを作るなら、次のような構成にすると使いやすくなります。
| セクション | 内容 |
|---|---|
| 調査概要 | 目的、対象期間、対象ユーザー、関連インシデントID |
| 前提条件 | 必要な権限、必要なログ、外部API、注意事項 |
| 初期化 | ライブラリimport、MSTICPy設定、ワークスペース接続 |
| データ取得 | KQLで必要なログを取得 |
| 集計 | ユーザー、IP、端末、アプリ、時刻で整理 |
| 可視化 | タイムライン、件数推移、関係性を表示 |
| エンリッチメント | IPレピュテーション、GeoIP、外部TIとの照合 |
| 判断 | 異常とみなす条件、確認結果、推奨アクション |
| 証跡 | 実行日時、実行者、保存先、レビュー欄 |
この構成にしておくと、Notebookは単なる分析コードではなく、調査プレイブックになります。security adminsは標準化しやすく、identity teamsは調査を再現しやすく、compliance teamsは判断根拠を確認しやすくなります。
2026年4月更新を踏まえて今すぐ確認すべきこと
今回のMicrosoft Learn更新を実務に落とし込むなら、まず次の3点を確認しましょう。
第一に、Microsoft SentinelのJupyter notebooksを使う目的を明確にすることです。標準機能で済む作業までNotebook化する必要はありません。Notebookは、複数のクエリ、Python分析、外部データ連携、可視化、証跡化が必要な調査に使うと効果を発揮します。
第二に、Azure Machine LearningとRBACを含めた実行環境を整えることです。NotebookはSentinelだけで完結する機能ではありません。Azure MLワークスペース、Compute、Key Vault、外部API、ネットワーク設定を含めて運用設計する必要があります。
第三に、Defenderポータル移行を前提に手順を見直すことです。2027年3月31日以降のAzure portalサポート終了に備え、今後作成・更新するNotebook手順書はDefenderポータルを基準にするのが現実的です。
Microsoft SentinelのJupyter notebooksは、単なる高度分析ツールではなく、調査手順を標準化し、チーム間で共有し、監査にも耐えやすくするための基盤です。まずはGetting Started Guideで接続と基本操作を確認し、次に自社で頻度の高い調査シナリオを1つ選んでNotebookテンプレート化するところから始めると、効果を実感しやすくなります。
コメント