Power Platform Administrator 勉強会 #08『クラウドフローによる環境設定の自動監視』

本稿は以下で発表した内容。

本稿では、Dataverseカスタムプラグインを全Environmentから自動収集・検知する監査フローをPower Automate（クラウドフロー）で実装した例を紹介する。

1. 対象読者

Power Platform管理者として、テナント全体のPower Platformの管理を任されている人。特に、ガバナンスにうるさい組織に属している人には嬉しいかも。

2. 背景

Power Platformの運用において、Power Platform管理者（IT/DXチーム）だけで、全ての環境管理を担うのは現実的ではない。

そのため、利用部署への環境管理権限（System Administratorロール）の委譲を前提としたガバナンスモデルを採用するケースが一般的。

ただし、「環境管理権限の委譲」と「監査」は常にトレードオフとなる。すなわち、環境設定が会社のルール通り適切に行われていることを確認するという、新たな課題が発生する。しかしながら、標準機能には環境設定をモニタリングする機能が用意されておらず、手作業に頼らざるをえない。

そこで、本稿では環境設定のモニタリングをPower Automateクラウドフローにより自動実行する方法を紹介する。

3. Power Platform標準機能等との比較

標準的なモニタリング機能と本稿手法を比較してみる。
標準的な機能としては、

1. Power Platform Admin Center（PPAC）
2. Purview監査ログ（Power Platform）
3. Dataverse監査ログ
4. CoE Starter Kit

監査項目の分類は以下。

分類	意味	PPAC	Purview	Dataverse	CoE SK	本稿手法
資産存在	何が存在しているか（作られているか）	〇			〇
利用状況	誰が・いつ・何を操作／実行したか		〇	△	〇
設定状態	現在どのような設定・構成になっているか	△				〇

だいぶおおざっぱではあるが、標準的な機能は、何が存在するか、使われているかをとらえるには優れているが、設定状態を網羅的に把握するのは難しい。

本稿手法は、この 設定状態把握の空白領域 を補完するもの。

詳細表（未検証）

生成AIに作らせたもので全然未検証。なんとなく各ツールの役割の雰囲気を感じるためのものなので、、

監査項目分類	監査項目	PPAC	Dataverse監査ログ	Power Platform Activity Log	CoE Starter Kit	本稿手法
資産存在	Environmentの存在	✅	–	–	✅	–
資産存在	Environment作成者	✅	–	✅	✅	–
資産存在	アプリInventory	✅	–	–	✅	–
資産存在	フローInventory	✅	–	–	✅	–
資産存在	Custom Connector定義	–	–	–	–	✅
資産存在	Dataverse PluginAssembly存在	–	–	–	–	✅
利用状況	アプリ／フローの実行状況	–	–	✅	✅	–
利用状況	Connector使用ログ	–	–	✅	✅	–
利用状況	Dataverseレコード操作履歴	–	✅	–	–	–
利用状況	Plugin実行ログ（Trace）	–	✅	–	–	–
利用状況	フロー共有履歴	–	–	✅	✅	–
利用状況	Maker操作履歴	–	–	✅	✅	–
設定状態	DLPポリシー適用状態	✅	–	–	✅	–
設定状態	Environmentセキュリティグループ	✅	–	–	–	✅
設定状態	Environment管理設定値	–	–	–	–	✅
設定状態	IP制限・ネットワーク設定	–	–	–	–	✅
設定状態	Environment Logging設定	–	–	–	–	✅
設定状態	Premium Connector許可状態	–	–	–	–	✅
設定状態	System Administrator割当状況	–	–	–	–	✅
設定状態	Plugin Publisher情報	–	–	–	–	✅
設定状態	External通信可能Plugin	–	–	–	–	✅

そして、設定状態のうち、特に注意すべきなのが、Dataverseプラグイン。本稿手法では、Dataverseのプラグインの存在有無のモニタリングを行う。

その理由

Dataverseプラグインは、Dataverseの拡張機能で、任意コード（C#）の実行が可能。

さらに問題なのは、Dataverseプラグインの登録・更新・削除はDataverse監査ログに記録されない点。つまり、Dataverse監査ログを見ていても、誰が追加したかを追跡することができない。

4. モニタリングフローの説明

4.1. 概要

フローはPower Platform管理者権限で実行。

処理の概要は以下:

1. Dataverse有効環境をループ
   1. 自己昇格
   2. Dataverseプラグインの有無確認
2. 結果をSharePointにJSONで保存
3. プラグイン存在時にメール通知

