Microsoft PurviewのEndpoint Data Loss Prevention（Endpoint DLP）では、Windowsの除外フォルダーに保存されたファイルも保護対象に広げる更新が予定されています。ポイントは、TempやAppDataなど、これまでDLP監視から外れやすかった場所にある機密データも検出・保護しやすくなることです。一般提供は2026年7月予定で、対象はMicrosoft Purview、プラットフォームはWeb、クラウドはWorldwide（Standard Multi-Tenant）として案内されています。(Microsoft)
この変更は、単に「検出範囲が広がる」だけではありません。既存のEndpoint DLPポリシー、Windowsのファイルパス除外、業務アプリの一時ファイル、開発ツールのキャッシュ、サポート調査時のログ取得などに影響する可能性があります。管理者は、一般提供前に除外パスの棚卸し、監査ログの確認、ポリシーの段階的展開を行うべきです。
Microsoft Purview Endpoint DLPの更新内容
今回の更新は「Microsoft Purview: Endpoint Data Loss Prevention – Ability to protect files stored in the excluded folders in Windows」というロードマップ項目です。Microsoftの説明では、Endpoint DLPが、TempやAppDataを含む一般的に除外されるWindowsフォルダー内のファイルにも保護を拡張し、これらの場所にある機密データの検出と保護範囲を改善するとされています。(Microsoft)
Endpoint DLPは、Microsoft Purview Data Loss Preventionの機能の一部で、オンボード済みのWindows 10、Windows 11、macOSデバイス上で機密情報の利用や共有を検出し、適切に保護するための可視性と制御を提供します。(Microsoft Learn)
今回の変更を実務目線で言い換えると、次のようになります。
| 観点 | これまで意識されやすかった状態 | 今回の更新後に確認すべきこと |
|---|---|---|
| 対象フォルダー | AppData、Temp、アプリのキャッシュ領域はDLP対象外になりやすい | 機密データが一時領域に保存された場合も検出・保護される可能性を確認する |
| セキュリティ効果 | ユーザーの通常保存先を中心にDLPを設計 | 業務アプリや開発ツールが作る一時ファイルまで含めてデータ流出リスクを評価する |
| 運用影響 | 除外により誤検知や性能影響を抑制 | 監査イベント、アラート、ブロックの増加に備える |
| 展開方針 | 既存ポリシーをそのまま維持しやすい | シミュレーション、パイロット、本番適用の順に検証する |
なぜTempやAppDataの保護が重要なのか
Windows環境では、ユーザーが明示的に保存したファイルだけが機密データの置き場所ではありません。業務アプリ、ブラウザ、圧縮・解凍ツール、PDFソフト、開発ツール、RPA、同期クライアントなどは、一時ファイルやキャッシュをTempやAppData配下に作成することがあります。
たとえば、次のようなケースです。
| 利用シーン | 起こり得るリスク |
|---|---|
| 添付ファイルをプレビューする | 一時フォルダーに機密資料のコピーが残る |
| 業務アプリからCSVを出力する | AppData配下に個人情報を含む中間ファイルが生成される |
| RPAが請求データを処理する | Temp配下に処理前後のファイルが一時保存される |
| 開発者がログやダンプを確認する | アクセストークン、顧客ID、メールアドレスなどがローカルに残る |
| 圧縮ファイルを展開する | 元ファイルより広い範囲に機密情報が複製される |
DLP運用では「ユーザーが意図的に保存したファイル」だけを見ると、実際のデータ流出経路を見落とします。TempやAppDataは、ユーザーに見えにくい一方で、機密情報が通過しやすい場所です。今回のEndpoint DLP更新は、この見えにくい領域を補強する意味があります。
既存設定への影響範囲
Microsoft Learnでは、Endpoint DLPの設定として、クラウド送信制限、アプリごとの制限、Windows/macOSのファイルパス除外、ブラウザーやドメイン制限、ポリシーTipsの表示、Office・PDF・CSVファイルの自動監査などを一元的に制御できると説明されています。設定画面は、Microsoft Purviewポータルの「Data loss prevention」からEndpoint settingsへ進む構成です。(Microsoft Learn)
特に確認すべきなのは、Windowsの「File path exclusions」です。現在のMicrosoft Learnでは、ファイルパス除外を設定すると、その場所のファイルはDLP監視、DLPアラート、DLPポリシー適用から除外され、除外場所で作成・変更されたファイルはDLPポリシーの強制対象にならないと説明されています。(Microsoft Learn)
また、Windowsの既定除外パスとして、AppData RoamingとAppData Localに該当するパスが示されています。(Microsoft Learn) このため、今回のロードマップ項目は、特にAppData周辺に機密データが生成される業務環境で重要です。
管理者が影響を受けやすい環境
次のいずれかに当てはまる場合は、一般提供前に検証すべきです。
| 環境・運用 | 確認すべき理由 |
|---|---|
| AppDataやTempを明示的に除外している | これまで検出されなかったファイルが監査・制御対象になる可能性がある |
| 業務アプリがローカル一時ファイルを多用する | 誤検知、処理遅延、ユーザー通知の増加が起こり得る |
| 開発者端末でソース、ログ、ダンプを扱う | 秘密情報や個人情報がキャッシュに含まれる場合がある |
| RPAやバッチ処理端末をDLP対象にしている | 自動処理がブロックや警告で止まる可能性がある |
| DLPポリシーをすでにBlockで運用している | 新たに検出されたファイルが即時ブロックされるリスクがある |
管理者が最初に確認すべき設定
まず確認すべき場所は、Microsoft PurviewポータルのEndpoint DLP settingsです。特に、Windowsのファイルパス除外、制限対象アプリ、ブラウザーとドメイン制限、ファイル拡張子グループ、監査設定を見直します。
| 確認項目 | 見るポイント | 対応の方向性 |
|---|---|---|
| File path exclusions for Windows | Temp、AppData、業務アプリ固有パスが含まれているか | 除外理由と業務影響を台帳化する |
| DLPポリシーの対象 | Devicesロケーションがどのユーザー・端末に適用されるか | パイロットグループを用意する |
| ポリシー状態 | 監査、シミュレーション、Blockのどれで運用しているか | いきなりBlockにしない |
| アラート設定 | 新規検出でアラートが過剰にならないか | 重要度、集約条件、通知先を調整する |
| 除外アプリ・制限アプリ | 業務アプリや開発ツールが対象になっているか | アプリ単位の業務影響を確認する |
| Activity explorer | AppDataやTemp由来のイベントが見えるか | GA前後でイベント数を比較する |
MicrosoftのDLP展開ガイダンスでは、ポリシー設計と同じくらい展開方法が重要であり、急いだ展開は業務プロセスに悪影響を与え、DLPの受容を妨げる可能性があると説明されています。展開は、影響の少ない状態から段階的に進めることが推奨されています。(Microsoft Learn)
推奨される展開手順
今回の更新に備えるなら、既存ポリシーをすぐ変更するよりも、まず「実際にどこで機密データが発生しているか」を確認することが重要です。
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 棚卸し | Windowsの除外パス、対象ユーザー、対象端末、DLPポリシーを一覧化 | 除外理由を説明できないパスがないか |
| 監査 | AppData、Temp、業務アプリの一時領域で発生するイベントを確認 | 機密情報の検出件数、業務アプリ別の傾向を見る |
| パイロット | 情シス、セキュリティ部門、代表部門の少人数に適用 | 誤検知、処理遅延、問い合わせ件数を見る |
| チューニング | SIT、ラベル、例外条件、通知文、アラート条件を調整 | 業務上正当な処理を過剰に止めていないか |
| 本番展開 | 部門単位または端末グループ単位で拡大 | ブロック前にユーザー教育とヘルプデスク準備を完了する |
Microsoft Learnでは、DLPポリシーの展開管理として、スコープ、状態、アクションの3軸を使い、シミュレーションモードから本格適用へ段階的に進める考え方が示されています。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
既存の除外設定を「不要」と決めつける
今回の更新によって保護範囲が広がるとしても、すべての除外設定を削除すればよいわけではありません。除外には、性能、互換性、業務継続のための理由がある場合があります。
たとえば、アプリケーションが大量の.tmpファイルや.jsonファイルを短時間で生成する場合、DLP評価の対象が増えることで端末負荷やアプリ動作に影響する可能性があります。除外設定は削除ではなく、まず「なぜ除外しているのか」「今も必要か」「代替制御はあるか」を確認します。
Blockポリシーをそのまま広範囲に適用する
既にEndpoint DLPをBlockで運用している場合、検出範囲の拡大によって、これまで止まらなかった操作が急にブロックされる可能性があります。
特に注意すべき操作は、USBコピー、ネットワーク共有への保存、印刷、ブラウザーへのアップロード、クリップボードコピーです。業務フローに直結するため、まずAudit onlyまたはシミュレーションでイベントを確認し、必要に応じてBlock with overrideを挟むと現場の混乱を減らせます。
ユーザー通知の文面を見直さない
DLPのポリシーTipsが表示されたとき、ユーザーが「何をすればよいか」を理解できないと、問い合わせが増えます。
悪い例は「この操作はポリシーにより禁止されています」だけの通知です。良い例は「個人情報を含むファイルを外部サービスへアップロードしようとしています。業務上必要な場合は承認済みの共有先を使ってください」のように、理由と次の行動が分かる文面です。
開発者端末やRPA端末を見落とす
開発者端末では、ログ、設定ファイル、API応答、テストデータ、クラッシュダンプなどに機密情報が含まれることがあります。RPA端末では、人が直接操作しないため、DLP通知に気づかず処理が止まる可能性があります。
これらの端末は、一般ユーザー端末と同じ基準で展開せず、別のパイロットグループとして検証するのが安全です。
開発者・アプリ担当者が確認すべきこと
この更新は管理者だけでなく、業務アプリや社内ツールを扱う開発者にも関係します。アプリがどこに一時ファイルを作るかによって、DLP検出やブロックの対象になる可能性があるためです。
確認すべきポイントは次の通りです。
| 確認項目 | 具体例 |
|---|---|
| 一時ファイルの保存先 | %TEMP%、%APPDATA%、%LOCALAPPDATA%、アプリ独自のキャッシュディレクトリ |
| 保存されるデータ | 個人情報、認証情報、顧客データ、契約情報、ソースコード、ログ |
| ファイル形式 | CSV、PDF、Officeファイル、JSON、ZIP、ログファイル |
| 保存期間 | 処理後に削除されるか、長期間残るか |
| エラー時の挙動 | 失敗時に機密データを含むダンプやログを残すか |
| 自動処理への影響 | DLP警告やブロックによりバッチ、RPA、同期処理が停止しないか |
開発者側では、機密情報を一時ファイルに書き出さない設計、処理後の安全な削除、ログのマスキング、テストデータの匿名化を見直すと効果的です。DLPで検出されてから対処するより、アプリ側で「機密データを不要に残さない」設計にする方が安定します。
セキュリティ面で期待できる効果
今回のEndpoint DLP更新で期待できる主な効果は、保護の抜け道になりやすいローカル一時領域の可視化です。
従来、ユーザーのデスクトップ、ドキュメント、ダウンロードフォルダーなどは管理対象として意識されやすい一方、AppDataやTempは「アプリが勝手に使う場所」として見落とされがちでした。しかし、実際には業務データのコピー、プレビュー、一時展開、キャッシュが残ることがあります。
この領域をDLPの検出・保護対象に含められるようになることで、次のような改善が見込めます。
| 効果 | 実務上の意味 |
|---|---|
| 機密データの残留検出 | ユーザーが意識していない一時コピーも把握しやすくなる |
| アップロード・コピー制御の強化 | 一時フォルダー経由の外部送信リスクを下げられる |
| インシデント調査の精度向上 | どのアプリや操作で機密情報が生成されたか追いやすくなる |
| 開発・業務アプリの改善材料 | 不要な機密データ保存やログ出力を見直すきっかけになる |
GA前にやるべきチェックリスト
一般提供予定の2026年7月までに、管理者は次の順で確認すると効率的です。
| 優先度 | チェック項目 | 完了の目安 |
|---|---|---|
| 高 | Microsoft 365 Roadmap ID 562992の更新状況を確認 | GA時期や説明に変更がない |
| 高 | WindowsのFile path exclusionsをエクスポートまたは記録 | AppData、Temp、業務アプリパスの有無が分かる |
| 高 | Devices対象のDLPポリシーを一覧化 | Audit、Block、Block with overrideの適用範囲が分かる |
| 高 | パイロット対象ユーザーを決める | 情シス、セキュリティ、業務部門代表を含める |
| 中 | Activity explorerで既存イベントを確認 | GA前後の比較基準を作る |
| 中 | ヘルプデスク向けFAQを用意 | ユーザーが警告を見たときの案内がある |
| 中 | 開発・RPA・業務アプリ担当に周知 | 一時ファイル保存先の確認依頼が済んでいる |
| 低 | 長期的な例外管理ルールを整備 | 例外の期限、承認者、見直し周期が決まっている |
まとめ：除外フォルダーを「見えない場所」のままにしない
今回のMicrosoft Purview Endpoint DLP更新は、WindowsのTempやAppDataなど、従来は除外されやすかったフォルダー内のファイルにも保護を広げるものです。ロードマップ上の一般提供予定は2026年7月で、現在はIn developmentとして案内されています。(Microsoft)
管理者が今やるべきことは、既存のDLPポリシーを急いで変えることではありません。まず、Windowsのファイルパス除外、対象ユーザー、対象端末、Blockポリシーの有無を棚卸しし、AppDataやTempでどの程度の機密データが発生し得るかを確認することです。
特に、業務アプリ、RPA、開発者端末、ログ出力、ファイルプレビュー処理は影響を受けやすい領域です。シミュレーションとパイロットでイベントを確認し、誤検知と業務影響を抑えながら展開すれば、DLPの保護範囲を広げつつ、現場の混乱を避けられます。
次に取るべき行動は明確です。Microsoft PurviewポータルでEndpoint DLP settingsを開き、WindowsのFile path exclusionsとDevices対象ポリシーを確認してください。そこから、AppData・Tempを含む一時領域のリスクを見える化することが、今回の更新に備える最初の一歩です。
コメント