Power Platform は Microsoft 365 サブスクリプションを導入していれば、標準ライセンスが含まれているため利用ができる大変便利なツールですが、何ができるかわからない（ヤバイことができてしまうのではないか、という意味で）ために、ライセンスを無効 (OFF) にしてしまっているという管理者の方は結構いるのではないかと思います。我々としてはデジタルトランスフォーメーション＆利活用のために Power Platform は重要かつ必須ともいえるツールであると考えているため、 Microsoft 365 を利用している方はぜひ Microsoft Teams と共に最大限活用してほしいと思っています。
そこで、 Power Platform をちゃんと理解していただいたうえで、正しく利用しましょう。また、セキュリティやガバナンス、コンプライアンスを維持するための設定についても解説します。
Power Platform 管理者が悩むこと
あえて定義するのであれば以下のようになると思いますが、あまり厳密に区別しなくてもよいと思います。
（どれも大事なので）
セキュリティ…情報漏洩やマルウェアなどのリスク
ガバナンス…好き勝手にやらせたらアプリがたくさんできて管理が大変。厳しく制限すると使われない。
コンプライアンス…法や社内ルールに反する悪いことができてしまう可能性
これらを頭文字を取ってＧＳＣと呼んだりします（しないかもしれません・・・）
Power Platform って何ができるの？
複数のサービスからデータを集めてまとめることができます。
Power Apps では複数のデータを簡単にユーザーに入力してもらい、効率的に出力（データソースに入れること）、わかりやすく表示（Appsの画面にデータを整形して表示すること）ができます。
Power Automate は何かが起こると（トリガー）、何かをする（アクション）仕組みができます。一つのトリガーで複数のアクションが実行できるので、PowerShellのスクリプトのような複雑な処理を一つにまとめることができます。これをワークフローといいます。
両方に共通していることは、コネクタを利用して複数のサービスからデータを簡単に持ってくることができる、ということです。
Dataverse は Power Platform に特化したデータベースです。SQL 等を記述しなくても簡単に扱うことができます。SharePoint List よりも大容量のデータを高速に扱えます。
さて、これで問題になってくることは 3 点です。
- 複数のデータソースを扱えるということは情報漏洩するのではないか、例えばTeamsのメッセージをTwitterにつぶやく、など
- アプリ化フロー化するとそれが容易かつ大量に行えるのではないか
- 管理者が監視制御する必要があるのではないか
一点目の懸念ですが、基本的にはユーザーが手動で行うこと以上のことはできません。例えば Teams のメッセージをコピーして Twitter にペーストすれば情報漏洩します。これは Power Platform でなくても可能です。
ただし、二点目のように容易に大量に行えるということは言えます。そこで後述する DLP ポリシーで一つのアプリフローで混在可能なコネクタを制御することで防ぐことができます。
三点目ですが、アプリフローをユーザーに任意に作らせることを制御したいという管理者は（結構）います。これを実現する方法は一応あるのですが、あまりお勧めしません。基本的には市民開発者に自由に開発してもらったほうが利活用推進になります。ただし、どうしても…という場合は CoE スターターキット等を導入したり、環境を分けることで実現可能です。
環境とDLPポリシー
Power Platform の管理にあたっては、環境と DLP ポリシーについて理解しておく必要があります。
環境はテナントの中に配置する複数の箱です。その箱の中には「アプリ」「フロー」「データ」が格納されています。
アプリは同じ環境にあるデータにはアクセスできますが、別の環境のデータにはアクセスできません。そしてその箱にアクセスできる人はあらかじめ決めた人だけです。
例えば人事部環境には人事部の人だけがアクセスできます。営業部環境の営業アプリは営業部の人だけがアクセスでき、顧客データベースにアクセスできますが、そのアプリは人事評価データベースにはアクセスできない、ということになるのです。
DLPポリシーはコネクタ間の通信を許可・禁止するためのポリシーです。これも箱と考えるとわかりやすいと思います。たとえば、「ビジネス」に SharePoint と Teams 、「非ビジネス」に GMail と Slack が入っているとします。 SharePoint と Teams のコネクタを両方同時に使うアプリフローは動作しますが、 Teams のメッセージを Slack に送信するようなアプリフローは動作しないということになります。また「ブロック」にいれたコネクタを使うアプリフローは動作しません。 Twitter をブロックに入れれば、 Twitter のコネクタは使えなくなるのです。
これを環境に適用します。例えば営業部門環境では Salesforce のコネクタを利用許可するということができます。DLPを適用する環境の範囲（これをスコープといいます）は以下が選択可能です。
- すべての環境を追加する（例外なくテナント内のすべての環境に適用される）
- 複数の環境を追加する（環境AとBに適用。すでにあるC,D,Eやこれから追加される環境は含まない）
- 特定の環境を除外する（環境AとBは除外。すでにあるC,D,Eやこれから追加される環境に適用）
- 特定の環境１つに適用（環境Aの管理者が設定する）
Power Platform 管理者以外の人が追加できる環境がある（Dataverse for Teams 環境だったり開発者プラン環境だったり）ということを想定すると、「すべての環境を追加する」「特定の環境を除外する」のどちらかのポリシーがないと統治できないことになります。
また、「すべての環境を追加する」と「特定の環境１つに適用」の2つのポリシーを一つの環境に適用することが可能です。この場合、すべてのポリシーを満たす通信のみができます。（３つ以上の場合も同様）
ポイントとしては、「ビジネス」「非ビジネス」というのは便宜上の箱の名前にすぎません。例えばポリシー１では「Teams と SharePoint」がビジネスに、ポリシー２では非ビジネスに含まれているとします。この場合、同一のアプリフローで Teams コネクタと SharePoint コネクタを利用可能です。
最初のDLPポリシーをどうするか
- Power Platform 管理センターを開き、[ポリシー]->[データポリシー]を選択します。
- ポリシーに名前を付ける で任意のポリシー名を記入します。
- 事前構築済みコネクタの項目で[ブロック可能]をクリックして、[はい]をチェックし適用します。
- すべて選択して[ブロック]をクリックします。
- [次へ]を2回クリックします。
- スコープの定義で[すべての環境を追加する]を選択して[次へ]をクリックします。
- レビュー画面で[ポリシーの作成]をクリックします。
これで Microsoft 365 コネクタのみが利用可能なポリシーが作成できました。少なくともこのポリシーがあれば外部へ情報漏洩するリスクはなくなります。そのうえで、必要なコネクタ（ Azure AD コネクタ、Power Apps管理コネクタ等）をブロックから非ビジネスに移動していけばよいでしょう。
環境が増えてきたり要件が確定してきたら、「ビジネス」「非ビジネス」の振り分けや、スコープを「特定の環境を除外する」に変更などを行います。
コネクタのアクションの設定
Twitter コネクタをブロックすると、一切利用できなくなります。ところが、マーケティング等において「投稿は禁止したいけど、検索は許可したい」ということがあります。この場合、事前構築済みコネクタの画面で、コネクタを選択し[コネクタの構成（プレビュー）]->[コネクタのアクション]をクリックします。
以下のような画面になり、アクションごとに許可とブロックを選択可能になります。
ただし、この機能はプレビューであり一部のコネクタでのみ定義可能です。
同様にSQL Serverコネクタ等で利用可能な接続先サーバー（エンドポイント）を指定することも可能です。
Power Platform の運用
Power Platform 管理者が行うことは以下の2つです。
- 環境と DLP ポリシーを正しく設計すること
- 市民開発者を育成すること
前者については説明した通りです。後者についてですが、 Power Platform のアプリは主に部や課といった範囲で使うためのものです。部課の仕事をアプリフロー化して効率よく行うということがメインになります。
（もちろん、全社向けアプリを作ったり、おひとり様アプリを作ることも可能ですが、それはメインではありません）
なので、部課に市民開発者が２，３人いれば、他のメンバーは利用者になり利活用の目的は達成できます。この２，３人を発掘したり、トレーニングをしたり、コミュニティに参加してもらって市民開発者どうしの横の連携を作ってもらうというのが管理者の役割になります。
ガバナンスを考える
ここで次に開発者が考えることは「アプリフローを作らせっぱなしでいいの？」ということです。例えば、「試しに作ったボタン1個おしたら通知が出るだけのサンプルアプリ」（野良アプリ）が大量に発生したらどうなるの？とか、「とある部門で作られた便利なアプリがあるんですけど、作った人が退職しちゃった！」といったケースですね。
正直なところ、この領域に関してあまり管理者が考慮する必要がない（＝考慮すると管理者の手間が増えすぎる）というのはあります。例えば野良アプリを放置してもセキュリティリスクがあるわけでもありません。退職する場合はエクスポート→インポートなどして適切に後任に引き継いでもらえばいいわけで、管理者が介入することでもない、といえるかもしれません。
ですが、やっぱり管理者のほうで管理したい、ユーザーが何をしているか見張っておきたい、という要望はあるかと思います。そこで、 Microsoft では管理のための便利ツール集として「 CoE スターターキット」というオープンソースのソリューションを公開しています。必要に応じて使っていただければと思います。これについては次のエントリーで説明します。
おまけ
Webinar で少し触れましたが、管理者が Power Platform のユーザー開放を躊躇する一番の理由は以下のようです。
