Microsoft Sentinel incident investigation in the Azure portalは、Azure portal上でMicrosoft Sentinelのインシデント調査とケース管理を行うための公式情報です。2026年5月14日に更新された内容を見るうえで重要なのは、「Azure portalで何ができるか」だけでなく、「Microsoft Defenderポータルへの移行を前提に、権限・コネクタ・自動化・KQL/API連携を見直す必要がある」という点です。特にSOC管理者、Microsoft Defender XDR連携を使う管理者、Logic AppsやAPIでインシデント処理を自動化している開発者は、調査手順と設定の両方を棚卸ししておくべきです。公式情報では、Microsoft Sentinelのインシデント調査はAzure portalのIncidentsページを起点に、タイムライン、類似インシデント、上位インサイト、エンティティ、ログ、タスク、アクティビティログを使ってMTTR短縮を狙う仕組みとして整理されています。(Microsoft Learn)
公式情報の要点：Azure portalの調査機能を理解しつつ、Defender移行を前提に運用を見直す
今回の「Microsoft Sentinel incident investigation in the Azure portal」は、新しい単体機能の発表というより、Azure portalで利用できるMicrosoft Sentinelのインシデント調査・ケース管理機能を体系的に説明した公式ドキュメントです。ドキュメントは「Microsoft Sentinel in the Azure portal」に適用され、最終更新日は2026年5月14日です。(Microsoft Learn)
ただし、実務上はAzure portalだけを見て終わりではありません。Microsoftは、Microsoft SentinelがMicrosoft Defenderポータルでも一般提供されており、2027年3月31日以降はAzure portalでMicrosoft Sentinelがサポートされず、Microsoft Defenderポータルのみで利用されると説明しています。つまり、Azure portalでの現在の調査機能を理解しながら、将来的なDefenderポータル中心の運用に移る準備が必要です。(Microsoft Learn)
現場で最初に確認すべきポイントは、次の3つです。
| 確認ポイント | 何を見るべきか | 放置した場合のリスク |
|---|---|---|
| 調査フロー | タイムライン、類似インシデント、エンティティ、ログ、タスクの使い方 | アナリストごとに調査品質がばらつく |
| Microsoft Defender連携 | Defender XDRコネクタ、インシデント同期、重複抑止 | インシデントの二重作成、KQLや自動化の不整合 |
| 移行準備 | Defenderポータル移行、RBAC、API、Logic Apps、プレイブック | 移行後に通知・チケット連携・レポートが止まる |
Azure portalでのインシデント調査は何ができるのか
Microsoft Sentinelのインシデントは、単なるアラート一覧ではありません。公式情報では、インシデントを「セキュリティ脅威に関する証拠、エンティティ、インサイト、コメント、操作ログを含む、継続的に更新される記録」と位置づけています。これにより、SOC担当者は「このアラートはなぜ重要なのか」「誰が関係しているのか」「過去に似た事象があったのか」を同じ画面の文脈で追えます。(Microsoft Learn)
Incident timelineで攻撃の流れを時系列に追う
Incident timelineは、インシデントに関連するアラートやブックマークを時系列で確認するための中心的な領域です。アラートの作成日時、重大度、プロバイダー、MITRE ATT&CKの戦術などを見ながら、攻撃の始点、横展開、権限昇格、データ流出の兆候を整理できます。(Microsoft Learn)
実務では、最初に「最も古いアラート」と「最も重大度が高いアラート」を確認します。たとえば、最初のイベントが不審なサインインで、その後に端末上の不審プロセス、メール転送ルールの作成が続いている場合、単一端末の問題ではなくアカウント侵害を起点とした一連の攻撃として扱うべきです。
Similar incidentsで過去事例と横展開を探す
Similar incidentsは、現在開いているインシデントと類似する過去または進行中のインシデントを確認する機能です。公式情報では、最大20件の類似インシデントが表示され、共通するエンティティ、分析ルール、アラート詳細などをもとに類似性が判断されると説明されています。(Microsoft Learn)
この機能は、特に次の場面で有効です。
| 活用シーン | 見るべきポイント | 判断例 |
|---|---|---|
| 同時多発の確認 | 同じIPアドレス、ユーザー、ホストが別インシデントにも出ていないか | 複数端末で同じC2通信があれば、単発ではなくキャンペーンの可能性 |
| 過去対応の再利用 | 過去の所有者、クローズ理由、対応コメント | 既知の誤検知ならチューニング候補にする |
| エスカレーション | 類似事例を担当したアナリスト | 過去対応者に確認し、調査時間を短縮する |
注意点は、Microsoft Defenderポータルへの移行後は、Azure portalで使えるSimilar incidents機能がそのまま同じ形で使えるとは限らないことです。移行ドキュメントでは、Similar incidentsはDefenderポータルではサポートされないと説明されています。移行後の調査手順では、Defender側の統合インシデント、エンティティページ、Advanced huntingを使った代替手順を用意しておきましょう。(Microsoft Learn)
Top insightsとエンティティで「誰が何をしたか」を深掘りする
Top insightsは、インシデントに含まれるエンティティに関する重要な分析結果を表示します。ユーザー、ホスト、IPアドレス、ファイル、URLなどについて、通常と異なる行動、脅威インテリジェンスとの関連、ウォッチリストとの一致などを確認できます。多くのインサイトはLogsパネルと連動し、元のクエリと結果を確認できるため、「なぜこの判断になったのか」を追いやすい設計です。(Microsoft Learn)
たとえば、あるユーザーが通常アクセスしない国からサインインし、その直後に複数のホストへ横展開している場合、Top insightsとエンティティのタイムラインを組み合わせることで、アカウント侵害から端末侵害へ進んだ可能性を早い段階で判断できます。
Logsとアクティビティログで調査と監査をつなげる
Azure portalのインシデント画面では、アラート、エンティティ、インサイトなどからLogsへドリルダウンできます。ログ画面がインシデントの文脈内で表示されるため、調査担当者は画面を行き来しすぎず、根拠となるKQL結果を確認できます。(Microsoft Learn)
また、アクティビティログは人間と自動処理の両方によるインシデント操作を記録します。コメントも含めて確認できるため、シフト交代、二次対応、監査対応で重要です。特に、閉じた理由、誤検知と判断した根拠、封じ込め済みかどうかはコメントに残す運用にしておくと、後から同じインシデントを再評価しやすくなります。
Microsoft Defender連携で変わるポイント
Microsoft Defender XDRとMicrosoft Sentinelを連携すると、Defender XDRのインシデント、アラート、エンティティをMicrosoft Sentinel側で扱えるようになります。公式情報では、Defender XDR連携により、ステータス、所有者、クローズ理由の双方向同期、アラートのグルーピング、インシデント間のディープリンクなどが利用できると説明されています。(Microsoft Learn)
Azure portalで引き続きDefender XDRデータをMicrosoft Sentinelに同期したい場合は、Microsoft Defender XDRコネクタを有効化する必要があります。一方、Microsoft SentinelをDefenderポータルにオンボードし、Defender XDRのライセンスがある場合、Defender XDRコネクタは自動的に設定され、対象となる個別Defender製品のコネクタは切り替わります。(Microsoft Learn)
コネクタ設定で確認すべきこと
| 項目 | Azure portal運用での確認内容 | 注意点 | |
|---|---|---|---|
| Defender XDRコネクタ | Microsoft SentinelのData connectorsでMicrosoft Defender XDRを有効化 | Defenderポータルにオンボード済みなら手動設定は不要 | |
| インシデントとアラート | Connect incidents & alertsを有効化 | 重複防止のためMicrosoft incident creation rulesをオフにする推奨設定がある | |
| エンティティ | Microsoft Defender for Identity経由でオンプレミスADのユーザー情報を同期 | Defender for Identityの導入状態を確認する | |
| イベント | Defender for Endpoint、Defender for Office 365などのAdvanced huntingイベントを収集 | 生ログの収集はコストや保持期間の設計が必要 | |
| 確認クエリ | SecurityIncident | where ProviderName == "Microsoft XDR" | UI表示とテーブル反映には時間差が出る場合がある |
Microsoft Defender XDRコネクタを有効化すると、以前から接続されていた一部の個別Defenderコンポーネントのコネクタは、見た目上は接続済みに見えてもデータが流れない状態になる場合があります。また、スタンドアロンコネクタからXDRコネクタへ切り替えるとアラートのスキーマが変わり、既存のKQL、ブック、外部連携に影響する可能性があります。(Microsoft Learn)
管理者が確認すべき権限と運用設定
Microsoft Sentinelでインシデントを調査するには、Microsoft Sentinel Responderロールが必要です。さらに、ゲストユーザーにインシデントの割り当てを行わせる場合は、Microsoft EntraテナントでDirectory Readerロールが必要です。通常ユーザーには既定で割り当てられていても、外部委託SOCやMSSPのゲストユーザーでは不足しやすい点に注意してください。(Microsoft Learn)
権限設計で失敗しやすいパターン
| 失敗パターン | 起きる問題 | 対策 |
|---|---|---|
| ゲストSOC担当者に必要なロールがない | インシデントの割り当てや調査操作ができない | Sentinel ResponderとDirectory Readerを事前確認 |
| Azure portalとDefenderポータルで権限設計を分けていない | 移行後に閲覧できるデータ範囲が変わる | Defender側のRBAC、統合RBAC、テーブル権限を棚卸し |
| 管理者権限で検証して本番展開する | 一般アナリストで操作できない画面が出る | Tier 1、Tier 2、SOC管理者ごとにテストユーザーで確認 |
| 外部委託先に過剰権限を付ける | インシデント調査以外の設定変更が可能になる | 最小権限でロールを分離する |
特にIdentityInfoテーブルを使っている組織は注意が必要です。Defenderポータル移行後、IdentityInfoはAdvanced hunting側でも使える一方、一部フィールドの名称変更や非対応があり、Microsoft Defenderで実行するAdvanced huntingクエリやカスタム検出の見直しが必要です。また、Defenderポータル移行後のIdentityInfoはネイティブDefenderテーブルとなり、Azure portal側のテーブルレベルRBACと同じ制御が使えないと説明されています。(Microsoft Learn)
自動化・Logic Apps・KQLで注意すべき変更点
Microsoft Sentinelの運用では、インシデント作成時にLogic Appsのプレイブックを起動したり、ServiceNowなどの外部チケットシステムへ連携したり、KQLでレポートを作成したりすることが多いはずです。ここは移行やDefender連携で特に壊れやすい領域です。
Defenderポータルにオンボードすると、インシデントの相関とマージはMicrosoft Defender側のエンジンが中心になります。公式情報では、Defenderの相関エンジンが共通要素を認識した場合、複数のアラートやインシデントを統合して、より包括的な攻撃ストーリーとして扱うと説明されています。(Microsoft Learn)
自動化ルールで見直すべき条件
| 見直す条件 | なぜ危険か | 推奨される見直し |
|---|---|---|
| インシデント名を条件にする | Defender側の相関により既存インシデント名が変わる場合がある | タグ、分析ルール名、重大度、エンティティ種別を使う |
| ProviderNameでSentinelだけを判定する | DefenderポータルではIncident provider nameがMicrosoft XDRになる | 条件を再設計し、対象インシデントをタグなどで識別 |
| Descriptionフィールドを使う | Defenderポータル移行後、SecurityIncidentテーブルにDescriptionフィールドが含まれない | 外部チケット連携の説明文生成ロジックを変更 |
| コメント編集を前提にする | Defenderポータルでは既存コメントの編集が同期されない | 追記型コメントとして運用ルールを定める |
| 手動/API作成インシデントをDefender側で見える前提にする | API、Logic App、Azure portal手動作成のSentinelインシデントはDefenderポータルへ同期されない | どちらのポータルで扱うべきか運用を分ける |
Defenderポータル移行後は、SecurityIncidentテーブルにDescriptionフィールドが含まれないため、このフィールドを自動化ルールの条件や外部チケット連携に使っている場合は修正が必要です。また、インシデント名の変更や、5〜10分間の複数更新が単一更新として送られる動作もあるため、更新イベントを細かく拾う自動化は検証しておきましょう。(Microsoft Learn)
開発者はMicrosoft Graph API移行も確認する
開発者やSREがインシデント調査を外部システムと連携している場合、Microsoft Graph Security APIの移行も無視できません。Microsoft Learnでは、従来の/security/alertsエンドポイントは非推奨で、2026年8月31日に廃止予定と説明されています。新しいAPIでは/security/alerts_v2や/security/incidentsを使い、アラートをインシデント中心のモデルで扱う必要があります。(Microsoft Learn)
特にMicrosoft Sentinelを使っている場合、ワークスペースがMicrosoft Defenderポータルに接続されていないと、Sentinel由来のアラートがv2 APIに返らない点に注意が必要です。既存の監視ボット、チケット連携、レポート生成、SOAR連携が/security/alertsに依存している場合は、エンドポイント、権限スコープ、データモデル、ODataフィルターをまとめて見直してください。(Microsoft Learn)
移行時の確認項目は次のとおりです。
| 確認対象 | 具体的に確認すること |
|---|---|
| APIエンドポイント | /security/alertsを使っていないか。/security/alerts_v2または/security/incidentsへ移行するか |
| アプリ権限 | SecurityAlert.Read.All、SecurityIncident.Read.Allなど新しい権限が必要か |
| データモデル | アラート単位ではなくインシデント単位で処理できるか |
| エンティティ処理 | userStates、hostStatesなど旧構造を前提にしていないか |
| Sentinel接続 | Microsoft SentinelワークスペースがDefenderポータルに接続されているか |
| 下流処理 | ServiceNow、Teams通知、Jira、SIEM再連携、レポートが新APIの出力に対応しているか |
SOC運用では「調査の型」を標準化する
Azure portalのMicrosoft Sentinelインシデント調査機能は多機能ですが、担当者が自由に使うだけでは効果が出ません。公式情報でも、Incident tasksはアナリストが重要手順を抜かさないようにするためのタスクリストとして説明されています。SOCマネージャーやエンジニアは、インシデント種別ごとにタスクを設計し、必要に応じて自動適用させる運用を検討すべきです。(Microsoft Learn)
たとえば、アカウント侵害の疑いがあるインシデントでは、次のような調査タスクを標準化できます。
| 順序 | タスク | 完了条件 |
|---|---|---|
| 1 | 影響ユーザーを確認する | エンティティで対象UPN、所属、権限を確認 |
| 2 | 初回サインインと異常サインインを確認する | タイムラインとLogsで時刻、国、IPを確認 |
| 3 | 類似インシデントを確認する | 同じIP、端末、ルールのインシデント有無を確認 |
| 4 | メール・端末・クラウド操作を確認する | Defender XDRや関連ログで横展開を確認 |
| 5 | 封じ込めを実施する | パスワードリセット、セッション失効、端末隔離などを記録 |
| 6 | クローズ理由を記録する | True positive、False positive、Benign positiveなどの根拠をコメントに残す |
このようにタスクを定義しておくと、新人アナリストでも最低限の確認を漏らしにくくなります。シフト交代時も「どこまで確認したか」が残るため、同じログを何度も見直す無駄を減らせます。
移行・展開時の注意点
Microsoft SentinelをDefenderポータルへ移行する場合、単に画面のURLが変わるだけではありません。インシデント相関、アラート表示、コメント同期、手動作成インシデント、Advanced hunting、IdentityInfo、Threat Intelligence、workbooksなど、複数の領域で挙動差があります。Microsoftは、移行後に統合インシデントキューでより包括的な攻撃ストーリーを確認できる一方、マルチワークスペースではプライマリワークスペースのアラートのみがDefender XDRデータと相関されると説明しています。(Microsoft Learn)
展開前には、次の順序で検証すると失敗しにくくなります。
| フェーズ | やること | 成果物 |
|---|---|---|
| 棚卸し | 分析ルール、自動化ルール、プレイブック、KQL、API連携、チケット連携を一覧化 | 影響範囲リスト |
| 検証 | テストインシデントで同期、相関、コメント、クローズ、再オープンを確認 | 検証ログ |
| 修正 | インシデント名依存、Description依存、ProviderName依存を修正 | 改修済みルール |
| 教育 | アナリスト向けにDefenderポータルの調査手順を共有 | 調査手順書 |
| 展開 | 段階的にワークスペースを移行し、監視を強化 | 移行計画とロールバック手順 |
特に注意すべきなのは、Defenderポータル移行直後に最大5分程度、Microsoft DefenderインシデントがMicrosoft Sentinelへ完全に統合されるまで遅延する場合がある点です。また、アラートの追加・削除はDefenderポータル側でのみサポートされるなど、操作できる場所が変わる機能もあります。(Microsoft Learn)
まず実施すべき確認チェックリスト
最後に、管理者と開発者が今すぐ確認すべき項目を整理します。
| 対象者 | 確認すること | 優先度 |
|---|---|---|
| SOC管理者 | Azure portalでの調査手順をタスク化し、コメント・クローズ理由の記録ルールを決める | 高 |
| Sentinel管理者 | Microsoft Sentinel Responder、Directory Reader、Defender側RBACを確認する | 高 |
| Defender管理者 | Defender XDRコネクタ、個別Defenderコネクタ、重複インシデント作成ルールを確認する | 高 |
| セキュリティエンジニア | KQL、workbooks、Advanced hunting、IdentityInfo依存を洗い出す | 高 |
| 開発者 | Microsoft Graphの/security/alerts依存を確認し、v2 APIとインシデントAPIへ移行計画を作る | 高 |
| 運用責任者 | 2027年3月31日以降のAzure portal非サポートを前提に、Defenderポータル移行計画を作る | 高 |
| MSSP・外部SOC | ゲストユーザー権限、マルチテナント運用、顧客ごとのワークスペース相関を確認する | 中〜高 |
Microsoft Sentinel incident investigation in the Azure portalは、Azure portalでの調査機能を理解するための重要な公式情報です。ただし、今後の運用ではMicrosoft Defenderポータルへの移行、Defender XDRとの統合、APIのインシデント中心モデルへの移行まで含めて考える必要があります。まずは、現在のインシデント調査手順、Defender XDRコネクタ、自動化ルール、KQL/API連携を棚卸しし、移行後に壊れやすい条件依存のルールから修正を進めましょう。
コメント