Defender for Cloud Appsのファイルポリシーは2027年1月6日に廃止|Purview DLP移行で消える機能・残る機能を先に知る

Hirokazu Yoshida
Hirokazu Yoshida

シニアセキュリティスペシャリスト / サイバーセキュリティスペシャリスト

こんにちは、ひろかずです。

Microsoft Defender for Cloud Appsのファイルポリシーは2027年1月6日に廃止されます。Purview移行で失われる機能、ライセンス要件、棚卸しと移行手順を一次情報・二次情報に基づいて整理しましたので共有します。

忙しい人向けの要約

  • 問い:Defender for Cloud Appsのファイルポリシー廃止で何をすべきですか?
    答え:2027年1月6日までにMDAのDLPファイルポリシーを棚卸しし、必要分をMicrosoft Purview DLPまたは自動ラベル付けポリシーへ再作成・検証してください。
  • Microsoft Defender for Cloud Apps(MDA)のファイルポリシーは2027年1月6日に廃止され、以後DLPファイルポリシーはサポートも強制もされません。対象はSharePoint・OneDriveに加え、Box・Dropbox・Google Workspace・Salesforce等の接続済みサードパーティSaaSを含みます。
  • 移行先はMicrosoft Purviewの DLPポリシーおよび自動ラベル付けポリシーです。自動変換ツールはなく、既存ポリシーを棚卸しして手作業で再作成する必要があります。
  • 移行先は完全互換ではありません。フォルダ単位のスコープ指定、ユーザー検疫、特定コラボレーターの削除、共有リンクの期限切れ等はPurviewに直接の同等機能がなく、Power Automate等での代替設計が必要です。
  • Purview DLPの利用にはMicrosoft 365 E5 / E5 Compliance相当のライセンスが前提。ライセンスがない移行対象顧客向けの無償オプションが案内されている(Message Center MC1417993:二次情報)。
  • SSPM・アプリガバナンス・脅威検知などMDAの非DLP機能は影響を受けません。「MDAごと終わる」わけではありません。

何が起きているの?

Defender for Cloud Appsのファイルポリシーとは、接続済みクラウドアプリ上の保存済みファイルをAPIでスキャンし、共有状態や機密情報に応じてアラートやガバナンスアクションを実行するポリシーです。Microsoftは、Defender for Cloud Apps(旧MCAS)のファイルポリシーを2027年1月6日に廃止すると公式ドキュメントに明記しました。期限後、MDA上のDLPファイルポリシーはサポートされず、動作もしなくなるとされています(Message Center MC1417993:二次情報)。

範囲を見誤りに注意

2026年7月のMicrosoftパートナー向けアナウンスは、廃止対象をSharePoint・OneDriveだけでなく、Box、Dropbox、Google Workspace、Salesforceなど接続済みサードパーティSaaSのDLPファイルポリシーまで含むと明記しています。同時に、SaaSセキュリティポスチャ管理(SSPM)、アプリガバナンス、脅威保護といった非DLP機能は影響を受けないことも示されています。

移行先はMicrosoft Purview

SharePoint・OneDrive向けのファイルDLPはすでにPurviewでGA済みで、非Microsoft SaaS向けにはGoogle Workspace、Box、Dropbox、Salesforce、ServiceNow、AWS、Cisco Webexの専用ポリシーロケーションがPurview側に順次導入されます。従来Purviewにあった「Instances」ロケーション(MDAのファイルポリシー基盤に依存する方式)も、同じ2027年1月6日に廃止されます(Message Center MC1429010)。

なぜ情報システム・セキュリティ担当者に関係するの?

この廃止の性質は「移行しなければ保護が黙って止まる」ことにあります。障害は起きません。アラートも出続けているように見えて、期限を過ぎたポリシーは強制されなくなる。「機密ファイルの外部共有を検知したら公開アクセスを削除する」というポリシーをMDAに置いている組織では、その自動修復が2027年1月7日から動かなくなります。

猶予は約1年半です。長く見えますが、猶予はあまりありません。

猶予がない三つの理由

移行には複数の工程を踏む必要があり、主な理由は次の3点です。

