2027年3月31日、Sentinel運用手順書が使えなくなる会社

※本記事は、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、経営層に考えていただきたい問いがあります。

Azure portalの画面を前提とした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ポリシーを確認

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

・変わらないもの
　- 主な確認事項：生ログの保存先、既存コネクタ、Log Analyticsの基本構造

・変わるもの
　- 主な確認事項：インシデント相関、画面、データ処理、CMK、権限、自動化

・新たに確認するもの
　- 主な確認事項：Defender XDRリージョン、統合RBAC、プライマリワークスペース

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

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

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

表1　移行期限の整理

・2026年7月14日現在
　- 状況：Azure portalを利用している組織に、移行計画開始が推奨されている

・移行準備期間
　- 状況：Defenderポータルへのオンボード、テスト、手順書改訂、教育を実施

・2027年3月31日以降
　- 状況：Azure portalでMicrosoft Sentinelをサポートしない

・期限後の利用者
　- 状況：Defenderポータルへリダイレクトされ、Defenderポータルのみで利用

・実務上の移行期限
　- 状況：2027年3月31日より前に、検証・教育・契約整理まで完了させる必要がある

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

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

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

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

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

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

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

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

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

・Log Analyticsワークスペース
　- 移行後の考え方：引き続き生データの保存基盤として利用

・既存のデータコネクタ
　- 移行後の考え方：基本的なデータ収集を継続

・KQL
　- 移行後の考え方：既存クエリを引き続き利用可能。ただし一部テーブル差異は要確認

・分析ルール
　- 移行後の考え方：Defenderポータルで作成・更新・管理可能

・自動化ルール
　- 移行後の考え方：引き続き利用可能。ただし条件・遅延・制約の確認が必要

・Logic Appsプレイブック
　- 移行後の考え方：引き続き利用可能。ただし実行経路等を再確認

・Azure Workbooks
　- 移行後の考え方：Defenderポータルでも主要な可視化手段として利用可能

・Log Analyticsの保持設定
　- 移行後の考え方：ワークスペース・テーブル単位の設定を継続

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

重要なのは、

すべてが作り直しになるわけではないが、運用結果が同じになるとは限らない

という点です。

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

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

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

当社のMicrosoft Sentinelは東日本リージョンのLog Analyticsワークスペースを利用しているため、ログはすべて日本国内で保存・処理されています。

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

・生データ
　- 例：接続サービスや機器から収集したイベント、ログ

・処理済みデータ
　- 例：インシデント、アラート

・構成データ
　- 例：データコネクタ設定、分析ルール、各種構成

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

・生データの保存
　- 保存場所・処理場所：Microsoft Sentinelに関連付けられたLog Analyticsワークスペースと同じリージョン

・生データの処理
　- 保存場所・処理場所：欧州、イスラエル、中国21Vianetについては各地域。それ以外のワークスペースは米国リージョンで処理されると記載

・Defenderポータル未接続時の処理済み・構成データ
　- 保存場所・処理場所：生データと同じ考え方で保存・処理

・Defenderポータル接続後の処理済み・構成データ
　- 保存場所・処理場所：Microsoft Defender XDRリージョンで保存・処理される場合がある

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

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

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

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

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

「Log Analyticsワークスペースはどこにあるか」

だけではありません。

次の問いまで必要です。

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

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

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

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

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

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

・Log Analyticsワークスペース
　- 確認結果：東日本／西日本／その他
　- 確認証跡：ワークスペース概要画面

・Sentinel生データの保存
　- 確認結果：ワークスペースと同一リージョン
　- 確認証跡：Microsoft公式資料

・Sentinel生データの処理
　- 確認結果：公式資料の地域区分を確認
　- 確認証跡：Microsoft公式資料

・Defender XDRリージョン
　- 確認結果：実テナント表示を記載
　- 確認証跡：Defender XDRアカウント画面

・Sentinel処理済みデータ
　- 確認結果：XDRリージョンで処理される可能性
　- 確認証跡：移行・所在地資料

・Sentinel構成データ
　- 確認結果：XDRリージョンで処理される可能性
　- 確認証跡：移行・所在地資料

・Sentinel Data Lake
　- 確認結果：プライマリワークスペースと同一リージョン
　- 確認証跡：Data Lake設定

・外部SOC・ITSM
　- 確認結果：委託先システムの保存地域
　- 確認証跡：契約・サービス仕様

・長期保存先
　- 確認結果：Storage、Sentinel、外部SIEM等
　- 確認証跡：保持設定画面

