SentinelのDefenderポータル移行は、単なる画面変更ではない

データ所在地・SOC運用・権限・委託契約を期限までに見直す

※本記事は、2026年7月14日時点のMicrosoft公式情報を基に作成しています。

「Microsoft Sentinelの画面が、Azure portalからMicrosoft Defenderポータルへ変わる」

この説明だけを聞くと、メニューの場所と操作画面を覚え直せば済むように思えるかもしれません。

しかし、実際の影響はそれだけではありません。

Microsoftは、2027年3月31日以降、Microsoft SentinelをAzure portalではサポートせず、Microsoft Defenderポータルでのみ利用する形へ移行すると案内しています。Azure portalを利用している組織には、現在から移行計画を開始することが推奨されています。期限後は、Azure portalでMicrosoft Sentinelを利用しているユーザーもDefenderポータルへリダイレクトされます。

2026年7月14日から期限までは、残り260日です。

しかし、260日後にポータルを切り替えればよいわけではありません。

見直すべき対象は、少なくとも次の六つです。

┌──────────────────────────────┐
│ ① SOCの画面操作・インシデント対応手順          │
├──────────────────────────────┤
│ ② データの保存場所・処理場所・保持期間          │
├──────────────────────────────┤
│ ③ SentinelとDefender XDRのロール・権限          │
├──────────────────────────────┤
│ ④ 自動化ルール・プレイブック・ITSM連携          │
├──────────────────────────────┤
│ ⑤ MSSP・SOC委託先との作業範囲・責任分界         │
├──────────────────────────────┤
│ ⑥ 監査・取引先チェックシートでの説明内容        │
└──────────────────────────────┘

情シス、法務、SOC、経営層に考えていただきたい問いがあります。

結論：移行対象は「ポータル」ではなく「セキュリティ運用モデル」である

今回の移行を、単なるURLや画面配置の変更と考えてはいけません。

Microsoftの公式移行資料では、Azure portalとDefenderポータルの間で、データの保存・処理・保持・共有に適用されるポリシーが異なると説明されています。

Azure portalを利用する場合にはMicrosoft Sentinelのポリシーが適用されますが、DefenderポータルでMicrosoft Sentinelデータを操作する場合には、Microsoft Defender XDRのポリシーが適用されます。

図1　今回変わるもの

【従来】
Azure portal
    ↓
Microsoft Sentinel
    ↓
Log Analyticsワークスペース
    ↓
Sentinel中心のインシデント・自動化・権限管理

                     移行

【今後】
Microsoft Defenderポータル
    ↓
Microsoft Sentinel ＋ Microsoft Defender XDR
    ↓
統合インシデント・統合エンティティ・統合ハンティング
    ↓
Azure RBAC ＋ Defender XDR統合RBAC
    ↓
Sentinelポリシー ＋ Defender XDRポリシーを確認

したがって、移行時には、次の三点を分けて確認する必要があります。

1．2027年3月31日に何が起きるのか

Microsoft Sentinelは、Microsoft Defender XDRやMicrosoft 365 E5ライセンスを持っていない組織も含め、Microsoft Defenderポータルで一般提供されています。

2027年3月31日以降はAzure portalでのMicrosoft Sentinelサポートが終了し、Defenderポータルのみで利用する形になります。

表1　移行期限の整理

期限当日に切り替える計画が危険な理由

ポータルを接続する操作自体よりも、その後の検証に時間がかかります。

ワークスペースを接続
        ↓
権限を確認
        ↓
インシデントの見え方を確認
        ↓
分析ルール・相関を確認
        ↓
自動化ルールを確認
        ↓
プレイブックを実行
        ↓
ITSM・ServiceNow等との連携を確認
        ↓
SOC手順書を書き換える
        ↓
アナリストを教育する
        ↓
委託先との責任分界を改訂する

このため、2027年3月31日は「移行作業を始める日」ではなく、改訂済みの運用を既に安定稼働させておく期限と考えるべきです。

2．変わらない部分もある

過度に不安をあおる必要はありません。

Microsoft SentinelをDefenderポータルへオンボードしても、既存のデータ収集とテレメトリーフローの基本構造は維持されます。

Microsoftの公式資料では、既存のデータコネクタは中断なく動作を継続し、Log Analyticsの基礎となる取り込みパイプラインやデータスキーマにも変更はないと説明されています。Microsoft Sentinelのバックエンドは引き続きLog Analyticsと統合されます。

表2　移行後も基本的に維持されるもの

