Power Platform DLPポリシー設計の鉄則：複数適用の落とし穴と3階層モデル【管理者向け】

DLPポリシーが複数適用された環境でのコネクタ使用の考え方がちょっとややこしかったので、メモ。

事前準備
ビジネスと非ビジネスが混在するとややこしい
実際に使ってみた
1. 同じグループ内のコネクタのみ使用
2. 別グループ間のコネクタを使用
アプリを作るときは事前にテナントのDLPポリシーを確認すべき
1. まとめ：複数ポリシー適用時の判定ルール（例）
【推奨】複数ポリシーで沼らないための「3階層設計」
1. 🏗️ DLPポリシーのおすすめ3階層構造
2. ポイント：Level 1（全社）で「締めすぎない」こと

事前準備

環境「DLPSample」を作成し、（普通こんな変なDLPポリシーは設定しないと思うけど）こんな感じでDLPポリシーを2つ作成する。

で、これら2つのDLPポリシーが適用される環境「DLPSample」でPower AppsとかPower Automateを使うことを考えてみる。

ビジネスと非ビジネスが混在するとややこしい

公式によると事前準備のようなDLPポリシーが設定されている場合、環境「DLPSample」で使用するコネクタはこんな感じでグループ化されると考えるらしい。

グループ1：「DLPポリシー1 → ビジネス」　かつ「DLPポリシー2 → ビジネス」
グループ2：「DLPポリシー1 → ビジネス」　かつ「DLPポリシー2 → 非ビジネス」
グループ3：「DLPポリシー1 → 非ビジネス」かつ「DLPポリシー2 → ビジネス」
グループ4：「DLPポリシー1 → 非ビジネス」かつ「DLPポリシー2 → 非ビジネス」

図にするとこんな感じ。

グループ1：SPO、O365Users
グループ2：Notifications、Outlook
グループ3：Teams、Excel
グループ4：MSNWeather、Twitter

で、この2つのDLPポリシーが設定された環境「DLPSSample」では、これらのグループをまたいだコネクタの使用はできない。

※参考公式：

複数のデータポリシーの組み合わせ効果 - Power Platform

複数のデータポリシーの複合効果の例。

実際に使ってみた

実際に環境「DLPSSample」でキャンバスアプリを作成し、これらのコネクタを使ってみる。

同じグループ内のコネクタのみ使用

例えば両方のDLPポリシーで「ビジネス」に設定されているコネクタ（グループ1）を両方同じアプリに入れてみると、当然何の警告もなく使用できるし、

DLPポリシー1ではビジネス、DLPポリシー2では非ビジネスとなっているコネクタ（グループ2）を両方同じアプリに入れてみても、何の警告もなく使用できる。

ということで、同じグループ内であれば問題なく使用できそう。

別グループ間のコネクタを使用

問題はここからで、例えば環境「DLPSample」に対するDLPポリシー（DLPポリシー2）では同じビジネスに設定されているSPOとTeamsを一緒に使おうとすると、

こんな感じで警告が出て一緒に使えないし、

逆にテナントに対するDLPポリシー（DLPポリシー1）で同じビジネスに設定されているSPOとNotificationsを一緒に使おうとしても、

同様に警告が出て一緒に使えない。

ということで、ある環境に複数のDLPポリシーが適用されている場合、いずれかのDLPポリシーで別々のグループに設定されたコネクタは同じアプリでは使用することができないことがわかる。

アプリを作るときは事前にテナントのDLPポリシーを確認すべき

今回はある環境に対してのDLPポリシーが設定されていたとしても、その設定によってテナントレベルのDLPポリシーが無視されることはない、という当たり前のことに気づけた。

特に顧客の環境でアプリを作成する際、まずはテナントレベルのDLPポリシーがどのように設定されているかを確認した方がよい。

まとめ：複数ポリシー適用時の判定ルール（例）

今回の検証結果を表にまとめると、以下のようになる。
「最も厳しい設定が勝つ」かつ「すべてのポリシーで同じグループにいないとエラーになる」のがポイント。

コネクタ	ポリシーA (全社)	ポリシーB (環境用)	最終結果
SharePoint	✅ Business	✅ Business	✅ 利用可能
Twitter (X)	🚫 Blocked	✅ Business	🚫 Blocked (Aで禁止のため)
Box	✅ Business	⚠️ Non-Business	⚠️ 混在エラー (グループ不一致)

結論： どのポリシーでも「許可（Business）」かつ「同じグループ」にいないと使えない。

【推奨】複数ポリシーで沼らないための「3階層設計」

「じゃあ、結局どうやってDLPポリシーを設計すればいいの？」について。

Microsoftのベストプラクティスや実際の現場運用を踏まえると、以下の「3階層アプローチ」で管理するのが最も事故が少ない。

🏗️ DLPポリシーのおすすめ3階層構造

ポリシーを「全社」「部門」「例外」の3レベルに分けて、上から被せていくイメージ。

Level 1: テナント共通ポリシー（全員適用）

✅ 目的： 最低限のセキュリティ担保
🚫 設定： Twitter(X)やFacebookなどのSNS系、HTTPコネクタなど「情報漏洩リスクが高いコネクタ」を全員問答無用でブロック。
👉 ここでブロックしたものは、下位のポリシーでどうあがいても使えなくなる（鉄の掟）。
Level 2: デフォルト環境用ポリシー（Personal Productivity）

✅ 目的： あくまで「個人利用（自分専用）」の遊び場として定義
⚠️ 設定： Office 365系（Outlook, Teams, Planner）など「個人の便利ツール」だけを許可し、それ以外はブロックするくらい厳しくてOK。
👉 最近のトレンドは、デフォルト環境を「全社員のゴミ箱」にしないこと。
「SharePointリストを使った業務アプリ」などはここで作らせず、下記の専用環境へ誘導するのが現代のベストプラクティスです。
Level 3: 開発・本番環境ポリシー（App Development）

✅ 目的： チームや全社で使う「ちゃんとしたアプリ」用
🔓 設定： ここで初めて「業務に必要なコネクタ（SQL, Salesforce, Custom Connectors）」を解禁。
👉 開発者プラン環境（Developer Environment）や、管理者が払い出したSandbox環境にこのポリシーを適用し、「作りたければ申請してね（＝デフォルト環境で作るな）」という運用フローを作る。