第一に、移行は自動ではなく、既存ポリシーの棚卸し→Purview側での再作成→シミュレーションモードでの検証→段階的な有効化という工程を踏むためです。Purviewの公式移行ガイドは、シミュレーションで既存ファイルポリシーと検知結果を突き合わせ、パイロットグループで動作を確認してから全社展開する段階的ロールアウトを推奨しています。

競合を鑑みた並行検証期間が必要

第二に、MDAとPurviewで同等ポリシーを同時に動かすと強制が競合するため、両システムの並行検証期間を確保する必要があります。

ライセンス準備のリードタイム

第三に、ライセンス確認と調達に時間がかかるためです。Purview DLPの前提はMicrosoft 365 E5またはE5 Compliance(相当のスタンドアロンライセンス)であり、E3中心の組織ではどのライセンスを調達するのかという判断が先に立ちます。

ライセンスについては、移行対象顧客向けに無償オプションが用意されているとMicrosoftのMessage Center通知(MC1417993:二次情報)が案内しています。従来MDAで使っていた中核機能に相当するPurview E5 Information Protection & Governanceライセンスへのアクセスを移行用途に限って提供するとされるもので、該当する場合はMicrosoftアカウントチームへの相談が必要とされていますMC1417993:二次情報:条件は個別にお問い合わせください)。

よくある誤解

誤解1:「Defender for Cloud Appsそのものが終わる」

終わりません。廃止されるのはDLPファイルポリシーであり、SaaSの検出(Shadow IT可視化)、SSPM、アプリガバナンス、脅威検知は継続します。OAuth連携アプリの統制にMDAを使っている組織は、そこを手放す必要はありません。

誤解2:「移行ボタンを押せばPurviewに引き継がれる」

自動移行はありません。公式ガイドが示すのは、既存ポリシーを1本ずつ文書化し、Purview側でDLPポリシーまたは自動ラベル付けポリシーとして再作成する手順です。正規表現ベースの検知はカスタム機密情報タイプ(Sensitive Information Type:SIT)として作り直します。

誤解3:「Purviewに移せば全機能が同等に使える」

同等ではない箇所が明確にあります。ユーザー検疫、特定コラボレーターの削除、共有リンクの期限切れ、ファイルの削除、所有権移転には直接の同等機能がなく、Power AutomateやSharePoint共有ポリシーでの代替が必要です。逆にPurviewにしかない改善もあり、シミュレーションモード(MDAには無い)と、ポリシー上限の大幅な緩和が該当します。

また、MDAはテナントあたり50ファイルポリシーであるのに対し、Purviewは情報保護・ガバナンス(MIP+MIG)系ポリシーが最大10,000、DLPルールがテナントあたり600と上限の粒度が異なるため、MDAの50ファイルポリシーとは単純な同一単位比較にはなりません。

実務で問題になりやすいポイント

いま何のファイルポリシーが動いているか誰も説明できない

多くの企業で最初に詰まるのは、この状態です。ファイルポリシーは導入時に作り込まれたまま放置されやすく、担当者の異動で意図が失われていることがよくあります。移行の成否は再作成の技術力よりも棚卸しの精度で決まります。

MDAとPurviewとでフォルダスコープが異なる

MDAでは親フォルダ単位でポリシーを絞れましたが、PurviewはSharePointのサイト単位スコープが最も近い形です。「特定の部門フォルダだけ検知したい」という設計は、サイト構成の見直しとセットで考え直すことになります。

共有状態修復の挙動差

MDAは既存の共有状態そのものを変更できました(特定コラボレーター削除、公開アクセス削除など)。Purview DLPの「アクセス制限」は以後のアクセスをブロックする動作であり、既存の共有設定を書き換えるにはPower Automateなどで追加実装することになります。監査対応で「検知したら共有を自動解除している」と説明してきた組織は、説明内容をアップデートする必要があります。

CASB/SSE併用組織の影響はat-rest実装の差し替えに限定される

NetskopeなどのCASB/SSEを併用している組織では、転送中データ(in-transit)のインラインDLPはSSE、保存データ(at-rest)のAPIスキャンはMDA、という役割分担がすでに確立していることが多く、今回の廃止でこの分担の構図自体は変わりません。SSE側のインラインDLPは廃止と無関係で、そのまま維持できます。

変わるのはat-rest側の実装製品です。MDAのファイルポリシーに置いていた検知・修復をPurview DLPへ再作成し、役割分担を記した文書(運用設計書・内部統制文書)の製品名とアラート確認先を更新する。CASB/SSE併用組織の対応は、この2点に限定されます。

