クラウド フローの共有とアクセス許可に関するガイド

このガイドは、適切なフロー共有シナリオを特定し、ユーザー アクセスを管理してセキュリティを確保するためのアクセス許可を確立するのに役立ちます。

Power Automate 環境でのアクセス許可とロールを管理する

フローの作成、編集、実行を実行できるユーザーを管理することは、安全で秩序ある Power Automate 環境を維持するために不可欠です。 Power Automate のセキュリティモデルは、複数のアクセス許可のレベルで動作します。

• 環境レベルのロール (環境管理者や環境作成者など): 特定の環境におけるリソースの管理または作成に関するユーザーの権限を管理します。
• Dataverse セキュリティ ロール (環境に Dataverse データベースがある場合): Basic ユーザー、システム カスタマイザーなどのロールは、データとエンティティへのアクセスを制御します。 たとえば、ユーザーは通常、Dataverse データを使用するアプリやフローを実行するには、少なくとも「Basic ユーザー」の役割が必要です。
• フロー レベルのアクセス許可: 個々のフローの設定を共有して、他のユーザーを共同所有者 (編集権限を持つ) または実行専用ユーザーにします。

環境ロールとセキュリティ

各環境では、適切なロールを持つユーザーのみがリソースを作成または管理できます。

• 環境管理者: 環境に対する完全な管理コントロールを持っています。 環境管理者は、すべてのフローの表示、ユーザーの追加と削除、ポリシーの設定など、すべてのリソースを管理できます。 Dataverse がない環境では、この役割だけで管理タスクを実行できます。 Dataverse 対応環境では、Dataverse のシステム管理者ロールがデータ操作に関して同様の役割を果たします。

• 環境作成者: この ロール を使用すると、ユーザーは環境内にフロー、アプリ、接続などの新しいリソースを作成できます。 環境作成者の役割では、Dataverse の既存のデータへのアクセス権は付与されません。アーティファクトを構築、共有する権限のみが付与されます。 Microsoft は、事前定義されたロールに対して最小権限モデルを採用しています: 環境作成者は、表示が許可されていないデータを公開することなく、アプリ/フローを作成するために必要な最小限のアクセス権を持っています。 作成者は、必要に応じて、作成したアプリ/フローを組織内の他のユーザーと共有できますが、追加の Dataverse のロールが割り当てられていない限り、自分の権限を昇格してデータを読み取ることはできません。

• 環境ユーザー (Basic ユーザー): Dataverseに基づく環境では、通常のエンドユーザーには、アプリを実行したり、Dataverse データとやり取りするフローを利用したりするために、Basic ユーザーのセキュリティ ロール (Common Data Service ユーザーとも呼ばれる) を付与する必要があります。 既定では、ユーザーを環境に追加すると (特に環境に Dataverse データベースがある場合)、このような ロール を明示的に割り当てる必要がある場合があります。 これにより、ソリューションを実行できますが、データに対する権限は基本的なもののみとなります。 Dataverse のない環境では、ユーザーが実行専用のフローを共有している場合、手動で追加しない限り、環境ユーザー リストに表示されない場合があります。 アクセス許可は、フロー共有を通じてのみ行われます。

フロー レベルの共有アクセス許可

個々のフロー レベルでは、所有者は主に次の 2 つの方法でクラウド フローを共有できます: 共同所有者の追加、または実行専用ユーザーの割り当て。 違いを理解することが不可欠です。

• 所有者/共同所有者: 共同所有者は、フローの元の作成者と基本的に同じ特権を持ちます。 共同所有者は、実行履歴の表示、フローのデザインの編集、設定の変更、フローの開始と停止、接続の管理、他の所有者の追加と削除を行うことができます。 つまり、すべての共同所有者に完全なコントロールが与えられますが、元の作成者を削除することはできません。 共同所有者も、チーム フロー リストにフローを表示し、自分が作成したフローと同じように管理できます。 これらのアクセス許可は多岐にわたるため、信頼できる個人またはグループのみを共同所有者として追加する必要があります。

  例: Alice が Bob のフローの共同所有者である場合、Alice はそのフローを変更または削除できるため、Bob のチームは、そのようなアクセスが意図されている場合にのみ Alice を追加する必要があります。