よくない説明

Microsoft Sentinelは東日本リージョンに構築しているため、すべてのデータが日本国内にあります。

改善した説明例

当社のMicrosoft Sentinel生データは、東日本リージョンのLog Analyticsワークスペースに保存しています。

一方、Microsoft Sentinelの公式仕様上、生データの処理場所、インシデント・アラート等の処理済みデータ、分析ルール・コネクタ等の構成データは、保存場所と異なる場合があります。

Microsoft SentinelをDefenderポータルへオンボードした後は、処理済みデータおよび構成データがMicrosoft Defender XDRリージョンで保存・処理される場合があります。当社のDefender XDRリージョンは［確認結果］です。

この書き方であれば、

保存
処理
生データ
処理済みデータ
構成データ

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

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

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

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

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

・Log Analyticsの生ログ
　- 主な保持設定：ワークスペース・テーブル設定による

・Sentinel Data Lake
　- 主な保持設定：Data Lakeの設定による

・Defender XDRデータ
　- 主な保持設定：原則180日

・Defender XDR高度なハンティング
　- 主な保持設定：原則30日

・Defender XDRのケース
　- 主な保持設定：削除されない例外あり

・Sentinelインシデント
　- 主な保持設定：利用ポータルと統合状態を確認

・Microsoft Sentinelアーカイブ
　- 主な保持設定：Log Analyticsの設定による

・Logic Apps実行履歴
　- 主な保持設定：Logic Appsの設定による

・ServiceNow等のチケット
　- 主な保持設定：外部システムの設定による

・SOC委託先の作業記録
　- 主な保持設定：委託契約・委託先環境による

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

セキュリティログの保存期間は180日です。

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

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

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

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

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

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

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

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

表6　CMKの適用範囲

・ワークスペース内の既存ログ
　- Defenderポータル接続後：CMK暗号化を継続

・新たに取り込まれるログ
　- Defenderポータル接続後：CMK暗号化を継続

・分析ルール
　- Defenderポータル接続後：CMK暗号化を継続

・自動化ルール等のSentinelコンテンツ
　- Defenderポータル接続後：CMK暗号化を継続

・アラート
　- Defenderポータル接続後：CMK暗号化の対象外になる

・インシデント
　- Defenderポータル接続後：CMK暗号化の対象外になる

・Sentinel Data Lake内の一部データ
　- Defenderポータル接続後：CMKが完全にはサポートされず、Microsoft管理キーを使用

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

【Log Analytics】
生ログ
分析対象データ
　　　│
　　　└──CMKを継続

【Microsoft Sentinelコンテンツ】
分析ルール
自動化ルール
　　　│
　　　└──CMKを継続

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

監査回答や社内規程で、

Sentinelデータはすべて当社管理の暗号鍵で暗号化している

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

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手順に影響する主な変更

・インシデント相関
　- 移行後の主な影響：Defender XDRの内部相関ロジックがインシデント統合を制御

・インシデント名
　- 移行後の主な影響：相関により、既存のインシデント名が変更される場合がある

・プロバイダー名
　- 移行後の主な影響：Defenderポータルでは原則Microsoft XDRとなる

・Fusion
　- 移行後の主な影響：Azure portalのFusion分析ルールは無効化され、XDR相関機能へ置き換わる

・アラートのみの分析ルール
　- 移行後の主な影響：インシデント作成が無効な場合、Defenderポータルに表示されない

・インシデント作成ルール
　- 移行後の主な影響：Microsoftセキュリティインシデント作成ルールは非アクティブ化

・手動・API作成インシデント
　- 移行後の主な影響：Sentinelで手動・API・Logic Appsにより作成した一部インシデントはDefenderポータルへ同期されない

・コメント編集
　- 移行後の主な影響：Defenderポータルでは既存コメントの編集をサポートしない

・閉じたインシデント
　- 移行後の主な影響：新しいアラートが追加されても、従来と同じ条件では再オープンされない場合がある

・自動化実行
　- 移行後の主な影響：インシデント同期やルール実行まで遅延が生じる場合がある

・手動プレイブック
　- 移行後の主な影響：アラートやエンティティからの手動実行には未対応の操作がある

・ハンティング
　- 移行後の主な影響：高度なハンティングではブックマークを使えず、Sentinelのハンティング画面を利用

・IdentityInfo
　- 移行後の主な影響：Advanced HuntingとLog Analyticsでスキーマ差異があり、クエリ確認が必要

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

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

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

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

