Microsoft Defender XDRのデータ保持とセキュリティ更新ポイント|管理者が確認すべき実務対応

Microsoft Defender XDRのデータ保持とセキュリティでまず押さえるべき結論は、Defenderポータル上のデータ保持は原則180日、Advanced Huntingで直接クエリできる期間は原則30日、Microsoft SentinelをDefenderポータルで扱う場合はDefender XDR側のデータ保持・共有ポリシーも確認が必要という点です。特にMicrosoft SentinelをAzureポータルからDefenderポータルへ移行する組織では、「画面が変わるだけ」と捉えると、保持期間、データ所在地、CMK、コネクタ、運用自動化の見落としが起きやすくなります。Microsoftは2026年6月24日更新のSentinel移行ガイドで、Defenderポータル利用時はMicrosoft Defender XDRのポリシーが適用される場面を明確にしています。(Microsoft Learn)

この記事では、公式情報「Data security and retention in Microsoft Defender XDR」をもとに、Microsoft Defender管理者、SOC担当者、コンプライアンス担当者が確認すべきポイントを実務目線で整理します。単なる仕様説明ではなく、どこを確認し、どの設定や運用を見直すべきかまで具体的に解説します。

目次

Microsoft Defender XDRのデータ保持とセキュリティで何が重要なのか

Microsoft Defender XDRは、Microsoft Defender for Endpoint、Defender for Office 365、Defender for Identity、Defender for Cloud Appsなど複数のMicrosoftセキュリティサービスのシグナルを統合し、インシデント、アラート、調査、対応を横断的に扱うサービスです。公式ドキュメントでは、統合サービスから収集されるデータとして、インシデントやアラートなどの処理済みデータ、コネクタ設定やルールなどの構成データが示されています。(Microsoft Learn)

今回の確認ポイントは、新しい検知機能の追加というより、データの保存場所、保持期間、共有範囲、Sentinel移行時の適用ポリシーを正しく理解することです。とくにグローバル企業や規制業種では、次のような実務課題に直結します。

確認テーマ実務上の意味見落とした場合のリスク
データ保持期間何日前まで調査できるかを決める過去調査や監査対応で必要なログが見つからない
Advanced Huntingの検索期間KQLで直接追跡できる期間を決める180日保持と誤解し、30日超の調査で詰まる
データ所在地データレジデンシーや社内規程に影響する国・地域要件との不整合が後から発覚する
Sentinelとの関係SIEM統合時の保持・検索・課金設計に影響するDefenderとSentinelの保持期間を混同する
データ共有Microsoftセキュリティ製品間の相関分析に影響するGCCや多国籍環境で想定外の共有経路を見落とす

影響範囲:Defender単体よりもSentinel連携環境で注意が必要

Microsoft Defender XDRだけを利用している組織では、今回確認すべき中心は「どのデータがどこに、どの期間保持されるか」です。一方、Microsoft Sentinelを使っている組織では、Defenderポータルへの移行や統合運用によって確認範囲が広がります。

Microsoftの移行ガイドでは、Microsoft SentinelをAzureポータルで使う場合はSentinel側のデータ保存、処理、保持、共有ポリシーが適用される一方、Defenderポータルで使う場合は、Sentinelデータを扱う場合でもMicrosoft Defender XDRのポリシーが適用されると説明されています。(Microsoft Learn)

つまり、影響を受けるのは次のような組織です。

  • Microsoft Defender XDRでインシデント、アラート、Advanced Huntingを使っている組織
  • Microsoft SentinelをDefenderポータルにオンボード済み、または移行予定の組織
  • Microsoft Defender for Endpoint、Office 365、Identity、Cloud Appsなど複数のDefender製品を連携している組織
  • データレジデンシー、保持期間、監査証跡、証跡削除に関する社内規程を持つ組織
  • MSSPやグローバルSOCのように、複数テナント・複数ワークスペースを運用している組織

