RBAC vs ABAC：关键差异、典型用例与如何选择

在企业安全领域，身份（Identity）已经成为主要的战场。 IBM X-Force 2025 Threat Intelligence Index 发现，大约 30% 的入侵与滥用有效用户身份有关；而且攻击者越来越倾向于通过登录进入系统，而不是强行突破。

因此，控制这些身份背后的数据、应用程序和基础设施的访问权限，是现代安全中最具影响力的设计决策之一；而 RBAC vs ABAC 则正是这一决策的核心争论。选错了，就会导致两种不良结果之一：要么是权限过度、从而放大泄露影响的用户；要么是权限过紧、无法完成工作的员工。

基于角色的访问控制（Role-based access control，RBAC）和基于属性的访问控制（Attribute-based access control，ABAC）是确定“谁可以访问什么”的两种主导模型。两者都不具有普遍的绝对正确性；对大多数组织而言，实际可行的做法是将二者分层组合，并以策略驱动的访问控制（Policy-based access control，PBAC）作为将两者贯通的治理框架加以扩展。

本指南将探讨这两种模型，说明各自在何种情况下最合适，并展示结合混合方法与 PBAC 如何塑造现代 access control management。

什么是基于角色的访问控制（RBAC）？

基于角色的访问控制（RBAC） 根据组织内用户所拥有的角色授予对资源的访问权限。管理员定义角色，为每个角色分配权限，并将角色分配给用户。用户所拥有的角色决定他们能够访问哪些 IT 资源。

三个核心构建块是用户、角色和权限。管理员将权限挂载到角色上，而不是直接挂载到用户上，因此只要更改某个角色的权限，就会自动更新所有持有该角色的用户的访问权限。正是这种间接机制，使 RBAC 相比于直接进行用户到权限的分配更具可扩展性。

NIST 的 RBAC 模型已标准化为 ANSI/INCITS 359 ，定义了四个 RBAC 成熟度级别，用于描述角色的结构与治理方式的严谨程度：

1. 扁平 RBAC 是基线。用户持有角色，角色承载权限。不存在角色层级，也没有强制执行职责分离。
2. 层级 RBAC 引入了角色继承。管理者角色会继承直接下属角色的所有权限，使层级关系能够自然地映射组织结构。
3. 受限 RBAC 强化职责分离。能够创建财务交易的用户也不能批准这些交易，从而通过基于角色的控制来防止欺诈。
4. 对称 RBAC 还增加了定期复核。会定期审查权限和角色；当访问不再有合理依据时，就会撤销访问权限。

大多数企业计划会选择受限或对称 RBAC，因为诸如 SOX、HIPAA 和 PCI DSS 之类的审计框架都要求有文档化的职责分离以及定期的访问复核。

RBAC 的工作原理

RBAC 是大多数企业平台的默认授权模型，包括 Microsoft 的身份与协作技术栈。相同的基本模式（用户 → 角色 → 权限）出现在大多数组织实际运行的系统中。

Microsoft Entra 中的 Microsoft Entra 有助于管理员管理对云资源的访问。使用 Entra RBAC：

• 你可以启用一组用户来管理虚拟网络，并启用另一组用户来管理虚拟机。
• 赋予数据库管理员管理 SQL 数据库的权限。
• 授予指定组对特定网站的控制权，或允许应用程序访问资源组中的所有资源。

Active Directory 中的 RBAC 基于 Active Directory 充当角色的安全组运行。每个组都拥有对特定资源的访问权限，所有成员都会继承这些权限。AD 包含默认的安全组，管理员也可以创建其他组。内置示例包括：

• Backup Operators 可以在不考虑标准文件权限的情况下恢复和替换文件。
• Remote Desktop Users 可以远程连接到 RD Session Host 服务器。
• Domain Admins 在特定的 AD 域中拥有广泛的权限。
• Enterprise Admins 可以进行影响整个林的更改，例如添加子域。
• Schema Admins 可以修改 Active Directory 架构（schema）。

RBAC in SharePoint 使用预定义的角色，成员会继承这些角色，包括：

• 终端用户在列表和文档库中处理内容。
• 高级用户会与站点组件（如列表、页面和库）进行交互。
• 网站所有者（Site Owners）负责控制整个 SharePoint 站点。
• 网站集合管理员可控制网站集合中的网站。
• SharePoint Farm 管理员对 SharePoint Farm 拥有完全控制权。

Exchange 中的 RBAC 同样遵循基于角色的分配。内置的管理角色包括：