Azure Workbooksも、Defenderポータルで引き続き主要な可視化・レポート手段として使用できます。

重要なのは、

という点です。

3．「東日本ワークスペースだから、すべて日本国内」は正確か

今回、法務・プライバシー・監査担当者が特に確認すべきなのが、データ所在地です。

従来、次のように説明していた組織は少なくないでしょう。

しかし、Microsoftの現在の公式資料では、Microsoft Sentinelが扱うデータを、次の三種類に分けています。

表3　Microsoft公式資料による保存・処理場所の整理

Microsoftの公式資料は、東日本のLog Analyticsワークスペースにある生データは同じ東日本リージョンに保存される一方、欧州・イスラエル・中国21Vianet以外の場所にあるワークスペースの顧客データは、米国リージョンで処理されると説明しています。

また、Microsoft SentinelをDefenderポータルへオンボードすると、処理済みデータと構成データがMicrosoft Defender XDRリージョンで保存・処理される場合があります。

図2　「保存」と「処理」を分けて考える

工場・サーバー・クラウド・Microsoft 365
                  │
                  │ 生ログ
                  ↓
┌───────────────────────────┐
│ Log Analyticsワークスペース                 │
│ 例：東日本                                  │
│                                             │
│ 生データの保存：ワークスペースと同じリージョン│
└───────────────────────────┘
                  │
                  │ 分析・相関・インシデント生成
                  ↓
┌───────────────────────────┐
│ Microsoft Sentinel                         │
│ ・アラート                                 │
│ ・インシデント                             │
│ ・分析ルール                               │
│ ・コネクタ設定                             │
└───────────────────────────┘
                  │
                  │ Defenderポータルへオンボード
                  ↓
┌───────────────────────────┐
│ Microsoft Defender XDRリージョン            │
│ ・処理済みデータ                           │
│ ・構成データ                               │
│ が保存・処理される場合がある                │
└───────────────────────────┘

したがって、確認すべき問いは、

だけではありません。

次の問いまで必要です。

① 生データはどこに保存されるか
② 生データはどこで処理されるか
③ アラート・インシデントはどこに保存されるか
④ ルール・コネクタ設定はどこで処理されるか
⑤ Defender XDRテナントはどのリージョンか
⑥ SentinelデータをどのMicrosoftサービスと共有するか

4．Defender XDRリージョンは、実テナントで確認する

Microsoft Defender XDRの地理的リージョンは、Microsoft Defenderポータルの次の場所で確認できます。

Microsoft Defenderポータル
        ↓
設定
        ↓
Microsoft Defender XDR
        ↓
アカウント

Microsoftの公式資料では、Microsoft Defender XDRテナントを作成後、別のリージョンへ移動できないと説明されています。統合サービスのデータは、元サービスの場所に加えて、データ共有先となる統合サービスのストレージルールで定める地域にも保存される場合があります。

表4　データ所在地説明表のひな型

よくない説明

改善した説明例

この書き方であれば、

• 保存

• 処理

• 生データ

• 処理済みデータ

• 構成データ

を混同せずに説明できます。

5．保持期間も一つではない

Microsoft Defender XDRのデータは原則180日間保持され、その期間中、Microsoft Defenderポータル全体で表示されます。

高度なハンティングでは、Microsoft Sentinel経由でより長期のデータを利用する場合を除き、通常は30日間のデータへアクセスできます。また、ケースについては削除されないという例外があります。

表5　保持期間を分けて確認する

取引先チェックシートで、

とだけ回答すると、どのログについての180日かが分かりません。

次のようにデータの種類を明記する必要があります。

・生ログ
・アラート
・インシデント
・高度なハンティングデータ
・ケース
・プレイブック実行履歴
・外部チケット
・証拠ファイル

6．CMKを使っている会社は、特に注意が必要

カスタマーマネージドキー、つまりCMKを利用している組織では、移行後の暗号化範囲も確認する必要があります。

Microsoftの公式資料では、Defenderポータルへのオンボード前からCMKを有効にしている場合、ワークスペース内の既存・新規ログデータは引き続きCMKで暗号化されます。

分析ルールや自動化ルールなどのSentinelコンテンツもCMKで暗号化されます。

しかし、オンボード後のアラートとインシデントは、CMKで暗号化されなくなると説明されています。

表6　CMKの適用範囲

図3　「ログがCMKだから、すべてCMK」ではない

【Log Analytics】
生ログ
分析対象データ
        │
        └──CMKを継続
       