• 実行専用ユーザー: 実行のみのユーザーは、通常、ボタンや SharePoint の項目トリガーなどの手動トリガーによって、フローの実行のみに制限されています。 フローを編集モードで開いたり、内部ロジックを表示したり、過去の実行履歴を表示したりすることはできません。 これは、同僚に自動化の恩恵を受けてもらいたいシナリオに最適です。 たとえば、ボタン フローやインスタント データ処理タスクを、設計権限を与えずに実行します。 実行専用ユーザーはフローの名前を表示して実行できますが、詳細を調べようとすると、表示が制限されます。 また、他のユーザーを追加したり、フローを変更したりすることもできません。

  例: ヘルプデスクには、チケットを作成して確認の返信を送信するための Power Automate ボタン フローがあります。 すべての現場担当者は実行専用ユーザーとして追加されるため、各自のデバイスからフローをトリガーできますが、フローの動作を変更することはできません。

リソース固有のセキュリティと環境ロールの比較

環境ロールとフロー共有権限は連携して機能します。 環境管理者、または特定の Dataverse 権限を持っているユーザーは、その幅広いアクセス権により、明示的な共有設定に関係なく、フローを表示または変更することができます。

• Power Platform 管理者または環境管理者は、個別に共有されていない場合でも、環境内のすべてのフローを表示、管理することができます。 たとえば、グローバル管理者は、必要に応じて自分自身を任意のフローに所有者として追加できます。
• 逆に、環境 ロール を持たないユーザーには、共有を通じて特定のフローへのアクセス権を付与できます。 この場合、そのユーザーはその 1 つのフローの特殊なケースの参加者になりますが、環境内の他のリソースにはアクセスできない可能性があります。

権限を効果的に管理するには、組織は、どのユーザーがフローの作成者 (作成者) であり、どのユーザーがフローの利用者* (実行者) であるかを正式に決定し、それに応じて役割を割り当てる必要があります。 次のセクションでは、これらの区別を実装し、リスクを最小限に抑えるためのベスト プラクティスについて説明します。

Power Automate のアクセス許可レベル - 所有者と実行専用ユーザー

フロー セキュリティの管理の重要な側面は、さまざまな共有アクセス許可レベルの機能を理解することです。 次の表は、クラウド フローの共同所有者と実行専用ユーザーの違いをまとめたものです。 Power Automate で、フローの共同所有者と実行のみのユーザーの権限と機能を比較します。

実際には、これらの違いは、共同所有者はフローの設計または保守で共同作業を行う必要があるユーザーに限定する必要があるのに対し、フローの機能を幅広く分散させるには実行専用の共有が推奨されることを意味します。 Microsoft のガイダンスでは、「フロー コラボレーションの共同所有者は、必要に応じてのみ追加してください。」と強調されています。 ほとんどの場合、フローを共有する必要がある場合は、実行専用のアクセス許可で共有します。これにより、ユーザーは、不正な変更やフロー内部の公開のリスクを負うことなく、自動化のメリットを享受できます。

環境外でフローを共有するリスクを軽減

環境のメンバーではないユーザーにフローへのアクセスを許可すると、いくつかのリスクが生じる可能性があります。

• ガバナンスの死角: 管理者は、誰がアクセス権を持っているかを把握していない可能性があります。
• データ漏洩の可能性: フローが機密データを処理する場合。
• 実行専用アクセス: トリガーがパラメーターの入力、または出力の可視化を許可している場合、変更管理が失われる可能性があるため、懸念点となる可能性があります。 これは、チーム外の共同所有者が意図しない編集を行った場合です。

これらのリスクを軽減するために、組織はポリシー、技術的制御、および監視の組み合わせを採用する必要があります。