• “收件人管理（Recipient Management）”成员可以创建或更新 Exchange 收件人。
• 帮助台成员可以查看并更新用户属性，例如地址和电话号码。
• Server Management 成员可配置特定于服务器的功能。
• Organization Management 成员在整个 Exchange 组织中拥有最高级别的访问权限。
• Hygiene Management 成员可配置反垃圾邮件和反恶意软件功能。

RBAC 优点

• 易于实施和说明：角色定义会映射到相关方已理解的业务功能。
• 一旦定义角色，管理工作量较低： 入职、角色变更和离职都通过角色分配来完成。
• 便于审计： 审计人员可以列出谁拥有哪些角色，以及这些角色授予哪些权限。
• 自然契合组织层级： 经理、分析人员和管理员会被分配到与业务结构相匹配的角色中。
• 在所有主要身份平台中都得到良好支持： Active Directory、Microsoft Entra、SharePoint 和 Exchange 都内置了 RBAC。

RBAC 的缺点

• 角色爆炸是经典的失败模式：随着组织规模扩大、例外情况不断累积，角色数量可能达到数百甚至数千，使角色变得难以管理。
• 静态角色无法覆盖上下文：位置、设备姿态、访问时间以及资源敏感度，仅靠角色无法表达。
• 过宽的静态授权会带来横向移动风险：如果某个角色持有者的账户被攻破，攻击者将获得该角色授予的所有权限。
• 异常处理会产生“一次性”角色：团队会为边缘情况创建范围很窄的角色，但这些角色很少会被淘汰。
• 角色数量越多，审查负担就越大：在没有自动化的情况下，要在规模化环境中运行对称 RBAC 会非常昂贵。

什么是基于属性的访问控制（ABAC）？

基于属性的访问控制（ABAC） 根据用户、资源、正在请求的操作以及请求发生的环境等属性来授予访问权限。在 RBAC 中，问题是“用户具有什么角色”；而在 ABAC 中，问题是“用户、资源、操作和上下文的组合目前允许做什么”。

管理员定义策略，明确在对特定资源执行某项操作时所需的属性组合。

当用户请求访问时，ABAC 会在运行时将该请求与相关策略进行评估。若属性满足策略，则授予访问权限；否则拒绝访问。

ABAC 在每次访问决策中会评估四类属性：

1. 用户（主体）属性：这些属性描述发起请求的人员：职位名称、部门、资历/等级、安全许可级别、雇佣状态。
2. 资源属性：这些属性描述正在被访问的资产：文件类型、数据分类、所有者、敏感级别、项目标签。
3. 操作属性：这些属性描述用户想要执行的操作：读取、写入、导出、删除、修改。
4. 环境属性：这些属性描述请求的上下文：一天中的时间、位置、IP 地址、设备姿态/安全状态、网络类型。

典型的 ABAC 策略会将这四个类别一起评估。例如："财务用户仅可在办公时间内，并且仅可从公司批准的加密设备访问个人可识别信息（PII）。"

这条单一规则将用户属性（财务部门）、资源属性（PII 分类）、操作属性（读取）以及环境属性（办公时间、受管理的设备）组合起来，从而得出一个明确的“允许或拒绝”决策。

ABAC 如何工作

ABAC 策略会在发起访问请求的瞬间评估属性，而不是依赖预先分配好的角色。请求到达后，策略引擎会检查相关的用户、资源、操作以及环境属性；只有在满足所有条件的情况下，才会授予访问权限。

典型的 ABAC 策略如下所示：

• 要访问薪资信息，用户必须是人力资源（HR）部门的成员，访问必须发生在办公时间内，并且用户只能访问其所属分支机构的记录。
• 要访问销售线索，用户必须是被分配到美国（United States）地区的销售代表。
• 要导出发票，请求必须来自受管理的设备，且必须在办公时间内发起；除非经理批准，否则涉及的记录数量必须少于 2,000 条。

Microsoft Entra 中的 ABAC 是一个实际示例，说明 ABAC 如何扩展 RBAC 而不是取代它。Microsoft Entra 通过角色分配基础权限，但也支持评估属性的条件。

管理员在授予访问权限之前，可以要求对象同时具备角色分配和特定的元数据标签。大多数现代云端 IAM 平台（AWS IAM、Entra、GCP IAM）都通过标签和策略条件支持这种模式。在云环境中，ABAC 通常是对 RBAC 的扩展，而不是对其替代。