技術的・運用的な確認ポイント

移行ガイドに沿って、確認は次の順で進めます。

  1. Microsoft Defenderポータルの Cloud Apps > ポリシー > ポリシー管理 で、種類フィルタを「ファイルポリシー」にして全件を抽出する
  2. 各ポリシーについて、対象アプリ/コンテンツ検査方式(Data Classification Service(DCS)・正規表現)/検知対象(SIT・ラベル)/コンテキストフィルタ(共有レベル・ファイル種別・ユーザーグループ)/ガバナンスアクションを文書化する
  3. 各ポリシーを「DLP検知・対応」型と「自動ラベル付け」型に分類する(前者はPurview DLPへ、後者はPurview自動ラベル付けポリシーへ)
  4. 条件マッピング表で移行可否を判定する。File ID条件は移行不可、作成日・更新日条件はSharePoint/OneDrive限定など、部分互換・非互換を先に洗い出す
  5. Purview側で再作成し、シミュレーションモードで既存ポリシーの検知結果と比較する
  6. 検証完了後にMDA側ポリシーを「無効化」する(削除はしない)。両製品で同等ポリシーを同時に有効化しない
  7. 移行後のアラート確認先を運用手順書に反映する(DLPアラートはPurviewポータルのData loss prevention > Alerts、アクティビティはActivity explorer)

Purviewの自動ラベル付けは新規・変更ファイルが対象であり、既存の保存済みファイルへ遡ってラベル付けするにはオンデマンド分類スキャンを別途実行する点も、移行計画に含めてください。

対応方針の比較表

方針内容向いている組織注意点
Purviewへ全面移行MDAの全ファイルポリシーをPurview DLP/自動ラベル付けへ再作成E5保有またはE5 Compliance調達可能なMicrosoft中心の組織フォルダスコープ・共有修復の非互換はPower Automate等で代替設計
SSE併用構成の維持(at-rest実装のみ差し替え)in-transitはSSEのまま、at-restのMDAポリシーのみPurviewへ再作成CASB/SSE併用組織役割分担は変更不要。文書の製品名・アラート確認先の更新を忘れない
廃止対象ポリシーの計画的縮退使われていないポリシーは移行せず廃止ポリシーが形骸化している組織「不要」の判断根拠を監査向けに記録してから無効化
無償ライセンスオプションの活用移行用途スコープのPurviewライセンス提供を相談E5未保有でMDA DLPを利用中の組織Microsoftアカウントチーム経由。条件・範囲は個別確認(MC1417993・二次情報)

見直し時のチェックリスト

  • MDAのファイルポリシー全件をエクスポート・文書化した(名称・対象アプリ・検査方式・アクション)
  • 各ポリシーを「DLP型」「自動ラベル付け型」「廃止候補」に分類した
  • File ID・フォルダスコープ・ユーザー検疫など非互換機能への依存有無を確認した
  • Purview DLPの前提ライセンス(E5 / E5 Compliance相当)の充足状況を確認した
  • 非Microsoft SaaS(Box・Google Workspace等)の専用ポリシーロケーションの提供状況を確認した
  • Purviewの「Instances」ロケーションで作成済みのポリシーの有無を確認した(同日廃止)
  • シミュレーションモードでの検証期間とパイロットグループを計画に組み込んだ
  • MDA側ポリシーの無効化タイミングと、削除前の監視期間を定めた
  • DLPアラートの確認先変更(Defenderポータル→Purviewポータル)を運用手順書・SOC連携に反映した

経営層・監査部門への説明ポイント

経営層には「製品の廃止」ではなく「保護の空白リスク」として説明するのが正確です。要点は以下の3点です。

  • 2027年1月6日を過ぎると、現行のクラウドDLP(外部共有された機密ファイルの検知・修復)が強制されなくなる。
  • 移行は手作業で、検証を含め数か月の工程になる。
  • ライセンス調達判断が必要になる可能性がある。

この3点を、期限から逆算したマイルストーンとともに提示します。

