Microsoft Purview のDLPで、SharePoint/OneDriveの「外部共有を原則禁止」にしつつ、外部デザイナーとの共同作業だけは安全に許可したい──そんな運用でつまずきやすいのが「例外」の作り方です。本記事では、スコープとルール条件の2層で例外を設計し、ホワイトリスト運用や期限付き例外まで落とし込む手順を解説します。
やりたいことを分解すると「禁止」と「例外」の両立
「社内のグラフィックデザイン用ファイルは、原則として外部共有を禁止したい。しかし、外部デザイナーと協業するプロジェクトでは、特定の担当者や特定ドメインに限って共有を許可したい」――この要件はよくあります。
ここで重要なのは、禁止だけなら設定は簡単でも、例外を“運用できる形”で作ろうとすると難易度が上がる点です。毎回ポリシー本文を編集して例外を足し引きするやり方は、事故の温床になりがちです。
- 例外を追加したつもりが、別のワークロードまで緩めてしまった
- プロジェクト終了後、例外メンバーを戻し忘れて「永続例外」になった
- ポリシーが増え、スコープ用グループと例外用グループが乱立して追えなくなった
この記事では、Purview DLPの機能として可能な「例外（除外）」の作り方を整理したうえで、現場で回るホワイトリスト運用・期限付き運用まで含めて設計します。
前提：外部共有の制御は1つの設定だけで完結しない
Purview DLPだけで全てを片付けようとすると、運用が重くなったり、意図しない抜け道が残ったりします。実務では、次のように“レイヤー分け”して考えると整理しやすくなります。
| レイヤー | 主な役割 | 得意なこと | 注意点 |
|---|---|---|---|
| SharePoint / OneDrive の共有設定 | 外部共有の土台（許可/禁止、ゲスト共有、匿名リンクなど） | テナント全体・サイト単位で「外部共有の形」を統制しやすい | ファイルの中身（デザインファイルだけ等）での細分化は苦手 |
| 感度ラベル（秘密度ラベル） | ファイルの機密度を明示し、保護/共有制御と連動させる | ユーザー教育と相性が良く、「これは社外NG」と伝えやすい | ラベル付け運用が回らないと形骸化しやすい |
| Microsoft Purview DLP | 「共有しようとした瞬間」を検知し、ブロック/警告/監査する | 条件（データ種別、ラベル、共有先、ユーザーなど）で柔軟に制御できる | 例外設計が雑だと、ポリシーが複雑化して保守が難しくなる |
本記事の主役はDLPですが、後半では「許可ドメイン一覧をDLPに埋め込み過ぎない」など、運用が破綻しにくい組み合わせ方も紹介します。
最初に決める：何を「デザインファイル」とみなすか
Purview DLPで外部共有を抑える前に、まず「何をデザインファイルとして保護対象にするか」を定義します。ここが曖昧だと、誤検知（業務が止まる）か、取りこぼし（漏えいする）のどちらかに寄ります。
| 判定アプローチ | 例 | メリット | デメリット |
|---|---|---|---|
| 場所で判定 | 「Design」サイト/ライブラリ配下のファイルを対象 | 最も分かりやすく、誤検知が少ない | 置き場所を守らないと漏れる（ルール運用が必要） |
| 感度ラベルで判定 | Design-Confidential など | 人に説明しやすく、例外もラベル単位で設計できる | ラベル付けの教育/自動ラベルが必要 |
| 拡張子/ファイル種別で判定 | .psd / .ai / .fig / .xd など | 「デザインツール固有ファイル」を狙い撃ちできる | 利用環境によって条件の作り方が変わるため、必ずテストが必要 |
| メタデータ/キーワードで判定 | ライブラリ列、ファイル名規則、プロジェクトコードなど | 現場の運用に合わせて細かく調整できる | ルールが複雑になりやすい |
おすすめは、「場所」または「感度ラベル」を軸にし、必要に応じて拡張子などを足す設計です。特に外部協業があるなら、次のように“場所を分ける”だけで例外運用が劇的に楽になります。
オリジナル提案：外部協業用サイト/ライブラリを分離すると例外が減る
「例外グループに入れると永続例外になりそう」「例外が増えて怖い」という場合、人で例外を作る前に、場所で切り分けるのが効果的です。
- 社内完結のデザイン資産：Design-Internal（外部共有は原則禁止）
- 外部協業が必要なプロジェクト：Design-Collab（共有設定は厳格にしつつ、許可ドメインだけに限定）
この形にすると、「外部共有が必要な担当者」を全社的な例外グループに入れ続ける必要がなくなります。プロジェクトのファイルがDesign-Collabにある間だけ共有が可能、という“場所のガードレール”が作れるためです。
| 例外の作り方 | メリット | デメリット | 向いている組織 |
|---|---|---|---|
| 人（例外グループ）で制御 | 場所を変えずに対応でき、柔軟 | 永続例外になりやすい。人の追加・削除が増える | 協業が頻繁で、担当者が明確に固定される |
| 場所（外部協業サイト）で制御 | 例外が少なくなり、監査もしやすい | 置き場所ルールが必要。既存運用の変更が伴う | プロジェクト単位で作業場所を作れる、管理統制を強めたい |
どちらが正解というより、「例外を増やさない設計（場所）」＋「最後の逃げ道（人の例外）」を組み合わせるのが堅牢です。
結論：Purview DLPの例外は2つのレイヤーで作れる
「DLPポリシー内に除外設定が見当たらない」と感じる理由は、DLPの例外が“独立したメニュー”として目立つ場所にあるとは限らず、スコープとルール条件の2層に分かれているためです。
| 例外を作る場所 | 何を除外できるか | 向いているケース | 向いていないケース |
|---|---|---|---|
| ポリシーの「適用範囲（スコープ）」 | 場所（サイト/アカウント/メールボックス等）や対象（ユーザー/グループ） | 「このサイトだけDLP対象外」「この役員OneDriveは別ポリシー」など、対象の切り分け | 「同じサイト内でも、特定の共有先ドメインだけ許可」など細かな条件分岐 |
| ルールの「条件」 | 共有の状況やユーザー/グループ、共有先ドメインなどの条件 | 「外部共有は原則ブロック。ただし特定グループ/特定ドメインは許可」 | ポリシーの設計が整理されていないと、条件が増えて読めなくなる |
柔軟さを優先するなら、基本はルール条件で例外（NOT/除外条件）を作るのが扱いやすいです。スコープ除外は「適用対象の整理」に使い、例外はルールで表現する、と役割分担すると破綻しにくくなります。
おすすめ設計：例外を“ポリシー編集なし”で運用するための型
「毎回DLPポリシーそのものを書き換えずに、ホワイトリスト用グループや許可ドメイン一覧で管理したい」という要望に対して、よく効く設計の型は次の3点です。
- 例外は“担当者（共有する側）”のグループで管理し、メンバー変更だけで運用する
- 許可ドメインは“集中管理できる場所”に寄せる（必要に応じてDLP条件にも入れる）
- ワークロードは分割（SharePoint/OneDrive/Exchangeなど）し、例外の意味をブレさせない
設計例（ロジック）
デザインファイル（例：.psd/.ai/.fig など）や「デザイン機密」ラベルのファイルが、SharePoint/OneDriveから外部共有されそうになったらブロック。ただし例外として、協業プロジェクト担当者グループが、許可されたパートナードメインに共有する場合だけ許可、という形です。
| 条件 | 例 | 狙い |
|---|---|---|
| 保護したい対象 | 場所（Design-Internal配下）、または感度ラベル（Design-Confidential）、必要なら拡張子条件 | 「何を守るか」を明確にし、他の業務ファイルまで巻き込まない |
| トリガー（何が起きたら） | 外部ユーザーへの共有、外部ドメインへの共有、外部向けリンクの作成 | “共有の瞬間”を抑える |
| 例外（許可する条件） | 共有者が例外グループのメンバー AND 共有先ドメインが許可リスト | 例外を最小化し、誤共有の余地を減らす |
この「例外＝担当者グループ」という形にすると、プロジェクトの開始・終了に合わせてグループメンバーを変えるだけで済み、DLPポリシー自体は固定化できます。
手順イメージ：ルール条件で例外（除外）を作る
Purview DLPでは、ルールの条件グループを使って例外を表現できます。UI上の文言は環境や更新で多少変わることがありますが、考え方は同じです。
- Microsoft Purview ポータルで ［データ損失防止（DLP）］ を開き、対象のDLPポリシーを選びます。
- 外部共有を制御している ルール を開き、編集画面へ進みます。
- ［条件（Conditions）］ セクションで 「グループを追加（Add group）」 を選択します。
- 追加した条件グループの先頭にある 「NOT」（または「Except if／除外」相当）のトグルをオンにします。
これで「この条件に当てはまる場合はルールの対象外（＝例外）」という意味になります。 - 「条件を追加（Add condition）」から、例外にしたい条件を選びます。
例外条件としてよく使うのは、次のようなパターンです。
| 例外条件の例 | 使いどころ | 運用のコツ |
|---|---|---|
| 共有者（送信者）が特定グループのメンバー | 「この担当者だけ外部共有を許可」 | 例外グループは1つに寄せ、ポリシーごとに乱立させない |
| 共有先のドメインが特定ドメイン | 「この協業先ドメインだけ許可」 | ドメインは増えやすいので、集中管理できる場所に寄せる |
| 特定ユーザーが共有した場合 | 一時的に例外を付けたい、役職者など | “恒久例外”になりやすいので期限付き運用とセットにする |
アクション（ブロック/制限）設定を具体的にイメージする
SharePoint/OneDrive向けDLPでは、「外部共有を試みたときに何を起こすか」をアクションで決めます。代表的な方向性は次の通りです。
- 外部共有をブロック：外部ユーザーへの共有・リンク作成を止める（利用者にはブロック理由を表示）
- アクセスを制限：万一共有が成立しても、組織外ユーザーが開けないように制限する
- 通知と監査：管理者へアラート/インシデントレポートを送る、監査ログに残す
- テストから段階的に：最初は監査/通知中心→誤検知を潰してからブロックへ
「止める」だけでなく「痕跡を残す」まで含めると、例外運用のレビューがしやすくなります。
例外条件の組み立て方（現場で事故りにくい順）
- 最も安全：「例外グループ」＋「許可ドメイン」の両方を満たすときだけ例外
- 次点：「例外グループ」だけで例外（共有先のドメインは別レイヤーで縛る）
- 非推奨：「許可ドメイン」だけで例外（担当者の誤操作で外に出る余地が大きい）
例外を増やすほど守りが薄くなります。例外条件は“積”で絞る（ANDで狭める）ほど安全です。
スコープ（適用範囲）で除外するべきケース
ルール条件の例外は強力ですが、スコープ除外が適しているケースもあります。特に、対象の場所や担当部門が明確に分かれている場合は、スコープで整理しておくとルールが読みやすくなります。
- デザイン部門専用のSharePointサイトだけをDLP対象にしたい（他部門サイトは別ポリシー）
- 検証用サイトや研修用テナント相当の場所は、運用上DLP対象外にしたい
- 特定のOneDriveアカウントだけ別の厳格なポリシーで管理したい
スコープの判断基準はシンプルで、「場所が違えば例外ではなく“別ルール（別ポリシー）”」です。場所が同じなのに人や共有先で分岐する場合は、スコープではなくルール条件で表現したほうが運用しやすくなります。
ワークロード別にポリシーを分けると、例外が管理しやすい
「複数ワークロード向けに5つ以上のポリシーがあり、スコープ用グループと例外用グループで構成が複雑」という悩みは、ワークロードと例外の意味が混ざってしまうと起きがちです。
おすすめは、次のように“境界”を先に決めることです。
| 分け方 | 例 | メリット |
|---|---|---|
| ワークロード別 | SharePoint/OneDrive用、Exchange用、Teams用 | 使える条件・アクションが分かれ、トラブルシュートしやすい |
| データ種別別 | デザインファイル、個人情報、契約書 | 「守る理由」が明確で、社内説明がしやすい |
| 対象部門別 | デザイン部門、営業部門 | 責任分界（運用担当）を分けやすい |
特に外部共有の制御はSharePoint/OneDrive側の影響も受けやすいため、まずはSharePoint/OneDrive向けのDLPを独立させ、そこで例外の作法（グループ運用、期限付与）を固めるのが現実的です。
ホワイトリスト運用を回すための「グループ設計」
例外をDLPポリシーにベタ書きすると、ポリシー編集が頻発し監査がつらくなります。そこで、例外はグループで受け、グループのメンバーシップだけを変える運用に寄せます。
おすすめの命名規則（例）
| 用途 | グループ名例 | 入れる人 | 備考 |
|---|---|---|---|
| 外部共有を許可する担当者 | DLP-Design-ExternalShare-Allow | 社内の共有実行者（PM/デザイナー等） | 「永続例外」を防ぐため、期限付き運用を前提にする |
| 検証・運用担当 | DLP-Admin-PolicyTest | セキュリティ/情報シス | 本番例外と混ぜない |
| サイトスコープ用 | DLP-Design-SPO-Scope | 対象サイトの管理者（またはサイト一覧管理） | スコープと例外を同じグループで兼用しない |
ポイントは、「スコープ用」と「例外用」を絶対に混ぜないことです。混ぜると、グループの意味がぶれて、後から誰も判断できなくなります。
許可ドメイン一覧をどう管理するか（現場で迷わない方針）
許可ドメインは増減が多く、「どこに正として置くか」を決めないとメンテナンスで詰みます。おすすめは次の順です。
- 第一候補：SharePoint/OneDrive側でドメイン制限（許可/ブロック）を集中管理し、DLPの例外は“共有者グループ”に寄せる
- 第二候補：DLPルールの例外条件に許可ドメインを入れる（少数・安定している場合）
- 第三候補：ゲストアカウントを管理し、ゲストをグループ化して例外に使う（運用負荷が高いが厳密）
また、ドメイン制限を本気で効かせたい場合は、匿名リンク（誰でもリンク）を許可していると抜け道になり得ます。外部協業を「特定ユーザー（ゲスト）」で行う運用に寄せるほど、ドメイン制限とDLPが素直に効きます。
期限付き例外を現実的に運用する方法
例外グループ運用の弱点は、コメントにもある通り「一度入れると永続例外になりやすい」点です。これを潰すには、期限が来たら自動的に外れる、または期限が来たら必ず見直す仕組みが必要です。
| 方法 | どうやるか | メリット | 注意点 |
|---|---|---|---|
| 期間付き例外グループ（手動棚卸し） | DLP-Design-Exception-3M のように期間を名前に入れ、定期的に棚卸し | 導入が簡単。追加コスト無しで始められる | 棚卸し忘れ＝永続例外になるため、運用ルールと責任者が必須 |
| Entra ID のガバナンス機能で期限付き付与 | アクセス申請→承認→期限付きでグループに追加→期限で自動削除 | 「期限で必ず落ちる」を仕組みにできる | ライセンス/設計が必要。申請フローの整備も必要 |
| PIM（特権ID管理）の活用 | 例外グループを“常時メンバー”ではなく、必要時に有効化 | 必要な時だけ権限を上げる発想にでき、監査も残しやすい | 「常に外部共有が必要」な部署には向きにくい |
| Power Automate / スクリプトで自動削除 | 申請記録（期限日）を管理し、期限到来でメンバーを外す | 要件に合わせて柔軟に作れる | 作り込みと保守が必要。失敗時の検知（監視）も必要 |
申請フロー例（テンプレ）
期限付き例外は、フローをテンプレ化すると現場に浸透します。例えば次のような形です。
- 担当者が申請フォームに「案件名・協業先ドメイン・期限（90日など）・目的」を入力
- プロジェクト責任者または情報シスが承認
- 承認されたら例外グループに追加（期限付きなら自動削除までセット）
- 期限前に自動リマインドし、必要なら延長申請を出す
- 期限到来で削除し、共有中のファイルは必要に応じて回収（権限見直し）
手動棚卸しでも事故を減らす運用テンプレ
- 例外グループへ追加するときに、必ずチケット番号/案件名/期限日を記録する（スプレッドシートでも可）
- 例外グループは「追加者」と「承認者」を分ける（可能なら）
- 棚卸しは月次に固定し、期限が来た案件は機械的に削除する
- DLPのインシデントレポート/監査ログを見て、例外が本当に必要だったか振り返る
「3ヶ月・6ヶ月の例外」という要望は、セキュリティ側にとっても合理的です。期限をデフォルトにしておくと、例外が増え続けるのを止められます。
複数ポリシーで構成が複雑なときの整理術
ポリシー数が増えてきたら、構成を“見える化”しないと破綻します。おすすめは、ポリシーを次の4要素に分けて棚卸しすることです。
- 対象ワークロード：SharePoint/OneDrive/Exchange/Teams など
- 対象データ：デザインファイル、個人情報、機密文書など
- スコープ：どこ（サイト/アカウント）に適用するか
- 例外：誰が、どこへ、どんな条件なら許可か
この4要素を表で整理すると、重複やねじれを発見しやすくなります。
| ポリシー名（例） | ワークロード | 守るデータ | スコープ | 例外の入口 |
|---|---|---|---|---|
| DLP-Design-SPO | SharePoint/OneDrive | デザインファイル | Design-Internal（サイト/OneDrive） | DLP-Design-ExternalShare-Allow |
| DLP-PII-EXO | Exchange | 個人情報 | 全社メール | DLP-PII-Mail-Exception |
「例外の入口（どのグループを触れば許可になるか）」を1行で言える状態にしておくと、運用担当が変わっても引き継ぎが楽です。
実装時の注意点：よくある落とし穴
- 例外が“万能鍵”になっていないか：例外グループに入ると何でも外部共有できる、という状態は避け、可能なら「許可ドメイン」などで二重条件にします。
- スコープと例外の二重管理：同じ目的で「スコープ用グループ」と「例外用グループ」を増やすほど、構造が複雑になります。スコープ＝場所、例外＝条件、の役割分担を固定します。
- ルールが増えたときの優先順位：複数ルールがある場合、どのルールが先に評価されるかで結果が変わります。例外を別ルールで表現する場合は特に注意します。
- テストモードなしの一発適用：いきなり強制ブロックにせず、まずはテスト/監査（通知）でヒット状況を観測し、誤検知を潰してから段階的に強化します。
- 利用者への伝え方：「なぜブロックされたか」「どこに申請すればよいか」が分からないと、現場は別の抜け道を探します。通知文面に申請手順と期限付き例外のルールを入れます。
チェックリスト（公開前に最低限確認したいこと）
- デザインファイルの判定条件（場所/ラベル/拡張子など）が業務実態に合っている
- ブロック対象が「外部共有」だけになっており、社内共有まで止めていない
- 例外条件は“担当者グループ”に寄っており、ポリシー編集が最小化されている
- 例外は期限付き（または棚卸し必須）として運用ルールが明文化されている
- 例外付与の申請窓口（フォーム/チケット）と承認者が決まっている
- 監査（誰がいつ外部共有したか）を追えるようにしている
まとめ：DLP例外は「場所」と「条件」を分け、期限付きで回す
Microsoft Purview DLPでは、例外（除外）はポリシーのスコープとルール条件（NOT/除外条件）の2層で実現できます。外部共有を原則禁止にしつつ、特定ユーザー/特定ドメインだけ許可したい場合は、ルール条件で例外を作るのが柔軟です。
運用面では、例外をグループで受けて「メンバー変更＝許可変更」に寄せることで、ポリシー編集の頻度を下げられます。さらに、外部協業用サイトの分離や、期限付き例外（棚卸し、ガバナンス機能、PIM、自動化）を組み合わせ、「例外を出しっぱなしにしない」仕組みを作るのが現実的な解決策です。
コメント