• 環境のアクセス制御を適用する: 基本的なベストプラクティスは、Microsoft Entra (Azure AD) セキュリティ グループを使用して環境のメンバーシップを制限することです。 セキュリティ グループを環境に関連付けることで、そのグループに所属するユーザーのみがその環境のロールに追加できるようになります。 つまり、作成者がグループ外のユーザーとフローを共有しようとしても、そのユーザーは環境に自動的に追加されません。 関連付けられたセキュリティ グループがある環境では、そのグループに属していないユーザーは基本的に外部ユーザーとなり、管理者がアクセス権を付与するまで機能は制限されます。 この設定では、管理者がポリシーに従ってセキュリティ グループに明示的に追加しない限り、外部ユーザーが環境リソースにアクセスできません。

  たとえば、Contoso の HR Apps 環境が HR-Team セキュリティ グループに関連付けられている場合、財務部門のユーザーは、管理者が HR-Team グループに追加しない限り、HR Apps のフローの共同所有者にすることはできません。このようにセキュリティ グループを使用することで、組織は各環境の使用を承認されたユーザーの境界を明確に維持することができます。

• 共同所有権の確認と制限: 共同所有者とのフローの共有は慎重に行う必要があります。 各共同所有者は実質的にフローの完全な所有者になるため、共同所有者の数は必要な所有者のみに制限します。 フローがトラブルシューティングのために外部のユーザー (たとえば、別のチームの開発者やコンサルタント) と共有された場合は、問題が解決した後で、それらの共同所有権を必ず削除してください。 継続的な必要がない限りは削除してください。 組織は、環境外に共同所有者を追加するとアラートがトリガーされたり、承認が必要になったりするガバナンス プロセスを実装する場合があります。 これは、Power Automate ガバナン スツール (Power Platform 管理コネクターを使用して、フローに新しい所有者が追加されたことを検出する管理フローなど) を使用することで実現できます。 その後、IT 部門または Power Platform のセンター オブ エクセレンス チームに通知します。

• 外部ユーザーに実行専用共有を優先する: 環境メンバーではないユーザーと共有することが避けられない、または正当な理由がある場合は、可能な限り、完全な編集権限ではなく実行のみのアクセス許可を使用します。 実行専用アクセスにより、リスクが大幅に軽減されます: ユーザーはフロー ロジックを表示したり変更したりできず、機密性の高いペイロードを含む可能性のある過去の実行データを取得できます。

  たとえば、フローがメールで顧客データを送信する場合、実行専用ユーザーはそのメール送信をトリガーできますが、フローを開いて昨日処理された顧客の詳細を取得することはできません。 この原則は、ユーザーのロールに必要な最小限のアクセス権を付与するという、最小権限の原則と一致しています。 実行専用の共有では、多くの場合、制御を引き渡すことなく、だれかがフローをトリガーまたは利用できるようにするというビジネス要件を満たすことができます。

• セキュリティ ロールを使用して職務をセグメント化する: フローの実行のみを行い、作成は行わないユーザーには、環境作成者の役割が割り当てられていないことを確認してください。 これらのユーザーを基本環境ユーザーとして保持するか、実行専用のフロー アクセスのみを持つ環境外に保持することで、不正なフローを作成またはインポートする可能性を減らします。 指定された作成者のみが作成者特権を持つ必要があり、他のユーザーはフローの出力のみを使用する場合があります。

  詳細については、セキュリティ ロールとグループを使用する: 作成者と実行専用ユーザーを管理するを参照してください。

• データ損失防止 (DLP) ポリシーを実装する: DLP ポリシーはコネクタの使用を制御することを目的としていますが、共有フローが禁止されているコネクタを使用できないようにすることで、間接的にリスクの軽減にも役立ちます。 たとえば、部外者にフローへの実行専用アクセス権が与えられている場合、厳格な DLP ポリシーにより、フローが承認されていないサービスへのデータのプッシュを突然開始することはできません。 DLP は共有自体を停止しませんが、フローが偶発的または意図的に誤用された場合の潜在的な損害を制限します。 ベスト プラクティスとして、コネクタをビジネスと非ビジネスのカテゴリに分類し、危険な組み合わせをすべてブロックします。 これにより、フローが広く共有されていても、未承認のエンドポイントにデータが漏洩することはありません。