よくある従来設計

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

推奨する見直し

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

表8　自動化ルール確認表

・インシデントタイトル
　- 確認内容：条件として使用していないか

・プロバイダー名
　- 確認内容：Azure Sentinel等を固定していないか

・インシデントプロバイダー条件
　- 確認内容：廃止・変更の影響を受けないか

・説明フィールド
　- 確認内容：条件に利用していないか

・更新者フィールド
　- 確認内容：移行後の値に対応しているか

・アラートルール名
　- 確認内容：移行後も一意に識別できるか

・タグ
　- 確認内容：自動化判定に使えるタグを付けているか

・同期遅延
　- 確認内容：即時実行を前提にしていないか

・プレイブック実行
　- 確認内容：アラート、エンティティ、インシデントのどこから実行するか

・外部ITSM
　- 確認内容：URL・ID・ProviderNameの変更に対応しているか

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

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

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

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

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

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

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

・アラート発生から1分以内の通知をSLAとしている
　- 見直し事項：実測し、サービス仕様とSLAを分ける

・5分通知がなければ障害扱いにしている
　- 見直し事項：Defender／Sentinel同期遅延を考慮

・SOCがプレイブックを即時実行できる前提
　- 見直し事項：インシデント同期状態を確認

・インシデントタイトルで自動起票
　- 見直し事項：分析ルールID・タグへ変更

・同じインシデントへ何度も更新通知する
　- 見直し事項：更新イベントの集約動作を確認

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

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

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

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

表9　ITSM連携の確認項目

・インシデントURL
　- 確認内容：Azure portalを指す旧URLのままになっていないか

・providerIncidentUrl
　- 確認内容：Defenderポータルへのリンクに利用するか

・providerName
　- 確認内容：Azure Sentinelを固定条件にしていないか

・serviceSource
　- 確認内容：発生サービスの識別に利用するか

・detectionSource
　- 確認内容：検出元をチケットへ記録するか

・productName
　- 確認内容：製品別の担当割当てに利用するか

・インシデント名
　- 確認内容：一意キーとして使っていないか

・インシデントID
　- 確認内容：Sentinel側とXDR側を対応付けられるか

・説明フィールド
　- 確認内容：外部チケットへ表示されないケースを確認したか

・コメント
　- 確認内容：編集・同期制限を考慮しているか

事故時に起こり得る問題

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

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

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

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

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

・Microsoft Sentinel閲覧者
　- 主な権限：データ、インシデント、ブック等の表示

・Microsoft Sentinelレスポンダー
　- 主な権限：閲覧権限に加え、インシデントの管理

・Microsoft Sentinel共同作成者
　- 主な権限：ルール、ソリューション等の作成・編集

・Microsoft Sentinelプレイブックオペレーター
　- 主な権限：プレイブックの一覧・表示・手動実行

・Microsoft Sentinel Automation共同作成者
　- 主な権限：自動化ルールがプレイブックを利用できるようにする

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

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

図6　二層の権限管理

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

表10　移行時の権限確認表

・Sentinelワークスペースをオンボード
　- 確認する権限：サブスクリプション所有者またはユーザーアクセス管理者、Sentinel共同作成者等

・Sentinelデータの閲覧
　- 確認する権限：Azure RBACのSentinel閲覧者等

・インシデント対応
　- 確認する権限：Sentinelレスポンダー、Defender XDR側権限

・分析ルール変更
　- 確認する権限：Sentinel共同作成者

・プレイブック実行
　- 確認する権限：Sentinelプレイブックオペレーター、Logic Apps権限

・Defender XDRインシデント閲覧
　- 確認する権限：Defender XDR統合RBAC

・Sentinelスコープ作成
　- 確認する権限：Defender XDR統合RBACの管理権限等

・データ収集規則変更
　- 確認する権限：Azure側のDCR書込み権限

・MSSPのテナント間アクセス
　- 確認する権限：Lighthouse、B2B、マルチテナントポータル等

・監査閲覧
　- 確認する権限：読取り専用ロールと対象スコープ

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

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

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

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

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

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

・アラートの閲覧
　- 技術上可能か：○／×
　- 契約上許可されているか：○／×
　- 最終承認者：SOC責任者

・インシデントの担当者変更
　- 技術上可能か：○／×
　- 契約上許可されているか：○／×
　- 最終承認者：情シス

・インシデント終了
　- 技術上可能か：○／×
　- 契約上許可されているか：○／×
　- 最終承認者：情シス・業務責任者

