Microsoft Sentinelの「Geographical availability and data residency in Microsoft Sentinel」は、Microsoft Sentinelのデータがどこに保存・処理されるのかを確認するための公式情報です。2026年4月22日の更新でまず押さえるべき結論は、Log Analyticsワークスペースのリージョン選定だけでなく、Defenderポータル連携、Microsoft Sentinel data lake、21Vianet環境の終了予定まで含めてデータレジデンシーを見直す必要があるという点です。特にsecurity admins、identity teams、compliance teamsは、「どのデータが、どのリージョンに保存され、どこで処理されるのか」を設計書と監査証跡に落とし込むべきです。Microsoft公式ページは2026年4月22日に更新されています。(Microsoft Learn)
Microsoft Sentinelの最新動向: Geographical availability and data residency in Microsoft Sentinelで何が変わったか
今回の公式ページで重要なのは、単に「利用可能リージョンを確認する」だけではありません。Microsoft Sentinelのアーキテクチャを、データ種別・保存場所・処理場所・連携サービス・保持期間の5つに分けて確認する必要があります。
| 確認項目 | 公式情報の要点 | 実務で見るべきポイント |
|---|---|---|
| Raw data | Log Analyticsワークスペースと同じリージョンに保存される | ワークスペース作成時のリージョン選定がデータレジデンシーの起点になる |
| Raw dataの処理 | Europe、Israel、China 21Vianetはそれぞれの地域で処理。それ以外はUSリージョンで処理 | 「保存場所」と「処理場所」を分けて説明できるようにする |
| Processed data / configuration data | Defenderポータルにオンボード済みの場合、Microsoft Defender XDRリージョンで保存・処理される可能性がある | SIEM単体設計ではなく、XDR統合後のデータ所在地も確認する |
| Microsoft Sentinel data lake | 対応リージョンがSIEMと同一ではない。関連するプライマリSentinelワークスペースと同じAzureリージョンにデプロイする必要がある | Data lakeを使う場合、先に対応リージョンを確認する |
| China 21Vianet | Azure operated by 21VianetリージョンのMicrosoft Sentinel機能は2026年8月18日に正式終了予定 | 中国環境を含むグローバル企業は移行計画が必要 |
Microsoft Sentinelは、Raw data、Processed data、Configuration dataを区別して扱います。公式情報では、Raw dataは接続済みのMicrosoftサービスやパートナーシステムから収集されるイベントデータ、Processed dataはインシデントやアラート、Configuration dataはコネクタ設定やルールなどと説明されています。(Microsoft Learn)
Raw dataはLog Analyticsワークスペースのリージョン選定が出発点
Microsoft SentinelのRaw dataは、Microsoft Sentinelに関連付けられたAzure Log Analyticsワークスペースと同じリージョンに保存されます。つまり、Microsoft Sentinelのデータレジデンシーを考えるときは、Sentinelそのものよりも先に、Log Analyticsワークスペースをどのリージョンに作るかを決める必要があります。(Microsoft Learn)
ただし、注意したいのは「保存」と「処理」が同じ意味ではないことです。公式情報では、EuropeのLog AnalyticsワークスペースはEuropeで、IsraelはIsraelで、China 21VianetはChina 21VianetでRaw dataが処理される一方、それ以外の場所にあるワークスペースはUSリージョンで処理されるとされています。(Microsoft Learn)
たとえば日本企業がJapan EastまたはJapan WestにSentinel用ワークスペースを作成した場合、Raw dataの保存先としては日本リージョンを選べます。一方で、公式説明に基づくと、Raw dataの処理場所については「日本国内で完結する」とは説明できません。監査対応では、保存場所だけでなく処理場所も明記しておくべきです。
Defenderポータルにオンボードしている環境はXDR側のリージョンも確認する
2026年4月時点の確認で特に見落としやすいのが、Microsoft SentinelをMicrosoft Defenderポータルにオンボードしているケースです。この場合、Processed dataやConfiguration dataは、Microsoft Defender XDRのリージョンで保存・処理される可能性があります。オンボードしていない場合は、Raw dataと同じ考え方で保存・処理されます。(Microsoft Learn)
Microsoft Defender XDRの公式情報では、運用リージョンとしてEuropean Union、United Kingdom、United States、Australia、Switzerland、India、UAEが示されています。また、Microsoft Defender XDRテナントは作成後に別リージョンへ移動できないとされています。(Microsoft Learn)
このため、Microsoft Sentinelの設計レビューでは次の問いを必ず確認してください。
- Microsoft SentinelはDefenderポータルにオンボード済みか
- Microsoft Defender XDRテナントの地域はどこか
- インシデント、アラート、検出ルール、コネクタ設定などの保存・処理場所を監査資料に反映しているか
- Sentinel単体のリージョン要件と、Defender XDR側のリージョン要件に矛盾がないか
特にidentity teamsは、ID関連ログやユーザー識別情報を含むアラートがSentinelとDefender XDRの両方で扱われる可能性を前提に、アクセス権限、データ所在地、監査ログの説明責任を整理しておく必要があります。
Microsoft Sentinel data lakeは「対応リージョン」と「同一リージョン制約」を確認する
Microsoft Sentinelの公式ページでは、対応リージョンの表がSIEM supported regionとData lake supported regionに分けて掲載されています。ここで重要なのは、SIEMとして使えるリージョンと、Microsoft Sentinel data lakeに対応するリージョンが必ずしも同じではないことです。さらに、Microsoft Sentinel data lakeは、関連付けられたプライマリSentinelワークスペースと同じAzureリージョンにデプロイする必要があります。(Microsoft Learn)
日本の場合、公式一覧ではSIEM supported regionとしてJapan EastとJapan Westが示され、Data lake supported regionとしてJapan Eastが示されています。つまり、日本でData lake利用を前提にするなら、最初からJapan Eastを軸にした設計を検討するのが現実的です。(Microsoft Learn)
| 利用シーン | 推奨される確認 |
|---|---|
| SIEMのみ利用 | 対象国・地域でSIEM supported regionがあるか確認する |
| Data lakeも利用 | Data lake supported regionがあるか確認する |
| 将来的にData lake利用予定 | 現時点でData lake対応リージョンにプライマリワークスペースを置くか検討する |
| 複数国のログを集約 | 各国の規制、処理場所、運用チームのアクセス権を整理する |
| 日本国内要件が強い | Japan East / Japan Westの使い分けと、処理場所の説明を分ける |
「今はSIEMだけだから」と非対応リージョンにワークスペースを作ると、後からData lakeを使いたくなったときに設計変更が大きくなります。Log Analyticsワークスペースはリージョンをまたいだデータ移行をネイティブにはサポートしておらず、別リージョンへ移す場合は新しいワークスペースの作成やデバイス・設定の再構成が必要です。(Microsoft Learn)
21Vianet環境を使う企業は2026年8月18日を前提に移行計画を立てる
Microsoft公式ページでは、Azure operated by 21VianetリージョンにおけるMicrosoft Sentinelの全機能が2026年8月18日に正式終了予定であり、新しいサブスクリプションのオンボードはできないと説明されています。(Microsoft Learn)
中国拠点を含むグローバル企業では、これは単なるリージョン情報ではなく、運用継続性の問題です。中国環境でSentinelを使っている、または使う予定があった場合は、次の観点で早めに棚卸ししてください。
| 確認対象 | 実務アクション |
|---|---|
| 既存のSentinel利用 | 対象ワークスペース、接続済みデータソース、分析ルールを一覧化する |
| 新規オンボード計画 | 21Vianet環境を前提にした計画を見直す |
| コンプライアンス要件 | 中国国内データ、国外転送、代替監視基盤の要件を整理する |
| 契約・運用体制 | Microsoft Azure operated by 21Vianetの担当窓口と影響を確認する |
| 移行スケジュール | 2026年8月18日より前に検証・切替・監査説明を完了する |
データ保持と削除ポリシーは「既定値」ではなく業務要件から決める
Microsoft Sentinelのデータは、顧客がワークスペースからMicrosoft Sentinelを削除した日、または顧客が設定した保持ポリシーに基づく日のうち、早い日まで保持されます。また、契約終了または期限切れから遅くとも90日以内に、Microsoftのシステムから復元不能な形で削除されると説明されています。(Microsoft Learn)
ここで重要なのは、保持期間を「長くすれば安全」と単純に考えないことです。セキュリティ運用では長期調査のためにログを残したくなりますが、コンプライアンス上は不要な個人情報や機密情報を長く保持しすぎるリスクもあります。
実務では、次のようにデータ種別ごとに保持方針を分けると整理しやすくなります。
| データ種別 | 例 | 保持方針の考え方 |
|---|---|---|
| セキュリティイベント | エンドポイント、クラウド、ネットワークのイベント | インシデント調査に必要な期間を基準にする |
| ID関連ログ | サインイン、認証、特権操作に関するログ | 不正アクセス調査と個人情報保護のバランスを見る |
| インシデント・アラート | SentinelやDefender XDRで生成された検出情報 | SOC運用、監査、再発防止レポートに必要な期間を決める |
| 設定情報 | コネクタ、分析ルール、自動化ルール | 変更管理と監査証跡に必要な期間を明確にする |
担当チーム別に見るべき確認ポイント
Microsoft Sentinelのデータレジデンシーは、セキュリティ管理者だけで完結するテーマではありません。identity teamsとcompliance teamsも同じ情報を見て、異なる観点から判断する必要があります。
| 担当チーム | 主な関心 | 確認すべきこと |
|---|---|---|
| Security admins | 検知、分析、運用継続 | Log Analyticsワークスペースのリージョン、Sentinel data lake対応、Defenderポータル連携状況 |
| Identity teams | IDログ、ユーザー情報、特権アクセス | ID関連ログがどこに保存・処理されるか、誰がアクセスできるか |
| Compliance teams | データ主権、規制、監査説明 | 保存場所、処理場所、保持期間、削除方針、21Vianet終了影響 |
| SOC運用チーム | 日々の調査、アラート対応 | リージョン変更や移行時の検知ルール、プレイブック、ブックへの影響 |
| クラウド基盤チーム | Azure設計、ネットワーク、コスト | ワークスペース再作成、データコネクタ再設定、リージョン制約 |
特にグローバル企業では、「本社のSOCが全世界のログを見る」設計と、「各国のデータ所在地要件」が衝突しやすくなります。Microsoft Sentinelのグローバル集約を検討する場合は、単にログを1か所へ集めるのではなく、国・地域ごとのワークスペース分割、アクセス制御、調査時の権限委任までセットで設計することが重要です。
既存環境を見直すための実務チェックリスト
既存のMicrosoft Sentinel環境では、次の順番で確認すると抜け漏れを減らせます。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | Sentinelに接続しているデータソースを一覧化する | Microsoftサービス、クラウド、オンプレミス、パートナー製品を分ける |
| 2 | Log Analyticsワークスペースのリージョンを確認する | Raw dataの保存場所として説明できるか |
| 3 | Raw dataの処理場所を確認する | Europe、Israel、China 21Vianet、それ以外の扱いを理解しているか |
| 4 | Defenderポータルへのオンボード状況を確認する | Processed data / Configuration dataがXDR側リージョンに関係するか |
| 5 | Microsoft Defender XDRテナントの地域を確認する | 作成後にリージョン移動できない前提で設計しているか |
| 6 | Sentinel data lakeの利用有無を確認する | プライマリワークスペースと同じAzureリージョンか |
| 7 | 保持期間と削除方針を確認する | セキュリティ調査と法務・監査要件の両方を満たすか |
| 8 | 21Vianet利用有無を確認する | 2026年8月18日の終了予定を移行計画に反映しているか |
このチェックリストは、年1回の監査だけでなく、Defenderポータル統合、Sentinel data lake導入、海外拠点追加、M&A後のテナント統合など、アーキテクチャが変わるタイミングでも再確認すべきです。
よくある誤解と失敗しやすいポイント
「日本リージョンに置けば、すべて日本国内で完結する」と説明してしまう
日本のSentinel対応リージョンとしてJapan EastとJapan Westは示されていますが、Raw dataの処理場所については、公式情報上、Europe、Israel、China 21Vianet以外はUSリージョンで処理されるとされています。保存場所と処理場所を同一視しないことが重要です。(Microsoft Learn)
Defenderポータル統合の影響を見落とす
SentinelをDefenderポータルにオンボードすると、Processed dataやConfiguration dataの保存・処理がMicrosoft Defender XDRリージョンと関係します。SIEMのワークスペースリージョンだけを確認して「データレジデンシー対応済み」と判断するのは不十分です。(Microsoft Learn)
Data lakeを後付けできる前提でリージョンを決める
Microsoft Sentinel data lakeは対応リージョンが限られ、関連するプライマリSentinelワークスペースと同じAzureリージョンにデプロイする必要があります。将来の分析基盤としてData lakeを使う可能性があるなら、初期設計の段階で対応リージョンを確認すべきです。(Microsoft Learn)
リージョン移行を軽く見積もる
Log Analyticsワークスペースは、リージョン間のワークスペースデータ移行をネイティブにはサポートしていません。別リージョンに移す場合は、新しいワークスペースの作成、データ収集元や設定の再構成が必要になります。(Microsoft Learn)
保持期間をSOCだけで決める
SOCは調査のために長期保持を望みがちですが、compliance teamsは最小化や削除要件も確認します。Microsoft Sentinelの保持方針は、セキュリティ調査、監査、個人情報保護、契約終了時の削除まで含めて決めるべきです。
まとめ: まずリージョン、次に統合、最後に証跡を確認する
2026年4月更新の「Geographical availability and data residency in Microsoft Sentinel」で最も重要なのは、Microsoft Sentinelのデータ所在地を単一のリージョン名だけで判断しないことです。Raw dataはLog Analyticsワークスペースのリージョン、Processed dataとConfiguration dataはDefenderポータル統合の有無、Sentinel data lakeは対応リージョンと同一リージョン制約、China 21Vianetは2026年8月18日の終了予定をそれぞれ確認する必要があります。
次に取るべき行動は明確です。まず既存のLog AnalyticsワークスペースとDefender XDRテナントのリージョンを確認し、Sentinel data lakeの利用予定を整理してください。そのうえで、保存場所、処理場所、保持期間、削除方針を1枚の設計資料にまとめ、security admins、identity teams、compliance teamsでレビューすることが、監査にも運用変更にも強いMicrosoft Sentinel環境を作る近道です。
コメント