Microsoft Purview DLPの条件を変更する際は、既存の本番ポリシーを直接編集せず、本番ポリシーのコピーをシミュレーションモードで評価してから切り替えるのが安全です。
シミュレーションモードでは、ポリシーを本番適用した場合に一致する項目やアラートを確認できますが、設定したブロックなどの強制アクションは実行されません。Microsoftも、稼働中のポリシーを複製して変更版をシミュレーションし、問題がなければ旧版を停止して新版を有効化する運用を例示しています。([Microsoft Learn][1])
ただし、シミュレーション中にポリシーヒントを表示する設定を選ぶと、ブロックはされなくても利用者に通知が表示されます。最初は通知なしで一致状況を調べ、その後、限定した利用者に通知ありで試すという二段階の確認が適しています。([Microsoft Learn][2])
Purview DLPの条件変更は本番ポリシーを直接編集しない
稼働中のDLPポリシーを直接編集すると、変更内容が想定以上に広く一致した場合、メール送信、ファイル共有、端末からのデータ転送など、正当な業務まで止める可能性があります。
安全に確認するには、次の構成にします。
| 方法 | 業務への影響 | 変更前との比較 | 元に戻しやすさ |
|---|---|---|---|
| 本番ポリシーを直接変更 | 変更後の条件が強制適用される | 変更前後の結果を分けにくい | 設定を正確に戻す必要がある |
| 本番ポリシーを停止して試す | 保護されない時間が発生する | 比較はできるが保護に空白が生じる | 旧ポリシーの再有効化が必要 |
| 本番ポリシーを複製してシミュレーション | 強制アクションによる業務停止を避けられる | 旧版と新版を明確に分けられる | 試験版を停止すればよい |
Microsoftの公式例でも、本番稼働中の「v1」をコピーして「v2」を作成し、v2をシミュレーションモードで調整した後、v1を停止してv2を強制適用する流れが示されています。([Microsoft Learn][1])
シミュレーション前に整理する項目
シミュレーションは、ポリシーを動かすだけでは十分ではありません。先に「何が一致すれば正しく、何が一致したら誤検知なのか」を定義しておかないと、結果を見ても判断できないためです。
変更目的を一文で決める
最初に、変更目的を次のような形式で一文にします。
どの利用者が、どの場所で、どの種類の情報を、どのように扱った場合に、何を制限するのか。
たとえば、「社外宛てのメールに一定件数以上の機密情報が含まれる場合は送信を制限する。ただし、承認済みの業務フローは対象外とする」といった形です。
「情報漏えいを防ぐ」のような抽象的な目的では、シミュレーション結果を合格・不合格に分けられません。
現行設定と変更後設定の差分を記録する
試験用ポリシーを作る前に、少なくとも次の項目を変更票へ記録します。
| 確認項目 | 現行ポリシー | 試験用ポリシー | 確認したいこと |
|---|---|---|---|
| 対象場所 | Exchange、SharePointなど | 変更後の対象場所 | 意図しない場所が含まれていないか |
| 対象者・対象範囲 | 全員、特定グループなど | 変更後の範囲 | 対象外にすべき利用者が含まれないか |
| 機密情報の条件 | 情報の種類、件数、信頼度など | 変更する条件 | 条件が広すぎないか |
| 例外 | 除外対象あり・なし | 追加・削除する例外 | 例外が広すぎないか |
| 実行するアクション | 監査、上書き可能なブロック、ブロックなど | 本番で予定するアクション | 正当な業務を止めないか |
| 通知・アラート | 現行設定 | 変更後の設定 | 利用者や管理者への通知が過剰でないか |
変更箇所を増やしすぎると、どの設定が誤検知の原因なのか分からなくなります。最初の試験では、必要な変更だけを加えるのが基本です。
本番ポリシーと試験用ポリシーを区別する
ポリシー名には、用途と状態が分かる情報を付けます。
CustomerData-v1-ProductionCustomerData-v2-Simulation-202609
日付や版番号を付けておけば、管理画面や変更記録で旧版と新版を取り違えにくくなります。
旧版は、新版の本番切り替えが完了するまで削除しません。設定を戻す必要が生じた場合に、旧版をそのまま再利用できるようにするためです。
Purview DLPをシミュレーションモードで評価する手順
シミュレーションモードを操作するアカウントには、必要なライセンスと権限が必要です。Microsoftの開始手順では、シミュレーションモードを操作するアカウントについて、Information Protection管理者ロールが案内されています。([Microsoft Learn][3])
本番ポリシーをもとに試験用ポリシーを作る
最初に、現在稼働しているポリシーの設定を保存し、その設定をもとに試験用ポリシーを作成します。
この段階では、次の状態にします。
- 現行ポリシーは本番稼働を継続する
- 試験用ポリシーだけに変更予定の条件を設定する
- 試験用ポリシーはまだ強制適用しない
- 旧版と新版の差分を変更票に残す
現行ポリシーを先に停止すると、試験中にDLPの保護が働かない空白期間が生じます。
試験用ポリシーをシミュレーションモードにする
Microsoft Purviewポータルのデータ損失防止ポリシーから試験用ポリシーを開き、ポリシー設定の最後にあるシミュレーションまたは有効化に関する設定で、シミュレーションモードを選択します。
現在のMicrosoft Learnでは、ポリシー作成または編集時に「Run the policy in simulation mode」を選択し、送信後にシミュレーションを開始する手順が案内されています。管理画面の日本語表記は、テナントや更新時期によって異なる場合があります。([Microsoft Learn][3])
初回の確認では、次の設定が安全です。
- シミュレーションモードを選択する
- ポリシーヒントは表示しない
- 一定期間後に自動で本番有効化する設定は選ばない
- 試験用ポリシーであることを名前と変更記録に明記する
Microsoft Purviewには、シミュレーション開始後、一定期間編集されなければポリシーを自動的に有効化する選択肢があります。承認前のポリシーが意図せず本番適用されないよう、自動有効化の設定は特に注意して確認します。([Microsoft Learn][3])
シミュレーション結果を開く
シミュレーション中のポリシーは、Microsoft Purviewポータルの次の場所から確認できます。
データ損失防止 > ポリシー > シミュレーション中のポリシー > シミュレーションの表示
シミュレーション結果は、主に次の3つの画面で確認します。([Microsoft Learn][1])
| 確認画面 | 分かること | 主な確認ポイント |
|---|---|---|
| シミュレーションの概要 | 実行状態、スキャン状況、スキャン件数、一致件数、場所別の一致 | 対象場所が正しいか、結果が十分に収集されているか |
| 確認対象の項目 | ポリシーに一致した項目とメタデータ | なぜ一致したか、業務上許容すべき項目か |
| アラート | シミュレーションによって生成されたアラート | 発生件数、重要度、管理者が対応できる量か |
シミュレーション中のアラートは、通常のDLPアラートコンソールやMicrosoft Defenderポータルには表示されず、シミュレーション専用のアラート画面に表示されます。普段Defenderだけを監視している運用では見落とすため、確認担当者と確認場所を事前に決めておく必要があります。([Microsoft Learn][1])
一致した項目を正当な業務と制限対象に分ける
一致件数の多さだけでは、ポリシーが正しいかどうかは判断できません。一致した項目を一件ずつ業務上の意味で分類します。
基本的には、次の3種類に分けます。
- 意図した一致：本番でも制限または警告したい操作
- 正当な業務の一致：ポリシーには一致したが、本番では許可したい操作
- 判断保留：業務担当者の確認がなければ許可・制限を決められない操作
判定記録の記入例
次の表は、判定方法を説明するための架空の例です。実際のシミュレーション結果ではありません。
| 業務場面 | 本来の扱い | シミュレーション上の一致 | 判定 | 次の対応 |
|---|---|---|---|---|
| 承認済みの取引先へ定例資料を送信 | 許可したい | 一致した | 誤検知候補 | 一致理由を確認し、必要なら条件や対象範囲を限定する |
| 顧客情報を未承認の保存先へ転送 | 制限したい | 一致した | 意図した一致 | 現在の条件を維持する |
| テスト用の文字列を含む研修資料 | 許可したい | 一致した | 誤検知候補 | 件数や信頼度などの検出条件を見直す |
| 機密資料を社外共有したが一致しない | 制限したい | 一致しない | 検出漏れ | 条件、対象場所、対象者の設定を確認する |
誤検知だけでなく、本来止めたい操作が一致していない検出漏れも確認することが重要です。
誤検知が出たときの修正順序
正当な業務が一致した場合、すぐに大きな例外を追加するのは避けます。広い例外を追加すると、正当な業務だけでなく、本来制限すべき操作まで除外される可能性があるためです。
次の順序で原因を確認すると、必要以上にポリシーを弱めずに調整できます。
対象範囲を確認する
最初に、ポリシーを適用する場所、利用者、グループ、サイト、アカウントなどが広すぎないか確認します。
たとえば、特定部門だけを対象にする予定だったにもかかわらず、全利用者が対象になっていれば、検出条件を変更する前に対象範囲を修正すべきです。
検出条件の組み合わせを確認する
一つの機密情報の種類だけで一致させている場合は、件数、信頼度、別の条件との組み合わせが必要かを検討します。
ただし、条件を厳しくしすぎると検出漏れが増えます。誤検知を減らす調整と、必要な検出を維持する確認を同時に行います。
例外はできるだけ狭くする
例外を設ける場合は、次のような広すぎる指定を避けます。
- 部門全体を無条件に除外する
- 特定の場所をすべて除外する
- すべての社外共有を許可する
- 特定条件に一致すれば内容に関係なく除外する
例外には、対象となる業務、責任者、必要な期間、見直し日を記録します。
ブロック以外の段階的な適用も検討する
Microsoftは、ポリシーの展開を「状態」「対象範囲」「アクション」の3方向で段階的に進める方法を案内しています。
シミュレーションの次に、限定したパイロット利用者へポリシーヒントを表示し、その後、必要に応じて上書き可能な制限や完全なブロックへ進める方法です。([Microsoft Learn][2])
一度に全利用者へ完全なブロックを適用するより、次の順序の方が問題を発見しやすくなります。
- 通知なしのシミュレーション
- パイロット利用者へのポリシーヒント
- 必要に応じて上書き可能な制限
- 本番範囲への強制適用
少数の一致だけで安全と判断しない
一致件数が少なかったとしても、ポリシーが安全とは限りません。
次のような理由で、十分な検証結果が集まっていない可能性があります。
- シミュレーション期間中に対象業務が発生していない
- 月末、年度末、請求日など特定日にしか発生しない
- 一部の部門や拠点しか対象になっていない
- ExchangeやTeamsでは過去のデータが評価されていない
- 確認画面に表示された一部の項目だけを見て判断している
- 本来検出すべき操作そのものを試していない
本番移行の可否は、件数ではなく、次の条件で判断します。
| 合格条件 | 確認内容 |
|---|---|
| 制限対象を検出できる | 本来止めたい代表的な操作が一致している |
| 正当な業務を確認できる | 日常業務、定例業務、例外的な業務を確認している |
| 誤検知の理由を説明できる | どの条件で一致したかを特定できている |
| 例外が限定されている | 除外範囲が必要以上に広くない |
| 管理可能なアラート量である | 担当者が確認・対応できる件数になっている |
| 業務担当者が承認している | 管理者だけでなく対象業務の責任者が確認している |
場所によってシミュレーションの評価範囲が異なる
Purview DLPのシミュレーションは、すべての場所で過去の全データを同じように再検査する機能ではありません。
| 対象場所 | 主な評価対象 | 結果を見るときの注意点 |
|---|---|---|
| SharePoint、OneDrive | 既存の項目と、新規または変更された項目 | 過去に保存されたデータも一致する可能性がある |
| Exchange | シミュレーション中に新しく送信される項目 | 過去のメール全体を再評価した結果ではない |
| Teams | シミュレーション中に新しく送信されるメッセージ | 期間中に対象業務が発生しなければ結果が少なくなる |
| Devices | シミュレーション中に発生する対象操作 | 過去の端末操作を遡ってすべて評価するものではない |
| Fabric関連 | 開始後に更新または再読み込みされた対象 | 更新されていない項目は評価対象にならない場合がある |
Microsoft Learnでは、SharePointとOneDriveについて既存および新規・変更項目が評価される一方、Exchange、Teams、Devicesでは、シミュレーション中に新しく発生した項目が評価されると説明されています。([Microsoft Learn][1])
また、SharePointとOneDriveでは、確認対象の項目として表示される件数と、全体の一致件数が異なる場合があります。現在の開始手順では、確認用に表示される一致項目は最初の100件までとされているため、表示された一覧だけで全体を判断しないようにします。([Microsoft Learn][3])
シミュレーション期間と結果保持の注意点
シミュレーション期間については、Microsoft Learnの公式ページ間で説明が異なります。
シミュレーションモードの概要ページでは、実行期間は最大15日、結果は30日間保持されると説明されています。一方、現在の開始手順ページでは、シミュレーションを30日より長く継続することもできるものの、表示されるのは直近30日間の結果と説明されています。([Microsoft Learn][1])
さらに、15日間編集されなかった場合にポリシーを自動的に有効化する設定もあります。([Microsoft Learn][3])
運用上は、次のように扱うと安全です。
- 15日以内を一つの評価単位にする
- 開始日、確認日、終了予定日を変更票に記録する
- 自動有効化の設定を確認する
- 30日を超える結果が必要なら、保持範囲を意識して再評価する
- 実際のテナントに表示される選択肢を切り替え前に確認する
長期間シミュレーションを放置すると、どの設定変更による結果なのか分かりにくくなります。一定期間ごとに結果を確定し、条件を変更した場合は新しい評価単位として記録する方が管理しやすくなります。
本番への切り替え計画を作る
シミュレーションで問題が見つからなかったとしても、そのまま担当者一人の判断で本番へ切り替えるのは避けます。
少なくとも次の承認を得ます。
- DLPまたは情報保護の管理責任者
- 対象業務の責任者
- セキュリティ監視の担当者
- 問い合わせを受けるヘルプデスク
- 必要に応じて法務、個人情報保護、内部監査の担当者
旧版と新版の切り替え順序を決める
旧版と新版を個別に操作する場合、完全に同時の切り替えを前提にしない方が安全です。
一般的には、保護されない空白を避けるため、次の順序を検討します。
- 新版を本番有効化する
- 新版の状態を確認する
- 旧版を速やかに停止する
- 本番のアラートとアクティビティを監視する
この順序では、短時間だけ旧版と新版が重複する可能性があります。重複による通知や判定が業務へ大きな影響を与える場合は、利用の少ない時間帯に切り替え、停止と有効化の順序、確認担当者、戻し方を事前に決めます。
重要なのは、「旧版を先に削除してから新版を準備する」「切り替え順序を当日に考える」といった運用を避けることです。
Microsoftは、本番有効化後にDLPアラートとアクティビティエクスプローラーを監視し、発生した問題へ対応する展開手順を案内しています。([Microsoft Learn][2])
問題が起きた場合の戻し方を決める
本番切り替え前に、ロールバック条件を明確にします。
たとえば、次のいずれかが発生した場合は、旧版へ戻すと決めておきます。
- 基幹業務のメールや共有が想定外に止まった
- 本来許可する操作が複数部門でブロックされた
- アラートが管理可能な量を大きく超えた
- 本来制限する操作が許可された
- 対象外の利用者や場所へポリシーが適用された
- ヘルプデスクで原因を説明できない問い合わせが続いた
ロールバック手順は、次のように簡潔にしておきます。
- 新版ポリシーを停止する
- 旧版ポリシーを再有効化する
- 影響を受けた業務と利用者を記録する
- 新版の一致条件と対象範囲を修正する
- 修正版を再びシミュレーションモードで評価する
DLPポリシーの状態は後から変更できるため、旧版を残しておけば、問題発生時に元の構成へ戻しやすくなります。([Microsoft Learn][2])
本番移行前の確認チェックリスト
シミュレーション開始前
- 現行ポリシーの設定を記録した
- 変更目的を一文で説明できる
- 現行設定と変更後設定の差分を整理した
- 本番ポリシーとは別に試験用ポリシーを用意した
- 試験用ポリシーの名前に版番号や用途を付けた
- 初回はポリシーヒントを表示しない設定にした
- 自動的な本番有効化が選択されていないことを確認した
- 結果を確認する担当者を決めた
シミュレーション中
- 対象場所ごとのスキャン状態を確認した
- 一致項目を意図した一致、誤検知、判断保留に分類した
- 本来止めたい操作が一致していることを確認した
- 正当な業務の代表例を確認した
- Exchange、Teams、Devicesでは新しい操作が評価対象であることを考慮した
- 表示された一部の一致だけで全体を判断していない
- 条件変更後に再評価した
本番切り替え前
- 業務責任者の承認を得た
- 旧版と新版の切り替え順序を決めた
- 切り替え日時と担当者を決めた
- ロールバック条件を決めた
- 旧版ポリシーを残している
- 切り替え後の監視担当者を決めた
- ヘルプデスクへ変更内容を共有した
まとめ
Purview DLPの条件変更で正当な業務を止めないためには、本番ポリシーを直接編集せず、コピーをシミュレーションモードで評価することが基本です。
シミュレーション結果では、一致件数だけを見るのではなく、個々の一致を「止めたい操作」「許可したい業務」「判断が必要な操作」に分けます。対象場所によって評価されるデータの範囲が異なるため、少数の一致だけで安全と判断してはいけません。
まず実施すべきことは、現行ポリシーと変更後ポリシーの差分表を作り、試験用のコピーを通知なしのシミュレーションモードで開始することです。結果を業務担当者と確認し、必要な調整と再評価を終えてから、切り替え順序とロールバック手順を決めて本番へ移行します。
[1]: https://learn.microsoft.com/en-us/purview/dlp-simulation-mode-learn “Learn about data loss prevention simulation mode | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/purview/dlp-create-deploy-policy “Create and deploy a data loss prevention policy | Microsoft Learn”
[3]: https://learn.microsoft.com/en-us/purview/dlp-simulation-mode-get-started “Get started with data loss prevention simulation mode | Microsoft Learn”
コメント