既定の環境でのユーザーが持つセキュリティロールから既定の環境でのアクセスコントロールを紐解く

既定の環境の制御… なんとなく困っている運用担当の方も多いと思います。

既定の環境は、使っているのか、使っていないのかわからないリソースが溜まりがちな場所です。

どうしてそんな状況になってしまうのか？

既定の環境にアクセスしたすべてのユーザーには、勝手にリソースを作成できるキュリティロールが割り当てられており、剥奪してもまた自動的に付与されます。この仕様により、既定の環境では、Power Platform にアクセスできてしまうと、トレーニングを受けていないユーザーであってもアプリを作成できてしまうことになります。そのため、謎のアプリが作成されてしまうこととなるのです。

新しいユーザーは、どのレベルでPower Platform 各製品へのアクセスが可能なのでしょうか？

今回は特に何のセキュリティロールの設定を明示的に行わず、Entra ID レベルでの管理者の権限のない一般的なユーザーでの挙動を確認してみます。

ユーザーできる権限をしっかり理解してから、対処案について提示します。

セキュリティロールの確認

Power Platform 管理センターにて、何もしていなくても勝手に付与されている、既定の環境でのセキュリティロールを確認します。

セキュリティロール

特にセキュリティロールを割り当てる作業をしなくても、以下のセキュリティロールが自動的に割り当てられていることがわかります。

以下のセキュリティロールが割り当てられています。

• Environment Maker
• Basic User

Environment Maker 、 Basic User のセキュリティロールはこちらで詳細を確認できます。

以下の画像は長すぎるので、ダウンロードしてお使いください。

Environment Maker のセキュリティロール詳細

Basic User のセキュリティロール詳細

キャンバスアプリ

このように、Basic User ではキャンバスアプリの作成権限がありません。

Environment Maker ではキャンバスアプリの作成、削除、編集権限があります。

モデル駆動型アプリ

Basic User では、モデル駆動型アプリを組織全体で読み取りができます。AI モデルは読み取りのみができます。

Environment Maker では、モデル駆動型アプリの読み取り、作成、編集ができますが、削除ができません。

AI Builder

AIモデルは作成等、一連のCRUD操作ができます。

Power Automate

Power Automate のフローは、メインは Process テーブルに格納されています。Environment Maker には一連の操作権限が含まれています。その他の関連テーブルにもユーザーの範囲での権限が付帯していることがわかります。

デスクトップフローを確認します。デスクトップフローについても作成権限が付与されていることがわかります。

Copilot Studio

Copilot Studio のエージェントの作成権限を見てみます。この権限は Copilot テーブルにあたります。一連の操作権限が含まれています。

セキュリティロールのまとめ

既定の環境で割り当てられる、Basic User + Environment Maker のセキュリティロールを総合すると以下のとおりです。

• リソースの作成ができる。ただし、テーブルの作成はできない。
• モデル駆動型アプリは削除ができない。
• 他の人が作成したモデル駆動型アプリを見ることができる。
• AI モデルを作成でき、AI モデルは自分に共有されたリソースしか利用できない。ただしライセンスがいる。ライセンスがないとAI Builder のトライアルに進む。

テーブルにまとめると以下のとおりです。

実際にリソースを作成する際の挙動の確認

Dataverse テーブルの作成

テーブルを作成しようとすると、新しい開発者環境を作成するように促されます。

既定の環境では、最初に与えられる権限ではテーブルの作成権限がありません。

Power Apps

ただし、リソースを作成する権限はあります。

ここで言うリソースとは、Power Apps のアプリ、Power Automate のフローなどです。

以下のように、キャンバスアプリ、モデル駆動型アプリを作成することができます。

モデル駆動型アプリはページデザインから作成することができます。

ビューとフォームを選ぶことでモデル駆動型アプリを作成できます。

モデル駆動型アプリの挙動は特殊で、テーブルを作成することはできませんが、既存のテーブルを利用することはできます。以下は、User、Account、Artcleのテーブルをモデル駆動型アプリに接続しました。

このように既定の環境にてモデル駆動型アプリを実行することができました。

デスクトップフロー

デスクトップフローにサインインしてみます。

サインインすることができました。アクセスしている環境は既定の環境です。

フローを作成することができます。

既定の環境にデスクトップフローを作成することができました。

デスクトップフローデザイナーにも表示されています。

クラウドフロー

クラウドフローを作成してみます。

クラウドフローを作成することができました。

Copilot Studio

ライセンスがないので、トライアルに促されます。トライアルとして進めます。

既定の環境でトライアルを開始することができました。このままリソースを作成します。

エージェントを作成することができました。

Power Pages

サイトの作成を行ってみます。

この方法で作成するとPower Pages の開発者環境内にページが作成されました。

この状態で既定の環境に切り替えを行ってみます。すると既定の環境では Power Pages のサイトを開発できないことがわかります。

Power Pages に関しては既定の環境でリソースを作成できません。

まとめ

既定の環境では、Basic UserおよびEnvironment Maker のセキュリティロールが与えられ、その権限の範囲内にて Power Platform のリソースを作成することができます。

トライアルが必要な Copilot Studio はテナントでのユーザーによるトライアルのセルフサービス サインアップのブロック、 環境作成が必要な Power Pages は Power Platform 環境の開発者環境の作成を管理者のみに設定する機能を利用すること、Power Automate デスクトップフローは Power Automate Premium ライセンスがないユーザーがフローを作成することをレジストリキーでブロックできます。

一方で、Power Automate のクラウドフロー、Power Apps キャンバスアプリ、Power Apps モデル駆動型アプリは作成できてしまいますが、マネージド環境の機能にて運用回避案があります。

対処案

製品ごとの対処案をテーブルにまとめると以下のとおりです。

既定の環境の管理には頭を悩ませますが、Microsoft のガイドラインも確認し、適切に対処しましょう。

以上、ご参考になれば幸いです。