• 定期的な監査と監視: フローのアクセス許可を監査するルーチン (毎月、または四半期ごとなど) を確立します。 このレビューの一環として、通常とは異なる共有があるフロー (特に外部所有者や大規模な実行専用ユーザー リストを持つフロー) を特定します。 それでも必要な場合は、それらを確認します。 Microsoft のドキュメントでは、現在のビジネス ニーズに合わせて権限を定期的に確認し、アクセス権が不要になったユーザーのアクセス権を削除することを推奨しています。

  監視は自動化できます。 たとえば、管理者はすべてのフローとその所有者および最終更新日に関するレポートを送信する管理コネクタを使用して、Power Automate フローを設定できます。 フローでは、承認された個人の指定されたリスト以外の所有者を持つフローが強調表示されます。 さらに、Power Platform 管理者分析ダッシュボードの活用を検討してください。 全体的な使用状況を表示でき、各フローを実行しているユーザーの数を知るためにフィルター処理できる可能性があります。

• 作成者を教育してポリシーを適用する: 認識の欠如によってリスクが生じる場合があります。 共有に関する明確なポリシーを文書化し、伝達します (例: 承認なしに、環境 X 以外のユーザーを共同所有者に追加しないでください。チーム外のユーザーに必要な場合は、実行のみのアクセスを使用してください)。Power Automate の作成者にこれらのガイドラインに関するトレーニングを実施することで、偶発的な曝露を減らすことができます。 組織内に Power Platform コミュニティやチャンピオン ネットワークがある場合は、フローを広く共有することの影響について注意喚起を行ってください。 最終的には、ユーザーは Power Automate によって共有が簡単になる一方で、環境間のコラボレーションには、コンプライアンスとセキュリティに関する手順に従う必要があることを理解する必要があります。

• 広範な共有のために個別の環境を使用する: 場合によっては、幅広いユーザーが使用するフロー専用の環境を用意することが賢明な場合があります。 たとえば、組織は適切なセキュリティ グループを持つ多くのユーザーに開かれている 共有サービス 環境を作成できます。 広範な使用を目的としたフローは、制限された環境の外で共有するのではなく、そこで開発してホストできます。 このようにして、環境の境界が維持されます。 高度に管理された環境は厳格に保たれ、オープンな環境は適切な監視のもと、部門横断的な共有のために指定されています。 この戦略を採用する場合は、設計上、ユーザー ベースが大きくなるため、オープン環境に強力な DLP ポリシーと監視が引き続き適用されていることを確認してください。

• 直接共有ではなく、フローのコピーを検討する: 別の環境のユーザーがフローの機能が必要な場合は、ライブフローを共有する代わりに、フローをパッケージとしてエクスポートし、そのパッケージを共有するという方法もあります。 Microsoft では、ユーザーが Power Automate 環境のメンバーではない場合にこの方法を推奨しています。ユーザーにフローのコピーを送信し、ユーザーが自分の環境にインポートすることができます。 その後、受信者は独自の接続を設定し、フローを個別に実行します。 これにより、元の環境のフローへの直接アクセスを回避することでリスクを軽減できます。 本質的に、環境に影響を与えることなく解決策を提供します。 トレードオフは、フローに対する更新は別のコピーであるため、自動的に同期されないことです。 ただし、1 回限りのニーズや外部チームとの共有の場合は、この方法によりクリーンな分離が保証されます。