特に「Defenderポータルに移行しても、今までのSentinel運用と同じ」と考えるのは危険です。画面統合そのものよりも、どのポリシーが適用されるか、どのコネクタ経由でアラートが入るか、どのワークスペースが主になるかを確認する必要があります。

データ保持期間:Defenderポータルは原則180日、Advanced Huntingは原則30日

Microsoft Defender XDRのデータ保持で最も重要なのは、ポータル上の表示期間と、Advanced Huntingでクエリできる期間が同じではないという点です。

公式ドキュメントでは、Microsoft Defenderのデータは180日保持され、その期間中はMicrosoft Defenderポータル全体で表示可能とされています。ただし、Advanced Huntingクエリは例外で、Microsoft Sentinelにストリーミングしている場合などを除き、Advanced Huntingページからクエリできるデータは30日間です。また、ケースは削除対象の例外として扱われます。(Microsoft Learn)

項目基本的な保持・利用期間管理者が確認すべきこと
Microsoft Defenderポータル上のデータ原則180日インシデント対応手順が180日以内の調査を前提にしているか
Advanced Huntingのクエリ対象原則30日30日超のハンティングをSentinelや別の保持先で補完しているか
Microsoft SentinelにストリーミングしたデータSentinel側の保持設定に依存Log Analyticsやデータレイクの保持・コスト設計を確認する
ケース180日削除の例外ケース運用と証跡管理のルールを明文化する
ライセンス猶予・停止中のデータ猶予・停止期間中も保持・表示契約終了後の削除タイミングを監査・法務と確認する

実務では、「Defenderに180日残るから、半年分のKQL調査ができる」と誤解されがちです。たとえば、3か月前に発生した標的型メールを起点に、端末、ID、クラウドアプリの動きをKQLで追跡したい場合、Advanced Huntingだけでは不足する可能性があります。30日を超える調査を想定するなら、Microsoft Sentinelへのストリーミング、Log Analyticsの保持期間設定、Microsoft Sentinelデータレイクなどを組み合わせて設計する必要があります。

データ保存場所:テナント作成後にリージョン移動できない点に注意

Microsoft Defender XDRのデータ所在地も重要です。公式情報では、Microsoft Defenderは欧州連合、英国、米国、オーストラリア、スイス、インド、UAEのAzureデータセンターで運用されると説明されています。また、Microsoft Defenderテナントは作成後に別リージョンへ移動できず、利用中の地理的リージョンはMicrosoft Defenderポータルの「Settings > Microsoft Defender XDR > Account」で確認できます。(Microsoft Learn)

日本企業にとって注意したいのは、Microsoft SentinelのLog Analyticsワークスペース所在地と、Microsoft Defender XDRのサービスデータ所在地を混同しないことです。Microsoft Sentinelは関連付けられたLog Analyticsワークスペースと同じリージョンにデータを保存し、日本リージョンもサポート対象として示されています。一方、DefenderポータルからSentinelをオンボードする場合、処理場所はオンボード時の指定先リージョンまたは既存のMicrosoft Defender XDRリージョンになる可能性がある一方、Rawデータの保存場所は変わらないと説明されています。(Microsoft Learn)

管理者が確認すべきリージョン項目

確認項目確認場所・観点
Defender XDRの地理的リージョンMicrosoft DefenderポータルのAccount設定
SentinelのRawデータ保存場所Log Analyticsワークスペースのリージョン
SentinelをDefenderポータルで扱う際の処理場所オンボード時の指定、既存Defender XDRリージョン
社内規程との整合データ所在地、処理場所、第三国移転、監査要件
グローバル環境の例外GCC、21Vianet、国・地域別クラウドの制約

データレジデンシー要件が厳しい組織では、「Microsoft 365のテナントが日本だから安全」といった大まかな理解では不十分です。Defender XDR、Sentinel、Log Analytics、関連するMicrosoftセキュリティ製品ごとに、保存・処理・共有の単位を切り分けて確認しましょう。

