制定租户环境策略以大规模采用 Power Platform
每家组织采用 Microsoft Power Platform 的旅程都是独一无二的。 租户环境策略可奠定基础，以便通过可管理且安全的方式加速使用。
本白皮书向您展示了如何使您的 Power Platform 租户环境策略与产品功能和愿景保持一致。 您将了解如何最佳利用该平台的最新功能来实施一项策略，从而使 Power Platform 的采用达到企业规模。
备注
您可以从浏览器中选择打印，然后选择另存为 PDF 来保存或打印本白皮书。
简介
Power Platform 使组织能够为快速创新构建低代码解决方案。 这些解决方案可以专注于个人和小团队的生产力，或者适用于整个组织。 它们还可以扩展到业务流程，包括外部客户和合作伙伴。 支持这些解决方案的是构建、测试和使用低代码资源的 Power Platform 环境。 随着组织越来越多地采用 Power Platform，实施良好的租户环境策略是必不可少的，以使其随着环境数量的增长而变得可管理和安全。
为了帮助您取得更大的成功，本文将指导您如何最好地使用可用的功能，建立您的第一个环境策略或改进您当前的计划。 我们还概述了对这些功能如何协同工作以及如何发展，以实现大规模管理 Power Platform 的愿景。 在本指南中，我们确定了如何将新用户正确路由到环境和组环境，以一致地应用治理、安全规则和租户环境策略的其他重要方面。 我们还提供了保护您的默认环境的详细步骤，这是实施环境策略的关键的第一步。
虽然有许多视角可用于管理 Power Platform 环境，但本文中的方法与 Microsoft IT 的最新产品方向一致，并使用当前功能和近期计划的增强功能。 此更新的指南可以帮助您确保仅使用对 Microsoft 大规模管理环境具有战略意义的环境功能和选项。
Microsoft的租户环境战略愿景
许多组织开始 Power Platform 之旅时，都是在一个名为默认环境的共享中央环境中构建和运行个人生产力应用程序和自动化。 这些资源通常只使用 Microsoft 365 中包含的基本功能，而不使用 Power Platform 的全部功能。 随着这种初始采用的加速， Microsoft 为组织提供了通往企业规模采用全部 Power Platform 功能的环境战略的入口。 当用户拥有高级 Power Platform（Power Apps、Power Automate、Microsoft Copilot Studio和 Dynamics 365）许可证时，这些高级治理功能才可用。 Power Platform 采用成熟度模型可以提供更多见解，帮助组织定义其路线图，以实现超越其环境策略的企业级采用。 这种方法可以帮助组织从基本的个人生产力成为企业规模的 Power Platform采用。
Power Platform 管理、治理和安全功能允许组织实现 Power Platform 的采用和管理，从而实现企业生产力和企业应用程序的大规模使用。 使用托管环境可以激活一组高级功能，从而实现更好的可见性和控制，并减少管理和保护环境的手动工作。 使用这些功能，您可以确保治理和安全策略的一致应用。 管理员可以使用这些功能过渡到企业规模的环境策略。 在管理上花费的时间和精力更少，有助于随着组织扩展使用范围而降低平台的总体拥有成本 (TCO)。
向企业规模过渡的一个关键因素是，使制作者更容易使用个人开发环境，增强他们的共享中心环境策略。 在共享的中央环境策略中，制作者在默认环境中构建、使用和共享应用。 这种策略会导致缺乏隔离和制作者相互侵犯。 想象一下，如果公司里的每个人都共享一个 OneDrive 文件夹来存放他们所有的文档。 相反，您可以使用环境功能来引导制作者进入他们自己的个人环境，在那里他们可以安全地构建他们的应用程序，防止制作者使用不相关的资产，同时简化管理员的管理。 可以将同事作为更多的制作者添加到这些环境中，以协作构建解决方案。
图：共享的中央环境（左）和环境路由策略（右）的图示。
新创建的制作者环境可以自动添加到应用规则的组中，以确保环境具有一致的治理和安全策略。 管理员可以通过将制作者的环境转移到一个规则宽松的组来处理异常。
由制作者创建的低代码资源代表了资源的应用程序生命周期管理 (ALM) 之旅的初始阶段。 作为这个初始阶段的一部分，捕获资源的每个版本并能够在必要时重新创建很重要。 当资源可供共享时，制作者可以使用附加到开发人员环境的持续集成来将其提升到生产环境，在生产环境中，用户可以独立于任何持续的制作者活动来运行资源。
您应该尽可能优先考虑管理环境的平台内置功能，而不是构建自己的工具。 如果内置功能不能满足您组织的独特需求，您可以使用平台管理工具来创建自定义工具。 当新特性可用时，您应该根据它们来评估任何自定义工具。 密切关注 Microsoft Boss 的平台路线图并维护您自己的路线图有助于简化这一过程。
您应该使用为组织的独特需求自定义的推荐环境功能来建立您的环境策略。 不要认为制定环境策略是一次性的活动。 它应该随着时间的推移而发展，以便在新的环境功能可用时将其纳入其中。
支持企业级环境策略的功能
环境 是管理、治理和安全性的 Power Platform 构建基块。 完整的功能概述超出了本文的范围；但是，本节重点介绍支持企业级环境策略实施的功能。
环境 类型描述了作为策略一部分的环境的不同用途。
托管环境 提供了一组高级功能，使环境更易于大规模管理。
许可证自动认领 允许用户在需要时认领 Power Apps 每用户许可证，而不是要求管理员提前确定需要许可证的用户，从而简化了许可证分配。
环境组和规则 介绍了如何将环境作为组进行管理，并将规则应用于组以自动执行一致的管理策略。
默认环境路由 会自动使制作者从在默认环境中创建资源转移到他们自己的个人环境。
Microsoft Dataverse 提供增强的安全性和 ALM。
首选解决方案 可帮助制作者确保他们构建的所有资产都在解决方案 Dataverse 中，从而更轻松地将其提升到其他环境。
Pipelines in Power Platform 提供了一个简化的流程，用于将资产从开发环境提升到测试和生产环境，使所有制作者都可以使用持续集成和部署（CI/CD）。
目录中 Power Platform 允许制作者共享组件（如应用和流）和更高级的起点（如模板）。
环境类型
下表描述了您可以创建的环境类型、它们的特征以及它们的预期用途。
| 类型 | 特点和用途 |
|---|---|
| 默认值 | 每个租客都有的环境。 许多 Microsoft 365 体验使用这种环境进行自定义和自动化。 这种环境并不适合长期或永久的工作，除了 Microsoft 365 个人生产力方案。 |
| 生产 | 这种环境旨在用于组织中的长期工作。 生产环境支持延长的备份保留期，从 7 天到 28 天不等。 |
| 沙盒 | 这些非生产环境支持拷贝和重置等环境操作。 沙盒最适合用于测试和 ALM 构建环境。 |
| Developer | 这些特殊的环境旨在作为制作者的个人开发工作空间，将低代码资产与用户和其他制作者隔离开来。 制作者最多可以有三个开发人员环境。 它们不计入您的租户容量。 如果所有者没有响应通知，90 天未使用的开发人员环境将自动关闭，然后从您的租户中移除。 Dynamics 365 应用在开发人员环境中不可用。 |
| 试用 | 这些环境旨在支持短期测试和概念验证。 每个用户只能有一个。 一段时间后，试用环境会自动从您的租户中删除。 |
| Microsoft Dataverse for Teams | 当您在团队中创建应用程序或从应用程序目录中安装应用程序时，会自动创建这些环境。 这些环境的安全模型与他们相关的团队保持一致。 |
| 客户支持 | 这些是支持 Microsoft 部门创建的特殊环境，允许工程师对问题进行故障排除。 这些环境不会影响您的租户容量。 |
在制定整体租户环境策略时，不同的类型与支持策略建议相关。
托管环境
根据环境类型，环境有一组基本的功能和特征。 托管环境在基本功能的基础上进行扩展，提供了一套高级功能，使管理员能够更轻松地进行大规模管理 Power Platform，并获得更多控制、更少工作和更多见解。 当您将环境设置为托管时，这些功能将被解锁。
下表列出了在撰写本文时可用的托管环境的功能。 新功能会经常添加，因此请查看文档以获取最新列表。 尽管所有的功能都可以帮助您构建一个环境策略，但是斜体的功能与本文概述的策略更相关。
| 更高的可见性 | 更多控制 | 更省力 |
|---|---|---|
| 使用情况洞察 管理员摘要 许可证报告 数据策略视图 ：将数据导出到 Azure Application Insights AI 为所有应用程序生成的描述 |
共享限制 桌面流的数据策略 解决方案检查器 手艺人欢迎内容 IP 防火墙 IP Cookie 绑定 客户管理的密钥 客户密码箱 扩展备份 |
轻松激活 Power Platform 管道 环境路由 环境组和规则 Power Platform 顾问 |
许可证自动申领
自动认领策略 会在用户需要使用某些应用程序或功能时自动向用户分配 Power Apps Power Automate 许可证。 自动化有助于减少使用的许可证数量，并避免手动分配许可证的开销。
配置策略后，在以下条件下，组织中需要个人 Power Apps 许可证的任何用户都会自动获得一个许可证：
如果没有独立 Power Apps 许可证的用户启动需要高级许可证的应用程序，系统会自动为该用户分配一个 Power Apps 每用户许可证。
如果没有独立 Power Apps 许可证的用户在托管环境中启动应用程序，系统会自动为该用户分配一个 Power Apps 每用户许可证。
同样，在配置策略后，组织中需要个人 Power Automate 许可证的任何用户都会在以下条件下被自动授予一个许可证：
用户通过有人参与的 RPA（机器人流程自动化）触发、保存或打开高级云端流。
用户请求 Power Automate 高级许可证。
如果您的环境策略包括托管环境，我们建议您配置许可证自动申领。 应用和流的用户遇到的许可摩擦最少，您只为主动运行应用或使用 Power Automate 的用户消耗许可。
环境组和规则
随着租户 Power Platform 采用率的提高，需要管理和治理的环境数量也会增加。 随着环境数量的增加，确保在环境中应用一致的设置和治理策略变得越来越困难。 环境组功能使这一点变得更容易，允许您创建命名组并将环境与它们相关联，就像将相关文档放在文件夹中一样。
在考虑使用环境组时，请记住以下注意事项：
环境必须经过托管才能包含在组中。
一个环境一次只能属于一个组。
环境可以从一个组移动到另一个组。
一个组中的环境可以来自多个地理区域。
组不能包含其他组。
为了帮助您应用一致的设置和治理，环境组可以配置并打开以下一个或多个规则：
共享画布应用程序的控制
使用情况见解
制作者欢迎内容
解决方案检查器实施
备份保留
AI 生成的说明
规则在发布后会变为活动状态。 活动规则适用于与该组关联的所有环境。
当组规则管理设置时，单个环境设置被锁定。 改变它们的唯一方法是修改规则。 如果环境从组中删除，它会保留组设置，但现在环境管理员可以更改它们。 这对环境策略很重要，因为它确保环境管理员不能覆盖您为组设置的策略。
使用环境组允许您以逻辑方式组织您的环境，类似于您的组织结构、产品服务层次结构或我们稍后将探讨的其他框架。 下图是 Contoso 组织如何考虑组织其环境组的概念性示例。
图：Contoso 租户的环境策略的概念化。
当您计划要配置的规则时，请仔细考虑您可以在概念层次结构的每个级别应用什么。 虽然您还不能配置组层次结构，但是您可以使用命名约定和规则配置的组合来实现您的概念设计。 例如，鉴于前面显示的 Contoso 租户概念化，下图表示组织可以用来实现其设计的环境组。
图：在实际租户中实施概念环境组的示例
在本文的后面，我们将探索使用环境组作为租户环境策略的一部分的更多方法。
默认环境路由
我们在本文中概述的环境策略的一个关键部分是让制作者远离在默认环境中创建资源。 环境路由功能将制作者重定向到他们自己的个人开发环境，并根据需要创建新的开发人员环境。
图：在构建应用程序时，制作者会自动重定向到个人开发人员环境，而不是默认环境。
默认情况下，由路由创建的开发人员环境是托管的。 拥有开发人员计划许可证的用户只能在环境中创建和预览资源。 要以用户身份运行资源，他们需要相应的许可证。
您可以单独使用环境路由，但推荐的方式是将其与环境组一起使用。 当以这种方式使用时，创建的任何环境都与您指定的包含所有新开发人员环境的组相关联，确保它立即被您的治理策略所覆盖。
系统会自动为创建者分配一个安全角色，使他们成为开发人员环境的环境管理员。 当环境是环境组的一部分时，作为环境管理员的制作者不能更改环境设置，因为它们是由环境组规则管理的。 只有可以修改组规则的管理员才能进行任何更改。
您可以通过两种方式实施更多的控制。 首先，您可以禁止在您的租户设置中手动创建开发人员环境。 设置此选项后，制作者不能在管理门户中自己创建环境。 他们也不会得到路由策略自动创建的路由。 其次，您可以在路由策略中指定一个安全组，以限制谁可以自动创建环境。
最初，环境路由支持在新的和现有的制作者使用 make.powerapps.com 时，将他们从默认环境中路由出去。 随着时间的推移，其他 Power Platform 服务将支持环境路由功能。
Microsoft Dataverse
Dataverse 安全地存储和管理应用程序使用的数据。 在环境策略的背景下，Dataverse 解决方案功能是用于将应用和组件从一个环境转移到另一个环境的功能。 制作者在容器（解决方案）中构建他们的资产，这些容器跟踪他们构建的内容。 解决方案可以很容易地移植到其他环境中。 使用这种方法，您可以将开发人员构建资源的环境与使用资源的生产环境分开。 制作者和用户都受益。 制作者可以继续发展他们的资源，用户不会对突然的变化感到惊讶。 当制作者准备好发布他们的更改时，他们可以请求将更新的资源提升到生产环境中。
Dataverse 解决方案是在 Power Apps 和 Power Automate 等 Power Platform 产品中实施 ALM 的机制。 Power Platform 中的管道使用解决方案来自动化制作者建立的资产的 CI/CD。 解决方案可以从 Dataverse 中导出，并存储在 Azure DevOps 或 GitHub 这样的源代码控制工具中。 如果您需要重新创建开发环境，那么源代码控制中的解决方案将成为事实的来源。 例如，如果一个制作者构建了一个流行的应用程序，然后删除了开发人员环境，那么存储在源代码控制中的导出解决方案可以用来重新创建一个可行的开发环境。
使用 Dataverse 创建环境时，另一个重要的考虑因素是是否有任何 Dynamics 365 应用程序将部署到该环境中。 如果存在这种可能性，您必须在创建环境时启用 Dynamics 365，否则以后将无法安装 Dynamics 365 应用程序。
我们建议您在制作者创建将与其他用户共享的资产的任何环境中提供 Dataverse。 这使得资产更容易做好 ALM 准备。
首选解决方案
当制作者在 Dataverse 环境中创建 Dataverse 资产，而不是从自定义解决方案开始时，该资产与默认解决方案相关联，并且可能还与 Common Data Service 默认解决方案相关联。 默认解决方案由在环境中创建资产的所有制作者共享。 没有简单的方法来识别哪个制作者创建了哪个组件或者哪个资产属于哪个应用。 这使得很难将一个流行的应用程序推广到另一个环境中与更多的受众分享。 您必须提升默认解决方案中的所有资产——这不是一个理想的方案。
为了支持您的环境策略并使其更易于使用，制作者应在其开发环境中创建一个自定义解决方案，然后将其设置为环境中的首选解决方案。 制作者在环境中设置首选解决方案，以指示他们创建的资产应该与哪个解决方案相关联。 首选解决方案可以帮助确保当制作者使用管道将他们的资源推广到其他环境时，推广的解决方案包含所有必需的资产。 请将此视为准备资产的 ALM 就绪状态。
Power Platform 中的管道
正如我们已经看到的，一个好的环境策略的一个关键原则是将资产的构建位置与部署和使用位置隔离开来。 这种分离确保了试图使用资产的用户不会因为制作者更新资产而遭遇停机。 然而，它需要将资产提升到生产环境——理想情况下，作为 Dataverse 解决方案的一部分——才能使用。
Dataverse 解决方案可以在环境之间手动传输。 但是，您可以使用管道实现流程自动化，并制定适当的策略来确保进行适当的变更管理。 根据您在解决方案检查器中设置的环境规则，管道会在部署解决方案之前自动实施所有规则，以防止进一步的部署错误。 下图说明了管道如何自动将资产从开发提升到生产。
图：管道可自动将存储在源代码管理中的资产从开发、测试升级到生产环境。
您可以配置需要包含在管道中的环境和流程（如审批）的数量。
管道与环境组一起工作。 它们可以针对开发环境进行预配置，以允许制作者在尝试与其他用户共享其资产时，通过响应提示来轻松启动推广过程。 作为使用管道的部署请求的一部分，制作者可以提议与谁共享他们的资产以及所需的安全角色。 管道管理员可以在部署之前批准或拒绝请求，方法是确保发起请求的制定者拥有最低特权。
管道 in Power Platform 将每个管道的定义存储在默认管理的主机环境 Microsoft 中。 但是，您可以在您管理的租户中定义多个主机环境，从而允许您处理独特的需求。
Power Platform 中的目录
开发者和制作者构建和共享组件的组织，如应用程序和流，以及模板，是更高级的起点，往往会从 Power Platform 中获得更多价值。 该 Power Platform 目录 使制作者能够轻松、更有效地跨环境共享其组件和模板。
目录安装在环境中，并且可以与管道主机一起安装在同一环境中。 通过拥有多个安装了目录的环境，还可以处理独特的资源分段需求。
功能路线图
随着 Microsoft 支持治理和管理的功能 Power Platform 不断发展，您可以在 Release Planner 中跟随操作。 您了解了计划中的内容、即将到来的发布波次中的内容以及现在可以尝试的内容。 您甚至可以通过保存想要关注的项目来创建自己的发布计划。
企业级环境策略的基础
我们讨论了我们对企业级租户环境策略的愿景，以及支持该策略的关键环境功能。 现在，我们来看看如何将这些功能结合起来作为环境策略的一部分。 您的策略应该基于您的组织的独特需求，所以在我们转向如何自定义策略以满足您的需求之前，让我们从一个基本示例开始。
在本例中，Contoso 领导层希望让员工能够利用 Power Platform 的优势，并确定了以下高级需求：
员工需要能够使用 Microsoft 365 建立自动化的文档审批流程和其他 Power Platform 自定义项。
员工应该能够建立 Power Apps 和 Power Automate 自动化来提高他们的个人生产力。
负责公司合规追踪应用的制作者必须能够开发和维护该应用。
为了支持这些要求，Contoso 管理和治理团队提出了以下环境拓扑：
图：Contoso Power Platform 大规模项目的拟议环境拓扑。
让我们详细研究一下这个环境拓扑图。
默认环境用于构建 Microsoft 365 生产力自定义项。 数据丢失预防政策和共享限制可限制其他类型的制作者活动，并对制作者在这种环境下可以建立的东西设置了护栏。
只有管理员能够创建试用、沙盒和生产环境。 制作者使用自定义 Microsoft 表单或其他流程请求新环境。 Microsoft Power Platform Center of Excellence (CoE) 初学者工具包包括可以使用的环境请求。
创建了四个环境组：开发、共享开发、UAT（用户验收测试）和生产。
为开发组设置的环境路由策略将制定者从默认环境路由到他们自己的开发人员环境。 当创建新的开发环境时，它们会自动与开发组相关联，并应用其规则。
共享开发组支持包含多个制作者的项目的环境。
UAT 小组包含用于在将资源提升到生产环境之前对其进行测试的环境。
生产组包含为生产使用托管应用程序、流和其他工件的环境。
这个提议的拓扑中缺少的东西是在开发、测试和生产环境之间自动升级的管道。 现在就来补充吧。
图：相同的环境拓扑，其中管道将管道主机环境连接到开发、测试和生产环境。
在修改后的环境拓扑图中，我们添加了一个管道主机环境和两个管道。 一个管道将资源从开发转移到测试，然后转移到生产环境。 将修改开发组上的管道规则以使用此管道。 另一条管道将资源从共享开发环境转移到测试环境，然后转移到生产环境。 共享开发组上的管道规则将被修改以使用此管道。
这个基本的环境策略提供了一个基础，您可以在此基础上构建其他用例，我们接下来将对此进行探讨。
特定场景的环境策略
下面是一些常见的用例，您可能需要将它们合并到基础租户环境策略中。
控制哪些制作者可以创建开发人员环境
默认情况下，拥有 Power Platform 高级许可证、开发人员计划许可证或 Power Platform 租户管理员角色的任何人都可以从管理门户创建开发人员环境。
在基础环境策略中，环境路由确保将制定者从默认环境引导到在指定组中创建的新开发人员环境。 然而，制作者仍然可以手动创建不在环境组中并且没有应用其规则的开发人员环境。
要细化哪些制定者有资格进行环境路由，请在路由配置中指定一个安全组。 配置安全组时，仅路由安全组的成员。 所有其他的都回到默认环境。
为高级制作者提供更大的灵活性
在基础环境策略中，所有新的制作者环境都被路由到指定的开发人员环境组。 通常，这组环境应用了一组相当严格的治理规则。
随着制作者变得越来越高级，您可以允许他们请求获得更多的能力。 您可以使用另一个环境组来跟踪这些高级标记，而不是将它们从原始环境组中删除并手动管理例外。
图：向具有宽松治理规则的环境添加更多功能强大的制作者。
按地区或业务部门组织开发人员环境
在环境路由的当前实现中，所有新的开发人员环境都在单个环境组中创建。 例如，如果您想按地区或业务单元组织您的制作者的开发人员环境，该怎么办呢？
使用路由将创建者引导到在指定组中创建的新开发人员环境中。 然后，您可以将其转移到另一个基于区域、组织单位或其他标准的组，在那里您可以应用更细粒度的治理规则。
图：环境路由在指定组中创建开发人员环境后，将它们移动到结构更具体的组。
如今，移动环境是一项手动操作，但是当 Power Platform 管理连接器在未来的更新中支持组功能时，您将能够实现自动化。
开发一款用于企业的应用
您组织中的一个团队可能正在开发一个适用于整个企业的应用程序。 该团队可能是 IT 驱动的，或者包括 IT 和业务用户（称为融合团队）。
在最简单的环境策略中，项目团队构建在一个共享环境中，该环境可以是沙盒或生产类型。 开发人员环境类型并不是支持多个制作者在一个资源上合作的最佳方式。 然而，制作者需要相互沟通，以避免共享环境中的碰撞和冲突。
不需要专门的测试和生产环境。 该应用程序可以在托管多个应用程序的组织范围的测试和生产环境中进行测试和部署。
图：在专用环境中开发两个企业应用程序，然后在与其他应用程序共享的环境中进行测试和部署。
在更高级的版本中，每个制作者都有自己的开发环境。 这有利于为制作者提供更好的隔离，但是会使在集成环境中组合单独的工作变得更加复杂。 尽管独立工作对于大型复杂的团队来说是有帮助的，但是对于在共享的开发环境中可以更成功地协作的小型团队来说，它会增加不必要的开销。
图：在单独的开发人员环境中处理同一应用的两名制作者必须在共享集成环境中合并他们的工作，然后才能进入测试和生产阶段。
这种变化通常包含了一个源代码控制策略，每个开发环境都被表示为源代码控制中的一个分支，当准备好对变更进行升级时，这个分支就会被合并。 重要的是要考虑应用程序在最初发布后将如何维护。
例如，应用程序的 1.0 版本可能正在生产中，而团队正在开发 2.0 版本。 您的环境策略必须支持修复 1.0 版中的问题，而 2.0 版的开发正在进行中。
图：在开发、测试和部署 2.0 版时，必须修补、测试和部署 1.0 版。
环境小组提供了多种方法来处理这种企业应用方案。 例如，这可以是一个单独的应用程序组，也可以是每个开发阶段都有不同的组。 在最佳实践部分，我们将探讨如何评估这些选项。
尽量减少开发人员环境的使用
个人开发环境是为开发者提供构建低代码解决方案的工作空间的推荐方式。 他们提供了与其他制作者最高水平的隔离。 但是如果您的组织想要最小化开发人员环境的数量，多个共享环境比鼓励开发者在默认环境中构建资产更好。
在这种情况下，您将限制开发人员环境的创建，并创建共享的生产类型开发环境。 您可以按照组织结构、区域或其他标准来组织这些共享环境。 环境组可以包含它们，以确保它们应用一致的治理规则。 授予制作者在分配给他们的环境中创建低代码资产的权限。
安全性是您环境策略的一部分
环境是安全使用 Power Platform 的关键组成部分。 它们代表了租户内部的安全边界，有助于保护应用和数据。 作为环境策略的一部分，您必须考虑您的安全需求如何影响租户环境的数量和用途。
环境使您能够在租户内创建多个安全边界来保护应用和数据。 通过在环境上应用一组可配置的安全特性，可以调整环境提供的保护以满足必要的安全保护。 对单个环境安全功能的详细讨论超出了本文的范围。 但是，在本节中，我们提供了如何将安全性视为您的租户环境策略的一部分的建议。
租户级别的安全性
大多数影响环境的安全设置都是为每个环境单独配置的。 但是，您可以在租户级别进行一些更改，以帮助支持您的环境策略。
- 考虑关闭 Power Platform 中的“与所有人分享”功能。 只有管理员能够与所有人共享资产。
- 考虑保护与 Exchange 的集成。
- 应用跨租户隔离 ，以帮助最大限度地降低租户之间数据泄露的风险。
- 限制为只有管理员可以创建全新生产环境。 限制环境创建 通常有利于保持控制：既可以防止未计算的容量消耗，也可以减少要管理的环境数量。 如果用户必须向核心 IT 请求环境，并且管理员为把关者，则更易于查看哪些用户正在处理。
保护默认环境的安全
默认环境在支持 Microsoft 365 生产力自定义项方面有一定作用。 但是，作为推荐的环境策略的一部分，最好尽可能减少其使用。 相反，制作者应该在他们自己隔离的环境中构建。 虽然您不能阻止对默认环境的访问，但是您可以最小化在默认环境中可以做的事情。
首先，使用环境路由将制作者引导到他们自己的工作空间来构建低代码资产。
检查谁拥有默认环境的管理员访问权限，并将其限制为需要的角色。
考虑将默认环境重命名为更具描述性的名称，如“个人生产力”。
为默认环境建立数据丢失防护 (DLP) 策略，阻止新的连接器，并限制制作者仅使用基本的、不可阻止的连接器。 将无法阻止的所有连接器移到业务数据组中。 将可以阻止的所有连接器移到阻止的数据组中。
创建规则 以阻止自定义连接器使用的所有 URL 模式。
保护默认环境应该是优先考虑的事情。 作为实施您的环境策略的第一步，它与租户级安全性一起执行。 如果不实施这些措施，制作者就有更多的机会增加默认资产。 有了它们和环境路由，就鼓励制作者使用他们自己的环境。
保护其他环境
如果您的组织与大多数组织一样，那么除了默认环境之外，您还有几个环境。 每个应用程序所需的安全级别可能因其包含的应用程序和数据而异。 开发人员环境通常比生产环境有更宽松的规则。 一些生产环境需要尽可能多的保护。
作为建立环境策略的一部分，确定环境的通用安全级别以及保护每个级别的功能，如下例所示。
图：三层环境安全性的示例以及适用于每层中的环境的安全功能。
将您确定的安全级别纳入您的组策略，并在可能的情况下，使用规则在您的环境中启用安全功能。 在本例中，规则限制在所有被指定为正常或中等安全的环境中共享。
根据您的数据丢失预防策略调整环境
数据策略是控制环境中低代码资源所使用的服务的整体治理工作的另一个重要部分。 环境组没有将 DLP 策略应用于环境的规则。 但是，您可以使您的 DLP 策略与您的环境组保持一致。 例如，您可以创建一个名称与环境组相同或相似的 DLP 策略，并将其应用于该组中的环境。
图：在此示例中，Personal Dev 组中的环境跟随阻止所有非Microsoft 连接器的 DLP 策略。
为您的组织量身自定义环境策略
在前面的章节中，我们描述了组织如何大规模管理环境的愿景。 我们探讨了基本功能，它们如何对环境策略做出贡献，以及使用它们的基础环境拓扑可能是什么样子。 我们给出了如何在此基础上构建以适应常见场景的示例。 因为每个组织都是独一无二的，所以下一步是为您量身自定义满足您组织需求的环境策略。
从您现在的地方开始
不管您的组织是第一次使用 Power Platform 还是已经使用了很多年，第一步是评估您的情况。 从高层次评估您的默认环境中有什么，您有什么其他环境，以及它们的用途。 通常环境策略是作为在组织中建立 Power Platform 治理的整体工作的一部分来完成的。 如果是这种情况，您可能已经建立了为您的组织自定义策略所需的一些治理愿景。
您应该了解的组织信息包括：
如何在组织中使用 Power Platform 的愿景是什么？
组织中谁将构建低代码资产？
您需要做出一些关键的决定：
制作者将如何获得新环境？
您是否会对您的环境进行分组，如果会，如何分组？
不同的环境需要什么样的安全级别，如何对环境进行分类？
您将如何决定应用程序、自动化或 Copilot 是使用现有环境还是新环境？
平台的基线特性和您的需求之间是否存在需要自定义治理流程的空白？
您将如何处理默认环境中的任何现有资产？
您是否有租户和环境 DLP 策略策略？如果有，它如何与您正在创建的环境策略保持一致？
您可能还会从云运营模式中找到一些灵感，这些模式是 Azure 云采用框架的一部分。
利用平台填补空白
您几乎总是会发现平台的内置功能无法满足的需求。 在评估这些空白时，考虑以下可能的评估结果：
空白是可以接受的。
可以使用 Power Platform Center of Excellence 初学者工具包来填补这一空白。
这一空白可以通过使用平台的功能来填补，比如 API、连接器和自定义应用，或者自动化。
可以使用第三方工具或应用程序来填补这一空白。
CoE 初学者工具包
Power Platform Center of Excellence 初学者工具包是一组组件和工具，旨在帮助您的组织采用和支持 Power Platform 的使用。 初学者工具包的一个重要方面是能够收集关于您的环境中平台使用情况的数据，这在您开发和发展环境策略时会有所帮助。
例如，环境 Power BI 控制面板提供一个概览，帮助您了解您的租户中存在哪些环境、谁创建了这些环境，以及它们包含哪些资产。
图：环境中的 Environments 仪表板 Power BI。
该工具包包括一些起点或灵感，例如，制作者可以使用一个流程来请求新环境以及针对其环境的 DLP 策略变更。
图：说明 CoE 初学者工具包中的环境管理流程的流程图。
平台可编程性和可扩展性
低代码平台出色的一点是，您可以用它来构建应用程序、自动化、门户和助手来帮助您进行管理。 您还可以使用较低级别的工具来填补支持您的环境策略的空白。
您可以使用以下连接器来构建应用程序和流：
您可以使用 Power Platform 命令行界面 (CLI) 来开发自动化功能，以帮助您管理环境生命周期以及与开发运维实践相关的其他任务。
借助面向 Power Platform 创建者和管理员的PowerShell cmdlet，您可以自动执行许多监控和管理任务。
Power Platform DLP SDK 可以帮助您管理租户和环境数据丢失防护策略。
最佳实践建议
在本文的这一部分中，我们基于基础部分和特定场景部分中的建议。
新环境
作为制定策略的一部分，请考虑何时创建支持工作负载的环境。 您的评估必须平衡环境提供的隔离的好处（例如，从安全角度来看，能够锁定特定环境比其他环境更有帮助）与缺点（例如，隔离会给试图跨应用程序共享数据的用户造成摩擦）。
当您评估一个应用或者一个自动化是否属于它自己的环境时，分别评估应用生命周期的不同阶段。 在开发过程中，与其他应用程序隔离很重要。 当在单个环境中开发多个应用程序时，您可能会面临创建跨应用程序依赖关系的风险。
作为一个一般的建议，如果可能的话，开发环境应该是单一用途的，可任意使用的，并且容易重新创建。
如果多个应用在生产环境中一起运行，那么在同一个环境中测试它们是有意义的。 事实上，如果您不测试将在生产中运行的应用程序，您可能会发现不了兼容性问题。
当您评估应用程序的生产环境时，请记住以下注意事项：
该应用程序与环境中的现有应用程序兼容吗？ 例如，两个应用程序都出于不同目的使用 Dataverse 联系人表格，这两个应用程序可能不兼容。 从 DLP 策略的角度来看，这些应用程序是否兼容？
数据分离是否有特殊的合规性或法规要求？ 例如，数据的敏感性是否要求将其隔离？ 有没有要求数据不能和其他数据包含在一起？
数据是高度机密还是高度敏感？ 泄密会给组织带来金钱或名誉损失吗？ 在单独的环境中进行隔离可以更好地控制安全性。
该应用程序是否需要来自其他应用程序的数据，并需要与它们搭配使用？ 例如，两个都使用客户表的应用程序应该一起托管。 将它们分开会产生冗余的数据副本，并产生维护数据的问题。
数据是否需要区域数据驻留？ 在某些情况下，可以将相同的应用程序或自动化部署到区域环境中，以确保适当的数据隔离和驻留。
大多数用户是否与环境在同一地区？ 如果环境在欧洲、中东和非洲，但应用程序的大多数用户都在美国，那么共享环境可能不会提供最佳性能。
是否需要新的管理员，或者现有的管理员是否足够？ 如果新应用程序需要更多管理员，他们是否与现有管理员兼容，因为他们都将拥有环境中所有应用程序的管理权限。
应用程序的预期寿命是多少？ 如果应用程序或自动化是暂时的或短暂的，将它安装在具有更多永久应用程序的环境中可能不是一个好主意。
用户必须为不同的应用程序使用多个环境会有困难吗？ 这可能会影响一切，包括在移动设备上查找应用程序以及必须从多个环境中提取数据的自助服务报告。
容量
每个环境（除了试用和开发环境之外）在初始配置时都会消耗 1 GB。 容量在租户之间共享，因此需要分配给需要的人。
容量预留方法：
- 管理共享测试和生产环境。 与共享开发环境不同，测试和生产环境中的权限应该仅限于用户对测试的访问。
- 请自动化临时开发环境的清理，并鼓励为测试或概念验证工作使用试用环境。
环境组
环境组非常灵活，允许您适应组织特有的各种用例。 以下是您可以考虑将环境分组作为环境策略一部分的几种方法：
按服务或组件；例如，ServiceNow 服务树
开发、测试和生产
部门、业务组或成本中心
按项目
按位置，如果一个位置中的大多数环境具有相似的治理需求；这也有助于满足类似的地区法规和法律要求
图：两个不同部门的环境组具有不同的规则。
命名环境和组
作为策略的一部分，考虑如何命名环境和组。
环境名称对管理员、制作者和用户可见。 通常只有管理员使用环境组，但是如果制作者有创建环境的权限，他们可能会遇到环境组。
自动创建的开发人员环境遵循模式<用户名>的环境；比如“Avery Howard 的环境”环境组不会自动命名。
环境和环境组名称不需要唯一。 然而，为了避免混淆，最好避免重名。
名称限制在 100 个字符以内。 较短的名字更容易使用。
建立一致的命名约定。
一致的名称有助于管理员了解该组的目的及其管理的环境，并使自动化和报告更容易。
常见的做法是在环境的名称中包含生命周期阶段；比如 Contoso Dev，Contoso Test，Contoso Prod。目标是明确区分具有相同内容但不同目的的环境。
另一种常见的做法是，当环境专用于该用户组时，在名称中包含部门或业务单位。
例如，您可能决定所有环境或环境组名称必须遵循模式<生命周期阶段>-<区域>-<业务单位>-<目的>（生产-美国-财务-工资单）。
保持名字简短、有意义，且具有描述性。
考虑您的团队将如何随着时间的推移而发展壮大，并确保您的命名约定能够适应这些不断发展的需求。
避免在名称中包含机密信息。 任何有权访问管理中心的人都可以看到名称。
默认环境中的资产
您的环境策略应该鼓励（或强制）使用个人的开发环境，以减少在默认环境中创建的内容。 然而，您应该看看制作者已经在默认环境中创建了什么，并评估如何处理每个用例。 是留在默认环境中合适，还是应该迁移到另一个环境中？
执行这种卫生工作的一个关键部分是确定在您的组织中广泛使用的应用程序，这些应用程序应该有自己的受保护的开发环境，与生产环境分开。
下表列出了示例使用案例和迁移操作。 最终，您的组织需要确定自己的用例以及与将资产留在默认环境中相关的风险因素。 详细了解何时从默认环境移动资产。
| 默认环境 | 迁移操作 |
|---|---|
| Microsoft 365 个人生产力 | 保持默认环境。 |
| 最近使用过但未共享的单个制作者的资产 | 转移到所有者的个人开发环境。 |
| 最近使用并共享的单个制作者的资产 | 转移到所有者的个人开发环境，并从共享的生产环境中运行。 |
| 最近使用并共享的多个制作者的资产 | 移动到共享的开发人员环境，并从共享的生产环境运行。 |
| 最近未使用的资产 | 通知所有者，如果没有回应，则转移到隔离区。 |
Dataverse for Teams 环境中的资产
Microsoft Dataverse for Teams 使用户能够使用 Microsoft Teams 、 Power Apps 和 Microsoft Copilot Studio 构建自定义应用程序、机器人和流入 Power Automate。 当团队负责人将此功能添加到其团队中时，将创建具有 Dataverse for Teams 数据库的 Microsoft Power Platform 环境，并将其链接到其团队。 了解如何建立治理策略来管理 Microsoft Dataverse for Teams 环境..
内部环境战略 Microsoft
Microsoft 将自己视为“零客户”，因为它在内部采用 Power Platform 来提高员工的自动化和效率。 以下数字为您提供了内部租户使用 Microsoft 规模的想法。
每月有 50,000-60,000 名活跃的制作者
超过 250,000 个应用程序和超过 300,000 个流
超过 20,000 种环境
Microsoft shifting 从之前的环境策略转变为使用最新 Power Platform 治理功能（包括托管环境、环境组和规则）的策略。
作为增强策略 Microsoft 计划的一部分，根据开发类型、组织所有权和风险级别将场景分组在一起。 因为整个公司都在构建很多东西，所以很难专注于每一个可能的场景，也很难针对每个用例进行自定义。 发生的事情太多了，需要自动化并尽可能多地利用现成的控件。
Microsoft 将其 Power Platform 环境构建为三大类，涵盖 7 个用例，反映不同程度的风险和控制：个人生产力、团队协作和企业发展。
个人生产力 –这适用于只想为自己构建应用程序或流程的人。 例如，他们不与他人合作。 这些用户路由到被锁定的个人开发环境。 这些环境使用托管环境功能，包括限制共享，还控制您可以在环境中执行的其他操作。 在这组环境中，可用的连接器和操作受到很大的限制。 这些环境风险最小。 使用锁定的个人环境使用户能够避免更严格的合规流程，仅用于构建个人生产力应用和流程。
团队协作 –这适用于为团队构建工具、自动化和流程的用户。 对于此方案， Microsoft 鼓励使用 Dataverse for Teams 环境。 生命周期、访问管理和数据标记在 Microsoft 365 组级别得到控制，因此我们不必花费时间从 Power Platform 治理角度管理这些用户。 这种使用水平是风险谱的下一步。
所有员工 使用的企业开发/生产级别–这些人构建在整个公司更广泛地使用的工具或解决方案。 这些环境可能存储最敏感的数据，使用更强大的连接器，并需要更多的治理。 这被认为是最高的风险，大部分精力都花在了治理上。 ALM 是必需的，生产前工作在沙盒环境中进行，并且在生产环境中只允许托管解决方案。 这些环境必须链接到 ServiceTree，这会强制执行重复的安全和隐私审查。 环境组规则是基于 ServiceTree 元数据和信号自定义的。 许多环境组和规则用于管理和控制这些环境。
Microsoft的治理策略不是静态的。 它是不断变化的，以适应新的挑战并融入新的 Power Platform 功能。
发展您的租户环境策略
在本文中，我们描述了如何建立企业级的租户环境策略。 无论您从何处开始旅程，该策略都可以与您的业务一起成长。 任何规模的组织都可以从我们提出的策略中受益；然而，对于已经处于较高规模的组织来说，好处更大。
制定租户环境策略不是一次性的活动。 这是一段旅程。 随着时间的推移，随着需求的变化，您应该改进您的策略。 您的策略也必须调整，以适应平台的新功能并应对新挑战。
像所有旅程一样，不同的组织在途中的不同点加入，但都有相同的目的地。 以下是代表您的组织目前所处位置的可能入口。
起始
您的组织正开始采用 Power Platform。 这通常被称为绿地。 您将从最好的地方开始您的旅程，因为您不必担心现有环境或新策略可能对您组织中的人员使用 Power Platform 方式产生的影响。 这是实施符合产品特性和最佳实践的企业级环境策略的最佳时机。
探索本文中概述的关键环境特性和策略。 请花时间了解设计和实施最符合您需求的租户环境策略所需的关键主题、考虑事项和决策。
现在就打下坚实的基础至关重要，这样可以避免日后在没有明确战略的情况下出现失控的情况。 做好计划，加快您对 Power Platform 的使用速度，但避免通过增加不必要的复杂性来过度设计您的环境策略。 请记住，这是一个旅程，您可以随着需求的变化继续发展您的策略。
Align
您的组织已经并正在执行一项环境策略，该策略需要进行修改以适应新的 Power Platform 功能和最佳实践。 这通常被称为棕色地带。 与刚刚起步的组织不同，您需要考虑改变环境策略对您的组织的影响。
探索本文中概述的关键环境特性和策略，并评估使您的策略更加一致所需的条件。 通常所有需要的是增量调整。 在可能的情况下，计划推出更改，以尽量减少对用户的影响。
以下建议是您可以实施的常见增量更改：
要在不影响现有环境的情况下开始调整，请创建一个包含新的开发人员环境的环境组，并为如何管理它们建立规则。 打开环境路由，以确保在指定的组中创建所有新的开发人员环境。
评估您的分组策略，如果需要，创建组来支持您的现有环境。 针对这些组建立符合现有限制和例外的规则。 将现有环境移到这些组中。
确定在默认环境中构建和使用的广泛流行的应用程序。 使用管道将其发布到您组织中的用户可以运行它们的生产环境中。 然后将这些应用程序的开发迁移到个人开发环境或专用的开发环境中。
创建一个计划来识别、隔离和删除默认环境中未使用的资产。
提高
您正在执行的环境策略已经符合最新的功能和最佳实践，但是您的组织希望添加更多的控制或功能。
向您的组织传达您的环境策略
如果您的 Power Platform 用户理解并认同您想要实现的目标，您就能更成功地实施租户环境策略。 如果您只是在没有任何沟通的情况下激活您的策略，用户会把这些变化看作是限制，并寻找解决它们的方法。
作为开发或改进策略的一部分，决定如何告知用户影响他们使用 Power Platform 的策略的关键要素。 他们不需要您的策略的所有技术细节，只需要有助于确保他们保持高效的基本要素，例如：
默认环境的用途
他们应该在哪里构建新的低代码资产
他们应该如何使用他们的个人开发环境
如何为特定业务部门或项目请求自定义环境
一般连接器使用策略，以及如何为其环境申请更多连接器权限
如何与他人分享他们的成果
制作者的责任；例如：
保持租户整洁。 如果不再需要，请删除您的环境、应用和流。 实验时使用测试环境。
明智地共享。 留意环境、应用、流和共享连接是否过度共享。
保护组织数据。 避免将数据从高度机密或机密数据源移动到未受保护的存储或外部存储。
当您的策略改变时，分享这些改变是如何影响您的用户的，这样他们就知道该做些什么了
一个好的开始是在添加新制作者的环境组中打开制作者欢迎内容。
图：使用欢迎内容帮助新制作者取得成功。
另一个与用户沟通的有效方法是建立一个内部 Power Platform 中心。 该中心可以成为人们就项目进行协作、分享想法以及发现应用技术实现更多目标的新途径的地方。 该中心可以让您分享与您的用户相关的环境策略的更多详细信息。 了解如何创建内部 Power Platform 应用中心。
结束语
在本文中，我们探讨了旨在帮助您的组织管理 Power Platform 企业级环境并将它们纳入您的租户环境策略的功能。
随着您的组织采用 Power Platform 和使用的加速，对环境的需求可能会快速变化。 您需要一种敏捷的方法来帮助您的环境策略跟上变化，并继续满足您的组织不断发展的治理需求。
租户环境策略成功的一个关键因素是与制作者和用户沟通并获得他们的支持。 确保构建低代码应用程序和自动化的人知道如何遵循组织的环境策略，以及他们应该在哪里构建他们的低代码资产。
每个组织的 Power Platform 采用之旅都是独一无二的。 我们提出了一些想法来帮助您有一个好的开始。 您的客户 Microsoft 团队或 Power Platform 合作伙伴可以帮助您为组织创建自定义程度更高的租户环境策略。