要約すると、フローの共有に伴うリスクを軽減するには、環境へのアクセスを厳格に管理し、共有オプションを慎重に使用し、注意深い監視を行うことが重要となります。 技術的な保護手段 (セキュリティ グループによって制御される環境や DLP ポリシーなど) とプロセス上の保護手段 (所有者の追加の承認や定期的な監査など) を組み合わせることで、組織は Power Automate のコラボレーションのメリットを享受すると同時に、セキュリティとコンプライアンスの問題を最小限に抑えることができます。

次のセクションでは、ガバナンスの特定の側面、つまり、ロールとグループを使用して、誰が作成者であるか、誰が単なるフローの実行者であるかを定義することに焦点を当てます。

セキュリティ ロールとグループを使用する: 作成者と実行専用ユーザーを管理する

重要なガバナンス上の決定事項としては、フローの作成と所有ができる「作成者」となるユーザーと、フローの実行のみに制限され、結果を利用できる「実行者」となるユーザーを決定する必要があります。 Power Automate と Power Platform は、主にセキュリティ ロールとセキュリティ グループを通じて、この区別を強制するいくつかのメカニズムを提供しています。

作成者と非作成者を区別する

エンタープライズ環境では、Power Automate のライセンスを持つすべてのユーザーが、必ずしもすべての環境でフローを構築する必要はありません。 設計上、環境作成者はその環境内にフローやその他のリソースを作成できます。 専用環境では、ソリューションの構築を担当するユーザーまたはグループにのみ、環境作成者 ロール を意図的に割り当てる必要があります。 たとえば、Finance Automation 環境では、財務 IT チームと少数のパワーユーザーのみに作成者の権限を付与すると決定する場合があります。

これは次の手順に従って修正できます:

• 環境作成者セキュリティ ロール を環境設定の特定のユーザーに直接割り当てます。
• Azure Active Directory (AD) セキュリティ グループを使用します。 対象となるすべての作成者をグループ (財務作成者グループ など) に追加し、環境に Dataverseがない場合は、そのグループ全体に環境作成者ロールを割り当てます。 Dataverse 機能対応環境では、グループメンバーを個別に追加するか、セキュリティ ロールを持つグループ チームを使用する必要がある場合があります。
• 広範な制御を行うには、環境をセキュリティグループに関連付けて、そのメンバーのみがその環境に入ることができるようにします。 そして、その中で、適切なサブセットに作成者の役割を付与します。 この 2 段階のアプローチにより、部外者が作成者として気付かれることなく参加することが不可能になり、内部者の中でも作成者としてのロールを担うのは一部の人たちのみとなります。 信頼できるガイダンスでは、環境セキュリティ グループ機能をすべての運用環境と機密性の高い環境に適用して、望ましくないユーザーの存在を防ぐことを推奨しています。

実行専用アクセスにセキュリティ グループを使用する

環境実行専用 ロール はありませんが、グループを使用して実行専用のアクセス許可を大規模に管理できます。 フローを共有する場合、所有者は、共同所有者または実行専用アクセスのいずれかについて、個々のユーザーではなくグループ名を入力できます。 営業レポート フロー ユーザーなどのセキュリティ グループを作成し、そのグループを関連するフローの実行専用ユーザーとして割り当てることができます。 その後、グループのすべてのメンバーが、それらのフローの実行アクセス許可を継承します。 管理が容易になります。 特定のユーザーのアクセス権を取り消すには、そのユーザーをグループから削除します。 そのグループが割り当てられていたすべてのフローへの実行アクセスが失われます。 同様に、新しいユーザーに複数のフローへの実行アクセス権を付与するには、そのユーザーをグループに追加します。 セキュリティグループは、このようにアクセス許可の管理を外部化することで、管理を簡素化するのに役立ちます。

Power Automate フローでは、実行のみを行う 50 人のユーザーをリストアップする必要はありません。1 つのグループをリストアップし、Azure AD または Microsoft 365 管理者がメンバーシップを処理します。

作成者と実行者のロールの割り当て

Dataverse 環境では、セキュリティ ロールを階層化することで、作成者と実行専用ユーザーが実行できる操作を微調整できます。

