通过

身份和访问管理建议

  • 项目

适用于此 Power Platform Well-Architected Security 清单建议：

SE:05 在所有工作负荷用户、团队成员和系统组成部署中实施严格的有条件且可审核的身份和访问管理 (IAM)。 根据需要将访问权限限制为独占。 对所有身份验证和授权实现使用现代行业标准。 限制和严格审核不基于标识的访问。

本指南介绍验证和授权可能尝试访问您的工作负荷资源的身份的建议。

从技术控制的角度来看，身份始终是主要的外围技术。 此范围不仅包括工作负荷的边缘。 还包括工作负荷内的各个组成部分。

典型身份包括：

  • 人类。 应用程序用户、管理员、操作者、审计人员以及不良行为者。
  • 系统。 工作负荷身份、托管身份、API 密钥、服务主体和 Azure 资源。
  • 匿名。 未提供有关其身份的任何证据的实体。

定义

术语 定义
身份验证 (AuthN) 验证身份是谁或它自称是谁的流程。
授权 (AuthZ) 验证身份是否具有执行请求操作的权限的流程。
条件访问 允许基于指定条件的操作的一组规则。
IdP 身份提供者，如 Microsoft Entra ID。
角色 具有一系列责任和操作的工作职能或职务。
预共享密钥 在提供者和使用者之间共享的一种机密，通过安全的商定的机制使用。
资源身份 为平台管理的云资源定义的身份。
角色 定义用户或组可以执行哪些操作的权限集。
作用域 允许角色执行操作的组织层次结构的不同级别。 也是系统中的一组功能。
安全主体 提供权限的身份。 可以是用户、组或服务主体。 任何团队成员都会获得同一访问级别。
用户标识 人员的身份，如员工或外部用户。
工作负荷身份 应用程序、服务、脚本、容器或工作负荷的其他组成部分的系统身份，用于对其他服务和资源进行身份验证。

备注

身份可以与其他类似的身份分组在称为安全主体的父级下。 安全组是一个安全主体的示例。 此关系关系可简化维护并提高一致性。 因为身份属性不在个人级别处理，所以出错的几率也会降低。 在本文中，身份一词包含安全主体。

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 更先进的安全功能，如条件访问和连续访问评估。

身份验证

身份验证是一个验证身份的流程。 请求身份需要提供某种形式的可验证身份证明。 例如:

  • 用户名和密码。
  • 预共享机密，如授予访问权限的 API 密钥。
  • 共享访问签名 (SAS) 令牌。
  • 在传输层安全性 (TLS) 相互身份验证中使用的证书。

Power Platform 身份验证涉及用户浏览器与 Power Platform 或 Azure 服务之间的一系列请求、响应和重定向。 该序列遵循 Microsoft Entra ID 身份验证代码授权流。

连接到数据源并对其进行身份验证将与对 Power Platform 服务进行身份验证分开进行。 有关详细信息，请参阅连接到数据源并向其进行身份验证。

授权

Power Platform 使用 Microsoft Entra ID Microsoft 身份平台通过行业标准 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。

  • 使用条件访问策略强制使用密钥安全属性。

  • 停用不使用的管理账户。

建立流程来管理身份生命周期

身份的访问权限时间不能超过身份访问的资源。 确保您有在团队结构或软件组件发生变化时禁用或删除身份的流程。

此指南适用于源代码管理、数据、控制平面、工作负荷用户、基础结构、工具、数据监视、日志、指标和其他实体。

建立身份治理流程，管理数字身份、高权限用户、外部/访客用户和工作负载用户的生命周期。 实施访问审查来确保当身份离开组织或团队时，其工作负荷权限被删除。

保护基于非身份的机密

如预共享密钥这样的应用程序机密应该被视为系统中的易受攻击点。 在双向通信中，如果提供者或使用者受到攻击，可能会引起重大的安全风险。 这些密钥也可能成为负担，因为它们会引入操作过程。

将这些机密视为可以从机密存储中动态拉取的实体。 它们不应该在应用、流、部署管道或任何其他项目中进行硬编码。

确保您具有撤销机密的能力。

应用操作实践来处理密钥轮换和到期等任务。

有关轮换策略的信息，请参阅自动轮换具有两组身份验证凭据的资源的机密和教程：更新 Key Vault 中的证书自动轮换频率。

确保开发环境的安全

对开发人员环境的写入访问应该封闭，对源代码的读取访问应该限制到需要知道的角色。 您应该有一个定期扫描资源并发现最新漏洞的流程。

维护审核线索

身份管理的一个方面是确保系统可以审核。 审核验证假设违反策略是否有效。 维护审核线索可以帮助您：

  • 验证是否使用强身份验证对身份进行了身份验证。 任何操作都必须可追溯，以防止抵赖攻击。

  • 检测薄弱或缺失的身份验证协议，获取用户和应用程序登录的可见性和洞察力。

  • 根据安全性和合规要求评估身份对工作负荷的访问，并考虑用户帐户风险、设备状态以及您设置的其他条件和策略。

  • 跟踪合规要求的进展或偏差。

大多数资源都有数据平面访问权限。 您需要了解访问资源的身份以及它们执行的操作。 您可以将这些信息用于安全诊断。

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 条件访问。

有关详细信息，请参阅：

连续访问

当评估某些事件以确定是否应撤销访问时，连续访问会加速。 传统上，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 识别高级威胁。

身份记录

通过 Microsoft Purview 合规性门户跟踪和查看 Power Apps、Power Automate、Copilot Studio、连接器和数据丢失防护活动日志。 有关更多信息，请参阅了解 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 中”身份验证选项，单点登录就能实现无缝连接。 也可以使用 Azure AD v2 手动配置；但在这种情况下，Teams 应用程序必须以 zip 文件的形式部署，而不是通过 Copilot Studio 中的一键式 Teams 部署。

了解详细信息：

使用客户密码箱安全地访问数据

Microsoft 人员（包括后续处理者）执行的大多数操作、支持和故障排除都不需要访问客户数据。 借助 Power Platform 客户密码箱，我们为客户提供一个界面，可在极少数需要访问客户数据的情况下查看和批准（或拒绝）数据访问请求。 例如，它会在 Microsoft 工程师需要访问客户数据时使用，无论是响应客户发起的支持票证还是 Microsoft 发现的问题。 有关详细信息，请参阅使用 Power Platform 和 Dynamics 365 中的客户密码箱安全地访问客户数据。

安全清单

请参考整套建议。

安全清单