本指南可帮助确定合适的流共享方案，并建立权限以管理用户访问并确保安全性。
管理 Power Automate 环境中的权限和角色
管理谁可以创建、编辑或仅执行流对于维护一个安全有序的 Power Automate 环境至关重要。 Power Automate 的安全模型基于多个权限级别：
- 环境级角色（如环境管理员和环境创建者）：控制用户在指定环境中管理或创建资源的能力。
- Dataverse 安全角色（如果环境包含 Dataverse 数据库）：如基本用户、系统自定义者等，用于控制对数据和实体的访问权限。 例如，用户通常需要至少具备基本用户角色才能运行使用 Dataverse 数据的应用程序或流。
- 流级权限：在单个流中设置共享权限，使其他用户成为共同所有者（具备编辑权限）或仅具备执行权限的用户。
环境角色与安全
在每个环境中，只有具有相应角色的用户才能创建或管理资源。
环境管理员：对环境拥有完全的管理控制权。 环境管理员可以管理所有资源，包括查看所有流、添加和删除用户以及设置策略。 在未启用 Dataverse 的环境中，该角色可独立执行管理任务。 在启用 Dataverse 的环境中，Dataverse 中的系统管理员角色在数据操作方面具有类似功能。
环境创建者：该角色允许用户在环境中创建新的资源，如流、应用程序和连接。 环境创建者角色不授予访问 Dataverse 中现有数据的权限——它仅授予创建和共享资源的能力。 Microsoft 遵循预定义角色的最小权限模型：环境创建者仅拥有创建应用程序/流所需的最低权限，且不会暴露其无权查看的数据。 创建者可按需与组织内其他成员共享所创建的应用程序/流，但无法自行提升权限以读取数据，除非被授予额外 Dataverse 角色。
环境用户（基本用户）：在 Dataverse 支持的环境中，普通终端用户必须被授予基本用户安全角色（有时称为 Common Data Service 用户），才能运行应用程序或使用与 Dataverse 数据交互的流。 默认情况下，将用户添加到环境时（尤其是环境包含 Dataverse 数据库时），可能需要显式分配此类角色。 这可确保他们可以运行解决方案，但仅具有数据的基本权限。 在不包含 Dataverse 的环境中，若用户仅被共享为只读流程，则可能不会出现在环境用户列表中，除非手动添加。 其权限仅通过流共享实现。
流级共享权限
在单个流程级别，所有者可以以两种主要方式共享云端流：添加共同所有者，或分配仅运行用户。 了解其中的区别至关重要。
所有者/共同所有者：共同所有者与流的原始创建者具有相同的权限。 共同所有者可以查看运行历史记录、编辑流的设计、更改其设置、启动和停止流、管理连接以及添加或删除其他所有者。 换句话说，任何共同所有者都可以完全控制，除非他们不能删除原始创建者。 共同所有者还可以在其团队流程列表中显示该流，并像管理自己创建的流一样管理它。 由于这些权限的广度，因此仅应将受信任的个人或组添加为共同负责人。
示例：如果 Alice 是 Bob 流的共同所有者，则 Alice 可以修改或删除该流，因此 Bob 的团队应仅在打算进行此类访问时添加 Alice。
仅执行用户：仅执行用户仅限于执行流，通常通过手动触发器（如按钮或 SharePoint 项触发器）进行。 他们无法在编辑模式下打开流、查看其内部逻辑或查看过去的运行历史记录。 这非常适合希望同事从自动化中受益的场景。 例如，运行按钮流或即时数据处理任务，而无需授予其设计权限。 仅执行用户可以查看流名称并执行流，但若尝试查看详细信息，其可见范围将受限。 他们也不能添加其他人或以任何方式更改流。
示例：客服中心有一个 Power Automate 按钮流用于创建工单并发送确认通知。 所有一线员工均被添加为仅执行用户，以便他们可从设备触发流，但无法修改流功能。
资源特定安全权限与环境角色
环境角色和流共享权限协同工作。 作为环境管理员或拥有某些 Dataverse 权限的用户，可以查看或修改流，而无需明确共享，因为他们具有广泛的访问权限。
- Power Platform 管理员或环境管理员本质上可以查看和管理环境中的所有流，即使未单独与他们共享。 例如，如果需要，全局管理员可以将自己作为所有者添加到任何流中。
- 相反，没有环境角色的用户可以通过共享获得对特定流的访问权限。 在这种情况下，该用户将成为该流的特殊案例参与者，但可能无权访问环境中的其他资源。
为了有效管理权限，组织应明确哪些用户是流制作者（创建者）而哪些是流消费者*（运行者），然后相应地应用角色。 以下各节介绍了实施这些区别和将风险降至最低的最佳实践。
Power Automate 中的权限级别—所有者与仅运行用户
管理流安全性的一个关键方面是了解不同共享权限级别的功能。 下表汇总了云端流的共同负责人和仅运行用户之间的差异。 它比较了在 Power Automate 中流共同所有者与仅运行用户的权限和能力。
| 能力/访问 | 共同所有者（可编辑） | 仅运行用户（可以运行） |
|---|---|---|
| 查看和编辑流定义 | 是的。 具有查看和修改流的步骤、设置和连接的完全访问权限。 | 不支持。 无法在编辑器中打开流或获取其配置。 他们只获得运行接口。 |
| 运行/触发流 | 是的。 可以手动运行流和修改触发器。 | 是的。 可以在流所有者允许的情况下触发流（例如，选择按钮或使用指定的触发器操作）。 |
| 查看运行历史记录（执行日志） | 是的。 可以查看过去的运行、成功和失败状态以及运行历史记录中的输出。 | 不支持。 无法显示流的运行历史记录或过去执行的详细信息。 |
| 管理流（启用/禁用、重命名、删除） | 是的。 可以更改流属性、打开或关闭流、更新连接以及完全删除流。 | 不支持。 无法更改流的状态或设置。 他们只有调用它的权限。 |
| 与他人共享流 | 是的。 可以添加或删除其他共同所有者，但他们无法删除原始创建者。 还可以分配仅运行用户。 | 不支持。 无法与其他任何人共享流。 他们是访问的受益者，而不是访问的授予者。 |
| 使用自有连接（调用者） | 不适用。 共同负责人使用流定义的连接。 如有需要，他们可以更新连接。 | 视情况而定。 仅运行用户在运行流时可能需要使用自有连接，如果流配置为由仅运行用户提供连接器。 否则，流将使用所有者的连接。 |
| 在 Power Automate 用户界面中的可见性 | 显示在“所有所有者的团队流”下。 共同所有者的名称列在所有者列表中。 | 在流的仅运行用户列表（流详细信息页面）中显示给所有者；然而，仅运行用户仅在能够运行流的上下文中获得流（例如，在按钮上或应用程序内；不在其拥有的或团队流下列出）。 |
在实践中，这些区别意味着共同所有者应仅限于真正需要协作进行流设计或维护的用户，而对于流功能的广泛分发，仅运行共享是首选。 Microsoft 的指南强化了这一点：“仅根据需要为流协作添加共同负责人。 在大多数情况下，如果需要共享流，请使用仅运行权限共享它。这确保了用户可以从自动化中受益，而不会冒着未经授权的修改或暴露流动内部的风险。
降低在其环境外部共享流的风险
允许不是环境成员的用户访问流可能会带来一些风险：
- 治理盲点：管理员可能无法意识到谁具有访问权限。
- 潜在数据暴露：如果流处理敏感数据。
- 仅运行访问权限：如果触发器允许参数输入或输出可见性，且失去变更控制，这可能成为问题。 这是团队外部的共同负责人进行意外编辑的时候。
为了降低这些风险，组织应采用策略、技术控制和监控的组合。
强制执行环境访问控制：基本最佳实践是使用 Microsoft Entra (Azure AD) 安全组限制环境成员资格。 通过将安全组与环境关联，仅该组中的用户可被添加到环境的角色中。 这意味着，即使创建者尝试与组外的某个人共享流，也不会自动将此人添加到环境中。 在与安全组关联的环境中，未加入该组的任何用户本质上都是外部人员，且在管理员授予访问权限前其权限受限。 此配置会阻止外部人员访问环境资源，除非管理员根据策略明确将他们添加到安全组中。
例如，如果 Contoso 的
HR Apps环境与HR-Team安全组相关联，财务部门的用户无法成为HR Apps中流的共同所有者，除非管理员首先将其添加到HR-Team组中。以这种方式使用安全组有助于组织明确界定每个环境的授权使用范围。审查并限制共同所有权：与共同所有者共享流程应谨慎进行。 每个共同所有者实际上都成为流的完全所有者，因此请将共同所有者的数量限制为仅必要的那些。 如果与外部人员（例如，来自其他团队的开发人员或顾问）共享流以进行故障排除，请确保在问题解决后删除其共同所有权。 除非存在持续需求，否则不应进行此操作。 组织可以实施治理流程，其中在环境外部添加共同负责人会触发警报或需要审批。 这可以通过使用 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 环境成员的场景下采用此方法——您可以向他们发送流的副本，供其导入到自己的环境中。 然后，接收方设置自己的连接并独立运行流。 这样可以避免直接访问原始环境的流，从而降低风险。 它本质上是将解决方案交给他们，而不会让他们在您的环境中立足。 权衡是，流的任何更新都不会自动同步，因为它是一个单独的副本。 但是，对于一次性需求或与外部团队共享，此方法可确保干净的分离。
总而言之，降低与共享流相关的风险在很大程度上归结为对环境访问的严格控制、谨慎使用共享选项和警惕的监督。 通过结合技术防护措施（如安全组控制的环境和数据丢失防护策略）与流防护措施（如添加所有者的审批流和定期审计），组织可以在享受 Power Automate 协作优势的同时，最大限度地减少安全和合规问题。
以下部分重点介绍治理的一个特定方面：使用角色和组来定义谁是创建者，谁只是流的运行者。
使用安全角色和组：管理制作者与仅运行用户
一个关键的治理决策是确定哪些用户应为创建者（可创建并拥有流），哪些用户仅限于运行流（可能仅消费结果）。 Power Automate 和 Power Platform 提供了多种机制来强制执行此区分，主要通过安全角色和安全组实现。
区分创客和非创客
在企业场景中，并非每个拥有 Power Automate 许可证的用户都应在每个环境中构建流。 根据设计，环境创建者可以在该环境中创建流和其他资源。 对于专用环境，应有意将“环境创建者”角色仅分配给负责构建解决方案的用户或组。 例如，您可能决定在财务自动化环境中，仅财务 IT 团队和少数高级用户拥有创建者权限。
通过以下方式强制执行此操作：
- 在环境设置中将环境创建者安全角色直接分配给特定用户。
- 使用 Azure active directory (AD) 安全组。 将所有目标创建者添加到一个组（例如，财务创建者组），如果环境中没有 Dataverse，则将整个组分配为环境创建者角色。 在 Dataverse 启用的环境中，您可能需要单独添加组成员或使用具有安全角色的组团队。
- 为了实现广泛控制，将环境与安全组关联，以便只有组成员才能进入该环境。 然后，在其中，将 Maker 角色授予相应的子集。 这种两级方法意味着外部人员无法未经检测地被引入为创建者，而在内部人员中，只有部分人拥有创建者角色。 权威指南建议将环境安全组功能应用于所有生产和敏感环境，以防止未经授权的用户存在。
使用安全组进行仅运行访问
虽然没有“环境仅运行”角色，但您可以通过组来大规模管理仅运行权限。 在共享流时，所有者可以输入组名称而非单个用户，以授予共同所有者或仅运行访问权限。 这意味着您可以创建一个名为销售报告流用户的安全组，并将该组分配为相关流的仅运行用户。 然后，组的所有成员都将继承这些流的运行权限。 管理变得更容易。 要撤消特定用户的访问权限，请将其从组中删除。 他们将失去对该组被分配的所有流的运行访问权限。 同样，要为新用户授予多个流的运行权限，只需将其添加到该组中。 安全组通过将权限管理外部化，从而简化了权限管理流。
Power Automate 流无需列出 50 个运行仅限用户；只需列出一个组，然后由 Azure AD 或 Microsoft 365 管理员处理成员资格。
备注
如果环境本身锁定为安全组，则用于流共享的组应为同一组或子集。 若与包含环境允许用户范围外人员的组共享流，他们可能无法实际运行该流，具体取决于环境设置。 您应根据环境访问策略协调组使用情况。
创建者与运行者的角色分配
在 Dataverse 环境中，可通过分层安全角色精细控制创建者与仅运行用户的能力。
- 创建者：至少需具备环境创建者角色才能创建流。 如果他们的流与 Dataverse 表交互，他们可能还需要额外的 Dataverse 角色（如系统自定义者）或特定表的权限，以正确设计和测试这些流。 环境创建者与授予数据访问权限的角色（如果需要）相结合，使他们能够构建完整的解决方案。 建议仅授予创建者所需的权限。 例如，如果一个制作者仅自动执行 SharePoint 和电子邮件，他们可能根本不需要 Dataverse 角色，只需存在于环境中即可。 然而，如果制作者构建一个流来更新 Dataverse 记录，他们需要对该表的权限。 规划安全角色时，如果必要，应为制作者分配一个单独的制作者数据角色，而不是授予他们过宽的角色。
- 仅运行用户：这些用户不需要环境制作者。 如果环境有一个 Dataverse 数据库，且流涉及 Dataverse 数据，他们可能需要基本用户角色（或其他角色），以便在流以他们的上下文运行时，对底层数据具有读写权限。 例如，手动触发流可能会代表运行者创建一个 Dataverse 记录。 如果是这样，则运行器需要权限才能创建该记录。 当使用仅运行用户提供连接选项时，流将在仅运行用户的凭据上下文中执行。 在这种情况下，必须确保这些用户通过 Dataverse 角色或相关系统权限获得执行流操作所需的最小权限。 如果流始终使用所有者的连接，则仅运行用户可能无需在 Dataverse 中拥有特殊角色——他们只需点击按钮，流便会使用所有者的权限。 应仔细考虑这种细微差别。 一种安全做法是为仅运行用户授予仅读取其可显示数据的权限，且不授予更多权限。 许多公司会创建自定义 Dataverse 角色或使用具有最小读取权限的基本用户，并将该角色分配给所有最终用户以满足运行应用和流的要求。
在管理角色时考虑治理
跟踪谁扮演什么角色。 Power Platform 管理员可通过管理中心或 PowerShell 列出环境中的所有用户及其分配的安全角色。 这可以与预期的制造商列表进行交叉引用。 保持资产清单是治理的最佳实践，例如：环境 X 制作者：Alice、Bob、Carol；环境 X 仅运行用户/消费者：市场部所有用户。 通过明确这一点，当收到添加新制作者的请求时，您可以检查他们是否已获得组批准，或获取必要的批准以扩大范围。
场景与示例
以下列表阐述了部分场景及其对应的解决方案示例。
- 场景：部门环境中仅需一小部分团队构建流，但部门内多人需运行这些流。
- 解决方案：部门 IT 负责人被授予环境管理员权限。一个 Azure AD 组部门制作者包含负责创建应用和流的五名成员。 该组将添加到“环境创建者”角色中。 这可以直接完成，也可以在组分配不可用时分配个人。 部门内所有成员均属于与环境关联的部门用户组，因此均具备用户访问权限。 在环境中创建且需由整个部门运行的流，将以只读权限共享给部门用户组。 通过这种方式，制作者可以构建和共享。 部门成员可以运行，但非部门人员无法访问，因为他们不在环境组中。
- 场景：生产环境中存在敏感流，除两名解决方案所有者外，任何人均不得编辑。
- 解决方案：仅这两名个人是环境制作者。 其他人没有制作者角色。 如果其他用户需要触发流，则会向他们授予仅限运行的访问权限。 可能，专用服务帐户或服务主体实际上是流的所有者，以实现稳定性，而这两个所有者则作为维护的共同所有者。 使用服务主体作为主要所有者可改进关键流的治理。 所有正式员工要么不在该环境中，要么仅具有用户角色。 可以将环境绑定到仅包含必要帐户的安全组，以进一步确保排他性。
- 场景：一个卓越中心环境，治理团队在所有环境中构建监控流。
- 解决方案：仅卓越中心团队有访问权限。 他们因角色而成为环境制作者。 不需要仅运行共享，因为这些流更多是内部流。 在此，卓越中心团队可能需要在租户级别拥有 Power Platform 管理员角色，这将隐式授予其对所有环境的权限。
角色分离的好处
通过明确区分创建者与执行者，可实现以下目标：
- 最小权限原则：用户仅获得所需权限。 仅运行用户不能突然开始创建绕过 IT 监督的流，因为他们缺少该角色。 创客可以自由地创造，但由于这个群体较小且已知，您可以更轻松地训练和监视他们。
- 简化生命周期管理：当员工离职或变更角色时，更易于更新访问权限。 例如，如果 Joe 是环境制作者且即将离开团队，您可以将其从“制作者”安全组中移除。 他将立即失去在该环境中创建和编辑的能力，同时如果他留在用户组中，则保留运行访问权限。 随后可将他的继任者添加至该组。 这种基于组的维护方式比手动添加或移除数十个流权限更为简洁。
- 合规性对齐：许多法规要求对访问权限进行控制。 能够向审计员证明仅这些特定人员可以修改此环境中的自动化流程；其他人仅能触发已批准的流，这有助于展示强大的内部控制措施。 还可以向审核员提供环境角色分配的导出，作为执行的证据。
- 避免混淆：如果所有人都拥有创建权限，可能会有更少的技术用户无意中创建或修改流，或因 Power Automate 界面而感到困惑。 通过限制创建者角色，可以确保只有经过培训的人员才能设计流，从而减少错误。
应定期重新审视这些措施。 随着业务需求的变化，作为消费者的人可能需要成为制造者（例如，高级用户出现在一个新团队中），或者制造者可能需要成为消费者。 治理模型应该足够灵活，以便通过适当的批准来适应这一点。 记录被授予环境创建者权限的标准以及请求该权限的过程，以便实现透明度和一致性。 同样，定义哪些条件可以触发撤消创建者访问权限，例如，移动到其他部门。
通过串联使用安全角色和组，组织可以在制定自动化的人员和使用自动化的人员之间实现清晰且可维护的分离。 这在 Power Automate 环境中同时提升了安全性和生产力。