【Microsoft Sentinelコンテンツ】
分析ルール
自動化ルール
        │
        └──CMKを継続

【Microsoft Defender XDR側】
アラート
インシデント
        │
        └──オンボード後はCMK対象外

監査回答や社内規程で、

と説明している場合には、内容の見直しが必要です。

7．SOCが見る「インシデント」は同じではなくなる

Defenderポータルでは、Microsoft SentinelとMicrosoft Defender XDRのインシデントが統合インシデントキューに集約されます。

Microsoftは、SOCのトリアージ手順を更新し、アナリストの再トレーニングが必要になる可能性を明示しています。統合キューでは、エンドポイント、ID、電子メール、クラウド、サードパーティログなどのアラートが、製品横断で相関されます。

図4　従来と移行後のインシデント管理

【従来】

Defender for Endpoint
        ↓
Defender XDRインシデント

Microsoft Sentinel分析ルール
        ↓
Sentinelインシデント

クラウド・NW・外部製品
        ↓
Sentinelインシデント


【移行後】

Endpoint ─┐
Identity ─┤
Email ────┤
Cloud ────┤
外部ログ ─┤
Sentinel分析ルール ─┘
             ↓
  Defender XDR相関エンジン
             ↓
    統合インシデントキュー

統合されることで、攻撃全体を把握しやすくなります。

一方で、これまで別々だったインシデントが一つにまとめられたり、インシデント名が変更されたりするため、既存の手順や自動処理がそのまま動くとは限りません。

8．移行によって変わる主なインシデント仕様

Microsoftの公式移行資料では、分析ルール、インシデント相関、自動化、プレイブック、コメント、API連携等について複数の変更点が案内されています。

表7　SOC手順に影響する主な変更

9．「インシデント名」を条件にした自動化は危険

Defenderポータルでは、Defender XDRの相関エンジンがインシデントを作成し、自動的に名前を付けます。

このため、インシデントタイトルを条件にした自動化ルールは、移行後に想定どおり動作しない可能性があります。

Microsoftは、インシデント名を条件にするのではなく、インシデント内のアラートを生成した分析ルール名やタグを利用することを推奨しています。

よくある従来設計

インシデント名に
「不審な管理者ログイン」
が含まれている
        ↓
ServiceNowへ緊急チケット作成
        ↓
SOC責任者へ電話通知

推奨する見直し

分析ルールID
        ＋
分析ルール名
        ＋
タグ
        ＋
重大度
        ＋
対象資産区分
        ↓
ServiceNowへ緊急チケット作成

表8　自動化ルール確認表

10．最大10分の遅延を想定した手順になっているか

Microsoftの公式資料では、Defenderポータルでインシデントが作成・更新されてから、自動化ルールがMicrosoft Sentinel側で実行されるまで、最大10分程度かかる場合があると説明されています。

また、Microsoft DefenderインシデントがMicrosoft Sentinelへ表示されるまで最大5分かかり、プレイブックのトリガーも遅延する場合があります。

図5　インシデント発生から自動処理まで

アラート発生
    ↓
Defender XDRで相関
    ↓
統合インシデントを作成
    ↓
Microsoft Sentinelへ同期
    ↓
自動化ルールを評価
    ↓
Logic Appsプレイブックを実行
    ↓
ServiceNow・Teams・メール等へ通知

この経路には、同期や評価の時間差が含まれる可能性があります。

そのため、次のような設計は再確認が必要です。

11．ServiceNowや外部ITSM連携も確認する

Microsoft Graphや外部ITSMと連携している場合は、画面だけでなく、API応答のフィールドも確認する必要があります。

Microsoftの公式移行資料では、Azure portal向けのincidentUrlに加え、Defenderポータルのインシデントへ直接リンクするproviderIncidentUrlが示されています。

また、プロバイダー名はAzure portal時代のAzure Sentinelから、DefenderポータルではMicrosoft XDRとなります。

表9　ITSM連携の確認項目

事故時に起こり得る問題

Defenderポータルでは重大インシデント
          ↓
ServiceNow連携条件が
ProviderName = Azure Sentinel
のまま
          ↓
条件に一致しない
          ↓
チケットが作成されない
          ↓
SOC委託先へ連絡されない

ポータル移行のテストでは、画面上でアラートを見るだけでなく、外部チケットが正しく起票され、正しい担当者に割り当てられるところまで確認する必要があります。

12．権限はAzure RBACだけ見ればよいのか

Microsoft Sentinelでは、引き続きAzure RBACが使用されます。

