Technical documentation
RBAC、ABAC 和 ReBAC：别被“替代论”误导，看懂核心差异再选型
RBAC、ABAC 和 ReBAC：别被“替代论”误导，看懂核心差异再选型
RBAC、ABAC 与 ReBAC 分别侧重角色归类、环境属性评估和实体关系，企业应依据权限依赖的核心要素选型，而非盲目追求替代升级。
权限模型的本质：是进化还是分工？
这三种模型并非线性进化的替代关系，而是针对授权核心要素不同的分工工具，各自解决角色、属性或关系维度的访问控制问题。
很多人习惯将 RBAC、ABAC 和 ReBAC 看作一条线性的“进化链”，总觉得新模型必然取代旧模型。这种线性替代论主要源于对权威文档的误读。NIST 计算机安全部门在梳理访问控制背景时，确实描述了从 ACL 和基于角色的模型走向依据属性评估请求的技术路径，并提及 2011 年 FICAM Roadmap v2.0 将属性基模型列为推荐方案 [1]。这一叙述容易让人产生“技术演进即版本更替”的错觉，仿佛后者就是前者的终极形态。
同样，AWS 在 2025 年的架构博客中将关系型授权称为企业授权的“替代方案”，旨在解决复杂实体关系和角色爆炸问题 [2]。但这仅是特定供应商在图数据库语境下的架构定位，并非通用的行业分类规则。现有证据无法证明三者存在唯一的递进顺序或排斥关系 [1][2]。
事实是，这三种模型并非彼此竞争的单一路线，而是针对组织授权信息的不同建模重心。判断依据不应是谁“胜出”，而应看权限依赖的核心要素：是需要角色归类、环境属性，还是实体间关系。忽视这一差异盲目追求“最新标签”，往往会导致策略设计偏离实际需求。
这里有一个常被忽略的视角：很多团队在选型失败后，并非因为模型本身不够先进，而是因为试图用一种模型去解释所有类型的业务逻辑。 比如，一家电商公司试图用纯粹的 RBAC 来管理“用户是否属于某类高价值会员（动态属性）”的权限，结果导致角色数量呈指数级爆炸；反之，另一家初创公司为了追求“灵活”，强行给简单的内部审批流程套用 ABAC，结果让运维人员难以理解每一条规则的触发条件。真正的痛点不在于技术栈的代际差，而在于业务语义的错位——当你的业务问的是“你是谁”时，却强行引入了“你在什么环境下”的复杂计算，或者当业务需要处理“我和这个资源是什么关系”时，却还在死守静态的角色列表。这种错配不仅没有带来效率提升，反而增加了系统的认知负荷和维护成本。
它们各自的主战场在哪里？
三者主战场不同：RBAC 聚焦角色归类，ABAC 负责环境属性评估，ReBAC 则专门处理实体间的动态关系，需根据具体场景匹配。
理解它们各自的“主战场”，比争论谁更先进更重要。这三者分别聚焦于不同的授权核心要素：角色归类、环境属性评估以及实体间关系 [1][2]。
ABAC：不只是属性多，而是显式表达授权理由
ABAC 常被误解为仅仅是给传统模型加了一堆属性字段。这种看法忽略了其本质差异。NIST 将其界定为系统依据主体、对象、动作及相关环境的属性，按规则评估一次访问请求以控制对对象的访问 [1]。这里的关键词是“可评估条件”。
在 ABAC 中，授权理由被显式转化为决策输入：主体是否具备某属性、对象处于何种状态、动作是否符合限制、环境前提是否满足，均可直接参与判定 [1]。区分它与基于角色方案的标准，不在于属性字段的数量，而在于系统是否允许动态的条件评估作为决策依据。如果权限仅依赖静态的角色分配，即便属性再多，本质上仍是传统逻辑；只有当动态属性直接决定访问结果时，才真正进入了 ABAC 的范畴。
ReBAC：是第三条道路吗？其实它常与混合设计共存
关于 ReBAC，AWS 将其定位为处理复杂实体关系的替代方案，旨在解决角色爆炸和令牌膨胀问题 [2]。这一描述容易让人误以为它是独立于前两者的“第三条道路”。但工程现实往往更为复杂。
将 ReBAC 绝对化为独立模型，会遮蔽混合设计的事实。NIST 页面明确指出，属性基模型也可以按照基于条件的规则或关系实施控制 [1]。AWS 提到的“替代”发生在特定图数据库架构语境下，用于应对特定的规模挑战，而非定义通用分类标准 [2]。因此，它并非完全孤立的孤岛，常与其他模型结合使用。
| 关注焦点 | 核心判断依据 | 典型适用场景 |
|---|---|---|
| RBAC | 用户所属的组织角色 | 层级分明、职责固定的传统组织架构 |
| ABAC | 主体、对象及环境的动态属性 | 需根据时间、地点、数据敏感度动态调整的场景 |
| ReBAC | 实体间的直接连接关系 | 社交网络、协作项目等复杂关联结构 |
较稳妥的工程视角是识别某项权限主要依赖角色归类、请求属性还是实体间关系，并据此确定策略输入与审计证据 [1][2]。选择哪种模型，取决于你的业务逻辑究竟是在问“你是谁”、“你在什么环境下”还是“你和资源是什么关系”。
一个值得补充的案例视角是：在 SaaS 协作领域，Slack 和 Notion 等现代工具的成功，很大程度上是因为它们默认采用了 ReBAC 的逻辑来处理“空间 - 成员 - 权限”的关系，而不是像传统 ERP 系统那样先建立庞大的角色树。 当你创建一个“营销项目组”时，你不需要为每个成员去配置一套复杂的“营销经理 + 内容编辑 + 财务审核”的角色组合，只需定义“我是该项目的成员”这一关系，系统自动推导出该关系对应的所有权限。这种模式在处理快速变化的跨部门协作时，比预先定义的静态角色要高效得多。然而，这并不意味着 ReBAC 能解决所有问题——如果一个企业内部有严格的合规要求，规定“只有总监级别的人才能查看薪酬表”，这时候单纯的关系图谱就无法表达“总监”这个抽象概念，必须回归到 RBAC 或 ABAC 的属性判断上。因此，最成熟的架构往往是：用 ReBAC 处理日常的协作流，用 RBAC/ABAC 兜底关键的合规边界。
如何根据核心要素进行权限模型选择？
正确的选型逻辑是先识别业务中权限依赖的最主要因素是角色、属性还是关系，再选择对应侧重的模型工具，而非单纯比较先进性。
很多团队在选型时容易陷入“谁更先进就用谁”的误区，把三种模型看作线性的升级阶梯。事实是，它们并非彼此替代的关系，而是针对不同建模重心的工具 [1][2]。真正的决策第一步，是识别业务中权限依赖的最主要因素是什么。
当权限绑定于身份职能时
如果你的系统里，权限分配主要取决于用户的职位或职能角色，比如“经理”、“财务”或“实习生”，那么基于角色的方案是最稳妥的选择。这种场景下，用户只需被赋予一个角色标签，就能自动继承该角色的所有操作权限。这种基于角色归类的模式，管理成本最低，也最符合传统企业的组织架构逻辑。
当权限需响应动态环境时
如果权限判定需要实时响应环境变化，属性基模型则更具优势。这类场景不只看“你是谁”，更要看“你在什么条件下”。例如，只有在工作时间、特定 IP 地址范围内、且设备安全状态达标时，才允许访问敏感数据。其核心价值在于将授权理由显式表达为可评估的条件集合，让策略能随环境波动而动态调整 [1]。
实操建议：在引入 ABAC 之前，先做一个“规则复杂度测试”。 不要一开始就试图把所有条件都写进代码。你可以尝试列出未来一年内可能出现的 5-10 个高频访问场景，看看这些场景是否都能用简单的 IF (User.Role == X) THEN Allow 来解决。如果超过 40% 的场景需要引入“时间”、“地理位置”、“设备指纹”或“数据标签”等动态变量，那么此时引入 ABAC 才是划算的；否则，强行上 ABAC 只会增加开发成本和调试难度。
当权限依赖复杂关系链时
若权限高度依赖实体间的复杂关系，如项目组成员变动、文档所有者变更或部门层级嵌套，关系型授权提供了第三条路径。它不再单纯依赖静态属性，而是通过图谱结构直接计算实体间的连接关系。这种模式在处理社交网络、协作平台等强关联场景中表现突出。
| 决策维度 | 核心依赖要素 | 典型应用场景 | 推荐模型 |
|---|---|---|---|
| 身份归属 | 用户职位/职能（如经理） | 传统企业行政流程 | RBAC |
| 环境状态 | 时间/IP/设备状态 | 高敏数据临时访问控制 | ABAC |
| 实体关系 | 成员/所有者/层级链接 | 项目协作/文档共享平台 | ReBAC |
最终建议不要盲目追求最新标签。现有材料显示，NIST 允许属性基模型包含关系控制，而 AWS 的“替代论”也受限于特定架构语境 [1][2]。混合使用往往才是解决复杂问题的稳妥工程方案。
常见问题解答 (FAQ)
Q: 我的系统既需要角色管理，又需要动态属性判断，必须二选一吗？ A: 不需要。现代权限体系很少是非此即彼的。你可以采用混合架构：用 RBAC 管理基础的用户分组，再用 ABAC 规则覆盖特定场景（如“仅限工作时间访问”），甚至结合 ReBAC 处理复杂的协作关系。关键在于理清每种策略的边界。
Q: ReBAC 是否意味着要放弃传统的角色概念？ A: 不一定。ReBAC 侧重于“关系”而非“角色”，但在实际工程中，关系往往是角色的补充。例如，在项目中，“项目经理”是一个角色，但“拥有该项目文档编辑权”可能更多依赖于“我是该项目的创建者”这一关系。两者可以共存。
Q: 为什么 NIST 推荐 ABAC，但我还在用 RBAC？ A: NIST 的推荐是基于未来趋势和灵活性的考量，并不代表现有方案过时。对于职责固定、层级清晰的中小型企业，RBAC 依然是性价比最高、维护最简单的选择。选型应服务于业务复杂度，而非盲目跟随标准。
参考来源
- Attribute Based Access Control | CSRC · https://csrc.nist.gov/projects/attribute-based-access-control（A级）
- Graph-powered authorization: Relationship based access control for access management | AWS Database Blog · https://aws.amazon.com/blogs/database/graph-powered-authorization-relationship-based-access-control-for-access-management/（B级）