※ この記事は、Microsoft Power Automate Advent Calendar 2025 12月12日 担当分の記事です。
DLPポリシーを作成するときに、既存のDLPポリシーをコピーしたいと思ったことはありませんか？私はあります。
DLPポリシーを複数作成するときは、たいていの場合、以前に作成したポリシーとほとんど同様の設定で、少しだけ変更したりするパターンが多いのではないかと思います。設定ミスを避けるためにも、できれば元のポリシーをコピーして、変更点だけ編集したいという思いは、常々ありました。
しかし、残念ながら、DLPポリシーのコピーは、Power Platform管理センターの標準機能としては搭載されていません。
あるとすれば、「CoE Starter Kit」の「Data Policy Impact Analysis」。
このアプリを利用すると、DLPポリシーのコピーを作成することができます。
とはいっても、CoE Starter Kitを導入するのは、ちょっと敷居が高いのも確かです。
そこで、Power Platformの管理系のコネクタを利用してどうにかできないか試してみました。
この記事は、その奮闘記です。
Power Platform for Admins（管理者向け Power Platform） コネクタ
Power Platform for Admins（管理者向け Power Platform） コネクタのリファレンスは、以下です。
管理者向けPower Platform - Connectors | Microsoft Learn
アクションを眺めてみると、DLPポリシーに関するアクションもいくつか存在していることが分かります。
既存のDLPポリシーの内容を取得して、新規DLPポリシー作成時に既存の内容を設定したら、コピーと同じになるであろうと予想して、作成を開始しました。
クラウドフローの作成
最終的に出来上がったフローの構成はこちらです。
「DLPポリシーの作成 V2」アクション
最終的に新しいDLPポリシーを作成することになるので、「DLPポリシーの作成 V2」アクションを使います。
まずは、何を入力として設定するか確認しました。
①「表示名」は、作成するDLPポリシーの名前を入力すればよさそうです。
※ 2025/11/14 までは「表示名」は、「Display name」でした。
ひとまず「DLPTEST」と入力します。
②「既定のコネクタの分類」は、選択肢から選べばよさそうです。
※ 2025/11/14 までは「既定のコネクタの分類」は、「Default conncetors classfication」でした。
どうやらDLPポリシーの「既定グループの設定」をどうするかの設定っぽいです。
ここは「Blocked」を選択。
③「Body/connctorGrups」は、「＋新しい項目を追加する」をクリックしていくと、こんな感じになっており、何やらコネクタの分類の設定をポチポチやらなければいけない様子。それは結構大変。
※ たぶん近いうちに「Body/connctorGrups」の名前は、変わっている気がします。
これまでのクラウドフロー作成の経験から、きっと既存のDLPポリシーを取得したら、このあたりの値をまるっと、動的コンテンツで設定できるのではないか。という感がここで働きます。
というわけで、この設定は後回しにします。
（この感はバッチリ的中します。）
④ 「ポリシー環境の種類」の選択肢を見る限り、スコープ定義の設定のように見えなくもない。
※ 2025/11/14 までは「ポリシー環境の種類」は、「Policy environmet type」でした。
DLPポリシーのスコープ定義は、「すべての環境を追加する」「複数の環境を追加する」「特定の環境を除外する」の3種類。4つの選択肢なのがなぜかがわかりませんね。
特に「OnlyEnvironments」と「SingleEnvironment」の違いが不明ですが、ひとつの環境にのみ適用したいのでここでは、いったん「OnlyEnvironments」を選択。
ちなみに「OnlyEnvironments」を指定した場合、スコープの定義は「複数の環境を追加する」に設定されました。
⑤「Body/environments」の「＋新しい項目を追加する」をクリックすると、なにやら、「id」「Type」「Name」を指定しないといけない。しかし、何を指定したらいいのやら・・・
※ たぶん近いうちに「Body/environments」の名前は、変わっている気がします。
ここで働いた感は、「環境」の情報を取得したら、「id」「Type」「Name」が取得できて、動的コンテンツで設定できるんでは？でした。
（はい、こちらも大正解）
さて、ここまでの設定は以下のようになります。
③ は、既存のDLPポリシーを取得したら、取れそう。
⑤ は、「環境」の情報を取得したら、取れそう。
という感のもと、続けていきます。
「DLPポリシーの取得 V2」アクション
「DLPポリシーの作成 V2」アクションの『③「Body/connctorGrups」の設定』には、既存のDLPポリシーを取得した値が設定できそうとあたりをつけています。
そこで、「DLPポリシーの取得 V2」アクションを実行して、出力結果を確認してみます。
「DLPポリシーの取得 V2」アクションに設定するのは、以下です。
⑥ 「Policy」の選択肢を見ると、何も現れないので、カスタム値の入力を使うしかない状態でした。入力するのは、「The name field of the Policy」。
ポリシーの「name」に設定されている値を入力しろってことのようです。
※ 2025/11/14 までは「ポリシー」（ポリシーの名前はフィールドです。）は、「Policy」（The name field of the Policy）でした。
ひょっとしたら、ここが最初から日本語表記だったら、name フィールドを取得することに気づかず、少しハマったかもしれません。
ポリシーの「name」にどんな値が入っているか分からないので、別のアクションで取得した値を確認することにしました。
「DLP ポリシー一覧の作成 V2」アクション
すでにDLPポリシーがいくつかあるので、「DLP ポリシー一覧の作成 V2」アクションを使って、DLPポリシーの「name」が取れるか確認することにしました。
⑦ アクションは、設定値はとくになく、そのまま実行できそうです。
「未加工の出力を表示する」の結果です。
（あまりにも長いので、途中カットしています。）
⑧ さっそく[name]がありました。表示名ではなく、内部IDのようです。
これを「DLPポリシーの取得 V2」アクションの「Policy」に動的コンテンツを利用して設定できそうです。
よく見ると、下の方に、「enviromments」があり、その配下に「id」「name」「type」があります。これは、「DLPポリシーの作成 V2」アクションの『⑤「Body/environments」』に設定できる値では？と、またまた感が冴えわたります。これもあとでみてましょう。
「DLPポリシーの取得 V2」アクション に戻る
「DLPポリシーの取得 V2」アクションの「ポリシー」に「カスタム値を入力する」から、動的コンテンツを利用して、「DLP ポリシー一覧の作成 V2」アクションの「name」を設定します。
すると「DLPポリシーの取得 V2」アクションが「For each」に囲まれました。それもそのはずですね。DLPポリシーは複数作成できます。一覧を取得したら、Arrayで返ってくるので、ループしちゃいますね。
今回、ループするのは問題ないので、そのままとします。
（このあと条件式を追加することで結果的にひとつしか作成しないようにする予定です。）
「DLPポリシーの作成 V2」アクション に戻る
「DLPポリシーの作成 V2」アクションの『⑤「Body/environments」』の「id」「name」「type」に「DLP ポリシー一覧の作成 V2」アクションの「environments」配下の「id」「name」「type」を動的なコンテンツで設定します。
設定し終わって、ふとみると、なんぼ回すねんというほどに「For each」に囲まれてしまいました。
（ここでの感は、外れましたね・・・）
よくみると、どうやらDLPポリシーが適用されている環境の情報を配列で保持しているようです。
ということは、「id」「name」「type」をそれぞれ設定するのではなく、「配列全体の入力に切り替える」を利用して、「id」「name」「type」が含まれている「environments」を指定すれば、解決するのでは？
ということで、いったん設定はできました。
次に最初に保留とした『③「Body/connctorGrups」の設定』です。
最初、DLPポリシーの取得から動的コンテンツで設定できるかを確認するために、「DLPポリシーの取得 V2」アクションを利用しようとしてたわけですが、その先でもほかのアクションが必要だったりしたため、最後まで残ってしまいました。
最初のときに予測したとおりでいきましょう。
「DLPポリシーの取得 V2」アクションはすでに設定が終わっているので、実行結果を見て、「Body/connctorGrups」が取得できるか確認します。
「未加工の出力を表示する」の結果です。
「connctorGrups」を発見しました。これを動的コンテンツで設定してみます。
「配列全体の入力に切り替える」を利用し、「body/connctorGrups」を設定します。
DLPポリシーのコピーを実行してみる
すべてのアクションの設定が完了したので、実行してみます。
無事、DLPポリシー作成に成功しました。
しかし、結果として、「DLPTEST」というDLPポリシーが複数個作成されてしまいました。
作成したクラウドフローは、DLPポリシーの一覧をもとに、すでに作成されているDLPポリシーの数分ループしながら、新規DLPポリシーを作成するようになっています。
「A Policy」「B Policy」「C Policy」と3つあった場合、「A Policy」の設定の「DLPTEST」、「B Policy」の設定の「DLPTEST」、「C Policy」の設定の「DLPTEST」となるわけです。
今回、特定のポリシーのみ作成するように条件を入れる予定でしたが、設定が完了したことですっかり飛ばしてしまいました。
元となるDLPポリシーをひとつだけ決めて、そのDLPポリシーを１つだけコピーするようにしたいため、条件には、「DLP ポリシー一覧の作成 V2」アクションの「DisplayName」が特定のDLPポリシー名と「等しい」とします。
DLPポリシーのコピーを作成する際の注意点
さて、今回作成したクラウドフローでは、元となるDLPポリシーと新規に作成したDLPポリシーは、コネクタの分類と割り当てている環境をまったく一緒にしています。そのため、結果として、すでに適用されているDLPポリシーのほかに、名前の違うDLPポリシーを同じ環境に割り当てているような形となっています。つまり、DLPポリシーの差異がないため、利用者影響はないのです。
※注意※
ただし「既定グループの設定」を強制的に「Blocked」にしている点は、差異が発生している可能性はあります。この点については、新しくコネクタが追加された際、どこに分類するかの設定のため、現在の動作には直接的に影響はしていないものとします。
とはいっても、一部でも違うのはよくないため、最終的には、固定値で強制的に入れていた以下の箇所は変更しています。
②「既定のコネクタの分類」には、「DLPポリシーの取得 V2」アクションの「body/defaultConnectorsDlassification」を動的コンテンツで設定。
④ 「ポリシー環境の種類」には、「DLPポリシーの取得 V2」アクションの「body/environmentType」を動的コンテンツで設定。
複数DLPポリシーを適用する場合、DLPポリシーのコネクタの分類に違いがあると、より厳しい方のルールが適用されます。最悪の場合は、今まで利用できていたコネクタが、利用できなくなるといった事態が発生します。
今回の「DLPポリシーをコピーする」というミッションには、DLPポリシーをコピーしたことで、既存の環境への影響を出してはいけないという要件があったことになります。
すでに適用されているDLPポリシーをコピー元として、新規にDLPポリシーを作成する必要がある場合は、以下の点に注意が必要です。
① 元となるDLPポリシーのスコープ定義と同じ環境に適用する
② ①が難しい場合は、 誰も利用していない環境を用意し、その環境に適用する
③ コピー作成後、速やかに編集し、適切な環境に割り当てる
事件勃発
ようやく、完成！と思ったら、珍事件が起きました。
条件式まで追加して、思ったように作成したはずでした。しかし、血迷ったのか、何か思いついたのかは定かではありませんが、条件の設定を色々いじっていました。
その結果、テスト実行を何回も行っていたところ、気づいたらこんなことになりました。
お気づきだろうか。右上のスクロールバーの短さを・・・・・
同名のDLPポリシーを500個ほど作成しておりました。
手動で削除するのは困難なため、慌てて「DLPTEST」という名前のポリシーを一括削除するクラウドフローを作成しましたとさ。
さいごに
今回、DLPポリシーを新規に作成するクラウドフローの作成を行いました。
通常、クラウドフローを利用して何かを行う場合、たいてい環境内に閉じると思います。（Dataverseコネクタなど環境を跨ぐものも一部ありますが。）
環境内で閉じている処理を行う場合、影響範囲は環境内に閉じるわけです。
しかし、今回の場合は、Power Platform管理センター上に作成されるDLPポリシーを扱いました。DLPポリシー作成に当たっては、既存の環境にDLPポリシーを割り当てる必要もありました。そのため、既存環境へ影響を及ぼさないように作成する必要があったわけです。
テナントレベルの設定変更の自動化ですので、設定をミスると場合によってはテナント全体に影響を及ぼしかねません。
一歩間違えば、DLPポリシーのコピーについては、作成の仕方を間違えると、すでにDLPポリシーが適用されている環境に、別のDLPポリシーを割り当ててしまうという利用者影響がある事故が発生する可能性もあります。
それに、DLPポリシーを無駄に500個以上作って削除しなければいけないというミスもリカバリーする必要があります。
管理者の運用観点で自動化を行うことも多いです。
管理者用の環境を作成することで事足りることは少なくありませんが、テナント全体に影響を与える処理を実装する場合は、検証用のテナントで開発・検証を行えるに越したことはないですね。
さて、私は、コピーしたDLPポリシーの名前を変更して、コネクタの分類を少し変更したうえで、新しい環境に割り当てます。