代表的なロールには、次のものがあります。

Microsoftは、可能な限り権限の少ないロールを利用し、グローバル管理者を緊急時等に限定するよう推奨しています。

一方、Defenderポータルでは、Microsoft Defender XDR統合RBACも関係します。

図6　二層の権限管理

【Azure RBAC】
・Log Analyticsワークスペース
・Microsoft Sentinel
・分析ルール
・自動化ルール
・Azureリソース
           │
           │ 両方を確認
           ↓
【Defender XDR統合RBAC】
・統合インシデント
・アラート
・高度なハンティング
・Defender XDRデータ
・Sentinelスコープ

表10　移行時の権限確認表

Microsoft SentinelをDefenderポータルへ接続しても、既存のAzure RBACアクセス許可を利用して、アクセス可能なSentinel機能とワークスペースを表示・操作します。一方、統合RBACを有効にする構成では、Defender側のロール・スコープも確認する必要があります。

13．「閲覧できる」と「担当である」は別

SOC委託先にDefenderポータルの閲覧権限を与えても、次の権限が自動的に与えられるわけではありません。

・分析ルールを変更する権限
・データコネクタを変更する権限
・プレイブックを修正する権限
・Azureリソースを隔離する権限
・ユーザーを無効化する権限
・端末をネットワーク隔離する権限
・インシデントを終了する権限
・証拠を外部へ提出する権限

逆に、技術上はインシデントを終了できる権限があっても、契約上は顧客の承認が必要な場合があります。

表11　技術権限と契約上の作業範囲

14．複数ワークスペースのSOCは「プライマリ」を確認する

Defenderポータルでは、一つのプライマリワークスペースと、複数のセカンダリワークスペースを接続できます。

プライマリワークスペースへアクセスできる利用者は、ワークスペースとDefender XDRのデータを読み取り・管理できます。

セカンダリワークスペースについては、ワークスペースデータを読み取り・管理できますが、Defender XDRのインシデントとアラートは同期されません。

また、複数ワークスペース環境では、プライマリワークスペースのアラートのみがDefender XDRデータと相関されます。

図7　複数ワークスペースの違い

                Microsoft Defender XDR
                         │
                         │ 相関・同期
                         ↓
            ┌──────────────────┐
            │ プライマリワークスペース │
            └──────────────────┘
                    ↑
                    │
                    │ Defender XDRと統合
                    │
      ┌─────────────┴─────────────┐
      ↓                                           ↓
┌──────────────┐                    ┌──────────────┐
│ セカンダリWS A │                    │ セカンダリWS B │
│ 工場・国内拠点 │                    │ 海外拠点       │
└──────────────┘                    └──────────────┘
ワークスペースデータの                 ワークスペースデータの
参照・管理は可能                       参照・管理は可能
XDRインシデント同期はなし               XDRインシデント同期はなし

複数拠点・MSSPで確認する事項

15．IdentityInfoのアクセス制御にも注意する

Microsoft SentinelをDefenderポータルへオンボードすると、IdentityInfoテーブルはDefender XDRとSentinelの両方を統合した形でAdvanced Huntingから利用できます。

ただし、Log Analytics側とAdvanced Hunting側では、フィールド名やサポートされる項目に違いがあるため、Defender側で実行するKQLやカスタム検出を確認・更新する必要があります。

さらに、Defenderポータルへ移行すると、IdentityInfoはネイティブDefenderテーブルとなり、テーブルレベルRBACをサポートしません。Azure portalでIdentityInfoへのアクセスをテーブルレベルで制限している場合、その制御をそのまま利用できなくなります。

表12　IdentityInfo確認表

16．データコネクタの画面も同じとは限らない

Defenderポータルへオンボードした後も、既存コネクタによるデータ収集は継続します。

ただし、Microsoftの公式移行資料では、次のMicrosoft系コネクタが、Defenderポータルのデータコネクタページに表示されないと説明されています。

• Microsoft Defender for Cloud Apps

• Microsoft Defender for Endpoint

• Microsoft Defender for Identity

• Microsoft Defender for Office 365

• Microsoft Defender XDR

• 一部のMicrosoft Defender for Cloudコネクタ

これらは統合セキュリティ運用に利用されますが、現在の公式資料上、Azure portalのMicrosoft Sentinelには引き続き表示されます。

2027年3月31日以降はAzure portalでのSentinel利用がサポートされないため、コネクタの状態確認、設定変更、障害調査をどこから行うかを、事前に実テナントで確認する必要があります。