データ共有:相関分析のメリットとコンプライアンス確認をセットで考える

Microsoft Defender XDRの価値は、複数製品のシグナルを横断して相関分析できる点にあります。公式情報では、Microsoft Defender XDRが、Microsoft Defender for Cloud、Defender for Identity、Defender for Endpoint、Defender for Cloud Apps、Defender for Office 365、Defender for IoT、Microsoft Sentinel、Microsoft Intune、Microsoft Purview、Microsoft Entra、Defender Vulnerability Management、Microsoft Copilot for Securityなど、顧客がライセンスを持つ製品間でデータを共有すると説明されています。GCCでは、サービス提供場所によって政府クラウドと商用クラウド間のデータ共有が発生する可能性にも触れられています。(Microsoft Learn)

これはセキュリティ運用上は大きな利点です。たとえば、ユーザーがフィッシングメールのURLをクリックし、その直後に疑わしいサインインが発生し、さらに端末で不審なプロセスが起動した場合、個別製品だけでは見えにくい攻撃の流れを1つのインシデントとして把握しやすくなります。

一方で、コンプライアンス部門や法務部門に説明する際は、次の観点を整理しておく必要があります。

  • どのMicrosoftセキュリティ製品が連携対象か
  • どのデータがアラート、インシデント、構成情報として扱われるか
  • データ共有が検知・相関・自動対応にどう使われるか
  • GCCや国別クラウドなど、特殊な環境で追加確認が必要か
  • Microsoft Copilot for SecurityなどAI支援機能を使う場合、別途どのプライバシー・データ保護情報を確認するか

「データ共有を止めるべきか」ではなく、業務上必要な相関分析を維持しつつ、説明責任を果たせる形で文書化するのが現実的な対応です。

Sentinel移行時の更新ポイント:ポータル統合後の運用差分を必ず確認する

2026年6月24日に更新されたMicrosoft Sentinelの移行ガイドでは、Defenderポータルへの移行に伴うデータ保存、プライバシー、コネクタ、CMK、ワークスペース構成、Automation、APIの差分が整理されています。特に重要なのは、SentinelをDefenderポータルで使う場合、Defender XDRのポリシー確認が必要になることです。(Microsoft Learn)

Sentinel連携環境で確認すべき主な差分

項目確認ポイント
データ保存・保持ポリシーAzureポータル利用時とDefenderポータル利用時で参照すべきポリシーが変わる
Rawデータ保存場所SentinelのLog Analytics保存場所は基本的に維持される
Microsoft製品アラートDefender XDRコネクタ経由に変わる場面がある
複数ワークスペースMicrosoft製品のテナントベースアラートは主ワークスペース中心になる
CMKオンボード後、アラートとインシデントはCMK暗号化されなくなる点に注意
Automation・Playbookインシデントプロバイダー、SecurityIncidentテーブル、トリガー遅延などを確認
Advanced HuntingSentinelデータとの統合クエリが便利になる一方、テーブル差分や権限差分に注意

特にCMKを使っている組織は注意が必要です。移行ガイドでは、Sentinel対応ワークスペースをDefenderポータルにオンボードした場合、ワークスペースのログデータや分析ルールなどはCMK暗号化が継続される一方、オンボード後のアラートとインシデントはCMK暗号化されなくなると説明されています。(Microsoft Learn)

これは、金融、公共、医療、グローバル製造業など、暗号鍵管理を統制要件に含めている組織では見落とせないポイントです。移行前に、セキュリティ部門だけでなく、監査、法務、リスク管理部門も含めて判断する必要があります。

移行期限:Defender XDRのデータ保持情報自体に期限はないが、Sentinel利用者は要注意

「Data security and retention in Microsoft Defender XDR」そのものは、特定日までに設定変更しなければならない移行期限を示すものではありません。ただし、Microsoft SentinelをAzureポータルで使っている組織には、Defenderポータルへの移行スケジュールが関係します。

