Microsoft Purview Data Loss Prevention（DLP）の「File Testing Against Sensitive Information Classifiers」は、DLPポリシーを変更せずに、アップロードしたファイルがどの機密情報分類子に一致するかを確認しやすくする機能です。管理者がまず見るべきポイントは、既存ポリシーへの直接的な変更ではなく、分類テストとDLP設計の事前検証がしやすくなる更新だという点です。
これにより、クレジットカード番号、個人番号、銀行口座、社内独自の社員番号などを含むファイルが、Microsoft Purview上でどの分類子に検出されるかを確認できます。特に、DLPルールを作成する前の検証、カスタムSITの調整、誤検知・未検知の切り分けで役立ちます。Microsoft 365ロードマップはリリース予定や説明が変更される可能性があるため、実運用ではテナント上の表示、Message Center、Microsoft Learnの最新情報を合わせて確認することが重要です。(Microsoft)
Microsoft PurviewのDLPファイルテスト機能とは
今回の更新は、Microsoft Purviewの分類機能において、ファイルを機密情報分類子に対してテストできる機能です。ロードマップID 557554では、メインのClassificationページに新しい機能が追加され、ユーザーが単一の分類子を選ぶ、または利用可能な分類子全体に対してテストを実行できると説明されています。目的は、ファイル内に機密情報が含まれるかを把握し、分類に関するトラブルシューティングを効率化することです。(Microsoft 365 Message Center Archive)
Microsoft Purviewで使われるSensitive Information Types（SIT）は、社会保障番号、クレジットカード番号、銀行口座番号などの機密情報を検出するためのパターンベースの分類子です。Microsoftが用意した既定のSITを利用できるほか、組織独自のカスタムSITも作成できます。SITはDLPポリシー、秘密度ラベル、保持ラベル、インサイダーリスク管理、コミュニケーションコンプライアンス、自動ラベル付けポリシーなどで使われます。(Microsoft Learn)
今回の機能を一言でまとめると、「DLPポリシーを本番展開する前に、ファイルがどの分類子に引っかかるかを確認するための検証機能」です。DLPのブロック、警告、監査、ユーザー通知そのものを置き換える機能ではありません。
何が変わるのか
従来も、Microsoft PurviewではSITのテスト機能を使い、特定の機密情報タイプに対してサンプルファイルをアップロードして検証できました。Microsoft Learnでは、SITのライフサイクル中に動作をテストでき、Microsoft Purviewポータルから対象のSensitive info typeを開いてTestを実行する手順が案内されています。(Microsoft Learn)
今回の更新で実務上大きいのは、個別の分類子だけでなく、利用可能な分類子全体に対してファイルをテストしやすくなる点です。これにより、「このファイルにはどのSITが反応するのか」「DLPルールに使うべき分類子はどれか」「想定外の分類子が一致していないか」を、ポリシー作成前に確認しやすくなります。
| 観点 | これまでの主な確認方法 | 今回の更新で期待できること |
|---|---|---|
| 分類子の選定 | 候補のSITを個別に選んでテスト | 1つのファイルに対して複数分類子の反応を確認しやすい |
| DLP設計 | ポリシー作成後にテスト・調整 | ルール作成前に分類子の当たりを付けやすい |
| 誤検知調査 | カスタムSITや条件を個別に見直す | どの分類子が一致しているかを切り分けやすい |
| 展開前検証 | サンプルファイルを使って限定的に確認 | 業務ファイルに近いサンプルで網羅的に確認しやすい |
ただし、テスト結果で一致が出たからといって、そのままDLPでブロックされるとは限りません。DLPポリシーでは、対象場所、条件、インスタンス数、信頼度、例外、アクション、ユーザー通知、監査設定などが別途影響します。
影響範囲：既存DLPポリシーは基本的に変更不要
この更新は、Microsoft PurviewのDLPおよびデータ分類を扱う管理者・利用者に影響します。公開情報では、Webプラットフォーム、Worldwide Standard Multi-Tenant向けの機能として扱われ、ステータスはLaunched、リリース種別はPreviewおよびGeneral Availabilityとして記録されています。(Microsoft 365 Message Center Archive)
重要なのは、既存のDLPポリシーや分類設定を自動的に変更する機能ではないという点です。Message Center由来の情報では、既存のDLPおよび分類構成はこれまで通り機能し、ポリシー変更は不要とされています。(M365 Admin)
| 対象 | 影響 | 確認すべきこと |
|---|---|---|
| Microsoft Purview管理者 | 分類テストの操作導線が増える | ロール、操作手順、検証用サンプルの準備 |
| セキュリティ・コンプライアンス担当 | DLPルール設計前の根拠を作りやすい | どの分類子をDLP条件に採用するか |
| 情シス・運用担当 | 問い合わせ時の切り分けがしやすい | 「分類されない」「検出されすぎる」原因の調査 |
| 開発者・業務アプリ担当 | 出力ファイルのDLP影響を事前確認しやすい | 帳票、CSV、PDF、ログ出力のサンプル検証 |
| 一般ユーザー | 直接の操作影響は限定的 | DLPポリシー変更時のみ通知やブロックに影響 |
管理者が最初に確認すべき設定
権限は「テストできる人」を絞る
分類テストでは、機密情報を含む可能性のあるファイルをPurviewポータルにアップロードします。そのため、誰でも使える便利機能として開放するのではなく、管理者、情報保護担当、DLP設計担当など、目的が明確なユーザーに限定するのが安全です。
Microsoft Purviewポータルでは、RBACに基づくアクセス許可モデルを使用します。ロールとスコープを使って、データセキュリティ、データガバナンス、リスクとコンプライアンスの各機能に対する権限を管理できます。なお、Purviewポータル内の権限管理だけでは、Exchangeなど各サービス固有の権限まですべて管理できるわけではない点にも注意が必要です。(Microsoft Learn)
実務では、次のように整理すると運用しやすくなります。
| 確認項目 | 推奨対応 |
|---|---|
| テスト実行者 | Information Protection Admins、Compliance Administratorなど、業務上必要な担当者に限定 |
| グローバル管理者の利用 | 日常的な検証では避け、最小権限のロールを使う |
| 外部委託・監査担当 | 必要期間だけ付与し、作業完了後に削除 |
| 管理単位のスコープ | 部門別運用がある場合は、スコープ付き権限を検討 |
| 操作ルール | 本番個人情報をそのまま使わず、検証用データを利用する |
テスト対象ファイルは「本番データそのもの」にしない
分類テストの目的は、機密情報が検出されるかを確認することです。しかし、実在する顧客情報、従業員情報、契約書、医療情報、資格情報などをそのままアップロードすると、検証作業自体がリスクになります。
検証ファイルは、次の条件で準備するのが現実的です。
| サンプル種別 | 例 | 使いどころ |
|---|---|---|
| 陽性サンプル | 架空のカード番号形式、架空の社員番号、ダミー住所 | 検出されるべきファイルの確認 |
| 陰性サンプル | 似た形式だが機密情報ではない文字列 | 誤検知の確認 |
| 業務形式サンプル | 実際の帳票レイアウトに近いPDF、Word、Excel、CSV | 画面・帳票・自動出力の検証 |
| 境界値サンプル | 1件だけ含む、10件含む、キーワードなし、全角混在 | インスタンス数・信頼度の調整 |
Microsoft LearnのSITテスト手順でも、一致する内容を含むファイルと一致しないファイルを用意して比較する流れが示されています。また、SITのテスト手順は暗号化されていないファイルが対象で、1回に1ファイルをアップロードしてテストする手順として説明されています。(Microsoft Learn)
カスタムSITは「検出できるか」より「使える精度か」を見る
カスタムSITを使っている組織では、今回の機能が特に役立ちます。たとえば、社員番号、顧客ID、案件番号、会員番号、社内コードなどは、単純な正規表現だけだと誤検知しやすい典型例です。
よくある失敗は、次のような設計です。
| 失敗例 | 起きる問題 | 改善の方向性 |
|---|---|---|
\d{8} のような広すぎる正規表現 | 日付、請求番号、電話番号の一部まで検出する | 周辺キーワード、チェックサム、接頭辞を追加 |
| キーワードが英語だけ | 日本語帳票で一致しにくい | 日本語・英語・表記ゆれを分けて登録 |
| 信頼度を低くしすぎる | 誤検知が増え、DLPアラートがノイズ化する | 業務上必要な件数や信頼度を調整 |
| 1つのSITに条件を詰め込みすぎる | 原因調査が難しくなる | 用途別にSITを分ける |
| 本番ファイルだけで確認する | 検証の再現性が低い | 陽性・陰性・境界値サンプルを保存する |
SITの信頼度にはHigh、Medium、Lowがあり、Highは誤検知を減らしやすい一方で未検知が増える可能性があります。LowやMediumは検出範囲を広げやすい一方で、誤検知が増えやすくなります。Microsoft Learnでは、信頼度は主要要素に加えて補助要素がどの程度検出されるかを反映すると説明されています。(Microsoft Learn)
日本語圏の環境では、全角・半角、スペース有無、英数字混在、部署ごとの略称、旧字体、ハイフンの種類なども見落としやすいポイントです。たとえば「機密 document」と「機密document」の両方が業務文書に出るなら、両方をテスト対象に含めるべきです。
DLPポリシーのテストとは分けて考える
今回のファイルテスト機能は、分類子の反応を見るための機能です。一方、DLPポリシーのテストは、実際のポリシー条件、対象場所、アクション、通知、例外、監査ログまで含めて確認する作業です。
Microsoft Learnでも、DLPポリシーの展開ではテストと調整を行うべきだと説明されています。つまり、分類子のテストで「検出される」ことを確認した後に、DLPポリシー側で「期待した動作になる」ことを別途確認する必要があります。(Microsoft Learn)
| 確認したいこと | 使うべき機能 |
|---|---|
| ファイル内のどの機密情報分類子が一致するか | 分類子に対するファイルテスト |
| カスタムSITの正規表現やキーワードが効くか | SITテスト、分類子テスト |
| DLPポリシーで警告・ブロックされるか | DLPポリシーのテスト、シミュレーション |
| 実環境でどのファイルが分類されているか | Data Explorer、Content Explorer、Activity Explorerなど |
| 既存データを再分類したいか | On-demand classificationなど |
特にSharePoint、OneDrive、Teams、Exchange、Endpoint DLPをまたぐ環境では、分類子の一致だけで判断すると誤ります。DLPの対象場所が違えば動作も変わりますし、同じSITを使っていても、ポリシーのアクションや例外条件によってユーザー体験は大きく変わります。
展開時の実務チェックリスト
今回の更新で大規模な移行作業は基本的に想定しにくいものの、管理者は「自動的に利用可能になるから何もしない」で終わらせるべきではありません。分類テスト機能は、DLP設計の品質を上げるための道具として組み込むと効果が出ます。
展開前に確認すること
| チェック項目 | 具体的な確認内容 |
|---|---|
| 機能の表示 | Microsoft PurviewポータルのClassification関連ページでテスト機能が表示されるか |
| 権限 | 誰がテストできるか、過剰な管理者権限を使っていないか |
| 対象分類子 | 既定SIT、カスタムSIT、EDM、必要な分類子が見えるか |
| サンプルファイル | 陽性・陰性・境界値の検証ファイルがあるか |
| DLPルール | テスト結果をどのDLP条件に反映するか |
| 記録方法 | テスト結果、採用した分類子、除外理由を残すか |
| 問い合わせ導線 | 「検出されない」「誤検知が多い」場合の調査担当が決まっているか |
開発者が確認すべきこと
開発者にとって重要なのは、Purview側の機能追加そのものよりも、自分たちのアプリや業務システムが出力するファイルがDLPにどう見えるかです。
たとえば、次のようなファイルを生成している場合は、管理者と連携してサンプルテストを行う価値があります。
- 顧客情報を含むCSVエクスポート
- 請求書、見積書、契約書のPDF
- 問い合わせ履歴やサポートログ
- 社員情報を含むExcel帳票
- Power Automateやバッチ処理で自動生成されるファイル
- 監査用に保存される添付ファイル
開発側でよくある見落としは、画面上ではマスクしているのに、エクスポートファイルではフルデータを出しているケースです。DLPはユーザーの画面表示ではなく、ファイル内容に基づいて検出されるため、帳票・CSV・PDFの実体を確認する必要があります。
また、DLPに引っかからないようにデータを不自然に分割する運用は避けるべきです。セキュリティ管理を回避するのではなく、不要な個人情報を出力しない、最小限の項目だけ含める、目的に応じてマスキングする、といった設計に寄せる方が安全です。
失敗しやすいポイント
「一致した分類子＝DLPブロック」と誤解する
分類子テストで一致が出ても、DLPポリシーが存在しない、対象場所に適用されていない、インスタンス数が条件を満たさない、例外に該当する、といった場合はブロックされません。
対応としては、分類子テストの結果をDLP設計メモに残し、その後にDLPポリシー側でテストします。分類子の検出確認とポリシー動作確認を同じ作業として扱わないことが大切です。
全分類子テストの結果をそのまま採用する
全分類子に対するテストは、候補を洗い出すには便利です。しかし、検出された分類子をそのままDLPルールに入れると、誤検知が増える可能性があります。
たとえば、顧客番号のような数字列が、別の国のID番号や汎用的な数値パターンに一致することがあります。この場合は、業務文書の文脈、周辺キーワード、信頼度、検出件数を見て、採用する分類子を絞り込みます。
カスタムSITを作ったまま放置する
組織独自のSITは、業務変更に弱い部分があります。社員番号の桁数変更、顧客ID体系の変更、帳票テンプレートの変更、システム移行による表記変更が起きると、以前は正しく検出できていたSITが急に使いにくくなることがあります。
今回の機能は、既存のカスタムSITを棚卸しするきっかけとしても使えます。特に、DLPアラートが多すぎるSIT、ほとんど検出されないSIT、作成者が不明なSITは優先的に見直すべきです。
日本語・全角文字の表記ゆれを軽視する
日本語文書では、半角英数字だけでなく、全角数字、全角ハイフン、読点、スペース、括弧、部署独自の略語が混在します。英語圏のサンプルだけで検証すると、日本語の実ファイルで未検知が起きやすくなります。
検証ファイルには、実際の業務文書に近い日本語の見出し、注記、表形式、改行、PDF化後の文字列などを含めると、より実態に近い結果を得られます。
管理者が取るべき次の行動
まず、Microsoft Purviewポータルで対象テナントに機能が表示されるか確認します。次に、テスト実行者の権限を確認し、過剰な管理者権限で日常運用しないようにします。そのうえで、既存のDLPルールに使っているSIT、カスタムSIT、業務上重要なファイル形式を洗い出し、陽性・陰性・境界値のサンプルを作成します。
優先順位は、次の順番がおすすめです。
| 優先度 | 対応 |
|---|---|
| 高 | 個人情報、決済情報、資格情報、契約情報を含むファイルを検証 |
| 高 | 既存DLPポリシーで誤検知・未検知が多いSITを見直す |
| 中 | カスタムSITの正規表現、キーワード、信頼度を調整 |
| 中 | 業務システムが出力するCSV、PDF、Excelをテスト |
| 低 | 使用頻度の低いSITや古い検証ファイルを整理 |
今回のMicrosoft Purview Data Loss Preventionのファイルテスト機能は、DLPの「最後のブロック機能」ではなく、DLPを正しく設計するための「事前診断機能」として使うと効果的です。管理者は、分類子の一致結果をもとにDLPポリシーを調整し、開発者は自分たちの出力ファイルがどのように分類されるかを確認することで、情報漏えい対策を後追いではなく設計段階から組み込めます。
コメント