表13　コネクタ運用手順の確認項目

17．SOC運用手順書のどこを書き換えるべきか

表14　改訂対象となる主な手順書

18．「証跡取得手順」は画面キャプチャだけでは不十分

監査やインシデント報告の証拠として画面キャプチャを利用している場合、ポータル移行後は、画面構成や表示項目が変わります。

また、Defender XDRの相関によって、複数のアラートが一つのインシデントへ統合されることがあります。

そのため、証跡には次の識別情報を含める必要があります。

表15　移行後の証跡取得項目

図8　推奨する証跡の関連付け

DefenderインシデントID
          │
          ├─SentinelインシデントID
          ├─アラートID
          ├─分析ルールID
          ├─ワークスペースID
          ├─外部チケット番号
          ├─プレイブック実行ID
          └─証拠ファイル管理番号

19．委託契約・SOC契約で見直す事項

今回の移行で、委託先の作業が自動的に増減するわけではありません。

しかし、実際の操作画面、必要権限、インシデント単位、データ閲覧範囲が変わるため、契約上の作業記載が実態と合わなくなる可能性があります。

表16　委託先との確認事項

委託契約上の表現例

見直し前

見直し後の整理例

これは一般的な整理例です。

実際の契約条項、責任、損害賠償、再委託等の法的判断は、具体的な事案に応じて弁護士等の適切な専門家へ確認する必要があります。

20．移行時のRACI表

以下は一般的な例です。

組織構成や委託範囲に応じて調整する必要があります。

表17　移行プロジェクトのRACI

凡例

21．移行完了を「接続済み」で判定しない

Defenderポータルでワークスペースが「接続済み」と表示されても、運用移行が完了したとは限りません。

表18　移行完了判定表

22．2027年3月31日までの移行ロードマップ

表19　推奨ロードマップ

図9　移行の優先順位

最優先
  │
  ├─インシデント対応
  ├─自動化・プレイブック
  ├─ITSM・緊急通知
  ├─権限
  └─データ所在地
        ↓
次に実施
  │
  ├─手順書
  ├─証跡
  ├─契約・責任分界
  └─教育
        ↓
最後に確認
  │
  ├─画面レイアウト
  ├─ダッシュボード
  └─利用者向け操作性

画面の見た目から確認するのではなく、止まると事故につながる運用から先に確認することが重要です。

23．情シス・SOC・法務向けセルフチェック

表20　Sentinel移行チェックリスト

判定の目安

24．取引先チェックシートで見直す質問

表21　見直し対象となる代表的な質問

25．山崎行政書士事務所が支援できること

SentinelのDefenderポータル移行では、次の二つを切り離さないことが重要です。

Microsoft Sentinel・Defender XDRの実設定
                       ×
SOC手順・責任分界・監査説明・委託先管理

山崎行政書士事務所では、Azure、Microsoft 365、Microsoft Entra ID等の設定、契約、運用ルール、ログ、委託先管理を整理し、情シス・法務・経営層が同じ説明をできる資料づくりを支援しています。

表22　主な支援成果物

単に「画面のスクリーンショットを差し替える」のではありません。

実際の、

• Log Analyticsワークスペースのリージョン

• Microsoft Defender XDRリージョン

• プライマリ・セカンダリワークスペース

• Azure RBAC

• Defender XDR統合RBAC

• 分析ルール

• 自動化ルール

• Logic Appsプレイブック

• ServiceNow等のITSM連携

• CMK

• SOC委託契約

• 取引先への既存回答

を確認し、技術的な実態と文書上の説明を一致させます。

2027年3月31日、使えなくなるのは画面だけではない

Microsoft SentinelがAzure portalからMicrosoft Defenderポータルへ移行することで、SIEMとXDRを統合した、より広い攻撃全体の把握が可能になります。

しかし、統合によって変わるのは、画面だけではありません。

データの保存・処理場所
インシデントの相関
アラートの見え方
自動化ルールの条件
プレイブックの実行
API・ITSMのフィールド
権限モデル
CMKの適用範囲
MSSPの作業範囲
証跡の取得方法

これらが変わります。

期限当日にDefenderポータルへアクセスできたとしても、

• SOCが正しいインシデントを見つけられない

• 自動化ルールが発火しない

• ServiceNowへチケットが作成されない

• 委託先に必要な権限がない

• 監査でデータ所在地を説明できない

のであれば、移行が完了したとはいえません。

2027年3月31日までに見直すべきなのは、ポータルの操作方法ではありません。