你当前正在访问 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 角色之间的关系：
如果将属性
true设置为isAssignableToRole，则可以创建可分配角色的组，并将 Microsoft Entra 角色分配给组。 仅保护此属性集的组。 唯一可以修改组成员身份的角色是全局管理员、特权角色管理员或组的所有者。只有 某些角色可以重置另一个管理员的密码 或多重身份验证（MFA）设置。 此限制可防止未经授权的管理员重置高特权帐户的凭据以获取更多权限。
如果 Azure 内置角色不满足组织的特定需求，你可以创建自己的自定义角色。 与内置角色一样，可以将自定义角色分配给租户、管理组、订阅和资源组范围内的用户、组和服务主体。 旨在尽可能使用 Azure 内置角色，并在必要时仅创建自定义角色。
设计访问控制策略时，请了解 角色、角色分配和自定义角色的服务限制。
某些 Azure RBAC 角色支持 基于属性的访问控制（ABAC）或角色分配条件。 使用条件时，管理员可以根据资源的属性动态分配角色。 例如，可以分配存储 Blob 数据参与者角色，但仅适用于具有特定索引标记的 Blob，而不是容器中的所有 Blob。
可以使用具有或
Microsoft.Authorization/roleAssignments/delete权限的内置和自定义 RBAC 角色Microsoft.Authorization/roleAssignments/write来创建、删除和更新角色分配。 具有此角色的任何人都可以决定谁拥有分配范围中任何资源的写入、读取和删除权限。 平台或应用程序登陆区域团队成员应考虑如何将特权角色委派给其他用户和组，以授予他们必要的自主性。 为了确保符合最低特权访问原则，他们可以使用 条件 来委托用户。
设计建议
一般建议
对有权访问 Azure 环境（包括平台订阅、应用程序订阅和 Microsoft Entra ID 租户）的用户强制实施Microsoft Entra 多重身份验证（MFA）。 许多符合性框架要求强制实施 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 和电子邮件是常见的攻击途径。 用户帐户遭到入侵时，如果不使用该帐户进行管理访问，则不太可能导致安全漏洞。
对特权角色使用单独的仅限云的帐户。 不要将同一帐户用于每日用于特权管理。 Privileged Microsoft Entra ID 和 Azure RBAC 角色在Azure 门户和文档中标记为 PRIVILEGED。
对于可以管理 Azure 应用程序资源的非特权作业函数角色，请考虑是否需要单独的管理帐户或使用 Microsoft Entra PIM 来控制管理访问权限。 PIM 确保帐户仅在需要时才具有所需的权限，并在任务完成时删除权限（也称为 实时访问）。
若要使角色分配更易于管理，请不要将角色直接分配给用户。 相反，将角色分配给组以帮助最大程度地减少角色分配的数量，每个订阅都有限制。
对组使用 Microsoft Entra PIM 向特权用户应用实时管理访问控制。 请考虑使用权利管理控制组成员身份。 可以使用权利管理功能将审批和审核工作流添加到组成员身份操作，并帮助确保不必要地添加或删除管理组成员。
授予对资源的访问权限时，请对 Azure 控制平面资源使用仅限 entra 的组Microsoft。 仅 Entra 用户和组以及使用 Microsoft Entra Connect 从本地同步的用户和组都可以添加到仅限 Entra 的组。 如果已有组管理系统，请将本地组添加到仅 Microsoft Entra 组。 使用仅限 Entra 的组有助于保护云控制平面免受对本地目录服务的未经授权的修改。 请注意， Microsoft仅 Entra-only 也称为 仅限云。
创建 紧急访问 帐户或打破玻璃帐户，以避免意外被锁定Microsoft Entra ID 组织。 紧急访问帐户具有很高的特权，仅分配给特定个人。 安全地存储帐户的凭据，监视其使用情况，并定期测试它们，以确保可以在发生灾难时使用它们。
有关详细信息，请参阅 Microsoft Entra ID 中管理员的安全访问做法。
Microsoft Entra ID 建议
将 Microsoft Entra ID 与 Azure Monitor 集成，以便分析登录活动和租户中更改的审核线索。 配置诊断设置，将登录日志和审核日志发送到管理订阅中的平台中心 Azure Monitor 日志工作区。
使用Microsoft Entra ID 治理的权利管理功能创建通过自动审批过程和特权组成员定期访问评审来控制组成员身份的访问包。
使用 Microsoft Entra 内置角色 从租户级别管理以下标识设置：
角色 说明 注意 全局管理员 管理使用 Microsoft Entra 标识的 Microsoft Entra ID 和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 登陆区域环境的示例角色分配结构。 它在安全性和易于管理之间提供平衡。 你可以根据组织的要求调整结构。 可以将同一个人分配给多个组，具体取决于他们在组织内的角色。 但是，应将 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安全组组织顶级管理组 生效的
DeployIfNotExistsAzure Policy 分配需要 托管标识 来修正不符合的资源。 如果将系统分配的托管标识用作 Azure Policy 分配过程的一部分，Azure 会自动授予所需的权限。 如果使用用户分配的托管标识，则必须手动授予权限。 托管标识角色分配必须遵循 PoLP，并且仅启用所需的权限才能对目标范围执行策略修正。 策略修正托管标识不支持自定义角色定义。 将角色分配直接应用于托管标识，而不是应用于组。
Microsoft Entra PIM 建议
使用 Microsoft Entra PIM 符合零信任模型和最低特权访问。 将组织的角色与所需的最低访问级别相关联。 在 Microsoft Entra PIM 中，可以使用 Azure 本机工具、扩展现有工具和进程，或者根据需要同时使用现有和本机工具。
使用 Microsoft Entra PIM 访问评审 定期验证资源权利。 访问评审是许多合规性框架的一部分，因此许多组织已有访问评审过程。
对需要提升访问权限或特权部署管道的自动化 Runbook 使用特权标识。 可以使用相同的工具和策略来管理访问用于管理同等权限用户的关键安全边界的自动化工作流。 应用程序团队的自动化和部署管道应具有角色分配，以防止应用程序所有者提升自己的特权。
控制特权高的 Azure RBAC 角色，例如分配给订阅或管理组上的平台或应用程序登陆区域团队成员的所有者或用户访问管理员。 对组使用 Microsoft Entra PIM 来配置 Azure RBAC 角色，因此它们需要与 Microsoft Entra ID 角色相同的提升过程。
例如，用户可能需要对应用程序登陆区域中的资源进行有限的管理访问权限。 有时，他们可能需要“所有者”角色。 可以创建两个安全组：应用程序管理员和应用程序所有者。 将最低特权角色分配给应用程序管理员组，并将所有者角色分配给应用程序所有者角色。 使用 PIM 组，以便用户在需要时可以请求所有者角色。 在所有其他情况下，用户仅具有执行其典型活动所需的权限。
将 受保护的操作 与 Microsoft Entra PIM 配合使用，以添加额外的保护层。 在 Microsoft Entra ID 中，受保护的操作是分配有 条件访问策略的权限。 当用户尝试执行受保护的操作时，他们必须首先满足分配给所需权限的条件访问策略。 例如，若要允许管理员更新跨租户访问设置，可以要求他们首先满足 防钓鱼 MFA 策略。
Azure 登陆区域加速器中的标识和访问管理
标识和访问管理是 Azure 登陆区域加速器实现的核心功能。 部署包括专用于标识的订阅，组织可在其中部署 AD DS 域控制器或其他标识服务（例如Microsoft Entra Connect 服务器）来部署其环境所需的订阅。 并非所有组织都需要订阅中的服务。 例如，某些组织可能具有已与 Microsoft Entra ID 完全集成的应用程序。
标识订阅具有与平台订阅中的中心虚拟网络对等互连的虚拟网络。 使用此配置，平台团队可以管理标识订阅，应用程序所有者可以根据需要访问标识服务。 必须保护标识订阅和虚拟网络，以保护标识服务免受未经授权的访问。
Azure 登陆区域加速器实现还包括以下选项：
- 分配用于治理标识和域控制器的建议策略。
- 创建虚拟网络，并通过虚拟网络对等互连连接到中心。