ABAC 优点

• 运行时的细粒度、上下文感知决策：访问权限基于当前条件，而非固定的角色分配。
• 减少角色“爆炸”：属性取代了为每个边缘情况都创建狭义定义角色的需求。
• 与零信任（Zero Trust）原则天然契合：每个请求都会根据当前上下文进行评估，这是零信任授权的核心。
• 可随组织复杂度扩展：属性能够覆盖新的场景，而无需新增角色。
• 支持按需（Just-in-time）和时间限制的访问： 诸如“active incident ticket”或“scheduled maintenance window”等环境属性，使短暂访问变得顺理成章。

ABAC 缺点

• 实施复杂度更高： 定义属性集、策略语言和治理模型需要投入大量的前期资源。
• 属性蔓延（attribute sprawl）相当于 ABAC 里的“角色爆炸”（role explosion）： 如果缺乏一致的命名、责任归属和治理，属性库会随着时间推移变得越来越混乱。
• 调试访问决策更困难： 结果取决于多个属性同时进行评估，这会使故障排查变得更加复杂。
• 审计轨迹需要专门的工具：没有决策日志时，重建究竟匹配了哪条策略以及原因并不直观。
• 规模化时的性能开销：在每个请求上评估基于属性的策略，通常比查找基于角色的权限更耗资源。不过，现代策略引擎能够在企业级规模下处理这些需求。

RBAC vs ABAC：关键差异

RBAC 和 ABAC 在每个关键维度上都存在差异：从访问如何被授予，到模型在压力下如何失效。下表总结了两者的权衡取舍。

一句话概括：RBAC 通过稳定的角色定义来组织访问，这种方式便于审计，但无法适应上下文；而 ABAC 在运行时基于灵活的基于属性的策略评估访问，能很好地处理上下文，但治理成本更高。

RBAC 和 ABAC 如何支持安全与合规

这两种模型都强制执行 最小特权，但实现机制不同。RBAC 在角色层面强制最小特权：用户应仅拥有其工作职能所需的角色，并且每个角色只授予该职能所需的权限。

ABAC 在请求层面强制最小特权：即使用户拥有某个角色，也只有在请求的完整上下文（设备、时间、资源敏感度）与策略一致时，才具备访问权限。

ABAC 与 Zero Trust 架构的契合度更高，因为 Zero Trust 要求对每一个请求进行持续的、具备上下文感知的验证。仅靠 RBAC 无法满足 Zero Trust 的要求，因为角色分配是长期存在且静态的。

在实践中，混合模型是组织在规模化部署 Zero Trust 的方式：RBAC 确定哪些主体应当拥有任何访问权限的基线，而 ABAC 则评估当前正在发生的特定请求，是否满足让该访问被认为适当所需的条件。

监管要求的匹配会根据具体框架而偏向不同的模型。

• SOX 和 PCI DSS 受益于 RBAC 在“角色”层面的职责清晰分离。审计人员可以列出角色，将其映射到财务控制措施，并验证不兼容的角色没有被同一用户同时持有。
• HIPAA 和 GDPR 越来越倾向于采用 ABAC 风格的控制，因为两项法规都要求在作出访问决策时考虑数据敏感性、访问目的以及数据主体权利——这些都是基于属性的概念。
• NIST SP 800-53 和 ISO 27001 同时参考两种模型，并建议采用最符合资产风险特征的控制措施。

在合规审计中，RBAC 会生成直接明了的授权证据（这里是角色，这里是它的权限，这里是持有它的人）。

ABAC 会生成决策日志证据（这里是策略，这里是评估的属性，这里说明为什么授予了访问权限）。成熟的合规项目会同时纳入这两方面。

何时选择 RBAC 而不是 ABAC（或反之）

选择取决于组织架构、访问复杂度、合规覆盖范围（footprint）以及 identity governance and administration (IGA) 的成熟度。

选择 RBAC 的情况包括：

• 贵组织的岗位职责定义明确，且访问需求保持稳定。
• 访问决策通常很少依赖于职位名称或部门之外的上下文信息。
• 合规框架要求在角色层面明确分离职责。
• 贵团队的 IAM 工具或专门的身份治理资源有限。
• 贵组织规模较小或中型，且增长模式可预测。
• 审计清晰度至关重要，审计人员需要易于解释的权限（entitlement）报告。

当满足以下情况时选择 ABAC：