Microsoftの最新のSentinel更新情報では、Microsoft SentinelはDefenderポータルで一般提供されており、2027年3月31日以降はAzureポータルでサポートされず、Microsoft Defenderポータルでのみ利用可能になると説明されています。(Microsoft Learn)

そのため、Sentinelを使っている組織は、データ保持とセキュリティの観点から次のように移行計画を立てるのが現実的です。

時期推奨アクション
すぐDefender XDRのリージョン、保持期間、Advanced Hunting利用期間を棚卸しする
移行設計時SentinelのLog Analytics保持、データレイク、CMK、RBAC、コネクタ構成を確認する
検証環境KQL、Automation、Playbook、チケット連携、API連携の動作差分をテストする
本番移行前SOC手順書、監査説明資料、インシデント対応フローを更新する
2027年3月31日までAzureポータル依存のSentinel運用をDefenderポータル前提に切り替える

なお、Azure operated by 21Vianetのような地域別クラウドでは別の終了・制約が示されているため、グローバル企業は商用クラウド、政府クラウド、中国リージョンを分けて確認してください。(Microsoft Learn)

管理者が今すぐ確認すべきチェックリスト

Microsoft Defender XDRのデータ保持とセキュリティは、単に「180日保持」と覚えるだけでは不十分です。運用に落とし込むには、以下の順に確認すると抜け漏れを減らせます。

Defender XDRの基本設定を確認する

まず、Microsoft Defenderポータルで自社テナントの地理的リージョンを確認します。テナント作成後にリージョン移動できないため、データレジデンシー要件がある場合は、契約・監査・社内規程と照合します。

確認する場所は、Microsoft Defenderポータルの以下です。

Settings > Microsoft Defender XDR > Account

ここで確認したリージョンを、社内のセキュリティ設計書や監査資料に反映しておくと、後から説明しやすくなります。

調査期間ごとのログ保持設計を作る

次に、インシデント調査で必要な期間を決めます。おすすめは、調査用途ごとに必要期間を分ける方法です。

調査用途目安推奨設計
日常的なSOCトリアージ数日〜30日Advanced HuntingとDefenderポータルで対応
月次レビュー・再調査30日〜180日Defenderポータル表示とSentinel保持を組み合わせる
監査・法務・長期調査180日超Sentinelの保持期間、アーカイブ、データレイクを検討
脅威ハンティングの履歴分析30日超になりやすいSentinelへのストリーミングや長期保持を前提にする

特にランサムウェアや内部不正の調査では、侵害開始から発覚まで30日を超えることがあります。Advanced Huntingだけに依存せず、長期調査用のデータ保持先を用意しておくべきです。

Sentinel移行前にコネクタとワークスペースを点検する

SentinelをDefenderポータルに統合する場合、Microsoft製品のアラート取り込み経路が変わることがあります。移行ガイドでは、Microsoftセキュリティ製品のアラートはMicrosoft Defender XDRコネクタ経由に変わり、複数ワークスペース環境では主ワークスペースのみが接続されると説明されています。二重取り込みやアラート欠落を避けるため、移行前にコネクタ構成を確認してください。(Microsoft Learn)

確認すべき項目は次のとおりです。

  • Microsoft Defender XDRコネクタでインシデントとアラートが有効か
  • 旧来の単体Microsoft製品コネクタが二重取り込みを起こしていないか
  • 複数ワークスペース環境で主ワークスペースと副ワークスペースの役割が明確か
  • MSSP運用で顧客テナントごとのデータ境界が説明できるか
  • Azureポータル側に残るコネクタ表示とDefenderポータル側の表示差分を手順書に反映しているか

Automationと外部連携を検証する

