适用于此 Power Platform Well-Architected Security 清单建议：
| SE：05 | 在所有工作负荷用户、团队成员和系统组件中实施严格的、有条件和可审核的标识和访问管理（IAM）。 根据需要将访问权限限制为独占。 对所有身份验证和授权实现使用现代行业标准。 限制和严格审查非身份验证的访问。 |
|---|
本指南介绍了对尝试访问工作负荷资源的标识进行身份验证和授权的建议。
从技术控制的角度来看，身份始终是主要边界。 此范围不仅限于工作负荷的边界。 它还包括您工作负荷中的单个部件。
典型标识包括：
- 人类。 应用程序用户、管理员、操作员、审核员和不良参与者。
- 系统。 工作负荷标识、托管标识、API 密钥、服务主体和 Azure 资源。
- 匿名。 未提供身份证明的实体。
定义
| 条款 | 定义 |
|---|---|
| 身份验证 (AuthN) | 验证身份是谁或它自称是谁的流程。 |
| 身份验证 (AuthZ) | 验证身份是否有权执行请求的操作的过程。 |
| 条件性访问 | 一组规则，允许基于指定条件执行的操作。 |
| IdP | 标识提供者，如Microsoft Entra ID。 |
| Persona | 具有一组职责和行动的职务或职称。 |
| 预共享密钥 | 提供者和消费者之间共享的机密类型，通过安全且已同意的机制使用。 |
| 资源标识 | 为平台管理的云资源定义的标识。 |
| 角色 | 定义用户或组可以执行的操作的一组权限。 |
| Scope | 允许角色运行的不同级别的组织层次结构。 也是系统中的一组特性。 |
| 安全主体 | 提供权限的标识。 它可以是用户、组或服务主体。 任何组成员都获得相同的访问权限级别。 |
| 用户标识 | 人员的标识，例如员工或外部用户。 |
| 工作负载标识 | 用于向其他服务和资源进行身份验证的应用程序、服务、脚本、容器或其他工作负荷组件的系统标识。 |
注释
可以在名为 安全主体 的父项下将标识与其他类似标识分组。 安全组是安全主体的示例。 这种分层关系简化了维护和提高一致性。 由于身份属性不是在单个的个体层面上处理的，因此错误的几率也会减少。 在本文中，术语 标识 包含安全主体。
Microsoft Entra ID作为 Power Platform 的标识提供者
所有 Power Platform 产品都使用Microsoft Entra ID（以前Azure Active Directory或Azure AD）进行标识和访问管理。 Entra ID 使组织能够保护和管理混合和多云环境的身份。 Entra ID 对于管理需要访问 Power Platform 资源的业务来宾也是至关重要的。 Power Platform 还使用 Entra ID 来管理需要使用服务主体功能与 Power Platform API 集成的其他应用程序。 使用 Entra ID，Power Platform 可以利用 Entra ID 更先进的安全功能，如条件访问和连续访问评估。
Authentication
身份验证是验证标识的过程。 请求身份需要提供某种形式的可验证身份证明。 例如：
- 用户名和密码。
- 预共享机密，例如授予访问权限的 API 密钥。
- 共享访问签名 (SAS) 令牌。
- 在传输层安全性 (TLS) 相互身份验证中使用的证书。
Power Platform 身份验证涉及用户浏览器与 Power Platform 或 Azure 服务之间的请求、响应和重定向序列。 序列遵循 Microsoft Entra ID 身份验证代码授予流。
连接到数据源并对其进行身份验证将与对 Power Platform 服务进行身份验证分开进行。 有关详细信息，请参阅连接到数据源并向其进行身份验证。
Authorization
Power Platform 使用 Microsoft Entra ID Microsoft Identity Platform 通过行业标准 OAuth 2.0 协议授权所有 API 调用。
关键设计策略
要了解工作负荷的身份需要，您需要列出用户和系统流、工作负荷资产和角色，以及它们将要采取的操作。
每个用例可能都有自己的一组控制，您在进行设计时需要假设违反情况。 根据用例或角色的标识要求，确定条件选择。 避免对所有用例使用一个解决方案。 相反，控件不应过于细致，以免产生不必要的管理开销。
需要记录身份访问轨迹。 这样做有助于验证控件，并且可以使用日志进行合规性审核。
确定身份验证的所有身份
从外部到内部的访问。 Power Platform 身份验证涉及用户浏览器与 Power Platform 或 Azure 服务之间的请求、响应和重定向序列。 序列遵循 Microsoft Entra ID 身份验证代码授予流。 Power Platform 会自动验证所有出于各种目的访问工作负荷的用户。
由内向外的访问。 您的工作负荷将需要访问其他资源。 例如，从数据平台读取或写入数据、从机密存储检索机密，并将遥测数据记录到监控服务中。 它甚至可能需要访问第三方服务。 这些是所有工作负荷身份要求。 但是，您还需要考虑资源身份要求；例如，部署管道将如何运行和验证。
确定授权所需的操作
接下来，需要了解每个经过身份验证的标识尝试执行的操作，以便可以对这些操作进行授权。 操作可以根据所需的访问类型进行分类。
数据平面访问。 在数据平面发生的操作会导致数据传输。 例如，从 Microsoft Dataverse 读取或写入数据的应用程序，或将日志写入 Application Insights。
控制平面访问。 在控制平面发生的操作会导致创建、修改或删除 Power Platform 资源。 例如，修改环境属性或创建数据策略。
应用程序通常以数据平面操作为目标，而操作通常同时访问控制和数据平面。
提供基于角色的授权
根据每个身份的责任，授权应允许的操作。 不应允许身份执行超过其必要的操作。 在设置授权规则之前，需要清楚地了解发出请求的人员或内容、允许该角色执行哪些操作，以及该角色可以执行的操作程度。 这些因素会导致将身份、角色和范围组合起来的选择。
考虑以下情况：
- 工作负荷是否需要对 Dataverse 具有数据平面访问权限以进行读取和写入访问？
- 工作负荷是否还需要访问环境属性？
- 如果身份被不良行为者盗用，在保密性、完整性和可用性方面会对系统产生什么影响？
- 工作负荷需要永久访问还是可以考虑条件访问？
- 工作负荷是否执行需要管理/提升权限的操作？
- 工作负荷如何与第三方服务交互？
- 对于代理，是否具有单一登录（SSO）要求？
- 智能体是以非认证模式、认证模式还是两者兼有的模式运行？
角色分配
角色是分配给身份的一组权限。 应分配只允许身份完成任务的角色，不再分配其他角色。 当用户的权限仅限于其作业要求时，更容易识别系统中的可疑或未经授权的行为。
提出如下问题：
- 只读访问权限是否足够？
- 身份是否需要权限才能删除资源？
- 角色是否只需要访问他们创建的记录？
- 分层访问是否基于需要用户的业务部门？
- 角色需要管理权限还是提升权限？
- 角色是否需要永久访问这些权限？
- 如果用户改变工作会发生什么情况？
限制用户、应用程序或服务的访问级别可以减少潜在的攻击面。 如果仅授予执行特定任务所需的最低权限，则成功攻击或未经授权的访问的风险会显著减少。 例如，开发人员只需要制作者访问开发环境，而不需要访问生产环境；他们只需要访问来创建资源，而不需要更改环境属性；并且他们可能只需要访问 Dataverse 中的读/写数据，而不需要更改 Dataverse 表的数据模型或属性。
避免以单个用户为目标的权限。 细粒度和自定义权限会造成复杂性和混乱，并且随着用户更改角色和在企业中变动，或者随着具有类似身份验证要求的新用户加入团队，这些权限可能会变得难以维护。 这种情况可能会造成难以维护的复杂的旧配置，并对安全性和可靠性产生负面影响。
权衡：精细访问控制方法可更好地审核和监视用户活动。
授予从最低权限开始的角色，并根据操作或数据访问需求添加更多角色。 您的技术团队必须有明确的指导来实现权限。
进行条件访问选择
不要为所有身份提供相同的访问权限级别。 根据两个主要因素做出决策：
- 时间。 身份可以访问您的环境多长时间。
- 权限。 权限级别。
这些因素不是相互排斥的。 具有更多特权和无限访问权限的已泄露标识可以更好地控制系统和数据，或使用该访问权限来继续更改环境。 将这些访问因素限制为预防措施和控制爆炸半径。
按需分配 （JIT） 方法仅在需要时提供所需的权限。
Just Enough Access （JEA） 仅提供所需的权限。
虽然时间和特权是主要因素，但还有其他适用条件。 例如，还可以使用访问发起点的设备、网络和位置来设置策略。
使用强控制来筛选、检测和阻止未经授权的访问，包括用户标识和位置、设备运行状况、工作负荷上下文、数据分类和异常等参数。
例如，您的工作负荷可能需要由供应商、合作伙伴和客户等第三方身份访问。 他们需要适当的访问权限级别，而不是向全职员工提供的默认权限。 通过明确区分外部帐户，可以更轻松地防止和检测来自这些途径的攻击。
关键影响帐户
管理标识引入了一些影响最大的安全风险，因为它们执行的任务需要对这些系统和应用程序进行特权访问。 泄露或滥用可能会对业务及其信息系统产生不利影响。 管理安全性是最重要的安全领域之一。
为保护特权访问免受顽固攻击者的攻击，必须采取一种完整且周密的方法，将这些系统与风险隔离。 下面是一些策略：
尽量减少关键影响帐户的数量。
使用单独的角色，而不是提升现有身份的权限。
使用 IdP 的 JIT 功能避免永久或持久访问 。 对于“打碎玻璃”情况，请遵循紧急访问流程。
使用新式访问协议 ，例如无密码身份验证或多重身份验证。 将这些机制外部化到您的 IdP。
使用 条件访问策略强制实施密钥安全属性。
停用未使用的管理帐户 。
建立用于管理标识生命周期的过程
对身份的访问时间不应超过身份所访问资源的可用时间。 确保在团队结构或软件组件发生更改时，建立一个禁用或删除账户的身份管理流程。
本指南适用于源代码管理、数据、控制平面、工作负荷用户、基础结构、工具、数据、日志、指标和其他实体的监视。
建立标识治理过程 ，以管理数字标识、高特权用户、外部/来宾用户和工作负荷用户的生命周期。 实施访问审查来确保当身份离开组织或团队时，其工作负荷权限被删除。
保护非身份基础的机密
应用程序机密（如预共享密钥）应被视为系统中的易受攻击点。 在双向通信中，如果提供商或使用者遭到入侵，可能会带来重大安全风险。 这些密钥也可能很繁重，因为它们引入了操作流程。
将这些机密视为可以从机密存储中动态拉取的实体。 它们不应该在应用、流、部署管道或任何其他项目中进行硬编码。
请确保你能够 撤销机密。
应用处理密钥轮换和过期等任务的操作做法。
有关轮换策略的信息，请参阅 自动化轮换具有两组身份验证凭据的资源的机密和 教程：更新 密钥保管库 中的证书自动轮换频率。
保护开发环境安全
对开发人员环境的写入访问应该封闭，对源代码的读取访问应该限制到需要知道的角色。 您应该有一个定期扫描资源并发现最新漏洞的流程。
维护审核线索
标识管理的一个方面是确保系统可审核。 审核将验证假设泄露策略是否有效。 维护审核线索可帮助你：
验证是否通过强身份验证进行认证。 任何操作都必须可 跟踪，以防止否认性攻击。
检测弱身份验证协议或缺少身份验证协议，并获取用户和应用程序登录的可见性和洞察。
根据安全性和 符合性要求 评估从标识到工作负荷的访问，并考虑你设置的用户帐户风险、设备状态和其他条件和策略。
跟踪符合性要求的进展或偏差。
大多数资源都具有数据平面访问权限。 你需要知道访问资源的标识及其执行的操作。 可以使用该信息进行安全诊断。
Power Platform 推进
Power Platform 访问控制是整个安全体系结构的重要部分。 访问控制点可以确保正确的用户获取 Power Platform 资源的访问权限。 在本节中，我们将探讨您可以配置的不同访问点及其在总体安全策略中的角色。
Microsoft Entra ID
所有 Power Platform 产品都使用Microsoft Entra ID（以前Azure Active Directory或Azure AD）进行标识和访问管理。 Entra ID 使组织能够保护和管理混合和多云环境的身份。 Entra ID 对于管理需要访问 Power Platform 资源的业务来宾也是至关重要的。 Power Platform 还使用 Entra ID 来管理需要使用服务主体功能与 Power Platform API 集成的其他应用程序。 使用 Entra ID，Power Platform 可以利用 Entra ID 更先进的安全功能，如条件访问和连续访问评估。
许可证分配
访问Power Apps和Power Automate需要先持有许可证。 用户可以访问的资产和数据由其许可证类型决定。 下表在较高级别概括了基于计划类型的用户可用的资源的差异。 详尽的许可详细信息可在许可概述中找到。
条件性访问策略
条件访问描述用于做出访问决策的策略 。 若要使用条件访问，需要了解用例所需的限制。 通过设置基于业务需要的访问策略来配置 Microsoft Entra 条件访问。
了解详细信息：
- 设置 Microsoft Entra 条件访问
Power Automate 中的条件访问和多重身份验证
连续访问
当评估某些事件以确定是否应撤销访问时，连续访问会加速。 传统上，使用 OAuth 2.0 身份验证，在令牌续订期间进行检查时，会发生访问令牌过期。 通过连续访问，用户的关键事件和网络位置变化将被连续评估，以确定用户是否仍应保持访问。 这些评估可能导致活动会话提前终止或需要重新验证。 例如，如果用户帐户被禁用，他们应该失去对应用的访问权限。 位置也很重要；例如，令牌可能已从可信位置获得授权，但用户更改了与不可信网络的连接。 连续访问会调用条件访问策略评估，用户将失去访问权限，因为他们不再从批准的位置进行连接。
目前，对于 Power Platform，只有 Dataverse 支持连续访问评估。 Microsoft 正在努力增加对其他 Power Platform 服务和客户的支持。 有关详细信息，请参阅 连续访问评估。
随着混合工作模型的不断采用和云应用程序的使用，Entra ID 已成为保护用户和资源的重要的主要安全外围。 条件访问将该外围扩展到网络外围之外，以包括用户和设备身份。 连续访问可确保随着事件或用户位置的变化，对访问进行重新评估。 Power Platform 使用 Entra ID 可以让您实现组织级的安全治理，您可以在整个应用程序组合中一致地应用治理。 查看这些身份管理最佳做法，以获得更多指导，帮助您制定自己的计划来将 Entra ID 与 Power Platform 一起使用。
组访问管理
请勿向特定用户授予权限，而是将访问权限分配给 Microsoft Entra ID 中的组。 如果某个组不存在，请与您的身份团队合作创建一个。 然后，可以在 Azure 外部添加和删除组成员，并确保权限是最新的。 您也可以将组用于其他目的，如邮件列表。
有关详细信息，请参阅 在 Microsoft Entra ID 中使用组进行安全访问控制。
威胁检测
Microsoft Entra ID 保护可以帮助你检测、调查和修正基于标识的风险。 有关详细信息，请参阅 什么是标识保护？。
威胁检测可以采取响应可疑活动的警报或主动搜索活动日志中的异常事件的形式。 Microsoft Sentinel 中的用户和实体行为分析（UEBA）可以轻松检测可疑活动。 有关详细信息，请参阅 使用 Microsoft Sentinel 中的 UEBA 识别高级威胁。
身份日志记录
Power Apps、Power Automate、Copilot Studio、连接器和数据丢失防护管理活动记录从 Microsoft Purview 合规门户跟踪和查看。 了解 Microsoft Purview。
记录对具有 Dataverse 数据库的环境中的客户记录所做的更改。 Dataverse 审核还记录用户通过应用或通过环境中的 SDK 进行的访问。 此审核在环境级别启用，需要对各个表和列进行额外配置。
服务管理员角色
Entra ID 包含一组预先建立的角色，这些角色可以分配给管理员以授予他们执行管理任务的权限。 您可以查看权限矩阵来获取每个角色权限的粒度明细。
使用 Microsoft Entra Privileged Identity Management （PIM） 管理 Power Platform 管理中心中的高特权管理员角色。
保护 Dataverse 数据
Dataverse 的一个主要功能是具有一个丰富的安全模型，适用于许多业务使用场景。 只有当 Dataverse 数据库在环境中时，此安全模型才可用。 作为一名安全专业人员，您可能不会自己构建整个安全模型，但可能会参与确保安全功能的使用符合组织的数据安全要求。 Dataverse 使用基于角色的安全性将特权集合分为一组。 这些安全角色可以直接关联到用户，也可以与 Dataverse 团队和业务部门相关联。 有关详细信息，请参阅 Microsoft Dataverse 中的 安全概念。
在 Copilot Studio 中配置用户身份验证
Microsoft Copilot Studio支持多个身份验证选项。 请选择满足您需求的那一个。 身份验证允许用户登录，从而授予智能体访问受限资源或信息的权限。 用户可以使用 Microsoft Entra ID 或任何 OAuth 2.0 标识提供者（如 Google 或 Facebook）登录。 详细了解 在 Copilot Studio 中配置用户身份验证。
使用基于 Direct Line 的安全性，可以通过使用Direct Line机密或令牌启用安全访问来限制对所控制的位置的访问。
Copilot Studio 支持单一登录（SSO），这意味着代理可以让用户登录。 必须在网页和移动应用程序上实施 SSO。 对于Microsoft Teams，如果选择“仅在 Teams 中”身份验证选项，SSO 是无缝的。 也可以使用 Azure AD v2 手动配置它;但是，在这种情况下，必须将 Teams 应用部署为 zip 文件，而不是通过 Copilot Studio 中的 1 键式 Teams 部署进行部署。
了解详细信息：
- 使用 Microsoft Entra ID 配置单点登录
- 为 Microsoft Teams 中的系统代理使用 Microsoft Entra ID 配置单一登录
- 使用通用 OAuth 提供程序配置单一登录
使用客户密码箱安全地访问数据
Microsoft 人员（包括后续处理者）执行的大多数操作、支持和故障排除都不需要访问客户数据。 借助 Power Platform 客户密码箱，我们为客户提供一个界面，可在极少数需要访问客户数据的情况下查看和批准（或拒绝）数据访问请求。 例如，它会在 Microsoft 工程师需要访问客户数据时使用，无论是响应客户发起的支持票证还是 Microsoft 发现的问题。 有关详细信息，请参阅 Securely access customer data using Customer Lockbox in Power Platform and Dynamics 365。
管理访客用户
您可能需要允许来宾用户访问环境和 Power Platform 资源。 与内部用户一样，可以使用 Microsoft Entra ID 条件访问和持续访问评估来确保来宾用户满足提升的安全级别。
为了进一步增强安全性并降低意外过度共享的风险，请根据需要阻止或启用 Microsoft Entra 来宾对基于 Dataverse 的环境的访问。
相关信息
- 配置标识和访问管理
- 连接到数据源并向其进行身份验证
- 向 Power Platform 服务进行身份验证
- Microsoft Dataverse 中的安全概念
- Power Platform 安全性常见问题解答
- 服务管理员权限矩阵
- 连续访问评估
- 设置 Microsoft Entra 条件访问
- 在 Microsoft Power Automate 中关于条件访问和多重身份验证的建议
- Microsoft 身份平台与 OAuth 2.0 授权代码流程
- Microsoft Entra ID 有哪些新功能？
- Microsoft Entra 内置职能
- Microsoft Entra ID 中基于角色的访问控制概述
安全清单
请参阅完整的建议集。