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

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

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

誰がフローを作成、編集、または単に実行できるかを管理することは、Power Automate 環境の安全性と秩序を維持するために極めて重要です。 Power Automate のセキュリティモデルは、複数の権限レベルに基づいて機能します:

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

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

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

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

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

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

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

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

• 所有者/共同所有者: 共同所有者は、フローの元の作成者と基本的に同じ特権を持ちます。 共同所有者は、実行履歴の確認、フローの設計の編集、設定の変更、フローの開始と停止、接続の管理、および他の所有者の追加や削除を行うことができます。 つまり、共同所有者には完全な管理権限が与えられますが、元の作成者を削除することはできません。 共同所有者も、チーム フロー リストにフローを表示し、自分が作成したフローと同じように管理できます。 これらの権限の範囲が広いため、共同所有者として追加するのは、信頼できる個人またはグループに制限する必要があります。

  たとえば、Alice が Bob のフローの共同所有者である場合、Alice はそのフローを変更または削除することができます。したがって、Bob のチームは、そのようなアクセス権を付与する意図がある場合にのみ、Alice を追加する必要があります。

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

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

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

環境ロールとフロー共有権限は連携して機能します。 環境管理者である場合や、特定の Dataverse 権限を持っている場合、アクセス権限が広範囲に及ぶため、明示的な共有設定にかかわらず、フローを表示または変更できる場合があります。

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

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

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 Admin Analytics のダッシュボードを活用することも検討してください。 全体的な利用状況を確認でき、さらにフィルターを行うことで、各フローを実行しているユーザー数を把握することができます。

• 作成者を教育してポリシーを適用する: 認識の欠如によってリスクが生じる場合があります。 共有に関する明確なポリシーをドキュメント化し、周知徹底ます。たとえば、環境 X 以外のユーザーを、承認なしに共同所有者として追加してはならないなど。チーム外のユーザーに対しては、必要な場合に限り実行専用アクセス権を使用します。Power Automate の作成者に対してこれらのガイドラインを周知徹底することで、意図しない情報漏洩を防ぐことができます。 組織内に Power Platform のコミュニティや推進者ネットワークがある場合は、フローを広く共有することの影響について、リマインダーを共有します。 結局のところ、ユーザーは、Power Automate によって共有が容易になる一方で、環境をまたぐコラボレーションを行う際には、コンプライアンスやセキュリティに関する手順を遵守する必要があることを理解しておく必要があります。

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

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

要約すると、フローの共有に伴うリスクを軽減するには、環境へのアクセスを厳格に管理し、共有オプションを慎重に使用し、注意深い監視を行うことが重要となります。 技術的な保護策 (セキュリティ グループで管理された環境や 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 のデータにアクセスする場合、そのフローがユーザーのコンテキストで実行される際に、基盤となるデータへの読み取り/書き込みアクセス権を得るためには、「Basic ユーザー 」ロール (またはその他のロール) が必要になる可能性があります。 たとえば、手動トリガーフローでは、実行者の代わりに Dataverse レコードが作成される場合があります。 その場合、ランナーはそのレコードを作成するアクセス許可が必要です。 実行専用ユーザーが接続を提供する オプションを使用する場合、フローは実行専用ユーザーの資格情報のコンテキストで実行されます。 そのような場合、フローが実行する操作を実行するために必要な最低限の権限を、Dataverse のロールまたは関連するシステム権限を通じて、それらのユーザーが確実に保有していることを確認する必要があります。 フローが常に所有者の接続を使用する場合、実行専用ユーザーは Dataverse で特別なロールを必要としない可能性があります。これはそのユーザーがボタンを押すだけで、フローが所有者の権限を使用するためです。 このニュアンスは慎重に検討する必要があります。 安全なアプローチは、実行専用ユーザーに対しては、表示可能なデータへの読み取りアクセス権のみを付与し、それ以上の権限は与えないようにすることです。 多くの企業では、アプリやフローを実行するという要件を満たすために、カスタム Dataverse ロールを作成するか、最小限の読み取り権限を持つ「Basic ユーザー」を使用し、それをすべてのエンド ユーザーに割り当てています。

ガバナンスを念頭に置いたロールの管理

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

シナリオと例

以下のリストでは、いくつかのシナリオと、それらに対する解決策の例を説明します。

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

ロール分離のメリット

作成者とランナーを明確に区別することで、以下のことが実現できます:

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

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

セキュリティ ロールとグループを組み合わせて使用することで、組織は自動化を構築する担当者と、自動化を利用する担当者の役割を明確かつ維持しやすい形で分離できます。 これにより、Power Automate 環境におけるセキュリティと生産性の両方が向上します。

関連情報

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