・プレイブック実行
　- 技術上可能か：○／×
　- 契約上許可されているか：○／×
　- 最終承認者：セキュリティ責任者

・端末隔離
　- 技術上可能か：○／×
　- 契約上許可されているか：○／×
　- 最終承認者：情シス

・ユーザー無効化
　- 技術上可能か：○／×
　- 契約上許可されているか：○／×
　- 最終承認者：ID管理責任者

・Firewall変更
　- 技術上可能か：○／×
　- 契約上許可されているか：○／×
　- 最終承認者：ネットワーク責任者

・証拠ダウンロード
　- 技術上可能か：○／×
　- 契約上許可されているか：○／×
　- 最終承認者：法務・情報管理

・Microsoftへのファイル提出
　- 技術上可能か：○／×
　- 契約上許可されているか：○／×
　- 最終承認者：セキュリティ責任者

・経営層への重大報告
　- 技術上可能か：－
　- 契約上許可されているか：○／×
　- 最終承認者：CISO・経営層

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

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

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

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

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

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

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

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

・プライマリワークスペース
　- 内容：どのワークスペースを指定するか

・データ相関範囲
　- 内容：どの拠点のアラートがXDRと相関されるか

・セカンダリの役割
　- 内容：参照・分析のみか、個別運用を継続するか

・MSSPのアクセス
　- 内容：テナントごとの認証・権限

・Azure Lighthouse
　- 内容：継続利用する機能と制約

・マルチテナントポータル
　- 内容：MSSPが利用する画面と作業範囲

・インシデントID
　- 内容：顧客・ワークスペースごとの識別方法

・報告単位
　- 内容：テナント、法人、拠点、工場、子会社

・データ所在地
　- 内容：各ワークスペースとXDRリージョン

・費用按分
　- 内容：ワークスペース・データ量・拠点別の整理

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確認表

・既存KQL
　- 確認内容：Advanced Huntingで正常に実行できるか

・フィールド名
　- 確認内容：Log Analytics版との差異がないか

・カスタム検出
　- 確認内容：Defenderテーブルに対応しているか

・閲覧制限
　- 確認内容：テーブルレベルRBACを利用していないか

・個人情報
　- 確認内容：氏名、メール、部署等の閲覧範囲

・外部SOC
　- 確認内容：委託先が全IdentityInfoを閲覧できないか

・Sentinelスコープ
　- 確認内容：行レベルの制限を利用するか

・証跡
　- 確認内容：権限割当てとテスト結果を記録したか

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　コネクタ運用手順の確認項目

・コネクタ状態の確認
　- 現在の手順：Azure portalのSentinel
　- 移行後の手順：Defenderポータルまたは各製品設定

・Defender XDR接続確認
　- 現在の手順：Sentinelデータコネクタ
　- 移行後の手順：Defender統合状態を確認

・Defender for Cloud
　- 現在の手順：サブスクリプション／テナントコネクタ
　- 移行後の手順：重複アラートを含め再確認

・Microsoft 365系
　- 現在の手順：個別コネクタ画面
　- 移行後の手順：XDR統合後の接続状態を確認

・接続障害の証跡
　- 現在の手順：Azure portalスクリーンショット
　- 移行後の手順：Defenderポータル等の証跡へ変更

・委託先作業
　- 現在の手順：Azure portalの操作を契約へ記載
　- 移行後の手順：Defenderポータルの操作へ改訂

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

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

・SOC一次対応手順
　- 主な改訂箇所：インシデントキュー、フィルター、担当者設定

・アラート調査手順
　- 主な改訂箇所：Defender XDRの相関、製品名、検出元

・インシデント終了手順
　- 主な改訂箇所：終了理由、再オープン、コメント

・ハンティング手順
　- 主な改訂箇所：Advanced Hunting、Sentinel Hunting、ブックマーク

・プレイブック実行手順
　- 主な改訂箇所：実行場所、同期遅延、権限

・自動化ルール管理手順
　- 主な改訂箇所：タイトル条件、ProviderName、タグ

・データコネクタ確認手順
　- 主な改訂箇所：表示場所、接続状態、重複防止

・証跡取得手順
　- 主な改訂箇所：画面、URL、インシデントID、時刻

・ITSM連携手順
　- 主な改訂箇所：providerIncidentUrl、APIフィールド

・権限申請手順
　- 主な改訂箇所：Azure RBAC、Defender XDR統合RBAC

