Microsoft SentinelをAzureポータルで運用している組織は、Microsoft Defenderポータルへの移行を「画面の変更」ではなく、SOC運用・自動化・権限・API連携の見直しとして扱う必要があります。2026年5月14日に更新されたMicrosoft公式記事「Transition your Microsoft Sentinel environment to the Defender portal」では、既存のMicrosoft Sentinel環境をDefenderポータルへ移行する際の前提条件、影響範囲、制限事項が整理されています。(Microsoft Learn)
結論から言うと、移行そのものに追加費用はなく、既存のLog Analytics基盤やデータ取り込みの基本構成は維持されます。一方で、インシデント相関、自動化ルール、プレイブック、APIレスポンス、RBAC、データ保持・プライバシーポリシーには実務上の影響があります。特に外部チケットシステム、ServiceNow連携、独自スクリプト、KQLベースの検知運用を使っている環境では、移行前に検証用ワークスペースで差分を確認しておくことが重要です。(Microsoft Learn)
Microsoft SentinelのDefenderポータル移行で押さえるべき結論
Microsoft Sentinelは、Microsoft Defenderポータル上でMicrosoft Defender XDRと組み合わせて利用できるだけでなく、Defender XDRやE5ライセンスがない環境でも単独で利用できます。Microsoftの公式情報では、2027年3月31日以降、Microsoft SentinelはAzureポータルではサポートされず、Defenderポータルでのみ利用可能になると案内されています。(Microsoft Learn)
そのため、管理者が今すぐ行うべきことは、単に「いつ切り替えるか」を決めることではありません。次の3点を先に確認する必要があります。
- 既存のインシデント運用が、Defender XDRの相関エンジンによる統合後も同じ判断で回るか
- Automationルール、Logic Appsプレイブック、外部チケット連携が移行後も期待通りに動くか
- 権限、データ保持、CMK、API連携の変更が社内の監査・セキュリティ要件に合うか
特に注意すべきなのは、Microsoft Defenderポータルへの移行後、すべてのインシデントが従来のMicrosoft Sentinel中心の見え方ではなく、Microsoft XDRをプロバイダーとする統合インシデントとして扱われる点です。従来の「アラート単位」「製品単位」「分析ルール単位」の運用をそのまま移すと、チケット起票条件や一次対応の判断がずれる可能性があります。(Microsoft Learn)
主な変更点と管理者が確認すべきポイント
Microsoft Defenderポータルへの移行では、データ収集基盤そのものよりも、運用画面・インシデント管理・自動化・権限制御の変化が大きなポイントになります。
| 確認領域 | 主な変更点 | 実務で確認すべきこと |
|---|---|---|
| ポータル | Microsoft Sentinelの操作場所がAzureポータル中心からDefenderポータル中心へ移る | 既存手順書、SOC向け教育資料、画面キャプチャを更新する |
| コスト | 移行自体に追加費用はない | Sentinelの従量課金、ログ取り込み量、保持期間の監視は継続する |
| データ収集 | 既存コネクタやLog Analyticsへの取り込み基盤は基本的に維持される | Defender XDRコネクタでインシデントとアラートが有効か確認する |
| インシデント相関 | Defender XDRの相関エンジンがアラート統合を制御する | インシデント件数、名称、統合条件の変化を前提に運用を見直す |
| 分析ルール | Microsoft Sentinelの分析ルールはDefenderポータルでも利用できる | アラートのみ生成するルール、Fusion依存の検知、カスタム検知を確認する |
| Automation | ルール条件、トリガー、実行タイミングに影響が出る | インシデント名やDescriptionフィールドに依存した条件を修正する |
| API | 統合インシデント・アラートではMicrosoft Graph REST APIの利用が推奨される | SecurityInsights API依存のスクリプト、チケット連携、レスポンス項目を確認する |
| RBAC | Defender統合RBACや一部テーブルの権限制御に注意が必要 | 最小権限、担当者ロール、IdentityInfoテーブルのアクセス制御を見直す |
既存のデータコネクタは基本的に中断なく動作し、Log Analyticsの取り込みパイプラインやデータスキーマも大きく変わりません。ただし、Defender製品に関連するアラートはMicrosoft Defender XDRコネクタから直接ストリーミングされるため、ワークスペース側でインシデントとアラートの取り込みが有効になっているか確認が必要です。(Microsoft Learn)
移行対象になる環境と前提条件
今回の公式情報が主に対象としているのは、すでにMicrosoft Sentinelが有効化された既存のLog Analyticsワークスペースを持ち、AzureポータルでSentinelを運用している組織です。新規顧客で、サブスクリプションのOwnerまたはUser Access Administrator権限を持ってオンボードした場合、ワークスペースはDefenderポータルへ自動的にオンボードされるとされています。(Microsoft Learn)
既存環境では、以下のような構成ほど移行前の検証が重要です。
| 環境の特徴 | 移行前に注意すべき理由 |
|---|---|
| 複数ワークスペースを運用している | プライマリワークスペースとセカンダリワークスペースの扱いを確認する必要がある |
| 複数テナントをMSSPやグループ会社で管理している | マルチテナントポータル、Azure Lighthouse、Entra B2Bの利用状況を整理する必要がある |
| ServiceNowなど外部チケットシステムと連携している | インシデントURL、説明文、プロバイダー名などのAPI項目変更が影響しやすい |
| AutomationルールやLogic Appsプレイブックを多用している | トリガー条件、実行遅延、手動実行制限を確認する必要がある |
| CMKや厳格なデータ保持ポリシーを使っている | ログ、インシデント、アラート、データレイクで暗号化や保持の扱いが異なる |
| KQL、Advanced Hunting、IdentityInfoを使っている | テーブル項目やRBACの違いによりクエリ修正が必要になる場合がある |
マルチワークスペース構成では、各ワークスペースをテナントごとにDefenderポータルへ個別にオンボードする必要があります。また、Microsoft Defender XDRデータとの相関はプライマリワークスペースのアラートが中心になるため、どのワークスペースを主軸にするかを先に決めることが重要です。(Microsoft Learn)
権限とRBACで確認すべきこと
Microsoft Defenderポータルへオンボードすると、サブスクリプション内のMicrosoft Threat ProtectionアプリとWindowsDefenderATPアプリにMicrosoft Sentinel Contributorロールが割り当てられます。これは統合運用に必要な構成ですが、セキュリティ管理者は「誰が何を操作できるか」だけでなく、「サービスプリンシパルにどの権限が付与されたか」も棚卸しする必要があります。(Microsoft Learn)
実務では、次の順番で確認すると漏れを減らせます。
| 確認項目 | 見るべき内容 |
|---|---|
| Azure RBAC | 既存のMicrosoft Sentinel Reader、Responder、Contributorなどの割り当て |
| Defender統合RBAC | Defenderポータル側での役割、スコープ、操作権限 |
| サービスプリンシパル | オンボード時に付与されるアプリ権限 |
| MSSP権限 | Azure Lighthouse、Entra B2B、マルチテナント管理のアクセス範囲 |
| テーブルレベルRBAC | IdentityInfoなど、移行後に同じ制御が維持されるか |
特に注意したいのがIdentityInfoテーブルです。Microsoft SentinelをDefenderポータルへ移行すると、Advanced Hunting側のIdentityInfoはDefenderのネイティブテーブルとして扱われ、テーブルレベルRBACをサポートしないとされています。Azureポータル側でIdentityInfoへのアクセスを細かく制限していた組織は、移行後に同じ制御ができるとは限らないため、監査部門やID管理担当者と事前に確認すべきです。(Microsoft Learn)
データ保存、プライバシー、CMKの注意点
AzureポータルでMicrosoft Sentinelを使う場合は、Microsoft Sentinelのデータ保存、処理、保持、共有ポリシーが適用されます。一方、DefenderポータルでMicrosoft Sentinelデータを扱う場合は、Microsoft Defender XDRのポリシーが適用されます。これは単なる画面変更ではなく、データ所在地、保持、共有、BCDRの考え方を再確認すべき変更です。(Microsoft Learn)
CMKを利用している環境では、移行前に必ず確認が必要です。公式情報では、オンボード前にCMKを有効にしていた場合、ワークスペース内のログデータや分析ルール、AutomationルールなどのSentinelコンテンツは引き続きCMKで暗号化されます。一方で、オンボード後のアラートとインシデントはCMKで暗号化されなくなるとされています。また、Microsoft Sentinelデータレイクに格納されるデータでは、CMKが完全にはサポートされず、Microsoft管理キーで暗号化される点にも注意が必要です。(Microsoft Learn)
規制業種やグローバル展開している企業では、次の観点で社内レビューを行うと安全です。
| 観点 | 確認例 |
|---|---|
| データ所在地 | ログ、インシデント、アラート、データレイクの保存場所が社内ポリシーに合うか |
| 暗号化 | CMK対象外になるデータが許容されるか |
| 保持期間 | Sentinel側とDefender XDR側の保持設定に矛盾がないか |
| データ共有 | 脅威インテリジェンスや統合分析で共有される範囲を説明できるか |
| 監査証跡 | 監査担当者がDefenderポータル上の操作ログを追跡できるか |
データコネクタとDefender for Cloud連携の確認
Microsoft SentinelとMicrosoft Defenderを統合しても、既存のデータコネクタは基本的に継続して動作します。ただし、DefenderポータルのData connectorsページでは、統合セキュリティ運用に使われる一部のDefender系コネクタが表示されません。具体的には、Microsoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Defender XDR、Microsoft Defender for Cloud Appsなどが対象です。これらはAzureポータル上のMicrosoft Sentinelでは引き続き一覧に表示されるとされています。(Microsoft Learn)
ここで失敗しやすいのは、「Defenderポータルに見えないから無効になった」と誤解することです。コネクタの表示場所と実際のデータ取り込み状態は分けて確認してください。
Defender for Cloudを利用している場合は、さらに注意が必要です。テナントベースのデータコネクタを使っている場合は重複イベントや重複アラートを防ぐ対応が必要です。レガシーなサブスクリプションベースのコネクタを使っている場合は、インシデントとアラートをMicrosoft Defenderへ同期しないようにする設定確認が必要です。(Microsoft Learn)
移行前のチェックでは、次のように棚卸しします。
| チェック項目 | 確認方法の例 |
|---|---|
| 主要ログの取り込み | 移行前後で同じKQLを実行し、件数とタイムスタンプを比較する |
| Defender XDRコネクタ | インシデントとアラートの取り込みが有効か確認する |
| Defender for Cloud | テナントベースとサブスクリプションベースのコネクタが混在していないか確認する |
| 重複アラート | 同じリソース、同じ時間帯、同じ検知名で重複していないか確認する |
| コネクタ表示 | DefenderポータルとAzureポータルで表示差分がある前提で運用資料を更新する |
分析ルールとインシデント相関の変更点
Microsoft Sentinelの分析ルールは、Defenderポータルでも作成、更新、管理できます。ウィザード、リポジトリ、Microsoft Sentinel APIを通じた管理も継続できます。ただし、インシデント相関の考え方は大きく変わります。AzureポータルでFusion分析ルールが担っていたアラート相関は、DefenderポータルではDefender XDRエンジンが担います。Fusion分析ルールは、SentinelをDefenderポータルへオンボードすると無効化されますが、相関機能自体はDefender XDRのインシデント作成・相関機能に置き換えられます。(Microsoft Learn)
この変更により、複数の分析ルールがそれぞれインシデントを生成するように設定されていても、Defender XDRの相関ロジックに一致すると、Defenderポータル上では統合されたインシデントとして表示される場合があります。攻撃の全体像を把握しやすくなる一方で、従来の「インシデント件数」をKPIにしていたSOCでは、件数の見え方が変わります。(Microsoft Learn)
また、Microsoft Sentinelの分析ルールで「アラートのみ生成し、インシデントは作成しない」設定にしている場合、そのアラートはDefenderポータルに表示されません。検知はしているのにSOCの一次対応画面に出てこない、という運用上の抜けが起きやすいため、重要な検知ルールは移行前にインシデント作成設定を見直してください。(Microsoft Learn)
Automationルールとプレイブックの落とし穴
移行で最も実務影響が出やすいのがAutomationルールとLogic Appsプレイブックです。Microsoft SentinelのプレイブックはAzure Logic Appsをベースにしていますが、Defenderポータルで運用する場合、一部のトリガーや手動実行、条件項目に制限があります。(Microsoft Learn)
特に確認すべきポイントは次の通りです。
| 項目 | 移行後の影響 | 対応ポイント |
|---|---|---|
| Incident provider条件 | すべてのインシデントのProviderNameがMicrosoft XDRになる | Microsoft Sentinel限定の条件指定を見直す |
| SecurityIncidentのDescription | 移行後はDescriptionフィールドが含まれない | Descriptionを条件にしたAutomationルールやチケット連携を修正する |
| インシデント名 | Defender XDRの相関により既存インシデント名が変わる場合がある | インシデントタイトルではなく、分析ルール名やタグを条件に使う |
| プレイブック起動遅延 | DefenderインシデントがSentinelに反映されるまで最大5分程度かかる場合がある | SLAや一次対応の自動化で遅延を考慮する |
| Automation実行遅延 | アラート発生からAutomationルール実行まで最大10分程度かかる場合がある | 即時隔離や通知の要件を再確認する |
| 手動実行 | アラートやエンティティに対する手動プレイブック実行はDefenderポータルで未サポート | 手動運用が必要な対応は代替手順を用意する |
| インシデントからのAutomation作成 | インシデント画面から直接Automationルールを作る操作はAzureポータルのみ対応 | DefenderポータルではAutomationページから新規作成する |
外部チケットシステムと連携している場合は、Descriptionフィールドが欠落する点に注意が必要です。たとえば、ServiceNowにインシデント説明文を連携している運用では、移行後にチケット本文が空欄になったり、調査に必要な情報が不足したりする可能性があります。移行前にテストインシデントを作成し、チケットの件名、本文、重大度、URL、担当キュー、更新履歴が正しく連携されるか確認してください。(Microsoft Learn)
API連携と開発者が確認すべき変更
Defenderポータルの統合エクスペリエンスでは、インシデントとアラートに関するAPI連携にも変更があります。公式情報では、アラート、インシデント、Advanced Huntingなどの自動化にはMicrosoft Graph REST API v1.0の利用がサポートされ、統合インシデントやアラートを扱う場合はMicrosoft Graph REST APIの利用が推奨されています。一方、分析ルールやAutomationルールなどMicrosoft Sentinelリソースへの操作には、Microsoft Sentinel APIが引き続き利用できます。(Microsoft Learn)
開発者が特に確認すべき項目は、レスポンスボディの差分です。
| API項目 | Azureポータル中心の運用 | Defenderポータル移行後の注意点 |
|---|---|---|
| インシデントURL | incidentUrlがMicrosoft SentinelポータルのURLを指す | providerIncidentUrlを利用してDefender側のインシデントURLを同期する |
| 検知元 | alertProductNamesを参照 | ?$expand=alertsを付けたGETが必要になる場合がある |
| プロバイダー名 | providerNameがAzure Sentinel | providerNameがMicrosoft XDRになる |
| サービスソース | 従来は存在しない項目がある | serviceSourceでMicrosoft Defender for Cloud Appsなどを識別できる |
| 検知ソース | 従来は存在しない項目がある | detectionSourceでセンサーや検知技術を確認できる |
| 製品名 | 従来は存在しない項目がある | productNameでアラートを発行した製品を識別できる |
独自のSOAR、チケット連携、SlackやTeams通知、ダッシュボード集計を作っている場合は、providerName = "Azure Sentinel"のような固定値判定が残っていないか確認してください。移行後はproviderName = "Microsoft XDR"になるため、条件分岐やフィルターが一致せず、自動処理が止まる可能性があります。(Microsoft Learn)
Advanced Hunting、KQL、IdentityInfoの確認
Microsoft SentinelをDefenderポータルへオンボードすると、既存のログテーブル、KQLクエリ、関数はAdvanced Huntingページから利用できます。また、インシデントに紐づくMicrosoft SentinelアラートはAlertInfoテーブルに取り込まれ、Advanced Huntingから参照できます。(Microsoft Learn)
一方で、AzureポータルのMicrosoft SentinelとDefenderポータルのAdvanced Huntingでは、すべてが同じ動作ではありません。たとえば、Advanced Huntingではブックマークがサポートされず、ブックマークはDefenderポータルのMicrosoft Sentinel > Threat management > Huntingで扱う必要があります。(Microsoft Learn)
IdentityInfoについても注意が必要です。Advanced Hunting側のIdentityInfoは、Defender XDRとMicrosoft Sentinelの統合フィールドを含むため、Log Analyticsワークスペース側のIdentityInfoと一部のフィールド名やサポート状況が異なります。Microsoft Sentinelの分析ルールやワークブックは従来のLog Analyticsワークスペース側のIdentityInfoを使うため影響を受けない一方、Defender側で実行するAdvanced Huntingクエリやカスタム検知は見直しが必要です。(Microsoft Learn)
実務では、次のようなKQLを優先して検証してください。
- ユーザーリスクやUEBAに依存する検知クエリ
IdentityInfo、AlertInfo、SecurityIncidentを参照するクエリ- SOCダッシュボードやワークブックで使っている集計クエリ
- チケット連携や通知に使っているインシデント抽出クエリ
- Defender XDRテーブルとSentinelテーブルを結合するクエリ
SOC運用で変わるインシデント対応フロー
Defenderポータルでは、製品をまたいだインシデントが統合キューに集約されます。従来は、エンドポイント、ID、メール、クラウド、SIEMのアラートを別々に確認していた運用でも、Defenderポータルでは複数領域のアラートをひとつの攻撃ストーリーとして扱えるようになります。(Microsoft Learn)
これは分析の効率化につながる一方で、SOC担当者に求められる知識範囲が広がることも意味します。たとえば、一次対応担当者が従来はエンドポイントアラートだけを見ていた場合でも、移行後はID、クラウドアプリ、メール、Sentinel由来のアラートを同じインシデント内で確認する必要があります。
移行後のSOC手順書では、以下を明文化しておくと現場の混乱を減らせます。
| 項目 | 明文化すべき内容 |
|---|---|
| インシデントの優先度 | Defender側の重大度、Sentinel分析ルール、対象資産の重要度をどう組み合わせるか |
| 一次切り分け | ユーザー、デバイス、IP、クラウドリソースのどこから確認するか |
| エスカレーション条件 | 複数ドメインのアラートが統合された場合、どのチームへ渡すか |
| チケット起票 | 統合インシデント単位で起票するか、アラート単位で分けるか |
| クローズ条件 | 追加アラート、関連エンティティ、推奨アクションを確認してから閉じるか |
| 教育 | Tier 1担当者にDefender XDR、Sentinel、KQLのどこまでを求めるか |
特に、インシデントが統合されることで「件数が減ったように見える」ケースがあります。これは必ずしも検知が減ったわけではなく、複数アラートがひとつのインシデントに統合された結果である可能性があります。KPIを設計している組織は、インシデント件数だけでなく、アラート件数、重大度、対応時間、再オープン率、誤検知率もあわせて見直すべきです。
移行作業の進め方
Microsoft Defenderポータルへの移行は、いきなり本番ワークスペースで実施するのではなく、棚卸し、検証、段階展開の順で進めるのが安全です。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 現状整理 | ワークスペース、データコネクタ、分析ルール、Automation、API連携を一覧化する | 移行対象リスト |
| 影響分類 | 重要度、外部連携有無、RBAC要件、CMK要件で分類する | 優先度付きリスク表 |
| 検証環境準備 | 代表的なワークスペースまたは検証用ワークスペースで接続を確認する | 検証手順書 |
| データ確認 | 主要ログ、アラート、インシデント、KQL結果を移行前後で比較する | 差分確認表 |
| Automation確認 | ルール、プレイブック、チケット連携、通知をテストする | 自動化テスト結果 |
| API確認 | Graph REST APIとSentinel APIのレスポンス差分を確認する | 修正対象スクリプト一覧 |
| SOC教育 | 新しい画面、インシデントキュー、調査フローを共有する | 運用マニュアル |
| 本番展開 | 影響の小さいワークスペースから段階的に展開する | 展開ログとロールバック手順 |
この順序で進めると、移行後に「アラートは出ているがチケットが作られない」「インシデント件名が変わってAutomationが走らない」「KQLの一部フィールドが見つからない」といったトラブルを事前に潰しやすくなります。
移行後に必ず見るべきチェックリスト
移行が完了したら、少なくとも数日から数週間は通常より細かく監視してください。特に、SOCが日次で確認している指標と、Automationの実行状況は早めに比較する必要があります。
| チェック項目 | 確認ポイント |
|---|---|
| ログ取り込み | 主要テーブルの件数、遅延、欠損が移行前と大きく変わっていないか |
| インシデント件数 | 統合により件数が減っているのか、検知漏れなのかを切り分ける |
| アラート可視性 | アラートのみ生成する分析ルールが運用画面から見えなくなっていないか |
| Automation | 期待した条件でルールが実行され、遅延が許容範囲内か |
| プレイブック | 手動実行、インシデント同期、外部連携が機能しているか |
| チケット連携 | URL、件名、本文、重大度、担当者、更新履歴が正しく同期されるか |
| KQL | Advanced Hunting、ワークブック、分析ルールのクエリがエラーなく動くか |
| RBAC | SOC担当者、監査担当者、MSSPが必要な範囲だけ操作できるか |
| データポリシー | 保持、暗号化、共有の扱いが社内要件に合っているか |
移行直後は、Defenderポータル上のインシデントとMicrosoft Sentinel側の同期に最大5分程度の遅延が発生する場合があります。また、アラート発生からAutomationルール実行まで最大10分程度かかる場合があるため、即時対応を前提にした運用では代替手段や監視条件を用意しておくべきです。(Microsoft Learn)
管理者と開発者が今すぐ取るべき対応
Microsoft SentinelのDefenderポータル移行は、期限直前に対応すると、画面変更よりも自動化・権限・API連携の修正で時間を取られます。まずは本番移行ではなく、現在の環境で影響を受ける要素を洗い出すことから始めてください。
優先度が高いのは、次の5つです。
- Automationルールでインシデント名、Description、ProviderNameを条件にしていないか確認する
- ServiceNowなど外部チケット連携で、インシデントURLや説明文が正しく連携されるか検証する
- Defender XDRコネクタでインシデントとアラートの取り込みが有効か確認する
- IdentityInfo、AlertInfo、SecurityIncidentを使うKQLやAdvanced Huntingクエリを検証する
- RBAC、CMK、データ保持、データ共有の扱いをセキュリティ・監査部門と確認する
Microsoft Defenderポータルへの移行は、SIEMとXDRを統合して調査効率を高める大きな変更です。一方で、既存運用をそのまま移すだけでは、Automationの不発、チケット情報の欠落、権限制御のずれが起きる可能性があります。最初の一歩として、ワークスペース、コネクタ、分析ルール、Automation、API連携の棚卸し表を作り、影響が大きい項目から検証環境で確認することが、最も現実的で安全な移行準備です。
コメント