既定の環境ルーティングの使いどころを考える(後編)

既定の環境ルーティングの使いどころを考える Power Apps
既定の環境ルーティングの使いどころを考える

この記事は、Power Apps Advent Calendar 2023 12月9日担当分の記事です。
※ よかったよ、役に立ったよという方は、前編のQiitaの記事の方いいね!をよろしくお願いします。

既定の環境ルーティングの使いどころを考える(前編) からの続きとなります。前編から続けて読んでいただけると嬉しいです。

環境ルーティングを利用する際に気になる点

マネージド環境の「既定の環境ルーティング」の機能を使えば、ユーザーがPower Appsに初めてアクセスするとユーザー専用の「開発者環境」が自動的作成されます。

組織で利用するのであれば、環境が作られたら、必ずDLPポリシーを設定したいものです。
管理者が環境を作成して提供する場合は、DLPポリシーの設定まで行って、利用者にこの環境を使ってと連絡することができます。
しかし、「既定の環境ルーティング」の機能は、ユーザーがアクセスするのはいつになるかわかりませんので、環境が作成されたらDLPポリシーが設定される必要があります。

DLPポリシーの設定

DLPポリシーをどのように設定すればよいでしょうか。

DLPポリシーをどの環境に設定するかを決定するのは、「スコープの定義」の部分です。
範囲の指定は以下の3種類です。

  1. すべての環境を追加する
  2. 複数の環境を追加する
  3. 特定の環境を除外する


データ損失防止 (DLP) ポリシーを作成する – Power Platform | Microsoft Learn

すべての環境を追加する

テナント内の環境すべて一律に同じDLPポリシーを設定すればよければ、「すべての環境を追加する」を選択することで解決できます。DLPポリシー設定後に作成された環境にも適用されます。

既定の環境も実稼働の環境も環境ルーティングで作成された開発者環境もすべてまるっと同じDLPポリシーを設定したい場合は、「すべての環境を追加する」でよさそうです。

複数の環境を追加する

DLPポリシーの設定はウィザード形式です。「複数の環境を追加する」の場合、どの環境に適用するか選択する必要があります。

この場合、種類が「Developer」の環境だけになるようにフィルタリングした結果して、開発者環境をあぶりだす必要があります。
そのうえで開発者環境を全選択して、ポリシーに追加します。

「複数の環境を追加する」の場合は、環境が作成されていないとDLPポリシーを適用できないということになります。
既定の環境ルーティングで開発者環境が作成されたら、DLPポリシーを設定し直す必要があるということになりそうです。

特定の環境を除外する

DLPポリシーを当てたくない環境を選択するという設定なので、「複数の環境を追加する」の場合と同様に、DLPポリシーを作成済みの環境を選択する必要があります。
例えば、種類が「Developer」以外にはこちらにDLPポリシーを設定するという場合に使われます。

(2024/01/11 修正 ※ takmasさん ご指摘いただきありがとうございます。)
「複数の環境を追加する」とは異なり、新しく作成された環境も除外されます。
除外ポリシーの場合は、新しく作成された環境は除外されません。

(2024/01/11 修正 ※ takmasさん ご指摘いただきありがとうございます。)
「特定の環境を除外する」の場合は、新しく環境が作成されると除外されてしまうことになります。
既定の環境ルーティングで開発者環境が作成される場合には向いてなさそうです。

「特定の環境を除外する」設定後に作成した開発環境には、ポリシーが適用されることになるため、既定の環境ルーティングで、開発環境を払い出すときに向いているように思います。

しかし、「開発者環境」以外を新規に作成した場合も同様のポリシーが適用されることになるため、別なポリシーを適用する必要ある場合は、除外を都度設定する必要がでてきます。

解決策を考えてみる

(2024/01/11 追記)「開発者環境」も都度作成され、かつ、それ以外の環境も作成される場合、かなり複雑になるかなと思います。