自己昇格を行うことで、 Power Platform管理者が、環境管理者ではない場合でも、環境設定の取得が可能。 本稿の例はプラグインを対象とするが、自己昇格は環境設定値の自動取得でも利用可能。したがって、同様の仕組みで、環境設定値のモニタリングが可能。

フロー詳細は以下:

4.2. 処理詳細

ポイントだけ解説。

List Environments as Admin

Power Platform for Admins Connector を用いてテナント内の環境一覧を取得。

その後、以下条件に、 Dataverseが存在する環境のみ を対象として抽出。

linkedEnvironmentMetadata.instanceUrl != null

Apply the system administrator role to the selected user

フロー実行者はPower Platform管理者を前提とするが、各環境管理者を兼ねている訳ではない。その場合、プラグインの有無を確認できない（PluginAssemblyテーブルが読めない）ため、 自己昇格 により、一時的に環境管理者権限を付与。

List rows from selected environment

プラグインはDataverseのPluginAssemblyテーブルに保存されているため、Dataverseからデータを取得。ただ、ユーザーが作成したもの以外のプラグインも存在するため、判定のためのテーブルも取得。

取得対象テーブル:

• PluginAssembly
• Solution
• Publisher
• SystemUser

Fetch XML Queryで取得すると楽。

クエリ

<!-- 右1（solutions）に左外部結合 -->
<link-entity name='solution' from='solutionid' to='solutionid' link-type='outer' alias='sol'>
  <attribute name='friendlyname' alias='sol_friendlyname' />
  <attribute name='uniquename' alias='sol_uniquename' />
  <attribute name='version' alias='sol_version' />
  <attribute name='ismanaged' alias='sol_ismanaged' />
  <attribute name='isvisible' alias='sol_isvisible' />
  <attribute name='publisherid' alias='sol_publisherid' />

  <!-- 右2（publishers）に左外部結合：solution.publisherid → publisher.publisherid -->
  <link-entity name='publisher' from='publisherid' to='publisherid' link-type='outer' alias='pub'>
    <attribute name='friendlyname' alias='pub_friendlyname' />
    <attribute name='uniquename' alias='pub_uniquename' />
    <attribute name='description' alias='pub_description' />
    <attribute name='createdby' alias='pub_createdby' />
    <attribute name='createdbyname' alias='pub_createdbyname' />
    <!-- ここで systemuser に join -->
    <link-entity name="systemuser" from="systemuserid" to="createdby" link-type="outer" alias="cb">
        <attribute name="fullname" alias="pub_createdby_formatted" />
    </link-entity>
  </link-entity>
</link-entity>

取得結果を基に、ユーザー作成プラグインかどうかを判定する。
Microsoft標準Pluginの特徴として、

条件	内容
Publisher CreatedBy	SYSTEM
FriendlyName	defaultを含む
UniqueName	defaultを含む

という傾向があるため、以下を満たさないPluginをユーザー作成プラグインとして判定。

Create File

環境単位で以下の情報を収集。

{
  "environment_id": "",
  "environment_name": "",
  "number_of_all_plugin": "",
  "number_of_ms_plugin": "",
  "number_of_custom_plugin": "",
  "custom_plugin": []
}

すべての環境の結果をJSON形式で監査ログとしてSharePointへ蓄積。

dataverseプラグイン監視_yyyyMMdd-HHmmss.json

Send an email (V2)

number_of_custom_plugin > 0

のEnvironmentのみ抽出し、監査担当者へメール通知。

5. まとめ

標準機能等では難しい環境設定値のモニタリングについて、本稿ではPower Automateクラウドフローにより実現した。

技術的なポイントとしては、自己昇格を挟むことで、Power Platform管理者が環境管理者となっていない環境に対しても、環境設定値を取得可能となる点である。

本稿ではモニタリング対象をDataverseプラグインとしたが、Dataverseから取得するデータを変更することで、他の環境設定値の取得に変更することも可能。

結果的に、環境管理の委譲と環境設定値のモニタリングの両立のサポートとなる。

同様の課題を抱えているPower Platform管理者の参考になれば幸いである。

6. 感想

• 自己昇格なんて仕組み知らなかったよ。これがあるとテナント管理者と環境管理者を分けられてグッド。
• Fetch XMLを使ったデータ取得が便利すぎた。テーブル結合とか。
• APIを直接呼ぼうとしたけど無理だったんだよなぁ。

7. 参考

自己昇格