• 作成者: フローを作成するには、少なくとも環境作成者ロールが必要となります。 それらのフローが Dataverse のテーブルと相互作用する場合、それらを適切に設計およびテストするには、システム カスタマイザーなどの追加の Dataverse のロール、または特定のテーブルに対する権限も必要になる可能性があります。 環境作成者と、データ アクセスを許可する ロール (必要な場合) を組み合わせることで、完全なソリューションを構築できます。 作成者には必要な特権のみを付与するのがベスト プラクティスです。 たとえば、作成者が SharePoint とメールのみ自動化している場合、その環境にいること以外には、Dataverse のロールはまったく必要ない可能性があります。 ただし、Dataverse レコードを更新するフローを構築する場合、そのテーブルに対する権限が必要です。 セキュリティ ロールを、作成者に過度に広範なロールを付与するのではなく、必要に応じて作成者に個別の作成者のデータ ロールを付与するように計画してください。
• 実行専用ユーザー: これらのユーザーには、環境作成者は必要ありません。 環境に Dataverse データベースがあり、フローが Dataverse データにアクセスする場合、そのフローがコンテキストで実行されると、そのユーザーは、基礎となるデータへの読み取り/書き込みアクセス権を取得するために、基本ユーザーロール (または別のロール) が必要になる場合があります。 たとえば、手動のトリガーフローでは、実行者に代わって Dataverse レコードが作成される場合があります。 その場合、ランナーにはそのレコードを作成するためのアクセス許可が必要です。 実行専用ユーザーが接続を提供する オプションを使用する場合、フローは実行専用ユーザーの資格情報のコンテキストで実行されます。 そのような場合、フローが実行するアクションを実行するために必要な最小限の権限を、Dataverse ロールまたは関連するシステム権限を通じて、それらのユーザーに付与する必要があります。 フローが常に所有者の接続を使用する場合、実行のみのユーザーは Dataverse で特別な役割を必要としない場合があります。ユーザーはボタンを押すだけで、フローは所有者の権限を使用します。 このニュアンスは慎重に検討する必要があります。 安全なアプローチは、実行専用のユーザーに、表示できるデータへの読み取りアクセス権を付与し、それ以上は許可しないことです。 多くの企業では、この要件を満たすために、カスタム Dataverse ロールを作成するか、最小限の読み取り権限を持つ「Basic ユーザー」を使用して、すべてのエンド ユーザーに割り当てて、アプリやフローを実行しています。

ガバナンスを念頭に置いてロールを管理する

誰がどのロールを持っているかを追跡します。 Power Platform 管理者は、管理センターまたは PowerShell から、環境内のすべてのユーザーと、それらに割り当てられたセキュリティ ロールを一覧表示できます。 これは、予想される作成者のリストと相互参照できます。 インベントリを管理することは、ガバナンスのベストプラクティスです。例: 環境 X の作成者: Alice、Bob、Carol; 環境 X 実行のみ/利用者: マーケティング部門の全ユーザー。 この点を明確にすることで、新しい作成者の追加要求があったときに、その作成者がグループによって承認されているかどうかを確認したり、サークルを広げるために必要な承認を得たりすることができます。

シナリオと例

次の一覧では、いくつかのシナリオとその解決策の例を示します。