• 访问决策取决于角色无法表达的条件：位置、设备姿态（posture）、一天中的时间、数据敏感度、租户边界。
• 你的环境是分布式的、使用多云，或支持混合型员工队伍。
• 例如 HIPAA 或 GDPR 这类监管要求，需要做出具备上下文感知的访问决策。
• 贵组织规模足够大，角色列表开始因需要处理边缘情况而不断增加。
• Zero Trust 是一个明确的架构目标。
• 访问需求经常变化，为每种情景创建新的角色并不现实。

将 RBAC 与 ABAC 结合：混合式方法

大多数成熟的组织并不在这两种模型之间二选一。它们使用 RBAC 作为基础访问，然后在该基础之上叠加 ABAC，用于基于上下文的敏感决策。

混合模型如何工作：

• 以 RBAC 作为基础：角色定义了谁将获得对哪些系统的基础访问权限。财务分析师（Finance Analyst）角色可访问财务报表平台。工程师（Engineering）角色可访问代码仓库。该层负责入职、离职，以及大部分例行的访问权限配置。
• 以 ABAC 作为精细化层：在这一基础之上，基于属性的策略会为敏感操作提供具备情境感知的强制执行。财务分析师可以通过 RBAC 读取报表，但导出 PII 会触发一条 ABAC 策略：要求使用受管理的设备、在营业时间内操作，并且当导出内容超过行数阈值时需要审批。

一个具体的医疗场景示例：组织通过 RBAC 为临床医生授予对患者记录的基础访问权限。随后，ABAC 策略会将实际的记录访问限制在临床医生值班的轮班时间内、仅允许使用医院发放的设备，并且只允许访问分配给临床医生所在科室的患者。

RBAC 回答“此人是否为临床医生”。ABAC 回答“此刻该访问是否恰当”。

这种混合方法可以避免两种方案各自的最糟情况。由于上下文存在于属性中，而不是存在于角色名称中，因此可以避免角色爆炸。

它避免了 ABAC 的混乱，因为广泛的访问决策仍然遵循角色的稳定结构。此外，它还会生成既易于解释又信息更具上下文的审计证据。

PBAC 如何扩展 RBAC 和 ABAC

基于策略的访问控制（Policy-based access control，PBAC）是一种将 RBAC 与 ABAC 连接起来的治理框架。PBAC 不再是单独强制角色或单独评估属性，而是将访问规则集中到可由人阅读的策略中，从而把两者结合起来。

一条 PBAC 策略可能会写道：“分析员可以从任何地点访问非机密文档，并且仅在业务时间内从企业网络访问机密文档。” 第一条子句是基于角色的；第二条子句是基于属性的；两者都存在于同一条策略中，并由中心统一管理。

PBAC 之所以重要，是因为它将授权转换为受治理、可审计的功能。团队可以使用 XACML（eXtensible Access Control Markup Language）等正式语言，或采用策略即代码（policy-as-code）框架来编写策略，对策略进行版本管理、审查，并以编程方式部署。

在多云、混合以及分布式环境中尤为重要：在这些环境里，每个系统都配备各自原生的访问控制实现。PBAC 是大型组织以规模化方式落地混合 RBAC + ABAC 的方法，尤其是在 privileged access management 用于敏感账户的场景中。

Netwrix 如何支持 RBAC、ABAC 以及混合访问控制

Netwrix 不会迫使您在 RBAC 和 ABAC 之间做出取舍。其平台同时支持两者，而两者的组合才是大多数成熟计划真正需要的。

Netwrix Identity Manager 负责基于角色（role-based）的基础：覆盖混合 Active Directory 与 Microsoft Entra ID 的 RBAC 策略、自动化的加入-变更-离职（joiner-mover-leaver）工作流，以及用于在整个生命周期中保持角色准确性的访问认证活动。

其无代码（不需要编写代码）工作流构建器使内部团队能够在不必聘请专业服务的情况下调整角色、审批和自动化配置（provisioning）。这正是防止 RBAC 计划逐步退化为由例外驱动的角色蔓延的关键。

Netwrix Access Analyzer 为混合环境与 ABAC 模型提供其所依赖的“事实依据”。它会映射跨文件系统、SharePoint、Active Directory、数据库以及云平台的有效访问权限，不仅揭示存在哪些权限，更会在考虑组嵌套、继承以及数据敏感性的情况下，说明这些权限实际授予了哪些访问能力。

申请演示 以了解 Identity Manager 和 Access Analyzer 如何在您的 RBAC 基线以及叠加其上的基于上下文的策略中协同工作。