Microsoft Purview の「Get started with data loss prevention for on-premises repositories」更新でまず押さえるべき点は、オンプレミスのファイル共有や SharePoint Server 上の機密データを DLP 対象にする場合、DLP ポリシーだけでなく、Microsoft Purview Information Protection scanner のバージョン、コンテンツスキャンジョブ、権限、ライセンス、シミュレーション運用を一体で見直す必要があることです。
2026年6月26日に更新された公式ページでは、オンプレミスリポジトリを DLP ポリシーの場所として使うための前提条件と構成手順が整理されています。特に重要なのは、「Information Protection scanner の新しいバージョンがある」という注記です。既存環境で旧 Azure Information Protection 統合ラベル付けクライアントや古い 3.x 系スキャナーを使っている場合は、DLP の検出・適用が期待どおり動くかを確認し、サポート期限内の Microsoft Purview Information Protection client へ移行する計画を立てる必要があります。(Microsoft Learn)
Microsoft Purview のオンプレミスDLPで確認すべき更新ポイント
Microsoft Purview Data Loss Prevention のオンプレミスリポジトリ対応は、クラウド上の Exchange、SharePoint Online、OneDrive、Teams だけを守る機能ではありません。ファイルサーバーや SharePoint Server のドキュメントライブラリに保存された「保存済みデータ」を、DLP ポリシーの対象にできます。公式ドキュメントでは、オンプレミスのファイル共有と SharePoint のドキュメントライブラリ／フォルダーに対して、保護アクションを適用できると説明されています。(Microsoft Learn)
今回の更新で管理者が見るべきポイントは、次のとおりです。
| 確認項目 | 更新・確認内容 | 実務上の意味 |
|---|---|---|
| スキャナーのバージョン | Information Protection scanner の新バージョンへの案内が追加・明示されている | 旧 AIP 2.x 系や古い 3.x 系を使っている環境は、DLP 導入前にアップグレード計画が必要 |
| 前提条件 | DLP の一致判定と適用は Microsoft Purview Information Protection scanner に依存する | DLP ポリシーだけ作っても、スキャナーとコンテンツスキャンジョブが未設定ならオンプレミス側は評価されない |
| ライセンス | スキャナーアカウントだけでなく、スキャン対象場所にファイルを追加・利用するユーザーにもライセンスが必要 | グローバル拠点の共有フォルダーでは、利用者範囲の棚卸しが必要 |
| コンテンツスキャンジョブ | リポジトリを指定し、DLP ルールを有効化する必要がある | ファイル共有、SharePoint Server、対象パスの登録漏れが検出漏れにつながる |
| 適用モード | 最初はシミュレーションまたは Enforce Off で検証するのが安全 | 誤検知による ACL 変更、隔離、アクセス遮断を避けられる |
| スコープ指定 | include / exclude の指定が重要。除外リストは包含リストより優先される | 「全社ファイルサーバーを意図せず対象化する」事故を防ぐ |
| 監査・可視化 | Activity explorer、監査ログ、DLP アラート、ローカル CSV レポートで確認する | 検出結果の根拠を残し、ポリシー調整に使える |
影響範囲：対象になる環境と対象外になりやすい範囲
オンプレミスリポジトリ向け DLP の対象は、主にオンプレミスのファイル共有と SharePoint Server のドキュメントライブラリ／フォルダーです。DLP は、機密情報の種類、秘密度ラベル、ファイル拡張子、Office ファイルのカスタムドキュメントプロパティなどを使って検出できます。(Microsoft Learn)
一方で、すべてのオンプレミスデータが自動的に対象になるわけではありません。DLP ポリシーの「On-premises repositories」ロケーションで評価されるのは、Information Protection scanner のコンテンツスキャンジョブに登録され、スキャン対象になったリポジトリです。スキャナーの設定、サービスアカウントの権限、SharePoint 側の権限、SQL Server 構成が不足していると、ポリシー以前の段階で評価が進みません。(Microsoft Learn)
特に注意したいのは、DLP ポリシー側の場所指定ではローカルパスがサポートされない点です。公式ページでは、\\server\share や \\server\share\folder1\subfolderabc、*secret*.docx、https://*/HR のような指定例が示される一方、C:\test や c:\ のようなローカルパスは使用不可の例として挙げられています。(Microsoft Learn)
管理者が最初に確認すべき前提条件
導入前の確認で最も重要なのは、「DLP ポリシーを作成できるか」ではなく、「オンプレミスの対象ファイルを安全に読み取り、評価し、必要に応じて保護アクションを適用できるか」です。
| 確認対象 | 確認すべき内容 | 見落とした場合のリスク |
|---|---|---|
| ライセンス | スキャン対象場所にファイルを追加・利用するユーザーが必要なライセンスを持つか | スキャナーアカウントだけを見て、利用者側のライセンス確認が漏れる |
| Purview ロール | Activity explorer を見る管理者に、Compliance administrator、Security administrator、Compliance data administrator、Global administrator など適切な権限があるか | 検出結果やイベントを確認できず、ポリシー調整ができない |
| スキャナー | Microsoft Purview Information Protection scanner がインストール済みか | DLP のオンプレミス評価が実行されない |
| ラベルとポリシー | テナントに少なくとも 1 つのラベルとポリシーが公開されているか | 機密情報の種類だけで検出する設計でも前提条件を満たせない |
| サービスアカウント | ファイル共有には Read / Write / Modify、SharePoint には Full Control など、用途に応じた権限があるか | 検出はできても、分類・保護・権限変更が失敗する |
| SQL Server | スキャナー構成データベースを保持できる SQL Server があるか | スキャナーの構成・クラスタ管理ができない |
| 監査 | 監査が有効か | Activity explorer や監査ログで追跡できない |
公式ドキュメントでは、スキャン対象場所にファイルを追加または利用するすべてのユーザーにライセンスが必要であり、スキャナーアカウントだけでは不十分だと明記されています。また、DLP データを Activity explorer で見るには、該当する管理者ロールが必要です。(Microsoft Learn)
設定変更で重要なポイント
コンテンツスキャンジョブで DLP ルールを有効化する
オンプレミスDLPでは、Microsoft Purview ポータルで DLP ポリシーを作るだけでは不十分です。Information Protection scanner のコンテンツスキャンジョブを作成し、評価対象のリポジトリを指定したうえで、DLP ルールを有効にする必要があります。公式手順では、作成したコンテンツスキャンジョブで DLP ルールを有効化し、すぐに適用段階へ進まない場合は Enforce を Off にする流れが示されています。(Microsoft Learn)
実務では、最初から Enforce On にするのは避けた方が安全です。オンプレミスDLPでは、アクセス権の変更やファイルの隔離といった業務影響の大きいアクションを設定できるため、まずは検出結果を集めて誤検知を減らすのが基本です。
スキャンは既定で差分スキャンになる
スキャナーは既定で差分スキャンを実行し、前回スキャン済みで変更されていないファイルはスキップされます。公式手順では、すべてのファイルを再評価したい場合、UI の「Rescan all files」または PowerShell の Start-Scan -Reset を使うと説明されています。(Microsoft Learn)
これは、ポリシー変更時に重要です。たとえば、クレジットカード番号だけを見ていたルールにマイナンバー相当の識別子や社内機密ラベルを追加した場合、既存ファイルを再評価しないと「ポリシーを変えたのに検出数が増えない」という誤解が起きます。検出条件を大きく変えた後は、対象範囲を絞ってフル再スキャンを検討してください。
DLP ポリシーのスコープは「All」にしない判断も重要
DLP ポリシーでオンプレミスリポジトリの場所を All にすると、スキャンされたすべてのファイルが DLP ルールの一致判定と適用対象になります。公式手順では、必要に応じて特定の場所にスコープを絞ること、include / exclude を使えること、除外リストが包含リストより優先されることが示されています。(Microsoft Learn)
初期導入では、次のように段階を分けると失敗しにくくなります。
| フェーズ | 推奨スコープ | 目的 |
|---|---|---|
| 初期検証 | 代表的な部門フォルダーや小規模な SharePoint ライブラリ | 検出条件とログ出力を確認する |
| パイロット | 人事、経理、法務など機密情報が多いが管理者と調整しやすい範囲 | 誤検知、業務影響、運用手順を確認する |
| 本番展開 | 拠点・部門単位で段階的に拡大 | アラート対応と例外管理を定着させる |
| 全社適用 | 運用ルールと例外申請が整った後 | 継続的な保護と監査を行う |
移行期限とサポート期限の見方
今回の「Get started with data loss prevention for on-premises repositories」ページ自体には、オンプレミスDLPの一律の強制移行期限は示されていません。ただし、Information Protection scanner は Microsoft Purview Information Protection client に含まれるため、実務上はクライアントのサポート期限が移行計画の基準になります。
公式のリリース管理ページでは、Windows 版 Microsoft Purview Information Protection client の一般提供版は、リリースから 1 年がライフサイクルとされています。2026年7月5日時点で確認すべき主なバージョンは次のとおりです。公式ページの日付形式は月／日／年です。(Microsoft Learn)
| バージョン | 公式のリリース日 | サポート期限 | 管理者の判断 |
|---|---|---|---|
| 3.2.92.0 | 2026年6月11日 | 2027年6月11日 | 本番移行先の有力候補。最新 GA として優先的に検証 |
| 3.2.57.0 | 2026年3月26日 | 2027年3月26日 | 既に導入済みならサポート内。ただし 3.2.92.0 の修正内容も確認 |
| 3.1.310.0 | 2025年6月30日 | 2026年6月30日 | 2026年7月時点では期限超過のため、早急に更新計画が必要 |
| 3.1.251.0 | 2025年4月24日 | 2026年4月24日 | 期限超過。DLP 展開前に更新が必要 |
旧 Azure Information Protection unified labeling client 2.x から 3.x へアップグレードする場合は、サービス名やコンポーネント名が変更されるため、追加の移行手順が必要です。公式手順では、旧 AIPScanner サービスの停止・アンインストール、クライアント 3.x のインストール、Install-Scanner、Update-ScannerDatabase、新しい MIPScanner サービスの開始といった流れが示されています。(Microsoft Learn)
3.x から新しい 3.x へ更新する場合でも、単にインストーラーを実行して終わりではありません。スキャナーサービスを停止し、最新クライアントをインストールし、1 台のスキャナーノードで Update-ScannerDatabase を実行し、各ノードでサービスを再開する手順が必要です。(Microsoft Learn)
3.2.92.0 以降で特に見たい管理者向け変更
2026年6月時点の 3.2.92.0 では、スキャナー管理者向けの機能構成が追加されています。Install-Scanner と Set-ScannerConfiguration に -FeatureSettings パラメーターが追加され、Get-ScannerConfiguration では Features プロパティを確認できるようになっています。また、同じ機能が Microsoft Purview ポータル側にも存在する場合は、ポータル設定が優先されると説明されています。(Microsoft Learn)
同バージョンでは、Custom Reporting 機能のプレビューも追加されています。これは、スキャナークラスターデータベースのレポート用テーブルや列を使い、独自レポートを作成したい組織向けの機能です。グローバル拠点ごとにスキャン件数、失敗件数、対象リポジトリ、ラベル適用状況を集計したい場合に検討価値があります。ただしプレビュー機能は本番利用の可否を社内基準で確認し、監査・運用レポートの正式な根拠にする前に検証環境で試すべきです。(Microsoft Learn)
また、ユーザーやグループをカスタム権限に割り当てる際の参照に Microsoft Graph が統合されました。アップグレード後は、必要なアクセストークンを取得するために Clear-Authentication と Set-Authentication を実行するよう公式ページで案内されています。(Microsoft Learn)
オンプレミスDLPで使える保護アクション
オンプレミスリポジトリで DLP ルールに一致した場合、公式ドキュメントでは主に次の保護アクションが説明されています。(Microsoft Learn)
| アクション | 内容 | 向いているケース | 注意点 |
|---|---|---|---|
| 全員のアクセスをブロック | 所有者、最後に変更したユーザー、管理者などを除いてアクセス権を削除 | 極めて機密性が高い情報の流出防止 | 業務停止の影響が大きいため、最初から本番適用しない |
| 明示的に許可されていない広範なアクセスを削除 | Everyone、Authenticated Users、Domain Users などを ACL から削除 | 共有フォルダーに広すぎる権限がある場合 | 部門横断の共有運用では問い合わせが増えやすい |
| 親フォルダーの権限を継承 | ファイル権限を親フォルダーから継承させる | ファイル単位で権限がばらついている場合 | 親フォルダーの権限設計が不適切だと逆効果 |
| 不適切な場所から削除 | 元ファイルを隔離フォルダーへ移し、スタブファイルを残す | 機密ファイルが誤った場所に置かれた場合 | 復旧手順と所有者通知を事前に決める必要がある |
ここで重要なのは、オンプレミスDLPの「ブロック」は、クラウドサービス上の共有停止とは異なり、NTFS や SharePoint の権限に直接影響する可能性がある点です。検出条件の誤りが ACL 変更や隔離につながるため、最初はシミュレーション、監査、限定スコープで始めるべきです。
安全に展開するための実装手順
現状を棚卸しする
まず、対象となるファイルサーバー、共有名、SharePoint Server の URL、管理部門、データ所有者を一覧化します。グローバル企業では、地域ごとにファイルサーバーの命名規則や SharePoint の URL 構造が異なるため、単純に \\server\share の一覧だけを集めても不十分です。
最低限、次の情報を整理します。
- 対象リポジトリのパス
- データ所有者
- 主な利用部門
- 保存される機密情報の種類
- 既存のアクセス権設計
- スキャン対象外にすべきシステムフォルダー
- 隔離や権限変更が発生した場合の問い合わせ先
スキャナーとクライアントをサポート内にする
次に、Microsoft Purview Information Protection client と scanner のバージョンを確認します。旧 2.x 系から 3.x 系への移行では、サービス名や手順が変わるため、通常の上書き更新と同じ扱いにしないことが重要です。3.x 系同士の更新でも、データベース更新とサービス再起動の手順を変更管理に含めます。(Microsoft Learn)
コンテンツスキャンジョブを作成する
Microsoft Purview ポータルの Information protection scanner でクラスタを作成し、コンテンツスキャンジョブを作成します。公式手順では、初期構成としてスケジュールを Manual、検出対象を Policy only、DLP policy の Enable DLP rules を On にする流れが示されています。リポジトリには UNC パスや SharePoint Server の URL を指定します。(Microsoft Learn)
SharePoint Server を対象にする場合は、ルート、サブサイト、ライブラリ、フォルダーのどの粒度で指定するかを決めます。広い URL を指定すると対象が増えやすいため、初期導入ではライブラリ単位または部門フォルダー単位から始めるのが安全です。
DLP ポリシーをシミュレーションで作成する
DLP ポリシーは、いきなり本番適用せず、シミュレーションモードで検証します。Microsoft の DLP 展開ガイダンスでは、ポリシーの状態、アクション、スコープを組み合わせて段階的に展開し、最も影響の小さいシミュレーションから完全適用へ進む考え方が示されています。(Microsoft Learn)
シミュレーションモードでは、ポリシーが適用された場合の影響をユーザー業務に影響させずに確認できます。公式ドキュメントでは、シミュレーション結果は別のダッシュボードで確認でき、誤検知を減らすための調整に使えると説明されています。(Microsoft Learn)
検出結果を複数の場所で確認する
オンプレミスDLPの検出結果は、Activity explorer、監査ログ、DLP アラート、スキャナーのローカル CSV レポートで確認します。公式ページでは、監査ログ UI や PowerShell の Search-UnifiedAuditLog で DLP ルール一致を確認できること、ローカルレポートには DLP Mode、DLP Status、DLP Rule Name、DLP Actions、Owner、NTFS 権限などの列が含まれることが示されています。(Microsoft Learn)
検出結果を見るときは、単に「何件検出されたか」ではなく、次の観点で確認します。
| 確認観点 | 見るべき内容 |
|---|---|
| 誤検知 | テストデータ、テンプレート、古いバックアップが大量に一致していないか |
| 権限影響 | 適用時に削除・継承される ACL が業務上妥当か |
| 所有者 | Owner が正しく判定されているか |
| 対象パス | 意図しない共有フォルダーや SharePoint ライブラリが含まれていないか |
| 例外 | 一時保管フォルダー、アーカイブ、システム連携フォルダーをどう扱うか |
失敗しやすいポイント
スキャナーアカウントだけに注目してしまう
オンプレミスDLPでは、スキャナーアカウントの権限とライセンスだけを確認しても不十分です。対象場所にファイルを追加・利用するユーザーにもライセンスが必要です。特に、海外拠点の共有フォルダーや買収企業から引き継いだファイルサーバーでは、利用者の実態とライセンス割り当てが一致していないことがあります。(Microsoft Learn)
ポリシーだけ有効にして、スキャンジョブ側の適用を忘れる
DLP ルールの適用には、DLP ポリシー側だけでなく、コンテンツスキャンジョブ側の設定も関係します。公式の利用シナリオでは、スキャン済みファイルに DLP ルールを強制適用するには、コンテンツスキャンジョブと DLP ポリシーの両方で enforcement を有効にする必要があると説明されています。(Microsoft Learn)
オンプレミスでもポリシーヒントが出ると思い込む
オンプレミス scanner では、クラウドの DLP と同じ感覚でユーザー向けのポリシーヒントを期待すると設計を誤ります。公式ドキュメントでは、オンプレミス scanner では policy tips は利用できないと説明されています。(Microsoft Learn)
そのため、ユーザー教育は別途必要です。たとえば、人事部門の共有フォルダーで隔離やアクセス権変更が発生する前に、「どのようなファイルが対象になるか」「隔離された場合に誰へ連絡するか」を周知しておく必要があります。
差分スキャンの仕様を理解せず、検出漏れと判断する
ポリシーを変更したのに検出件数が増えない場合、DLP が動いていないのではなく、差分スキャンで変更済みファイルだけが評価されている可能性があります。大きなルール変更後は、限定範囲で Start-Scan -Reset を使うなど、再評価の計画を立てます。(Microsoft Learn)
グローバル運用での判断基準
グローバル企業で Microsoft Purview のオンプレミスDLPを展開する場合は、技術設定だけでなく、地域ごとの運用差を吸収する設計が必要です。
| 判断項目 | 推奨される考え方 |
|---|---|
| クラスタ設計 | 地域、ネットワーク、データ所有部門ごとに分けると障害範囲を限定しやすい |
| スケジュール | 業務時間外にスキャンを寄せる。時差があるため UTC だけで管理しない |
| 例外管理 | 各国・各部門で例外申請の窓口を決める |
| レポート | Activity explorer とローカル CSV の両方を使い、中央管理と現地確認を分ける |
| 移行管理 | サポート期限を基準に、地域ごとの更新時期を前倒しで決める |
| 本番適用 | まず監査、次に限定アクション、最後にブロックや隔離へ進む |
特に日付の扱いには注意が必要です。Microsoft のリリース管理ページは月／日／年形式を使うと明記しているため、06/11/2026 は 2026年6月11日です。グローバルの変更管理表へ転記するときは、日本式の日付に変換して誤読を防ぐと安全です。(Microsoft Learn)
管理者が次に取るべき行動
今回の更新を受けて、Microsoft Purview のオンプレミスDLPを使っている、または導入予定の管理者は、まずスキャナーのバージョンとサポート期限を確認してください。旧 AIP 2.x 系や期限切れの 3.x 系を使っている場合は、DLP ポリシーの調整より先に、Microsoft Purview Information Protection client 3.x への移行・更新を計画する必要があります。
次に、対象リポジトリ、サービスアカウント、ライセンス、Purview ロール、コンテンツスキャンジョブを棚卸しします。そのうえで、DLP ポリシーはシミュレーションから開始し、Activity explorer、監査ログ、ローカル CSV レポートで誤検知と業務影響を確認します。オンプレミスDLPは、適切に使えば古いファイルサーバーや SharePoint Server に残る機密データを可視化・保護できますが、設定を急ぐと ACL 変更や隔離による業務影響が出やすい機能です。
まずは「最新サポート内のスキャナー」「限定スコープ」「シミュレーション」「検出結果のレビュー」の4点をそろえ、問題がない範囲から段階的に本番適用へ進めるのが現実的な進め方です。
コメント