Power Apps や Power Automate の導入を検討する際に、よく情報システム部門に勘違いされるのがデータ漏洩や野良アプリ・野良フローが作成されてしまうという懸念で、特に日本だとよく分からずに知らないという理由だけで完全にライセンス毎ブロックされている情報システム部門が多い印象なので、今回は実際に私がアドバイザリープログラムを提供している、45,000ユーザーの銀行系のお客様で採用いただいている環境構成をお話します。

テナントレベルでの制御

まず、全体的なテナントレベルの構成・制御内容についてお話します。

銀行系のようなお客様の場合、情シスの方々自身も脅威として考えられるため、基本的にはOffice 365･Microsoft 365 の全体管理者権限を持っていません。全体管理者権限を持つと、いくら制御をしている環境であっても、自分だけ例外で制御をオフにしたり、データへ管理者権限でアクセスできてしまうリスクがあるためです。実際、Microsoft Docs上でも全体管理者の機能が必要な場合な時だけに必要な専用アカウントを使おうというガイダンスを記載しています。

え、全体管理者が普通はいない場合、どうするの？と思われるかと思いますが、そこで設定されているのが、2つのAzure ADの機能となります。

Azure AD PIMS

Azure ADの機能の一つである、PIMS（Priviledge Identity Management）は、普段割り当てられている権利よりも更に上位の特権を必要とする場合に、承認された場合にのみ、アクセス可能となる機能です。

この機能を利用するにはAzure AD Premium P2 というライセンスまたはEnterprise Mobility & Security E5 を保有している必要があります。もちろん、この機能だけでなく、AIを活用したリスクベースの条件付きアクセスポリシーなど、他にもいろいろなセキュリティ機能も備わっています。

Azure AD PIMSを設定すると、このような利用例が実現することができ、実際のお客様でも以下のような運用をされていました。

Azure PIMSについて：Privileged Identity Management とは? – Azure AD | Microsoft Docs

 Azure AD 条件付きアクセス

PIMSに加え、設定されているのが、条件付きアクセスです。これは、様々な条件（例えば利用しているパソコンや、アクセス元のIPなど）を元に、アクセスを許可したり、2段階認証を設定したり、そもそもブロックしたりすることができます。実際のお客様では Power Platform 管理者権限を付与されているユーザーなどに対しては、二段階認証を有効化させる設定にすることで、リスクを最小限に抑えることをされています。

条件付きアクセスポリシーの詳細：Azure Active Directory の条件付きアクセスとは | Microsoft Docs

セキュリティグループについて

Power Apps を利用するに当たって、アクセスの許可は様々な単位で管理することができます。

  • 環境単位
  • アプリ単位
  • データ単位
  • フォーム単位（モデル駆動型アプリの場合）

もちろん、これらを個別に設定していくことも可能ですが、極力管理をシンプルにするためには、Azure AD／Microsoft 365のセキュリティグループを活用することをおすすめします。

データ損失ポリシー（DLP）

特定のコネクタの利用を無効化させたり、個別には利用できるものの、組み合わせによっては無効化させることができるのが、DLP（データ損失ポリシー）です。別途説明した記事があるのでここでは詳細は説明しませんが、データ損失ポリシーはPower Apps／Power Automate の環境単位で設定することができるため、まずは全社に適用されるテナントレベルのポリシーを設定し、そこから例外を追加していく方法が採用されています。環境の分け方については次の部分で説明します。

環境の構成・設定

環境は、活用方法とどれぐらいのサポートが必要かに合わせて複数の環境で構成されており、主に4種類に分類することができます。

デジタルスタジオ

ミッションクリティカルなアプリ、IT主導となる、IT部門・外部SIerで開発したりするアプリがこの分類に当たります。IT部門で運用も行うため、DLPの設定は一番緩い設定となり、あらゆるシステムと接続します。専用のオンプレミスデータゲートウェイも割り当てられ、パフォーマンスに影響が出ないようにします。

 デジタルセル

これはデジタルスタジオと似ていますが、あるプロジェクトや部門で利用される場合で、あくまでも運用・責任となる部門は業務側にあります。ミッションクリティカルなアプリとは違い、長期的に利用されることは想定されておらず、例えば長くて2－3年ほどで終了となるものがこの分類になります。事前にIT部門へ申請し、利用用途を明確化しておき、DLPの設定もその利用用途に合わせて設定されます。

 セルフサービス

全社で1つの環境を用意しますが、既定の環境とは違います。業務利用を前提としており、既定の環境よりは利用できるコネクタも多くなります。定期的にアプリの棚卸しを行い（Power Automateで自動化します）、不要なアプリは削除される仕組みです。作られたアプリはIT部門の管轄外になるため、サポートは社内のコミュニティでのサポートのみとなります。ここで作られたアプリの重要度が増すと、IT部門へサポート依頼を行い、デジタルセルへと移行することもできます。このプロセスは重要で、現場のイノベーションを潰すことなく、自由度の高い環境を用意することで、業務改革が現場レベルから起こるのです。

 既定の環境

これはMicrosoft 365のプランについてくるPower Apps／Power Automateにもある、既定の環境です。ここで作れる・使えるものはMicrosoft 365の範囲内のみで、非常に限定的です。IT部門のサポートは受けず（もちろんMicrosoft 365のサポートは受けられますが）、チームや部署レベルの効率化・社員自身の効率化のためだけに使います。初心者はここで色々試し、トレーニングもこの環境またはトレーニング環境で受けます。慣れたらセルフサービスが使えるようになる、という社内制度を設ける会社もあります。

Dataverseの設定

環境構成を踏まえて設定できるのが、Microsoft Dataverse自体に対するセキュリティグループの設定です。極秘プロジェクトや、経理部門だけにアクセスさせたいなどの利用用途にセキュリティグループをDataverseへ設定することで、そのセキュリティグループのみが該当の環境へアクセスすることができます。

セキュリティグループの設定方法：環境へのユーザー アクセスのコントロール: セキュリティ グループおよびライセンス – Power Platform | Microsoft Docs

市民開発者とプロ開発者を共存させる

デジタルスタジオを除き、プロの開発者であっても、市民開発者であっても同じ環境を利用します。それによって、プロの開発者は自分が持っているAPIをカスタムコネクタとして社内で公開し、その公開されたコネクタを市民開発者に使ってもらうということが可能となります。よって、プロの開発者は画面周りの構築をする工数を減らし、APIの開発に集中するメリットもあり、市民開発者としては自分の好きな画面構成で、社内のシステムが使えるようになる、どちらにもメリットのある仕組みができあがります。

モバイル・タブレット端末の制御

モバイルやタブレット端末にはMicrosoft Intuneがインストールされています。そのため、万が一端末を紛失した場合でも、Intuneによって遠隔でデータを保護することができます。Power Apps もこのIntuneに対応しています。

Microsoft Intune の概要 – Azure | Microsoft Docs