Microsoft Sentinel の「Geographical availability and data residency in Microsoft Sentinel」は、単に対応リージョンを確認するための記事ではありません。結論から言うと、生ログは Microsoft Sentinel に紐づく Log Analytics ワークスペースのリージョンに保存されますが、Microsoft Defender ポータルにオンボードしている場合、インシデントやアラートなどの処理済みデータ、設定データは Microsoft Defender XDR 側のリージョンで保存・処理される可能性があります。ここを見落とすと、データ所在地、監査、保持期間、移行設計に影響します。
2026年5月14日に更新された Microsoft Learn 公式情報では、Microsoft Sentinel のデータ種別ごとの保存場所、SIEM とデータレイクの対応リージョン、Defender ポータル連携時の扱い、中国 21Vianet リージョンでの廃止予定などが整理されています。管理者は「ワークスペースのリージョン」「Defender ポータルへの接続状況」「データレイクの利用有無」「保持ポリシー」「自社のデータ所在地要件」をセットで確認する必要があります。(Microsoft Learn)
Microsoft Sentinel のデータ所在地でまず押さえるべき結論
Microsoft Sentinel のデータ所在地を判断するときは、データをひとまとめに考えないことが重要です。公式情報では、Microsoft Sentinel が扱うデータを大きく次の3種類に分けています。(Microsoft Learn)
| データ種別 | 代表例 | 保存・処理の考え方 | 管理者が見るべきポイント |
|---|---|---|---|
| 生データ | イベントログ、接続済み Microsoft サービスやパートナー製品から収集したログ | Microsoft Sentinel に関連付けた Azure Log Analytics ワークスペースと同じリージョンに保存 | ワークスペースのリージョン、保持期間、削除ポリシー |
| 処理済みデータ | インシデント、アラートなど | Defender ポータルにオンボードしている場合、Microsoft Defender XDR リージョンで保存・処理される可能性 | Defender ポータル接続状況、Defender XDR テナントのリージョン |
| 構成データ | コネクタ設定、分析ルール、その他の設定 | Defender ポータルにオンボードしている場合、Microsoft Defender XDR リージョンで保存・処理される可能性 | ルール、コネクタ、権限、監査証跡 |
ポイントは、「Log Analytics ワークスペースを日本リージョンに置いたから、Microsoft Sentinel に関するすべてのデータが常に日本国内だけで完結する」とは限らないことです。特に Microsoft Defender ポータルで Microsoft Sentinel を利用する構成では、Defender XDR のデータ所在地ポリシーも確認する必要があります。
2026年5月14日更新の公式情報で注目すべき変更点
今回の公式情報で実務上注目すべき点は、次の5つです。
| 注目点 | 内容 | 影響を受けやすい組織 |
|---|---|---|
| Defender ポータル連携時のデータ所在地 | 処理済みデータと構成データが Microsoft Defender XDR リージョンで保存・処理される可能性がある | Defender ポータルへ移行中の SOC、Microsoft Defender XDR と Sentinel を統合運用する組織 |
| SIEM とデータレイクの対応リージョン | Microsoft Sentinel SIEM と Microsoft Sentinel data lake の対応リージョンが分けて示されている | データレイクを利用予定の組織、長期保存や調査基盤を設計する組織 |
| データレイクのリージョン制約 | Microsoft Sentinel data lake は、関連付けられたプライマリ Sentinel ワークスペースと同じ Azure リージョンに展開する必要がある | 既存ワークスペースを使ってデータレイクを有効化する組織 |
| China 21Vianet リージョンの廃止予定 | Azure operated by 21Vianet リージョンでは、Microsoft Sentinel の全機能が2026年8月18日に正式廃止予定。新規サブスクリプションのオンボードも停止 | 中国リージョンを利用しているグローバル企業、中国法人を持つ企業 |
| 保持と削除の考え方 | Sentinel データは、ワークスペースから Sentinel を削除した時点、または顧客が設定した保持ポリシーのいずれか早い時点まで保持される | 監査、証跡保全、インシデント調査の保持期間を定める組織 |
公式記事では、Microsoft Sentinel data lake は関連付けられたプライマリ Sentinel ワークスペースと同じ Azure リージョンに展開する必要があると明記されています。また、日本については、SIEM の対応リージョンとして Japan East と Japan West、データレイクの対応リージョンとして Japan East が示されています。(Microsoft Learn)
日本環境で特に注意すべきリージョン設計
日本の企業がまず確認すべきなのは、既存または新規の Log Analytics ワークスペースがどのリージョンにあるかです。Microsoft Sentinel の生データは、関連付けられた Log Analytics ワークスペースと同じリージョンに保存されます。日本での SIEM 利用だけを考えるなら Japan East と Japan West が候補になりますが、Microsoft Sentinel data lake まで利用する場合は Japan East の対応状況を前提に設計を確認する必要があります。(Microsoft Learn)
一方で、Microsoft Defender XDR は、欧州連合、英国、米国、オーストラリア、スイス、インド、UAE などの地理的リージョンで運用されると説明されています。Defender XDR テナントは作成後に別リージョンへ移動できず、リージョンは Microsoft Defender ポータルの Settings > Microsoft Defender XDR > Account で確認できます。(Microsoft Learn)
つまり、日本リージョンの Sentinel ワークスペースを使っていても、Defender ポータルにオンボードした後の処理済みデータや構成データについては、Defender XDR 側のリージョン設計を別途確認する必要があります。金融、医療、公共、グローバル子会社の監査など、データ所在地の説明責任が重い環境では、導入前に次の確認を行うべきです。
| 確認項目 | 確認する理由 |
|---|---|
| Sentinel ワークスペースの Azure リージョン | 生データの保存場所を説明するため |
| Microsoft Defender XDR テナントのリージョン | Defender ポータル連携後の処理済みデータ・構成データの保存先を確認するため |
| Sentinel data lake の対応リージョン | データレイクを有効化できるか、既存ワークスペースと整合するかを判断するため |
| 社内のデータ所在地ポリシー | 国内保存要件、越境移転、委託先管理、監査証跡の説明に影響するため |
| 保持ポリシー | インシデント調査、証跡保全、削除要求への対応に影響するため |
Microsoft Defender ポータルへ移行する場合の影響
Microsoft Sentinel を Azure ポータル中心で使っていた組織が Microsoft Defender ポータルへ移行する場合、画面が変わるだけではありません。Microsoft Learn では、Azure ポータル利用時は Microsoft Sentinel のデータ保存、処理、保持、共有ポリシーが適用され、Defender ポータル利用時は Sentinel データを扱っている場合でも Microsoft Defender XDR のポリシーが適用されると説明されています。(Microsoft Learn)
移行時に見落としやすい点を整理すると、次のようになります。
| 項目 | 影響 | 対応のポイント |
|---|---|---|
| データ保存・処理ポリシー | Defender ポータルでは Microsoft Defender XDR 側のポリシーが適用される | 移行前にデータ所在地、保持、共有の説明資料を更新する |
| CMK | 移行前に Customer-Managed Keys を有効化している場合、ワークスペース内のログデータや Sentinel コンテンツは引き続き CMK で暗号化されるが、オンボード後のアラートとインシデントは CMK 暗号化されない | CMK 必須の社内基準がある場合、移行可否を事前レビューする |
| インシデント相関 | Defender ポータルでは Defender XDR の相関エンジンがインシデント作成やマージを制御する | 既存の Fusion や分析ルールによる運用手順を見直す |
| 自動化ルール・プレイブック | 一部の手動実行やアラート操作が Defender ポータルで非対応または動作差分あり | Logic Apps、ServiceNow 連携、チケット起票フローをテストする |
| Advanced Hunting | Sentinel の既存ログテーブル、KQL クエリ、関数を Advanced Hunting で利用できるが、テーブルや保持期間の扱いに差分がある | SOC の調査手順書と KQL クエリを更新する |
特に CMK は、セキュリティ部門や監査部門が重視する論点です。Microsoft Sentinel data lake については、CMK がサポートされていないため、CMK を前提とした暗号化ポリシーを持つ組織では、データレイクの利用が自社基準に合うかを事前に判断する必要があります。(Microsoft Learn)
管理者が確認すべき設定と作業手順
Microsoft Sentinel のデータ所在地に関する確認は、導入後に慌てて調べるより、設計段階でチェックリスト化しておく方が安全です。既存環境の見直しにも使えるよう、実務の順序で整理します。
まずワークスペースの棚卸しを行う
最初に、Microsoft Sentinel が有効化されている Log Analytics ワークスペースを一覧化します。確認する項目は、ワークスペース名、サブスクリプション、リソースグループ、Azure リージョン、保持期間、接続済みデータコネクタです。
ワークスペースが複数ある場合は、用途も明記します。たとえば「本番 SOC 用」「検証用」「日本拠点用」「欧州拠点用」「MSSP 管理用」のように分類しておくと、リージョン要件や保持期間の判断がしやすくなります。
Azure Monitor のワークスペース設計では、要件がなければ単一ワークスペースから始め、規制、データ所有権、課金、保持期間、アクセス制御、回復性などの条件に応じて複数ワークスペースを検討する考え方が示されています。(Microsoft Learn)
Defender ポータルへのオンボード状態を確認する
次に、そのワークスペースが Microsoft Defender ポータルに接続されているかを確認します。ここがデータ所在地判断の分岐点です。
| 状態 | データ所在地の考え方 |
|---|---|
| Defender ポータルに未オンボード | 処理済みデータ・構成データは、生データと同じ考え方で保存・処理される |
| Defender ポータルにオンボード済み | 処理済みデータ・構成データは、Microsoft Defender XDR リージョンで保存・処理される可能性がある |
この確認をしないまま「Sentinel は日本リージョンだから問題ない」と判断すると、監査時に説明が不足する可能性があります。特に Microsoft Defender XDR、Microsoft Sentinel、Microsoft Security Copilot を統合した運用を進めている組織では、セキュリティ運用基盤全体としてデータの流れを確認することが重要です。
データレイクを使う場合はプライマリワークスペースを確認する
Microsoft Sentinel data lake を使う場合は、プライマリ Sentinel ワークスペースのリージョンが重要です。公式情報では、データレイクはプライマリ Sentinel ワークスペースと同じリージョンにプロビジョニングされ、Defender に接続されている同一リージョンのワークスペースがデータレイクに関連付けられると説明されています。(Microsoft Learn)
注意すべきなのは、オンボード時にすべてを細かく選べるわけではない点です。Microsoft Learn では、同じリージョンで Defender に接続されているワークスペースが自動的に対象となり、個別ワークスペースを自分でオフボードすることはできないとされています。オフボードにはサポートリクエストが必要です。(Microsoft Learn)
既存のワークスペース構成が複雑な場合は、データレイクを有効化する前に「同じリージョンにある Defender 接続済みワークスペース」を洗い出してください。
保持期間と削除ポリシーを確認する
Microsoft Sentinel のデータは、顧客がワークスペースから Sentinel を削除した時点、または顧客が設定した保持ポリシーに従った時点のうち、早い方まで保持されます。また、ライセンスの猶予期間や停止状態でもデータは保持されますが、契約終了または満了後は、遅くとも90日以内に Microsoft のシステムから回復不能な形で削除されると説明されています。(Microsoft Learn)
一方、Microsoft Defender XDR のデータ保持は通常 180 日で、Advanced Hunting では原則 30 日分のデータにクエリでアクセスできます。ただし、Microsoft Sentinel にストリーミングしている場合は、Sentinel 側の保持期間がより長くなる場合があります。(Microsoft Learn)
実務では、次のように分けて決めると運用しやすくなります。
| データ | 推奨される確認観点 |
|---|---|
| 高重要度インシデントの証跡 | 監査や法務対応で必要な保存期間 |
| 通常のアラート・イベント | SOC の調査期間、コスト、検索頻度 |
| 長期保管ログ | データレイク、アーカイブ、検索ジョブのコスト |
| 個人情報を含むログ | 削除要求、越境移転、アクセス制御 |
| 開発・検証ログ | 不要な長期保持を避けるための短期保持設定 |
開発者・SecOps エンジニアが見落としやすいポイント
管理者だけでなく、KQL、API、Logic Apps、チケット連携、IaC を扱う開発者や SecOps エンジニアにも影響があります。
KQL クエリと Advanced Hunting の差分を確認する
Defender ポータルに Microsoft Sentinel をオンボードすると、Advanced Hunting で既存の Sentinel ログテーブル、KQL クエリ、関数を利用できます。また、インシデントに紐づく Sentinel アラートは AlertInfo テーブルに取り込まれます。(Microsoft Learn)
ただし、すべてが従来と同じではありません。たとえば、IdentityInfo テーブルは Defender 側のネイティブテーブルとして扱われ、Azure ポータルで IdentityInfo に対してテーブルレベル RBAC を使ってアクセス制御していた場合、その制御は Defender ポータル移行後に利用できなくなると説明されています。(Microsoft Learn)
既存の KQL をそのまま移植するのではなく、次の確認を行ってください。
| 確認対象 | 確認内容 |
|---|---|
| テーブル名 | Defender 側で参照するテーブル名が変わらないか |
| 列名 | 既存クエリで参照している列が Advanced Hunting でも利用できるか |
| 保持期間 | Advanced Hunting で参照できる期間と Sentinel 側の保持期間の差 |
| RBAC | テーブルレベル RBAC やリソース単位の権限が維持されるか |
| ブックマーク | Advanced Hunting では従来の Sentinel ブックマークと扱いが異ならないか |
Logic Apps や外部チケット連携を移行前にテストする
Defender ポータル移行後は、インシデントやアラートの扱いに差分があります。たとえば、SecurityIncident テーブルに Description フィールドが含まれなくなるため、インシデント作成トリガーの条件や、ServiceNow などの外部チケットシステムで説明文を使っている連携は見直しが必要です。(Microsoft Learn)
また、Azure ポータルや API、Logic Apps プレイブックから手動作成した Microsoft Sentinel インシデントは、Defender ポータルへ同期されないと説明されています。チケット起票やエスカレーションを自動化している場合は、実際の移行前に検証用ワークスペースで再現テストを行いましょう。(Microsoft Learn)
IaC ではリージョンとポリシー例外を明示する
Bicep、ARM テンプレート、Terraform などで Sentinel 環境を展開している場合、リージョンを変数で曖昧に扱うと、データ所在地の説明が難しくなります。ワークスペース、データコネクタ、保持期間、データレイク関連リソースは、環境ごとに明示的に管理するのが安全です。
Microsoft Sentinel data lake のオンボードでは、既存の Azure Policy が必要なリソース展開をブロックする可能性があります。公式情報では、対象リソースグループに対して Microsoft.SentinelPlatformServices/sentinelplatformservices のポリシー例外を構成することが案内されています。(Microsoft Learn)
展開パターン別の判断基準
Microsoft Sentinel のデータ所在地設計は、「単一ワークスペースがよいか、複数ワークスペースがよいか」という単純な比較では決まりません。組織要件ごとに判断する必要があります。
| 展開パターン | 向いているケース | 注意点 |
|---|---|---|
| 単一ワークスペース | 国内中心の運用、要件がシンプル、SOC が一元管理したい | データ所在地や部門別アクセス制御の要件が強い場合は不向き |
| 地域別ワークスペース | 日本、欧州、米国などでデータ所在地要件が異なる | クエリ、分析ルール、ブック、コスト管理が複雑になる |
| 部門・子会社別ワークスペース | データ所有者や請求先を分けたい | ルールや運用手順の標準化が必要 |
| Microsoft Defender ポータル統合 | SIEM と XDR を統合し、インシデント対応を効率化したい | Defender XDR のデータ所在地、保持、権限モデルを確認する |
| Microsoft Sentinel data lake 利用 | 長期調査、データレイク探索、グラフ分析を使いたい | プライマリワークスペースのリージョン、CMK 非対応、コスト影響を確認する |
| MSSP・マルチテナント運用 | 複数顧客や複数テナントを横断管理したい | Azure Lighthouse、ゲストユーザー、ワークスペース数、クエリ性能を設計する |
ワークスペース設計では、運用データとセキュリティデータを同じワークスペースに統合すると可視性が高まる一方、セキュリティ要件やコスト要件によっては分離が適する場合があります。アクセス制御では、リソースコンテキスト RBAC やテーブルレベル RBAC も考慮する必要があります。(Microsoft Learn)
移行前チェックリスト
Microsoft Defender ポータル連携や Microsoft Sentinel data lake の展開前に、次の項目を確認してください。
| チェック項目 | 完了の目安 |
|---|---|
| Sentinel ワークスペースの一覧化 | すべてのワークスペースについてリージョン、用途、保持期間が分かる |
| Defender ポータル接続状況の確認 | どのワークスペースが Defender にオンボード済みか分かる |
| Defender XDR テナントリージョンの確認 | Defender ポータル上でリージョンを確認し、監査資料に反映している |
| データレイク利用可否の確認 | プライマリワークスペースのリージョンと対応リージョンが一致している |
| CMK 要件の確認 | CMK が必要なデータと、CMK 非対応の領域を整理している |
| 保持期間の確認 | Sentinel、Defender XDR、Advanced Hunting の保持期間差分を理解している |
| KQL と自動化の検証 | 主要なクエリ、Logic Apps、チケット連携を検証済み |
| RBAC の確認 | テーブルレベル RBAC、リソースコンテキスト RBAC、Defender 側の権限モデルを確認済み |
| コスト影響の確認 | データレイク、長期保持、検索ジョブ、データ量の増加を見積もっている |
| 中国リージョンの確認 | Azure operated by 21Vianet を使っている場合、2026年8月18日の廃止予定への対応方針がある |
まとめ：最初に確認するのは「ワークスペースのリージョン」と「Defender 連携状況」
Microsoft Sentinel の「Geographical availability and data residency in Microsoft Sentinel」で最も重要なのは、データ種別ごとに保存・処理場所が変わる点です。生データは Log Analytics ワークスペースのリージョンが基準になりますが、Microsoft Defender ポータルにオンボードしている場合、処理済みデータや構成データは Microsoft Defender XDR 側のリージョンで扱われる可能性があります。
管理者は、まず既存の Sentinel ワークスペースを棚卸しし、リージョン、保持期間、Defender ポータル接続状況、データレイク利用有無を確認してください。開発者や SecOps エンジニアは、KQL、Advanced Hunting、自動化ルール、Logic Apps、外部チケット連携の差分を移行前にテストする必要があります。
次に取るべき行動はシンプルです。自社の Sentinel ワークスペース一覧を作成し、「生データ」「処理済みデータ」「構成データ」「データレイク」の保存・処理場所を1枚の設計表にまとめることです。その表があれば、監査対応、移行判断、リージョン選定、コスト見積もり、SOC 運用変更を同じ前提で進められます。
コメント