• シナリオ : 部門内の環境において、フローを構築するのは少人数のチームのみですが、部門内の多くの従業員がそれらを実行しています。
• ソリューション: 部門の IT リーダーは、環境管理を任されています。Azure AD グループ 部門の作成者 には、アプリとフローを作成する 5 人が所属しています。 そのグループが環境作成者 ロール に追加されます。 これは直接行われるか、グループ割り当てが利用できない場合は個人が割り当てられます。 部門内の全員が、環境に関連付けられている部門ユーザー グループに所属しているため、全員がユーザーとしてアクセスできます。 部門全体で実行する必要がある環境で作成されたフローは、実行専用として部門ユーザー グループと共有されます。 このようにして、作成者はビルドして共有します。 部署のメンバーは実行できますが、部署外のユーザーは環境のグループに属していないためアクセスできません。
• シナリオ: 機密性の高いフローを含む運用環境で、2 人のソリューション所有者以外は編集できません。
• ソリューション: この 2 人だけが環境作成者です。 他に作成者のロールを持つ人はいません。 他のユーザーがフローをトリガーする必要がある場合は、実行専用のアクセス権が付与されます。 場合によっては、専用のサービス アカウントまたはサービス プリンシパルが実際には安定性のためのフローの所有者であり、2 人の所有者がメンテナンスの共同所有者である可能性があります。 サービス プリンシパルをプライマリ所有者として使用すると、クリティカル フローのガバナンスが向上します。 正社員は、その環境にはいないか、ユーザー ロールのみを持っています。 環境は、排他性をさらに保証するために、必要なアカウントのみを含むセキュリティ グループに関連付けることができます。
• シナリオ : ガバナンス チームがすべての環境にわたる監視フローを構築する、センター オブ エクセレンス環境です。
• ソリューション: センター オブ エクセレンス チームのみがアクセスできます。 環境作成者のロールが付与されています。 これらのフローはより内部的なものであるため、実行専用の共有は必要ありません。 ここでは、重要なセンター オブ エクセレンスのメンバーは、テナントレベルで Power Platform 管理者のロールを付与されており、これにより、すべての環境に対するアクセス権が暗黙的に付与されています。

ロール分離の利点

作成者とランナーを明確に区別することで、次のことを実現します。

• 最小特権: ユーザーは必要なアクセス許可のみを取得します。 実行専用ユーザーにはロールがないため、ITの監視をバイパスするフローの作成をいきなり開始することはできません。 作成者は自由に作成できますが、その人口は少なく、知られているため、より簡単にトレーニングして監視できます。
• ライフサイクル管理の簡素化: 従業員が退職したりロールが変わったりした場合、アクセス権を簡単に更新できます。 たとえば、Joe が作成者で、チームを離れる場合は、作成者セキュリティ グループから削除します。 その環境での作成と編集は即座にできなくなりますが、ユーザー グループに残っている場合は実行アクセス権が保持されます。 その後、彼の後任を Makers グループに追加できます。 このグループベースのメンテナンスは、何十ものフローのアクセス許可を手動で追加および削除するよりも簡単です。
• コンプライアンスの調整: 多くの規制では、アクセスの制御が求められています。 この環境では、これらの特定の個人だけが自動化を変更でき、他の者は承認されたフローを起動することしかできないことを監査人に示すことができるため、強力な内部統制の実証に役立ちます。 監査人は、施行の証拠として、環境ロールの割り当てのエクスポートを与えることもできます。
• 混乱を避ける: 誰もが作成権限を持っている場合、技術的な知識のあるユーザーが誤ってフローを作成したり変更したり、Power Automate インターフェースに戸惑ったりするケースが少なくなる可能性があります。 作成者ロールを制限することで、トレーニングを受けた担当者のみがフローを設計できるようにし、ミスを減らすことができます。

これらの対策は定期的に見直す必要があります。 ビジネス ニーズの変化に伴い、利用者が作成者になる必要性が生じたり (新しいチームにパワーユーザーが加入するなど)、作成者が利用者になる必要が生じたりする場合があります。 ガバナンス モデルは、適切な承認があればこれに対応できる柔軟性を備えている必要があります。 環境作成者の特権を付与するための条件と、それを要求するためのプロセスを文書化し、透明性と一貫性を確保します。 同様に、作成者アクセス権の取り消し (別の部署への移動など) をトリガーできる条件を定義します。

セキュリティ ロールとグループを連携させることで、組織は自動化を作成するユーザーと自動化を使用するユーザーを明確かつ保守可能な形で分離できます。 これにより、Power Automate 環境のセキュリティと生産性の両方が向上します。

関連情報

• 環境外のユーザーとの共有フローを管理する
• クラウド フローを共有する