DLPポリシーの設定方法から見ると、どうしたら、既定の環境ルーティングで作成されるたびに、DLPポリシーを設定すればいいかがパッと思いつかないのではないでしょうか?
この組み合わせでイケるのでは?とひらめいた方はぜひ教えてください。
(こういうのを組み合わせるの苦手。。。

じゃあどうしようか?

少しタイムラグあるかもしれませんが、定期的にDLPポリシーの設定を行うことです。
「複数の環境を追加する」で種類が「Developer」の環境が増えていたら、適用するを毎日毎日繰り返すのです。
開発者環境はいつ作られるかわからないのです。

苦行か。。。

自動化を考える

毎日毎日、人の手でチェックしながらなんてやりたくないんじゃ!
ということで、自動化を考えてみます。
(自動化?Power Appsのアドベントカレンダーだった気がするけど。。。)

Power Platform管理者向けにはいろいろツールが揃っています。

どんなのがあるのという方向けにちょっと横道にそれます。
(宣伝タイム。。。)
2022年の「Japan Power Platform Conference 2022」で登壇した際にCoEスターターキットツールについてお話したのですが、その中で管理コネクタとかPowerShellとかもあるよってことを少しだけ触れています。
登壇時の資料はこちら↓
Power Platform の管理に役立つCoE スターター キットを触ってみた | ドクセル (docswell.com)
※ 情報が古くなっている箇所もあるので注意してください。最新情報はスライド下部に記載の[参考]URLから公式ドキュメントをご確認ください。

そういえばPowerShellあったなということで、見てみます。
Power Apps の PowerShell サポート – 管理者向けの Power Apps コマンドレット- Power Platform | Microsoft Learn

PowerShellでなんとかなるか?

環境一覧はとれそうです。種類はとれるのか?

環境コマンド – すべての環境の一覧の表示 – Power Platform | Microsoft Learn

「など」だと。。。

(仕方ないので)コマンド打ってみます。
「EnviromentType」で取れそうです。


「EnviromentType」が「Developer」な環境の「DisplayName」とか抽出したらなんとかなるんじゃないだろうか?ということで、次にDLPポリシーの更新を見てみます。

環境コマンド -DLP ポリシーの更新 – Power Platform | Microsoft Learn

「など」だと(再)。。。

(仕方ないので)コマンド打ってみます。
「PolicyName」と「UpdatePolicy」を指定すればよさそう。
「UpdatePolicy」の指定しなかったらエラー。そうでしょうね。

リファレンスを探そう。。。
(良い子はいきなりコマンド打たずにリファレンスを先に参照しましょう。。。)

ありました。こちらです。
Set-DlpPolicy (Microsoft.PowerApps.Administration.PowerShell) | Microsoft Learn

Objectで指定できそうです。
(本記事では割愛します。検証できていないだけです。ごめんなさい。)

コマンド組み合わせて、PowerShellでスクリプト作成し、タスクスケジューラとかに仕込んで定期実行するとかで頑張ればできそうです。(頑張るのか?。。。

管理コネクタを使ってPower Automate(クラウドフロー)でできないか?

管理コネクタ使うという方法もありそうです。
「Power Platform for Admins」コネクタで「環境一覧を管理者として作成する」「DLP ポリシーの更新 V2」アクションがあります。
Power Platform for Admins – Connectors | Microsoft Learn

(自動化?Power Appsのアドベントカレンダーだった気がするけど。。。再)

こちらの方法をとる場合、開発者環境がユーザー数×3個までが最大で作成できることを考えて、Power Platform要求数の制限を気にしていただいたほうがよいかなと思います。

Power Platform要求数ってなに?という方は過去に記事を書いたので、合わせて読んでいただくと嬉しいです。
Power Platform 要求数の制限(Power Automateの場合) | たなの覚え書き (tana-techlog.net)
Power Platform 要求数 について考えてみる | たなの覚え書き (tana-techlog.net)

実は最初に思ったこと

Dataverse for Teams環境出た時も、DLPポリシーどうやってあてるん?という疑問があり、そのときにも思ったのです。
確認してみると、その疑問の回答はドキュメントに記載がありました。
Dataverse for Teams 環境の管理 – Power Platform | Microsoft Learn

公式でも「PowerShellでスクリプト」「定期的に」。。。まあそうなりますよね。

この方法の問題点は、PowerShellでも、Power Automateでもできるのですが、どうしてもスケジュール実行になる点と、仕組みを自分たちで作らないといけないんですよ。頑張らないとなのです。
せめて、PowerShellもPower Automateも環境が作成されたということを検知してくれたら、少しは頑張れるんですが。。。

DLPポリシーの設定で環境の種類で適用できたら解決するのになぁ

開発者環境にはすべてこのDLPポリシーを適用するって設定できたら、それでオールOKなんですよ。

というわけでフィードバックしようかなと思ったところ、、、Power Apps Ideas というフィードバックとかするサイトで「それ!!!!!!!!!!!!!」という要望を見つけました。
(正確にはコミュニテイーメンバーの方に教えていただきました!どなたから教えていただいたか失念してしまいました。ごめんなさい。ぜひ名乗りをあげてください。)

DLP policy – block by environment type · Community (powerapps.com)
ぜひ、内容をご覧いただき、ご賛同いただけるなら、Voteしてください!(割と切実。。。

さいごに

「Power Platform 管理者は、組織において、利用者に安心を与える存在であるとともにPower Platform の価値を最大限引き出すことのできる存在」であると思います。

管理系のアップデートで追加された機能をうまく活用し、管理の工数を削減するとともにに利用者へ多くの価値を提供できないかを考えていきたいですね。



コメント