・MSSP作業手順
　- 主な改訂箇所：マルチテナント・プライマリワークスペース

・データ所在地説明書
　- 主な改訂箇所：SentinelとXDRの保存・処理場所

・CMK説明資料
　- 主な改訂箇所：アラート・インシデントの暗号化範囲

・BCP・DR手順
　- 主な改訂箇所：Defenderポータル障害時の代替確認

・教育資料
　- 主な改訂箇所：新しいメニュー、トリアージ、相関モデル

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

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

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

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

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

・DefenderインシデントID
　- 内容：Defender XDR側の一意識別子

・SentinelインシデントID
　- 内容：Sentinel側の識別子

・プロバイダー名
　- 内容：Microsoft XDR等

・製品名
　- 内容：Endpoint、Identity、Cloud、Sentinel等

・検出元
　- 内容：検出技術・センサー

・分析ルールID
　- 内容：Sentinel分析ルールとの関連

・ワークスペース
　- 内容：プライマリ・セカンダリの区別

・テナントID
　- 内容：MSSP・複数法人での識別

・発生日時
　- 内容：UTCと日本時間を併記

・更新日時
　- 内容：相関・追加アラートの時間

・担当者
　- 内容：誰が対応したか

・状態・終了理由
　- 内容：変更前後を記録

・コメント
　- 内容：内容と作成者、編集制限

・プレイブック
　- 内容：実行ID、結果、実行時刻

・外部チケット
　- 内容：ServiceNow等の番号

・取得者
　- 内容：誰が証跡を取得したか

・ハッシュ等
　- 内容：ファイルとして保全する場合の完全性情報

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

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

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

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

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

表16　委託先との確認事項

・利用ポータル
　- 確認事項：Azure portalかDefenderポータルか

・対象テナント
　- 確認事項：どのMicrosoft Entraテナントか

・対象ワークスペース
　- 確認事項：プライマリ・セカンダリの範囲

・閲覧データ
　- 確認事項：Sentinelだけか、XDR全体か

・担当インシデント
　- 確認事項：Sentinel由来だけか、統合インシデント全体か

・一次対応
　- 確認事項：確認、分類、担当割当て、コメント

・終了権限
　- 確認事項：委託先が終了できるか

・自動対応
　- 確認事項：プレイブックを実行できるか

・修復権限
　- 確認事項：端末隔離、ユーザー無効化等を行えるか

・証跡取得
　- 確認事項：何を、どの形式で保存するか

・データ保存
　- 確認事項：委託先が自社環境へ転記するか

・ITSM
　- 確認事項：どのチケットシステムを利用するか

・緊急連絡
　- 確認事項：Defenderポータル障害時の連絡方法

・教育
　- 確認事項：新ポータルの訓練を誰が負担するか

・移行作業
　- 確認事項：設定変更・テスト・手順改訂の担当

・移行完了判定
　- 確認事項：誰が受入れを承認するか

委託契約上の表現例

見直し前

受託者は、Azure portal上のMicrosoft Sentinelに表示されるインシデントを監視する。

見直し後の整理例

受託者は、Microsoft Defenderポータル上の統合インシデントキューを監視し、別紙に定める対象テナント、対象ワークスペース、対象製品および権限範囲に従い、一次判定、担当者割当て、コメント記録およびエスカレーションを実施する。

端末隔離、ユーザー無効化、インシデント終了、プレイブック実行その他の修復操作は、別紙の承認区分に従う。

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

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

20．移行時のRACI表

以下は一般的な例です。

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

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

・移行方針の承認
　- 経営・CISO：A
　- 情シス：R
　- Sentinel担当：C
　- SOC：C
　- 法務・個人情報：C
　- 委託先・MSSP：I

・現行環境の棚卸し
　- 経営・CISO：I
　- 情シス：A
　- Sentinel担当：R
　- SOC：C
　- 法務・個人情報：I
　- 委託先・MSSP：C

・データ所在地確認
　- 経営・CISO：I
　- 情シス：R
　- Sentinel担当：R
　- SOC：C
　- 法務・個人情報：A
　- 委託先・MSSP：C

・Defender XDRリージョン確認
　- 経営・CISO：I
　- 情シス：A
　- Sentinel担当：R
　- SOC：C
　- 法務・個人情報：C
　- 委託先・MSSP：I

・ワークスペース設計
　- 経営・CISO：I
　- 情シス：A
　- Sentinel担当：R
　- SOC：C
　- 法務・個人情報：I
　- 委託先・MSSP：C

