通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 基于角色的访问控制

  • 项目

基于组的访问权限和特权是一种很好的做法。 处理组而不是单个用户的方式简化了访问策略的维护，提供了跨团队的一致访问管理，并减少了配置错误。 在相应的组中分配用户或删除用户有助于使特定用户的权限保持最新。 Azure 基于角色的访问控制 (Azure RBAC) 可用于对围绕用户角色组织的资源进行细致的访问管理。

有关作为标识和安全策略一部分的建议 Azure RBAC 做法的概述，请参阅 Azure 标识管理和访问控制安全最佳做法。

Azure 基于角色的访问控制概述

通过使用 Azure 基于角色的访问控制，可以在团队中分离职责，并为特定的 Microsoft Entra 用户、组、服务主体或托管标识授予足够的访问权限来执行其作业。 可以限制每组资源的权限，而不是让每个人都可以无限制地访问你的 Azure 订阅或资源。

Azure 角色定义列出了允许或禁止分配有该角色的用户或组执行的操作。 角色的范围指定这些定义的权限适用的资源。 可在多个级别（管理组、订阅、资源组或资源）指定范围。 范围采用父/子关系结构。

Azure RBAC scope hierarchy

有关将用户和组分配给特定角色以及将角色分配给范围的详细说明，请参阅使用 Azure 门户添加或删除 Azure 角色分配。

规划访问控制策略时，请使用最低权限访问模型，该模型仅授予用户执行其工作所需的权限。 下图展示了通过此方法使用 Azure RBAC 的建议模式。

Suggested pattern for using Azure RBAC

注意

定义的权限越具体或越详细，你的访问控制就越有可能变得复杂且难以管理。 随着云资产规模的扩大，尤其如此。 避免特定于资源的权限。 相反，使用管理组进行企业范围的访问控制，使用资源组在订阅中进行访问控制。 还要避免用户特定的权限。 而是分配对 Microsoft Entra ID 中的组的访问权限。

使用 Azure 内置角色

Azure 提供了许多内置角色定义，其中包含三个用于提供访问权限的核心角色：

  • 所有者角色可以管理所有事项，包括对资源的访问权限。
  • 参与者角色可以管理除资源的访问权限之外的所有事项。
  • 读者角色可以查看所有内容，但不能进行任何更改。

从这些核心访问级别开始，附加的内置角色提供更详细的控件，用于访问特定的资源类型或 Azure 功能。 例如，可以使用以下内置角色来管理对虚拟机的访问权限：

有关使用内置角色管理对特定功能的访问的另一个示例，请参阅有关对跨业务单位、环境或项目跟踪成本中控制成本跟踪功能访问权限的讨论。

有关可用内置角色的完整列表，请参阅 Azure 内置角色。

使用自定义角色

尽管 Azure 中内置的角色支持各种不同的访问控制场景，但它们并不一定满足组织或团队的所有需求。 例如，如果你有一组负责管理虚拟机和 Azure SQL 数据库资源的用户，则可能需要创建自定义角色以优化对所需访问控制的管理。

Azure RBAC 文档包含如何创建自定义角色的说明，以及有关角色定义如何工作的详细信息。

大型组织的责任和角色分离

组织可以通过 Azure RBAC 为大型云资产中的各种管理任务分配不同的团队。 它使中心 IT 团队可以控制核心访问和安全功能，同时为软件开发人员和其他团队提供对特定工作负荷或资源组的大量控制。

大多数云环境还可以从使用多个角色的访问控制策略中受益，并强调这些角色之间的责任分离。 此方法要求对资源或基础结构的任何重大更改都需要多个角色完成，确保必须由多人审核并批准更改。 这种责任分离可限制用户在不知道其他团队成员的情况下访问敏感数据或引入漏洞的能力。

下表说明了将 IT 职责划分为各自独立的自定义角色的常见模式：

组 常见角色名称 责任
安全操作 SecOps 提供一般安全监管。
建立并强制执行安全策略，例如静态加密。

管理加密密钥。

管理防火墙规则。
网络运营 NetOps 管理虚拟网络中的网络配置和操作，例如路由和对等互连。
系统运营 SysOps 指定计算和存储基础结构选，并维护已部署的资源。
开发、测试和运营 DevOps 生成和部署工作负荷功能和应用程序。

操作功能和应用程序以符合服务级别协议和其他质量标准。

即使这些角色由不同级别的不同人员执行，这些标准角色中的操作和权限的细分在应用程序、订阅或整个云资产中通常是相同的。 因此，可以创建一组通用的 Azure 角色定义，以应用于环境中的不同范围。 然后，可以为用户和组分配一个公共角色，但仅限于他们负责管理的资源、资源组、订阅或管理组的范围。

例如，在具有多个订阅的中心辐射型网络拓扑中，你可能会对中心和所有工作负荷分支使用一组通用的角色定义。 可以将中心订阅的 NetOps 角色分配给组织的中心 IT 团队成员，他们负责维护所有工作负荷使用的共享服务网络。 然后，可以将工作负荷分支订阅的 NetOps 角色分配给该特定工作负荷团队的成员，这样他们就可以在该订阅中配置网络，以最大程度地支持其工作负荷要求。 两者都使用相同的角色定义，但基于范围的分配可确保用户仅具有执行其作业所需的访问权限。