監査部門に対しては、DLP統制の実装場所と証跡の所在が変わることを事前に通知してください。ポリシーの定義・アラート・アクティビティ履歴の確認先がDefenderポータルからPurviewポータルへ移るため、内部統制文書(ITGC・ISMSの適用宣言書など)でMDAのファイルポリシーを統制の実装として記載している場合は、記載の更新が必要です。移行前後の検知結果の比較記録は、統制の連続性を示す証跡として残す価値があります。

実務担当者が次に取るべき対応ステップ

  1. 今週中:MDAのファイルポリシー利用有無を確認する。1本も使っていなければ、この廃止に関する即時対応は不要(Purviewを将来のDLP実装先として認識するのみ)
  2. 2026年8月中:ファイルポリシー全件の棚卸しと分類を完了する。あわせてPurviewライセンスの充足状況を確認し、不足があればMicrosoftアカウントチームへ無償オプションを含めて相談する
  3. 2026年9〜10月:Purview側でポリシーを再作成し、シミュレーションモードで検証を開始する。非互換機能(ユーザー検疫・コラボレーター削除等)の代替をPower Automate等で設計する
  4. 2026年11〜12月:パイロット→全社の段階でPurviewポリシーを有効化し、MDA側を無効化する。運用手順書・監査文書を更新する
  5. 2027年1月6日前:MDA側の無効化済みポリシーを最終確認のうえ削除し、移行完了を記録する

まとめ

現在のところ、廃止日は2027年1月6日です。まずやることは一つで、Microsoft Defenderポータルを開き、ファイルポリシーが何本動いているかを数えることです。

ゼロなら安心してタブを閉じてください。1本でもあれば、それぞれが何を守っていて、Purviewで再現できるのか・できないのかを、この記事のチェックリストに沿って年内に判定してください。判定が済めば、残りは工程管理の問題になります。

FAQ

Q1. Defender for Cloud Appsのファイルポリシーはいつ廃止されますか?

2027年1月6日です。以後、MDA上のDLPファイルポリシーはサポートも強制もされません。

Q2. Defender for Cloud Apps自体が使えなくなるのですか?

いいえ。廃止はDLPファイルポリシーのみで、SaaSセキュリティポスチャ管理、アプリガバナンス、脅威保護などの非DLP機能は影響を受けません。

Q3. BoxやGoogle WorkspaceのDLPも影響を受けますか?

受けます。廃止対象はSharePoint・OneDriveに加え、Box・Dropbox・Google Workspace・Salesforce等の接続済みサードパーティSaaSのDLPファイルポリシーを含みます。移行先として、Purviewに各アプリ専用のポリシーロケーションが順次導入されます。

Q4. 移行は自動で行われますか?

いいえ。既存ポリシーを棚卸しし、Purview DLPまたは自動ラベル付けポリシーとして手作業で再作成します。正規表現はカスタム機密情報タイプとして作り直します。

Q5. Purviewへの移行に必要なライセンスは?

Microsoft 365 E5またはE5 Compliance(相当のスタンドアロンPurview DLPライセンス)が前提です。当該ライセンスを保有していない移行対象顧客向けに、移行用途に限定した無償オプションの案内があるとされています(Message Center MC1417993:二次情報、条件は要個別確認)。

Q6. Purviewで再現できない機能はありますか?

あります。ユーザー検疫、特定コラボレーターの削除、共有リンクの期限切れ、ファイル削除、所有権移転には直接の同等機能がなく、Power Automate等での代替設計が必要です。フォルダ単位のスコープもサイト単位に変わります。

Q7. MDAとPurviewで同じポリシーを並行稼働させてよいですか?

同等ポリシーの同時有効化は強制の競合を生むため不可です。Purview側をシミュレーションモードで検証し、有効化した後にMDA側を無効化する順序が公式に示されています。

Q8. ファイルポリシーを使っていない場合は何かする必要がありますか?

対応は不要です。今後DLPを実装する場合は、最初からPurviewで設計してください。

おわりに

「そもそも自社のMDAでファイルポリシーが何本動いているか分からない」「PurviewとNetskopeでDLPの守備範囲をどう分けるべきか整理したい」… 移行そのものより、その手前の棚卸しと責任分界の整理で止まってしまうのではないでしょうか。

2027年1月の期限から逆算した現実的な移行計画づくりとして、まずは自社状況の整理から始めてみてください。

この記事が誰かの役に立てば幸いです。

この記事をシェア