你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
标识标识体系结构后，需要管理应用程序和平台登陆区域中资源的授权和访问权限。 考虑每个经过身份验证的主体有权访问和需要访问的资源，以及如何降低未经授权访问资源的风险。 有关详细信息，请参阅标识体系结构设计。
概述
身份和访问管理设计区域提供了指导，帮助你在 Azure 中实现企业访问模型，并实现和保障控制平面安全。 在应用"订阅民主化"设计原则时，应用程序团队可以在平台团队设置的策略防护措施中自行管理工作负载。 此方法也体现了策略驱动的治理原则。
平台团队负责预配新的应用程序登陆区域或订阅。 为应用程序所有者预配登陆区域时，平台团队应使用适当的访问控制对其进行配置，以便应用程序所有者可以管理自己的资源。 应用程序所有者应能够在 Microsoft Entra ID 中创建和管理用户和组，并将角色分配给这些用户和组。 然后，应用程序所有者可以根据需要管理对其资源的访问权限，并将访问权限委托给其他用户和组。 根据应用程序的要求，登陆区域还应具有与Active Directory 域服务（AD DS）或Microsoft Entra 域服务（Microsoft 标识平台订阅）的可选网络连接。
使用 Azure 基于角色的访问控制（RBAC）管理对 Azure 资源的管理访问权限。 请考虑用户是否需要在较小的范围内拥有权限，例如单个应用程序的管理员，或者在更大的范围内拥有权限，例如管理多个应用程序工作任务的网络管理员。 无论哪种情况，都遵循最小化访问原则，并确保用户只有正常活动所需的角色。 必要时使用自定义角色和 Microsoft Entra Privileged Identity Management (PIM) 来强制实施实时 (JIT) 访问。 尽管平台团队负责标识和访问管理基础，但平台和应用程序团队都是服务的使用者，应遵循相同的原则。
标识和访问管理对于成功将一个登陆区域与另一个登陆区域分离以及组织内的工作负荷隔离非常重要。 它是平台和应用程序登陆区域的关键设计区域。
如果你的组织使用订阅分发流程，则可以自动化应用程序落地区域的大量身份和访问配置。 实施订阅自动售货以帮助标准化登陆区域创建，以便应用程序团队可以管理自己的资源。
设计注意事项
某些组织在多个应用程序之间共享服务。 例如，可能有多个独立应用程序使用集中式集成服务。 在这种情况下，请考虑集中管理哪些服务，哪些服务被下放给应用程序团队，并了解需要强制实施安全边界。 为应用程序团队授予对共享服务的管理访问权限可能有助于开发人员工作效率，但提供的访问权限可能比所需更多。
管理不跨越安全边界的应用程序资源可以委托给应用程序团队。 请考虑委派维护安全性和合规性所需的其他方面。 让用户在得到安全管理的环境中配置资源，使组织能够利用云的敏捷特性，并防止出现任何与关键安全或监管边界产生冲突的情况。
RBAC
重要
经典资源和经典管理员将于 2024 年 8 月 31 日停止使用。 删除不必要的共同管理员，并使用 Azure RBAC 进行精细的访问控制。
了解 Microsoft Entra ID 角色与 Azure RBAC 角色之间的差异。
Microsoft Entra ID 角色控制对租户范围内服务的管理权限，这些服务包括 Microsoft Entra ID，以及其他 Microsoft 服务，如 Microsoft Teams、Microsoft Exchange Online 和 Microsoft Intune。
Azure RBAC 角色控制 Azure 资源（例如虚拟机、订阅和资源组）的管理权限。
Azure RBAC 所有者和用户访问管理员角色可以修改 Azure 资源上的角色分配。 默认情况下，Microsoft Entra 全局管理员角色无权管理对 Azure 资源的访问权限。 它必须显式启用。 有关详细信息，请参阅提升访问权限以管理所有 Azure 订阅和管理组。
重要
Microsoft 建议使用权限最少的角色。 这有助于提高组织的安全性。 全局管理员是一个高度特权的角色，应仅限于无法使用现有角色的紧急情况。
下图显示了 Microsoft Entra ID 角色与 Azure RBAC 角色之间的关系：
显示 Microsoft Entra ID 与 Azure RBAC 角色之间关系的示意图。
如果将 属性设置为
isAssignableToRole，则可以创建可分配角色的组，并true。 只有设置此属性的组会受到保护。 唯一可以修改组成员身份的角色是全局管理员、特权角色管理员或组的所有者。只有某些角色可为其他管理员重置密码或多重身份验证 (MFA) 设置。 此限制可防止未经授权的管理员重置高特权帐户的凭据以获取更多权限。
如果 Azure 内置角色不满足组织的特定需求，你可以“创建自己的自定义角色”。 与内置角色一样，可以将自定义角色分配给租户、管理组、订阅和资源组范围内的用户、组和服务主体。 旨在尽可能使用 Azure 内置角色，并在必要时仅创建自定义角色。
设计访问控制策略时，请了解角色的服务限制、角色分配和自定义角色。
部分 Azure RBAC 角色支持基于属性的访问控制（ABAC）或角色分配条件。 使用条件时，管理员可以根据资源的属性动态分配角色。 例如，可以分配存储 Blob 数据参与者角色，但仅适用于具有特定索引标记的 Blob，而不是容器中的所有 Blob。
可以使用具有
Microsoft.Authorization/roleAssignments/write或Microsoft.Authorization/roleAssignments/delete权限的内置和自定义 RBAC 角色来创建、删除和更新角色分配。 具有此角色的任何人都可以决定谁拥有分配范围中任何资源的写入、读取和删除权限。 平台或应用程序登陆区域团队成员应考虑如何将特权角色委派给其他用户和组，以授予他们必要的自主性。 为了确保符合最低特权访问原则，他们可以使用 条件 来委托用户。
设计建议
一般建议
对拥有 Azure 环境（包括平台订阅、应用程序订阅和 Microsoft Entra ID 租户）权限的用户强制实施 Microsoft Entra 多重身份验证 (MFA)。 许多合规框架要求强制实施多因素认证。 MFA 有助于降低凭据被盗和未经授权的访问的风险。 若要防止未经授权的敏感信息访问，请确保在 MFA 策略中包含具有读者角色的用户。
对有权访问 Azure 环境的用户使用 Microsoft Entra 条件访问策略。 条件访问是另一项功能，可帮助保护受控的 Azure 环境免受未经授权的访问。 应用程序和平台管理员应具有反映其角色风险状况的条件访问策略。 例如，你可能要求仅从特定位置或特定工作站执行管理活动。 或者，对具有 Azure 资源管理访问权限的用户的登录风险容忍度可能低于标准Microsoft Entra ID 用户。
启用 Microsoft Defender for Identity 以帮助保护用户身份和保障用户凭据。 Defender for Identity 是 Microsoft Defender XDR 的一部分。 可以使用 Defender for Identity 识别可疑用户活动并获取事件时间线。 还可以将其与条件访问一起使用，以拒绝高风险身份验证尝试。 将 Defender for Identity 传感器部署到本地的域控制器和 Azure 标识订阅中的域控制器。
使用 Microsoft Sentinel 来扩展和提供威胁情报及调查功能。 Sentinel 使用 Azure Monitor 日志、Microsoft Entra ID、Microsoft 365 和其他服务中的日志来提供主动威胁检测、调查和响应。
将管理访问权限与非管理性、日常访问（例如 Web 浏览和电子邮件访问）分开。 Web 和电子邮件是常见的攻击途径。 用户帐户遭到入侵时，如果不使用该帐户进行管理访问，则不太可能导致安全漏洞。
对特权角色使用单独的仅限云的帐户。 不要将同一个帐户用于日常使用和特权管理。 Microsoft Entra ID 和 Azure RBAC 特权角色在 Azure 门户和文档中标记为“特权”。
对于可以管理 Azure 应用程序资源的非特权工作职能角色，请考虑是否需要使用单独的管理帐户或 Microsoft Entra PIM 来控制管理访问权限。 PIM 确保帐户仅在需要时才具有所需的权限，并在任务完成时删除权限（也称为及时访问）。
若要使角色分配更易于管理，请不要将角色直接分配给用户。 应该将角色分配给组，以帮助最大程度地减少角色分配的数量，因为每个订阅都有限制。
使用适用于组的 Microsoft Entra PIM 对特权用户应用实时管理访问控制。 考虑使用权利管理来控制组成员身份。 可以使用权限管理功能将审批和审核工作流添加到组成员资格操作，并帮助确保管理员组成员不会被不必要地添加或删除。
在授予对资源的访问权限时，请使用 Microsoft Entra 专用组管理 Azure 控制平面资源。 Entra 专用用户和组，以及通过 Microsoft Entra Connect 从本地同步的用户和组，都可以添加到仅包含 Entra 用户的组中。 如果组管理系统已就绪，请将本地组添加到仅限 Microsoft Entra 的组。 使用仅限 Entra 的组有助于防止本地目录服务在未经授权的情况下修改云控制平面。 请注意，“仅限 Microsoft Entra”也称为“仅限云”。
创建紧急访问帐户（也称为应急帐户），以免意外地被锁定在 Microsoft Entra ID 组织之外。 紧急访问帐户具有很高的特权，仅分配给特定个人。 安全地存储帐户的凭据，监视其使用情况，并定期测试它们，以确保可以在发生灾难时使用它们。
有关详细信息，请参阅 Microsoft Entra ID 中面向管理员的安全访问做法。
Microsoft Entra ID 建议
将 Microsoft Entra ID 与 Azure Monitor 集成，以便可以分析登录活动以及租户内的更改审核跟踪。 配置诊断设置，将登录日志和审核日志发送到管理订阅中的平台中心 Azure Monitor 日志工作区。
使用 Microsoft Entra ID 治理的权利管理功能创建访问包，通过自动审批流程和特权组成员的定期访问评审来控制组成员身份。
使用 Microsoft Entra 内置角色从租户级别管理以下标识设置：
角色 说明 注意 全局管理员 管理 Microsoft Entra ID 及使用 Microsoft Entra 标识的 Microsoft 服务的所有方面。 不要将 5 个以上的人员分配到此角色。 混合标识管理员 管理从 Active Directory 到 Microsoft Entra ID 的云预配，并管理 Microsoft Entra Connect、Microsoft Entra 直通身份验证、Microsoft Entra 密码哈希同步、Microsoft Entra 无缝单一登录（SSO）和联合设置。 安全管理员 读取安全信息和报告，并管理Microsoft Entra ID 和 Microsoft 365 中的配置。 应用程序管理员 创建和管理应用注册和企业应用的各个方面。 无法授予租户范围的管理同意。 不要将高特权角色分配给低特权角色可以执行的任务。 例如，分配用户管理员角色来管理用户，而不是全局管理员角色。 有关详细信息，请参阅 Microsoft Entra 内置角色权限。
使用管理单元来限制一组管理员，使他们只能管理你的租户中的特定对象。 可以使用管理单元委托对目录子集的管理。 例如，可以将服务台的管理委托给更广泛的组织内的单个业务部门。
管理单元还可以帮助消除将单独的Microsoft Entra ID 租户作为安全边界的需求，其中单独的团队在同一组织中管理Microsoft 365 平台和 Azure 平台。 例如，可以使用管理单元将 Azure 应用程序安全主体的管理委托给应用程序团队，而无需向整个 Microsoft Entra ID 租户授予权限。
使用 受限管理单元 提供进一步的保护。 阻止除指定特定管理员集以外的任何人修改特定对象。 例如，职责策略分离可能要求你使用此功能来阻止任何人修改特定用户帐户，甚至是具有用户管理员角色的用户。 此限制适用于应用程序使用的服务帐户，甚至管理员也不应修改。 还可以阻止特权提升，例如，如果有人修改具有平台或登陆区域管理权限的用户帐户或组。
Azure RBAC 建议
为了简化管理并降低配置错误的风险，请跨所有应用程序登陆区域标准化角色和角色分配。 例如，如果你有一个委托用户管理虚拟机的角色，请使用所有应用程序登陆区域中的相同角色。 此方法还简化了在登陆区域之间移动资源的过程。
使用 Azure RBAC 管理对资源的数据平面访问（如果可能）。 数据平面终结点的示例包括 Azure 密钥库、存储帐户或 SQL 数据库。
确保使用适当的权限模型配置 Azure Monitor 日志工作区。 使用集中式 Azure Monitor 日志工作区时，请使用资源权限来确保应用程序团队可以访问自己的日志，但不能访问其他团队的日志。
内置角色
考虑内置角色是否适合你的要求。 在许多情况下，可以将多个内置角色分配给安全组，以便为用户提供适当的访问权限。 但有时，无法使用内置角色并遵守最低特权访问，因为角色可能包含超出用户要求的权限。 若要进行更精细的控制，请考虑创建自定义角色，该角色反映执行作业函数所需的特定权限。 有关详细信息，请参阅 提供基于角色的授权。
许多 Azure 内置角色在平台和资源级别提供预定义的角色分配。 组合多个角色分配时，请考虑整体效果。
Azure 登陆区域加速器包括多个用于常见管理功能的自定义角色。 可以将这些角色与 Azure 内置角色一起使用。 下表描述了 Azure 登陆区域加速器的自定义管理角色或区域：
管理角色或区域 说明 动作 不作 Azure 平台所有者（例如内置所有者角色） 管理管理组和订阅生命周期 *订阅所有者 订阅所有者的委派角色 *Microsoft.Authorization/*/write、Microsoft.Network/vpnGateways/*、
Microsoft.Network/expressRouteCircuits/*、
Microsoft.Network/routeTables/write、
Microsoft.Network/vpnSites/*应用程序所有者（DevOps、应用操作） 订阅范围内的应用程序或运营团队的参与者角色 *Microsoft.Authorization/*/write、Microsoft.Network/publicIPAddresses/write、
Microsoft.Network/virtualNetworks/write、Microsoft.KeyVault/locations/deletedVaults/purge/action网络管理 (NetOps) 管理平台范围的全局连接，例如虚拟网络、UDR、NSG、NSG、NVA、VPN、Azure ExpressRoute 等 */read、
Microsoft.Network/*、
Microsoft.Resources/deployments/*、
Microsoft.Support/*安全运营 (SecOps) 安全管理员角色，有权横向查看整个 Azure 资产和密钥保管库清除策略 */read、
*/register/action、
Microsoft.KeyVault/locations/deletedVaults/purge/action、
Microsoft.PolicyInsights/*、
Microsoft.Authorization/policyAssignments/*、
Microsoft.Authorization/policyDefinitions/*、
Microsoft.Authorization/policyExemptions/*、
Microsoft.Authorization/policySetDefinitions/*、
Microsoft.Insights/alertRules/*、
Microsoft.Resources/deployments/*、
Microsoft.Security/*、Microsoft.Support/*这些角色可能需要额外的权限，具体取决于责任模型。 例如，在某些组织中，NetOps 角色可能只需要管理和配置全局连接。 在需要更集中的方法的组织中，可以通过更多允许的操作（例如在中心和分支之间创建对等互连）来扩充 NetOps 角色。
角色分配和组
当平台团队预配应用程序登陆区域时，应确保创建所有必需的标识和访问管理对象，例如安全组、标准角色分配和用户分配的托管标识。
在订阅或资源组范围创建登陆区域角色分配。 Azure Policy 分配发生在管理组范围，因此你应该在更低范围预配登陆区域角色分配。 使用此方法可确保登陆区域管理员对其资源拥有完全自治，但无法修改管理其登陆区域的 Azure Policy 分配。
每个应用程序登陆区域都应有自己的组和角色分配。 不要创建泛型组并将其分配给多个登陆区域。 此方法可能会导致配置错误和安全漏洞，并且很难大规模管理。 如果一个用户需要访问多个登陆区域，请将它们分配给每个登陆区域中的相应组。 使用 ID 治理来管理他们的组成员身份。
将角色分配给组，而不是分配给用户。 此方法有助于确保用户在加入或离开组织时具有正确的权限。 它还有助于确保用户在团队之间移动时具有正确的权限。 例如，如果用户从网络团队移动到安全团队，则应将其从网络组中删除，并将其添加到安全组。 如果将角色直接分配给用户，则在迁移到其他团队后，他们将保留该角色。 使用 ID 治理来管理组成员身份，而不是手动添加和删除组成员。
为同一应用程序的不同环境（例如开发/测试和生产）维护单独的安全配置。 为每个环境创建单独的组和角色分配。 不要跨环境共享托管标识或服务主体。 将每个环境视为单独的登陆区域。 此方法有助于确保开发/测试和生产之间的隔离，并标准化在环境之间移动应用程序部署的过程。 如果同一个人需要访问多个登陆区域，则应将它们分配给每个登陆区域中的相应组。
考虑平台管理员是否需要对应用程序登陆区域拥有权限。 如果是这样，请使用 Microsoft Entra PIM 来控制对这些资源的访问，并分配所需的最低特权权限。 例如，平台管理员可能需要访问特定的应用程序登陆区域来排查问题，但不应对应用程序数据或代码进行例行访问。 在这种情况下，平台管理员可以请求访问应用程序。 特权角色管理员批准请求，平台管理员在指定时间段内被授予所需的权限。 此方法有助于强制分离职责，并保护应用程序登陆区域免受意外或恶意配置错误的影响。
将管理责任委托给其他人（例如应用程序团队）时，请考虑是需要完整权限集还是仅需要子集。 遵循最低特权原则 (PoLP)。 例如，可以将“用户访问管理员”角色或 RBAC 管理员角色分配给需要管理对 Azure 资源的访问权限但不需要自行管理资源的用户。 若要限制用户可以委托和分配 Azure RBAC 分配的标识、标识类型和角色，请使用 具有条件的委派角色分配。 应用程序团队可以使用条件在平台团队设置的约束内管理自己的安全主体。 其他特权角色分配需要上报给平台团队。 在使用条件来分配 RBAC 角色时，请考虑以下因素：
查看内置和自定义特权角色的当前角色分配，并评估是否应向这些现有分配添加适当的条件。 例如，可以将条件添加到 Azure 登陆区域加速器提供的订阅所有者和应用程序所有者自定义角色。 这些条件可以限制可以向其分配角色的主体类型，或限制可以分配的特定角色。
为角色分配添加条件时，请遵循 PoLP。 例如，仅限将委派操作应用于向组分配角色，或允许通过委派操作分配除所有者、用户访问管理员和 RBAC 管理员等特权管理员角色之外的所有角色。
如果可用条件模板不满足要求或策略，请生成自己的条件。
查看将 Azure 访问管理委派给其他人 的已知限制 。
下表显示了 Azure 登陆区域环境的示例角色分配结构。 它在安全性和易于管理之间提供平衡。 你可以根据组织的要求调整结构。 可以将同一个人分配给多个组，具体取决于他们在组织内的角色。 但是应该将 RBAC 分配应用于特定登陆区域中的特定组。
资源 用户 角色分配 分配目标 分配范围 应用程序 X 登陆区域 应用程序 X 所有者 应用程序所有者（自定义，包含在 Azure 登陆区域加速器中） Application X Admins安全组应用程序 X 生产和开发/测试订阅 应用程序 X 登陆区域 应用程序 X 所有者 应用程序访问管理员（自定义，具有角色分配条件来管理对其自己的应用程序的访问权限） Application X Admins安全组应用程序 X 生产和开发/测试订阅 应用程序 X 登陆区域 应用程序 X 数据管理员 数据管理员（自定义，具有所需数据资源的权限） Application X Data Team安全组应用程序 X 生产和开发/测试订阅 应用程序 Y 登陆区域 应用程序 Y 所有者 应用程序所有者（自定义，包含在 Azure 登陆区域加速器中） Application Y Admins安全组应用程序 Y 生产和开发/测试订阅 应用程序 Y 登陆区域 应用 Y 测试团队 测试参与者（自定义，具有应用程序测试所需的权限） Application Y Test Team安全组应用 Y 的开发和测试订阅 沙盒 应用程序 Z 开发团队 所有者（内置） Application Z developers安全组沙盒订阅中的应用程序 Z 资源组 平台资源 平台管理团队 参与者（内置） Platform AdminsPIM 组Platform管理组平台登陆区域 平台管理团队 阅读器（内置） Platform Team安全组组织顶级管理组 租户范围 安全团队 安全操作（自定义，包含在 Azure 登陆区域加速器中） Security Ops安全组组织顶级管理组 租户范围 安全团队 条件访问管理员（内置且启用了受保护操作） Security administrators安全组Microsoft Entra ID 租户 租户范围 网络团队 网络操作（自定义，包含在 Azure 登陆区域加速器中） Network Ops安全组所有订阅 租户范围 FinOps 团队 计费读取者（内置） FinOps Team安全组组织顶级管理组 具有
DeployIfNotExists效果的 Azure Policy 分配需要使用托管标识来修正不合规的资源。 如果将系统分配的托管标识用作 Azure Policy 分配过程的一部分，Azure 会自动授予所需的权限。 如果使用用户分配的托管标识，则必须手动授予权限。 托管标识角色分配必须遵循 PoLP，并且仅启用在目标范围执行策略修正所需的权限。 策略修正托管标识不支持自定义角色定义。 将角色分配直接应用于托管标识而不是组。
Microsoft Entra PIM 建议
使用 Microsoft Entra PIM 来遵守零信任模型和最低特权访问原则。 将组织的角色与所需的最低访问级别相关联。 在 Microsoft Entra PIM 中，可以使用 Azure 本机工具、扩展现有工具和进程，或者根据需要同时使用现有和本机工具。
使用 Microsoft Entra PIM 访问评审来定期验证资源权利。 访问评审是许多合规性框架的一部分，因此许多组织已有访问评审过程。
对需要提升访问权限的自动化 Runbook 或者对特权部署管道使用特权标识。 可以使用相同的工具和策略来治理那些访问关键安全边界的自动化工作流，就像治理具有同等权限的用户一样。 应用程序团队的自动化和部署管道应具有角色分配，以防止应用程序所有者提升自己的特权。
控制高特权 Azure RBAC 角色，例如分配给订阅或管理组上的平台或应用程序登陆区域团队成员的所有者或用户访问管理员。 使用 Microsoft Entra PIM for groups 来配置 Azure RBAC 角色，以便要求与 Microsoft Entra ID 角色相同的提升过程。
例如，用户可能需要对应用程序登陆区域中的资源进行有限的管理访问权限。 他们偶尔需要“所有者”角色。 可以创建两个安全组：应用程序管理员和应用程序所有者。 将最小特权角色分配给应用程序管理员组，并将所有者角色分配给应用所有者组。 使用 PIM 组，以便用户在需要时可以请求所有者角色。 在所有其他情况下，用户仅具有执行其典型活动所需的权限。
使用 受保护的操作 与 Microsoft Entra PIM 配合，以添加额外的保护层。 在 Microsoft Entra ID 中，受保护操作是分配有条件访问策略的权限。 当用户尝试执行受保护的操作时，他们必须首先满足分配给所需权限的条件访问策略。 例如，若要允许管理员更新跨租户访问设置，可以要求他们首先满足防钓鱼 MFA 策略。
Azure 登陆区域加速器中的标识和访问管理
标识和访问管理是 Azure 登陆区域加速器实现的核心功能。 该部署包括一个专用于标识的订阅，组织可以在其中部署适合其环境的 AD DS 域控制器或其他标识服务（例如 Microsoft Entra Connect 服务器）。 并非所有组织都需要订阅中的服务。 例如，某些组织可能具有已与 Microsoft Entra ID 完全集成的应用程序。
标识订阅具有一个虚拟网络，该虚拟网络与平台订阅中的中心虚拟网络对等互连。 使用此配置，平台团队可以管理标识订阅，应用程序所有者可以根据需要访问标识服务。 必须保护标识订阅和虚拟网络，以保护标识服务免受未经授权的访问。
Azure 登陆区域加速器实现还包括以下选项：
- 分配用于治理标识和域控制器的建议策略。
- 创建虚拟网络，并通过虚拟网络对等互连连接到中心。