・プライマリWS決定
　- 経営・CISO：A
　- 情シス：R
　- Sentinel担当：R
　- SOC：C
　- 法務・個人情報：I
　- 委託先・MSSP：C

・Azure RBAC確認
　- 経営・CISO：I
　- 情シス：A
　- Sentinel担当：R
　- SOC：C
　- 法務・個人情報：I
　- 委託先・MSSP：C

・Defender XDR RBAC確認
　- 経営・CISO：I
　- 情シス：A
　- Sentinel担当：R
　- SOC：R
　- 法務・個人情報：C
　- 委託先・MSSP：C

・オンボード作業
　- 経営・CISO：I
　- 情シス：A
　- Sentinel担当：R
　- SOC：C
　- 法務・個人情報：I
　- 委託先・MSSP：C

・分析ルールテスト
　- 経営・CISO：I
　- 情シス：C
　- Sentinel担当：A／R
　- SOC：R
　- 法務・個人情報：I
　- 委託先・MSSP：C

・自動化テスト
　- 経営・CISO：I
　- 情シス：C
　- Sentinel担当：A／R
　- SOC：R
　- 法務・個人情報：I
　- 委託先・MSSP：C

・ITSM連携テスト
　- 経営・CISO：I
　- 情シス：A
　- Sentinel担当：R
　- SOC：R
　- 法務・個人情報：I
　- 委託先・MSSP：C

・SOC手順書更新
　- 経営・CISO：I
　- 情シス：C
　- Sentinel担当：C
　- SOC：A／R
　- 法務・個人情報：C
　- 委託先・MSSP：R

・データ所在地説明書
　- 経営・CISO：I
　- 情シス：C
　- Sentinel担当：C
　- SOC：I
　- 法務・個人情報：A／R
　- 委託先・MSSP：C

・委託範囲整理
　- 経営・CISO：I
　- 情シス：C
　- Sentinel担当：C
　- SOC：C
　- 法務・個人情報：R
　- 委託先・MSSP：A／C

・アナリスト教育
　- 経営・CISO：I
　- 情シス：C
　- Sentinel担当：C
　- SOC：A
　- 法務・個人情報：I
　- 委託先・MSSP：R

・机上訓練
　- 経営・CISO：I
　- 情シス：A
　- Sentinel担当：R
　- SOC：R
　- 法務・個人情報：C
　- 委託先・MSSP：R

・本番移行承認
　- 経営・CISO：A
　- 情シス：R
　- Sentinel担当：C
　- SOC：C
　- 法務・個人情報：C
　- 委託先・MSSP：I

凡例

・R
　- 意味：作業を実行する担当

・A
　- 意味：最終承認・説明責任

・C
　- 意味：協議対象

・I
　- 意味：報告対象

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

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

表18　移行完了判定表

・Defenderポータルへワークスペースを接続した
　- 完了／未完了：

・Defender XDRリージョンを記録した
　- 完了／未完了：

・生データ・処理済みデータ・構成データを整理した
　- 完了／未完了：

・CMKの適用範囲を確認した
　- 完了／未完了：

・プライマリワークスペースを決定した
　- 完了／未完了：

・Azure RBACを確認した
　- 完了／未完了：

・Defender XDR統合RBACを確認した
　- 完了／未完了：

・SOC委託先の権限をテストした
　- 完了／未完了：

・統合インシデントの表示を確認した
　- 完了／未完了：

・インシデント相関をテストした
　- 完了／未完了：

・アラートのみの分析ルールを確認した
　- 完了／未完了：

・Fusionの代替動作を確認した
　- 完了／未完了：

・自動化ルールを全件テストした
　- 完了／未完了：

・プレイブックを全件テストした
　- 完了／未完了：

・ITSM・ServiceNow連携をテストした
　- 完了／未完了：

・APIフィールドの変更を確認した
　- 完了／未完了：

・KQL・カスタム検出を確認した
　- 完了／未完了：

・IdentityInfoの権限・スキーマを確認した
　- 完了／未完了：

・証跡取得手順を改訂した
　- 完了／未完了：

・SOC手順書を改訂した
　- 完了／未完了：

・委託先との責任分界を改訂した
　- 完了／未完了：

・取引先チェックシート回答を改訂した
　- 完了／未完了：

・アナリスト教育を完了した
　- 完了／未完了：

・机上訓練を完了した
　- 完了／未完了：

・本番受入れ承認を記録した
　- 完了／未完了：

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

