Azure の「Get started with collecting files that match data loss prevention policies from devices」は、Microsoft Purview Data Loss Prevention（DLP）で端末上のファイル操作を検出し、ポリシーに一致したファイルを Azure Storage へ証跡として収集するための公式手順です。2026年6月26日更新の公式情報を見る限り、重要なのは「DLPポリシーの設定」だけではありません。端末のオンボード、Azure Blob Storage または Microsoft 管理ストレージの選定、権限設計、ネットワーク到達性、調査担当者のアクセス権まで合わせて確認する必要があります。(Microsoft Learn)
特にグローバル企業では、収集されたファイルが機密情報そのものを含む可能性があるため、保存リージョン、部門別のアクセス分離、保持期間、調査担当者の権限を先に決めることが重要です。なお、2026年6月26日時点の公式ページでは、この機能に関する明確な移行期限や廃止期限は示されていません。一方で、Microsoft-managed storage や Data Security Investigations、Triage Agent との連携を見据える場合は、従来の「とりあえず Azure Blob に保存する」運用から、調査プロセス全体を再設計する必要があります。(Microsoft Learn)
Azure の「Get started with collecting files that match data loss prevention policies from devices」とは
この公式ページは、Microsoft Purview DLP の「evidence collection for file activities on devices」、つまり端末上のファイル操作に対する証跡収集を構成するための手順です。DLPポリシーに一致したファイルを、オンボード済みの Windows 10/11 デバイスまたは macOS デバイスから Azure Storage へコピーし、DLP調査担当者や管理者が内容を確認できるようにします。macOS は公式情報上では Preview として扱われています。(Microsoft Learn)
ここでいう「証跡」は、DLPインシデント調査やポリシーの誤検知確認に役立つファイルコピーです。Microsoft は、このコピーを法的な意味での証拠保全や変更不能な証拠として扱うものではないと説明しています。訴訟対応や法的保全が目的であれば、Microsoft Purview eDiscovery の利用を検討すべきです。(Microsoft Learn)
実務上は、次のような場面で有効です。
- USBメモリへのコピーをブロックしたが、実際にどのファイルが対象だったか確認したい
- クラウドサービスへのアップロード検知で、機密情報の種類とファイル内容を調査したい
- DLPポリシーの誤検知が多く、実ファイルを見て条件を調整したい
- 海外拠点や部門ごとに、DLPインシデント調査の担当範囲を分けたい
2026年6月26日更新で管理者が確認すべきポイント
2026年6月26日に更新された公式ページでは、証跡収集を使い始めるための前提条件、ストレージ構成、DLPポリシー設定、証跡のプレビューとダウンロード、既知の制限が整理されています。単なる画面操作の説明ではなく、ストレージと権限設計を含む運用設計の資料として読むべき内容です。(Microsoft Learn)
| 確認項目 | 管理者が見るべきポイント | 実務上の影響 |
|---|---|---|
| 対象デバイス | Windows 10/11、macOS Preview のオンボード状況 | オンボードされていない端末では証跡収集の対象にならない |
| 対象操作 | USB、ネットワーク共有、印刷、RDP、Bluetooth、クラウドアップロード、ブラウザー貼り付け、制限アプリによるアクセスなど | どの操作でファイルを収集するかをポリシーごとに決める必要がある |
| ストレージ | Customer-managed storage または Microsoft-managed storage | 保持期間、リージョン、アクセス方法、コスト、調査機能との連携が変わる |
| 権限 | Purviewロールと Azure Blob Storage 側の権限 | 調査担当者が見られない、または過剰に見えてしまうリスクがある |
| ネットワーク | Customer-managed storage では一部のプライベートアクセス構成が使えない | Private Endpoint 前提の厳格な閉域設計とは相性を確認する必要がある |
| 制限事項 | 500MB上限、JIT保護やネットワーク共有時の例外など | 「アラートはあるが証跡ファイルがない」ケースを想定しておく |
影響範囲：AzureだけでなくPurview、端末、調査運用にまたがる
この更新の対象は「Azure Storageの設定」だけではありません。実際の影響範囲は、Microsoft Purview DLP、Endpoint DLP、Azure Blob Storage、Microsoft Entra ID の権限、調査担当者の運用ルールまで広がります。公式手順でも、デバイスのオンボード、要件整理、Azure Storageの作成、証跡収集の有効化、DLPポリシー設定、使用量確認という流れで構成されています。(Microsoft Learn)
対象になるファイル操作
証跡収集を有効にすると、DLPポリシーに一致したファイルに対して、次のような操作が行われた場合にファイルコピーを保存できます。対象操作はDLPポリシー側で選択します。(Microsoft Learn)
| 操作カテゴリ | 具体例 | 管理上の見方 |
|---|---|---|
| 外部媒体 | リムーバブルUSBへのコピー | 退職者、委託先、共有端末で特に確認したい操作 |
| 社内外の共有 | ネットワーク共有へのコピー | ファイルサーバーや部門共有への持ち出し確認に有効 |
| 印刷 | 機密ファイルの印刷 | 紙への持ち出しリスクを確認できる |
| リモート操作 | RDP経由のコピーや移動 | 仮想デスクトップ、踏み台端末の運用で重要 |
| ブラウザー・クラウド | クラウドサービスへのアップロード、サポート対象ブラウザーへの貼り付け | シャドーITや生成AIサービス利用時の確認に役立つ |
| アプリ制御 | 制限アプリによるアクセス | 許可されていないアプリ経由のデータ利用を把握する |
対象になるDLPアクション
証跡収集は、DLPポリシーのアクションが「Audit only」「Block with override」「Block」の場合に、ポリシー設定と組み合わせて動作します。つまり、いきなりブロック運用を始めなくても、監査モードで実ファイルを確認しながら条件を調整できます。(Microsoft Learn)
実務では、最初から「Block」にするよりも、まず「Audit only」で対象操作と誤検知傾向を確認し、次に「Block with override」で業務上必要な例外理由を収集し、最後に高リスク操作だけ「Block」に移す流れが安全です。
Customer-managed storage と Microsoft-managed storage の違い
証跡ファイルの保存先は、大きく分けて Customer-managed storage と Microsoft-managed storage の2種類です。公式情報では、前者は顧客が管理する Azure Storage、後者は Microsoft 管理のストレージとして説明されています。どちらが優れているというより、保持期間、アクセス制御、リージョン、調査ワークフローのどこを重視するかで選びます。(Microsoft Learn)
| 比較項目 | Customer-managed storage | Microsoft-managed storage |
|---|---|---|
| 向いているケース | リージョンや保持期間を自社で細かく制御したい | 設定を簡素化し、Purview中心で調査したい |
| 保持期間 | 自社要件に合わせて管理可能 | 最大180日と説明されている |
| アップロード上限 | Azure Blob Storage 側の設定に依存 | テナント全体で1日最大5GBと説明されている |
| リージョン | 顧客が選択 | Microsoft Purview テナントと同じリージョン |
| アクセス | 権限を持つユーザーがBlobにアクセス可能 | 人がストレージへ直接アクセスする設計ではない |
| 権限設定 | Azure Storage側のRBAC設計が必要 | Endpoint DLP設定で扱いやすい |
| ネットワーク | BlobコンテナーURLの許可が必要 | compliancedrive.microsoft.com の許可が必要 |
| コスト | Azure Storageコストが別途発生 | 現時点ではE5に含まれるが、過剰利用時の扱いは将来変更の可能性があると説明されている |
グローバル企業で特に注意したいのは、保存リージョンと調査担当者の所在地です。公式情報では、規制要件に対応するため、コピー元デバイスと同じ地政学的または規制上の境界内に Azure Storage アカウントを置くこと、さらに保存後の機密アイテムへアクセスするDLP調査担当者の所在地も考慮することが推奨されています。(Microsoft Learn)
Customer-managed storage を選ぶ場合の注意点
Customer-managed storage を使う場合は、Azure Blob Storage を自社で作成し、Microsoft Purview の Endpoint DLP 設定にコンテナーURLを登録します。公式ページでは、Azure Blob コンテナーURLの形式として https://storageAccountName.blob.core.windows.net/containerName が示されています。(Microsoft Learn)
注意すべきなのは、ストレージアカウント作成時のネットワーク設定です。公式情報では、ストレージアカウント作成時に「Enable public access from all networks」を選択すること、Virtual networks や IP addresses、private access のサポートは利用できないことが示されています。これは、Private Endpoint やストレージファイアウォールで厳しく閉じる設計を前提にしている組織では、事前にセキュリティ例外や代替設計を検討すべきポイントです。(Microsoft Learn)
また、コンテナー単位で別々の権限を設定したい場合にも注意が必要です。公式情報では、各コンテナーは所属するストレージアカウントの権限を継承し、コンテナーごとに異なる権限は設定できないと説明されています。部門や地域ごとにアクセス権を分ける必要がある場合は、複数コンテナーではなく複数ストレージアカウントで分離する設計が必要です。(Microsoft Learn)
Microsoft-managed storage を選ぶ場合の注意点
Microsoft-managed storage は、権限やストレージ設定を簡素化したい組織に向いています。Microsoft Purview ポータルの Endpoint DLP settings から evidence collection を有効化し、storage type として Microsoft managed storage を選択します。(Microsoft Learn)
特に、Data Security Investigations や Triage Agent など、Purviewの調査機能を活用したい場合は Microsoft-managed storage の重要度が高まります。Microsoft Purview の2026年6月の更新情報では、Endpoint DLP evidence collection が Data Security Investigations のデータソースとして Preview 提供され、端末のDLPイベントを集約して分析できると説明されています。(Microsoft Learn)
さらに、Triage Agent で Devices、つまりEndpointのDLPアラートをトリアージするには、evidence collection for file activities on devices を有効にする必要があります。公式情報では、対象ポリシーが限定的な適格性になる理由として、この機能が有効でない場合や、関連付けられたストレージが Microsoft storage でない場合が挙げられています。(Microsoft Learn)
設定変更の実務手順
証跡収集を導入する場合は、いきなりDLPポリシーを変更するのではなく、先に「誰の、どの端末の、どの操作を、どこへ保存し、誰が見られるのか」を決めることが重要です。公式手順でも、デバイスのオンボード、要件整理、ストレージ作成、証跡収集の有効化、DLPポリシー設定という順序が示されています。(Microsoft Learn)
事前に決めること
| 決めること | 判断基準 | 例 |
|---|---|---|
| 対象ユーザー | 全社か、部門単位か、リスクの高い職種に限定するか | 役員、人事、経理、開発、退職予定者 |
| 対象デバイス | Windowsのみか、macOS Previewも含めるか | まずWindows 11管理端末から開始 |
| 対象操作 | 収集すべき操作を絞るか、広く監査するか | USB、クラウドアップロード、印刷を優先 |
| 保存先 | Customer-managedか Microsoft-managedか | 法規制重視ならCustomer-managed、調査効率重視ならMicrosoft-managed |
| 保持期間 | 調査期間、監査要件、ストレージコスト | 30日、90日、180日など |
| 調査権限 | 誰がプレビュー・ダウンロードできるか | セキュリティ運用チームのみ、部門DLP担当者のみ |
Purview側で証跡収集を有効化する
Microsoft Purview ポータルで、Settings から Data Loss Prevention、Endpoint DLP settings を開き、「Setup evidence collection for file activities on devices」を展開してトグルを On にします。端末がオフラインのときにローカルへ証跡を保存する期間は、7日、30日、60日から選択できます。(Microsoft Learn)
その後、Customer-managed store または Microsoft managed store を選択します。Customer-managed storage の場合は Azure Blob Storage のURLを登録し、Microsoft-managed storage の場合は Microsoft managed store を選択して構成します。(Microsoft Learn)
DLPポリシー側でファイル収集を有効化する
DLPポリシーでは、Locations のステップで Devices のみを選択し、Policy settings では高度なDLPルールを作成またはカスタマイズします。Incident reports では、管理者へのアラート送信を有効にし、「Collect original file as evidence for all selected file activities on Endpoint」を選択します。さらに、USBコピー、印刷、クラウドアップロードなど、証跡を収集したいファイル操作を選びます。(Microsoft Learn)
実務上は、最初から全操作を対象にすると保存量と調査負荷が急増します。まずは高リスク操作を優先するのが現実的です。例えば、社外流出リスクを重視するなら「USBコピー」「クラウドサービスへのアップロード」「RDP経由のコピー」から始めます。内部不正や紙での持ち出しを重視するなら「印刷」も対象に含めます。
権限設計で失敗しやすいポイント
証跡収集では、DLPポリシーに一致したファイルの中身そのものが保存されます。そのため、通常のDLPアラート閲覧権限よりも慎重な権限設計が必要です。公式情報では、証跡をプレビューするには Data Classification Content Viewer、ダウンロードするには Data Classification Content Download ロールが必要とされています。Data Classification Content Download は、Data Security Management、Information Protection、Information Protection Investigators などの組み込みロールグループに事前割り当てされています。(Microsoft Learn)
Customer-managed storage の場合は、Azure Blob Storage 側にも権限が必要です。調査担当者にはBlobを読み取るための権限、対象ユーザーには端末からAzureへアイテムをアップロードするための権限を設計します。公式情報では、最小権限の原則に従うことがベストプラクティスとして示されています。(Microsoft Learn)
ありがちな失敗は、次の3つです。
| 失敗例 | 起きること | 対策 |
|---|---|---|
| DLP管理者にだけ権限を付けた | アラートは見えるが証跡をプレビューできない | PurviewロールとAzure RBACを分けて確認する |
| 部門別にコンテナーを分けただけ | コンテナー単位で期待したアクセス分離ができない | アクセス境界ごとにストレージアカウントを分ける |
| ダウンロード権限を広く付与した | 機密ファイルの二次流出リスクが増える | プレビュー権限とダウンロード権限を分離する |
移行期限はあるのか
2026年6月26日更新の公式ページでは、この機能に関する明確な移行期限、廃止日、強制切り替え日は示されていません。したがって、「いつまでに必ず移行しなければならない」と断定するのは適切ではありません。(Microsoft Learn)
ただし、ストレージタイプの変更は運用影響があります。公式情報では、Customer-managed storage と Microsoft-managed storage はいつでも切り替えられる一方で、切り替え後は新しいデータストアにポリシーを適用するためにポリシーの更新が必要とされています。また、RBAC権限が維持されていれば、ストレージ管理タイプを変更しても一致ファイルはアラート結果に引き続き含まれると説明されています。(Microsoft Learn)
そのため、移行期限ではなく「機能適格性」と「調査体験」の観点で見直すべきです。特にTriage AgentやData Security Investigationsを使う予定がある場合は、Microsoft-managed storage を前提にした設計が必要になるケースがあります。(Microsoft Learn)
証跡の確認方法
収集された証跡は、Activity explorer または Microsoft Purview ポータルの Alerts ページから確認できます。Activity explorer では、期間を選択して対象のアクティビティを開き、Evidence file に表示される Azure Blob Storage のリンクから一致ファイルを確認します。Alerts ページでは、DLPアラートの詳細から Events、Source の順に確認し、対象ファイルを表示します。(Microsoft Learn)
なお、同じファイルがすでに Azure Storage Blob に存在する場合、そのファイルに変更が加えられ、かつユーザーが対象操作を行うまで再アップロードされません。調査時に「新しいアラートなのにファイルが更新されていない」と見える場合は、この仕様を確認してください。(Microsoft Learn)
既知の制限と運用上の注意点
証跡収集は便利ですが、すべてのDLPイベントで必ず原本ファイルを取得できるわけではありません。公式情報では、いくつかの既知の制限が示されています。(Microsoft Learn)
| 制限・注意点 | 内容 | 管理者の対応 |
|---|---|---|
| ファイルサイズ上限 | デバイスからアップロードできる最大ファイルサイズは500MB | 大容量CAD、動画、圧縮ファイルなどは別の調査手段も用意する |
| JIT保護時 | Just-in-Time Protection がスキャン済みファイルでトリガーされた場合、証跡ファイルは収集されない | JIT保護と証跡収集の役割を分けて理解する |
| ネットワーク共有上のファイル | ネットワーク共有に保存されたファイルでは証跡ファイルが収集されない場合がある | ファイルサーバー側の監査ログや別のDLP制御と組み合わせる |
| 複数ファイルを同一プロセスで開くケース | 非Officeアプリで複数ファイルを同じプロセスで開き、1つがポリシーに一致して外部送信されると、複数ファイルでDLPイベントが発生しても証跡が取得されない | アラート件数と証跡件数が一致しない前提で調査手順を作る |
| 複数ルール一致 | 1つのファイルで複数ポリシールールが検出された場合、最も制限の厳しいルールが証跡収集を有効にしているときだけ保存される | 高優先度ルールほど証跡収集設定を明示的に確認する |
この機能は「全イベントの完全な証拠保全」ではなく、「DLPインシデント調査を補助するファイルコピー」として設計するのが現実的です。法務、監査、セキュリティ運用が同じ期待値で使えるように、事前に用途を文書化しておくべきです。(Microsoft Learn)
グローバル運用での設計ポイント
グローバル企業では、単一のストレージに全世界の証跡を集約すると、データ所在地、アクセス権、調査担当者の管轄が複雑になります。公式情報では、部門や役割ごとに管理者や調査担当者を分けたい場合、別々のAzure Storageアカウントを作成する例が示されています。たとえば、経営層用と人事部門用で別々のストレージアカウントを用意すれば、それぞれの担当者が自分の範囲の証跡だけを扱いやすくなります。(Microsoft Learn)
ただし、証跡収集でサポートされる Azure Storage アカウント数には上限があり、公式情報では最大10個と説明されています。国、地域、部門、機密区分ごとに細かく分けすぎるとすぐに上限に近づくため、「法規制で分けるべき境界」と「運用上のラベルや管理単位で分ければ足りる境界」を整理してから設計してください。(Microsoft Learn)
設計の目安は次の通りです。
| 要件 | 推奨設計 |
|---|---|
| EU、米国、日本など規制境界を分けたい | 地域ごとにストレージアカウントを分ける |
| 人事・法務・経営層だけアクセスを分けたい | 部門または機密領域ごとにストレージアカウントを分ける |
| 調査担当者は中央SOCのみ | Microsoft-managed storage も含めて検討する |
| 長期保管や独自の削除ポリシーが必要 | Customer-managed storage を検討する |
| PurviewのAI支援調査を重視 | Microsoft-managed storage を優先的に検討する |
管理者がすぐ確認すべきチェックリスト
導入前または既存設定の見直しでは、次の順番で確認すると抜け漏れを減らせます。
| 順番 | 確認項目 | 完了の目安 |
|---|---|---|
| 1 | 対象デバイスがEndpoint DLPにオンボードされているか | Windows 10/11、必要に応じてmacOS Preview端末が対象に入っている |
| 2 | 収集対象の操作を決めたか | USB、印刷、クラウドアップロードなどをリスクに応じて選定している |
| 3 | ストレージ方式を決めたか | Customer-managedか Microsoft-managedかを理由付きで決めている |
| 4 | リージョンとアクセス境界を決めたか | 国・地域・部門・役割ごとの分離方針がある |
| 5 | Purviewロールを付与したか | プレビュー担当者とダウンロード担当者を分けている |
| 6 | Azure Blob側の権限を確認したか | Customer-managed storage の場合、調査担当者と対象ユーザーの権限が適切 |
| 7 | DLPポリシーでDevicesのみを選んだか | 証跡収集対象のポリシーでDevices locationが正しく設定されている |
| 8 | アラートと証跡収集を有効化したか | Incident reports でアラート送信と原本ファイル収集が有効 |
| 9 | 制限事項を運用手順に反映したか | 500MB上限、JIT保護、ネットワーク共有時の例外を調査手順に記載 |
| 10 | テスト用ファイルで動作確認したか | Activity explorer または Alerts から証跡を確認できる |
まとめ：DLP証跡収集は「保存先」より先に調査設計を決める
Azure の「Get started with collecting files that match data loss prevention policies from devices」は、Microsoft Purview DLPで検出した端末上のファイルを Azure Storage または Microsoft-managed storage に収集するための重要な設定です。2026年6月26日更新の公式情報では、ストレージ選択、権限、対象操作、確認方法、既知の制限が整理されており、DLP運用を強化したい管理者にとって確認すべき内容が多く含まれています。(Microsoft Learn)
管理者が最初にやるべきことは、ポータルでトグルをOnにすることではありません。まず、どの部門・地域・端末・操作を対象にするかを決め、証跡ファイルを誰が見られるべきかを定義してください。そのうえで、Customer-managed storage で自社管理を重視するのか、Microsoft-managed storage でPurview中心の調査体験を重視するのかを選ぶのが安全です。
移行期限は明示されていませんが、Triage Agent や Data Security Investigations との連携を考えるなら、証跡収集の有効化と Microsoft-managed storage の適合性は早めに確認する価値があります。まずは監査モードで高リスク操作に限定してテストし、証跡の保存、権限、プレビュー、ダウンロード、既知の制限を一通り検証してから、本番ポリシーへ段階的に展開してください。
コメント