Defenderポータル移行では、インシデントやアラートの扱いも変わります。移行ガイドでは、SecurityIncidentテーブルのDescriptionフィールドがオンボード後に含まれなくなること、インシデントがDefenderからSentinelに同期されるまで最大数分の遅延が起きること、短時間の複数更新がまとめられる可能性があることなどが示されています。(Microsoft Learn)

ServiceNowなどのチケットシステム、Logic AppsのPlaybook、独自SOAR、Graph API連携を使っている場合は、次のテストが必要です。

  • インシデント作成時にチケットが正しく作られるか
  • Descriptionなど特定フィールドに依存していないか
  • インシデントプロバイダー名の変化で条件分岐が壊れないか
  • 同期遅延がある場合でもPlaybookが再実行・再試行できるか
  • 5〜10分以内の連続更新を逐次処理する前提になっていないか

自動化は「動いているように見えるが、一部条件だけ失敗する」ケースが多いため、代表的な重大度、製品、インシデント種別ごとに検証するのが安全です。

よくある誤解と正しい理解

「Defender XDRは180日保持だからAdvanced Huntingも180日検索できる」は誤り

Defenderポータル上のデータ保持と、Advanced Huntingで直接クエリできる期間は別です。Advanced Huntingは原則30日です。30日を超えるKQL調査が必要な場合は、Microsoft Sentinelなど別の保持設計を組み合わせます。(Microsoft Learn)

「SentinelをDefenderポータルに移してもデータポリシーは完全に同じ」は誤り

AzureポータルでSentinelを使う場合と、DefenderポータルでSentinelを使う場合では、参照すべきポリシーや運用差分があります。Microsoftは、Defenderポータル利用時にはDefender XDRのポリシーが適用される場面を明記しています。(Microsoft Learn)

「Defenderポータルに移行するとSentinelのRawデータ保存場所も移動する」は単純化しすぎ

SentinelのRawデータは、関連付けられたLog Analyticsワークスペースに保存されます。Defenderポータルでオンボードした場合、処理場所にはDefender XDR側のリージョンなどが関係する可能性がありますが、Rawデータの保存場所は変わらないと説明されています。(Microsoft Learn)

「CMKを使っていれば移行後のアラートやインシデントも同じ暗号化になる」は要確認

SentinelでCMKを有効化している場合でも、Defenderポータルにオンボード後のアラートとインシデントはCMK暗号化されなくなると説明されています。CMKが監査要件に含まれる組織は、移行前に必ず確認が必要です。(Microsoft Learn)

実務でのおすすめ対応方針

Microsoft Defender XDRのデータ保持とセキュリティを見直すときは、製品仕様の暗記ではなく、インシデント対応、監査、法務、コスト、データ所在地をつなげて設計することが重要です。

まず、Defender XDRのリージョンと保持期間を確認し、Advanced Huntingの30日制限を前提にしたハンティング手順へ更新します。次に、30日超・180日超の調査が必要なデータを洗い出し、Microsoft Sentinelの保持期間やデータレイク、アーカイブ設計に反映します。SentinelをDefenderポータルへ移行する場合は、CMK、コネクタ、主ワークスペース、Automation、API連携を本番前に検証してください。

最後に、この記事の内容をそのまま運用チェックリストに落とし込むなら、次の4点から始めるのが効果的です。

  • Defender XDRのAccount設定で地理的リージョンを確認する
  • Advanced Huntingで必要な調査期間が30日以内か棚卸しする
  • Sentinel連携環境ではRawデータ、処理場所、保持期間、CMKを分けて確認する
  • 2027年3月31日までにAzureポータル依存のSentinel運用をDefenderポータル前提へ移行する

Microsoft Defender XDRは、複数のセキュリティシグナルを統合できる強力な基盤です。一方で、統合が進むほど「どのデータが、どこに、どの期間、どのポリシーで扱われるか」は複雑になります。管理者は、今回の公式情報をきっかけに、データ保持・データ所在地・Sentinel移行・自動化連携をまとめて点検しておくべきです。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次