表19　推奨ロードマップ

・2026年7月～9月
　- 実施内容：現行Sentinel、XDR、SOC、委託先の棚卸し
　- 成果物：移行影響調査表

・2026年9月～10月
　- 実施内容：データ所在地、CMK、保持期間、ワークスペース構成確認
　- 成果物：データ所在地説明表

・2026年10月～11月
　- 実施内容：Defenderポータルへ検証オンボード
　- 成果物：検証記録

・2026年11月～12月
　- 実施内容：分析ルール、自動化、プレイブック、ITSMテスト
　- 成果物：テスト結果表

・2027年1月
　- 実施内容：権限・RACI・委託範囲の改訂
　- 成果物：権限表、RACI

・2027年1月～2月
　- 実施内容：SOC手順書、証跡手順、教育資料を更新
　- 成果物：改訂版手順書

・2027年2月
　- 実施内容：SOCアナリスト教育、机上訓練
　- 成果物：教育・訓練記録

・2027年3月前半
　- 実施内容：本番移行、受入れ試験
　- 成果物：受入れ確認書

・2027年3月中旬
　- 実施内容：旧手順の利用停止、最終監査
　- 成果物：移行完了報告

・2027年3月31日
　- 実施内容：Azure portalサポート終了期限
　- 成果物：Defenderポータル運用へ一本化

図9　移行の優先順位

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

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

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

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

・2027年3月31日の期限を経営層が把握している
　- はい／いいえ：

・現在Azure portalを使う担当者を把握している
　- はい／いいえ：

・Defenderポータルへのオンボード状況を把握している
　- はい／いいえ：

・Defender XDRリージョンを確認した
　- はい／いいえ：

・生データの保存場所と処理場所を分けて説明できる
　- はい／いいえ：

・処理済みデータ・構成データの所在地を整理した
　- はい／いいえ：

・CMKの適用範囲変更を把握している
　- はい／いいえ：

・プライマリワークスペースを把握している
　- はい／いいえ：

・セカンダリワークスペースの制限を把握している
　- はい／いいえ：

・Azure RBACとDefender XDR RBACを一覧化した
　- はい／いいえ：

・SOC委託先の閲覧範囲をテストした
　- はい／いいえ：

・統合インシデントの相関動作を確認した
　- はい／いいえ：

・インシデント名を条件にした自動化がない
　- はい／いいえ：

・ProviderNameを固定した連携がない
　- はい／いいえ：

・プレイブックの同期遅延をテストした
　- はい／いいえ：

・ServiceNow等の連携をテストした
　- はい／いいえ：

・IdentityInfoのアクセス制御を確認した
　- はい／いいえ：

・SOC手順書をDefenderポータル用に改訂した
　- はい／いいえ：

・証跡取得手順を改訂した
　- はい／いいえ：

・委託先との責任分界を改訂した
　- はい／いいえ：

・取引先チェックシート回答を改訂した
　- はい／いいえ：

・アナリスト訓練を実施した
　- はい／いいえ：

・本番移行後の受入れ基準がある
　- はい／いいえ：

判定の目安

・0～7
　- 状態：移行が画面変更としてしか認識されていない可能性があります

・8～14
　- 状態：技術準備はありますが、データ・権限・委託管理が不十分です

・15～19
　- 状態：基礎は整っています。自動化・証跡・訓練を強化します

・20～23
　- 状態：移行準備は進んでいます。実運用との継続的な照合が必要です

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

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

・ログはどこに保存されますか
　- 移行後に確認すべき内容：生データ、処理済みデータ、構成データを分ける

・データは国内で処理されますか
　- 移行後に確認すべき内容：SentinelとDefender XDRの処理場所を確認

・保存期間は何日ですか
　- 移行後に確認すべき内容：Log Analytics、XDR、ケース、ITSMを分ける

・暗号鍵は自社管理ですか
　- 移行後に確認すべき内容：アラート・インシデントのCMK対象外を確認

・誰がログを閲覧できますか
　- 移行後に確認すべき内容：Azure RBAC、XDR RBAC、MSSPを確認

・委託先はデータを保存しますか
　- 移行後に確認すべき内容：外部SOC、ITSM、再委託先を確認

・インシデント対応は何分以内ですか
　- 移行後に確認すべき内容：同期遅延と人的SLAを分ける

・インシデント証跡を提出できますか
　- 移行後に確認すべき内容：Defender・Sentinel・ITSMのIDを関連付ける

・データ削除は可能ですか
　- 移行後に確認すべき内容：データ種別ごとの保持・削除方法を確認

・海外移転はありますか
　- 移行後に確認すべき内容：保存と処理、Microsoftサービス間共有を確認

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

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

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

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

表22　主な支援成果物

・移行影響調査
　- 内容：Azure portal依存の画面、操作、API、手順を棚卸し

・Sentinel構成整理表
　- 内容：ワークスペース、コネクタ、ルール、自動化の整理

・データ所在地説明表
　- 内容：生データ、処理済みデータ、構成データの整理

・保存期間整理表
　- 内容：Log Analytics、XDR、ケース、外部ITSMの保持期間

・CMK適用範囲表
　- 内容：ログ、ルール、アラート、インシデントの暗号化整理

・ロール・権限表
　- 内容：Azure RBACとDefender XDR統合RBACの可視化

・SOC・情シスRACI
　- 内容：検知、調査、終了、修復、報告の責任分界

・委託先責任分界表
　- 内容：MSSP、SOC、SIer、自社の作業範囲整理

・運用手順書更新
　- 内容：Defenderポータルの画面と新しい運用への改訂

・証跡取得手順
　- 内容：インシデントID、画面、ログ、チケットの保全方法

・ITSM連携確認表
　- 内容：URL、ProviderName、APIフィールドの確認

・移行テスト項目表
　- 内容：ルール、自動化、プレイブック、権限の試験

・取引先説明資料
　- 内容：データ所在地、保存期間、委託先の説明整理

・移行完了報告書
　- 内容：テスト、教育、受入れ、残存課題の記録

・机上訓練シナリオ
　- 内容：重大インシデントを想定したSOC訓練

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

実際の、

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の作業範囲
証跡の取得方法

これらが変わります。

Azure portalの画面を前提としたSOC手順、証跡取得手順、委託契約上の作業範囲は、そのまま使えるでしょうか。

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

SOCが正しいインシデントを見つけられない
自動化ルールが発火しない
ServiceNowへチケットが作成されない
委託先に必要な権限がない
監査でデータ所在地を説明できない

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

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

Sentinelを中心に作られていたSOC運用、データ説明、権限、委託関係を、Defender XDRとの統合を前提に再設計すること。

それが、今回の移行の本質です。

技術上の脚注

脚注1：Azure portalのサポート期限

2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defenderポータルでのみ利用する形になります。Azure portalの利用者はDefenderポータルへリダイレクトされます。

脚注2：生データと処理済みデータの所在地

生データはLog Analyticsワークスペースと同じリージョンに保存されます。一方、処理場所は保存場所と同一とは限りません。また、Defenderポータルへオンボードした場合、処理済みデータと構成データがDefender XDRリージョンで保存・処理される場合があります。

脚注3：Defender XDRリージョン

Microsoft Defender XDRの地理的リージョンは、Defenderポータルのアカウント設定で確認できます。作成後、別リージョンへ移動できないと説明されています。

脚注4：CMK

ワークスペース内のログやSentinelコンテンツはCMK暗号化を継続できますが、Defenderポータルへのオンボード後、アラートとインシデントはCMKで暗号化されなくなります。

脚注5：仕様変更への対応

Microsoft Sentinel、Microsoft Defender XDR、統合RBAC、Data Lake、各種プレビュー機能は今後も変更される可能性があります。実際の移行時には、Microsoft Learn、管理画面、メッセージセンター、契約条件および実テナントの表示を改めて確認してください。

本記事に関する注意事項

本記事は、2026年7月14日時点のMicrosoft公式情報を基にした一般的な情報提供を目的としています。

Microsoft Sentinel、Microsoft Defender XDR、Log Analytics、Microsoft Defenderポータル等の機能、提供状態、保存・処理場所、保持期間、必要ライセンス、権限、画面、API仕様は変更される可能性があります。

本記事で示したRACI、権限表、契約上の記載例、移行手順は一般的なひな型です。個別のシステム構成、データ、契約、業界規制、利用地域、委託関係に応じた調整が必要です。

本記事は、特定の事案について個人情報保護法、GDPR、秘密保持義務、委託契約等への適法性を断定するものではありません。個別具体的な法的判断、契約交渉、損害賠償、紛争対応または代理については、弁護士等の適切な専門家への相談が必要です。

山崎行政書士事務所はMicrosoftとは独立した事業者です。本記事はMicrosoftによる公式見解、保証または認定を示すものではありません。