【身份与访问控制工程】RBAC、ABAC、ReBAC：权限模型怎么选

在授权架构总览中，我们从宏观层面讨论了 RBAC → ABAC → ReBAC 的推理链。本文从数据结构、查询模式和工程运维三个维度，把三种模型放到同一个坐标系中比较——回答一个具体问题：你的业务到哪个阶段，当前的权限模型会开始出现系统性问题？

一、RBAC：最简单，最有陷阱

1.1 RBAC 的数据结构

RBAC（Role-Based Access Control）的核心数据结构是三个集合和两张关系表：

\(U\)：用户集合
\(R\)：角色集合
\(P\)：权限集合
\(UA \subseteq U \times R\)：用户-角色分配
\(PA \subseteq R \times P\)：角色-权限分配

一次授权检查就是问：是否存在一条路径 \(u \xrightarrow{UA} r \xrightarrow{PA} p\)？

1.2 角色爆炸：RBAC 的熵增定律

RBAC 的工程寿命取决于业务的复杂度增长率。典型路径：

阶段 1（5 个角色）：Admin、Manager、Editor、Viewer、Auditor。
阶段 2（30 个角色）：为每个部门创建 Admin/Viewer 变体（HR-Admin、Eng-Admin、Finance-Viewer……）。
阶段 3（300 个角色）：不同项目需要不同权限——“Project-Alpha 的 Editor，但不是 Project-Beta 的 Editor”。
阶段 4（3000 个角色）：交叉约束出现——“只有经手金额超过 1 万的交易的审批员”、“同时属于 Finance 和 Compliance 部门的人才有权查看审计报告”。

角色爆炸不是缺陷，是 RBAC 的物理定律：RBAC 的每个角色必须在前端设计中提供所有维度——当权限问题的维度从 1 增加到 3（如部门 + 项目 + 审批级别），角色数量按 \(\prod_{i} n_i\) 增长。

1.3 RBAC 仍是主流——为什么

大部分 SaaS 业务的前期权限需求确实只有一维（角色）或二维（角色 + 租户）。RBAC 在这些场景下是最优解：

数据结构简单（user_role、role_permission 两张表）。
管理界面直观（Admin 一看就懂”给这个用户分配这个角色”）。
检查性能最优（缓存 user→roles 映射，O(1) 查询）。

关键判断：当你的角色数量超过”你可以在一页列表里扫完”的量（约 50 个），或者角色名开始出现诸如 Engineering-Manager-APAC-ProjectX 的复合前缀——RBAC 已经到了需要重新评估的阶段。

二、ABAC：表达能力换管理复杂性

2.1 ABAC 的核心抽象

ABAC（Attribute-Based Access Control）的语法是：

如果 主体属性 + 资源属性 + 环境属性 满足 策略规则 → 允许/拒绝

例如：

允许 IF
  subject.department == resource.department
  AND subject.clearance_level >= resource.sensitivity_level
  AND environmental.current_time BETWEEN 09:00 AND 18:00
  AND environmental.ip_address IN trusted_networks

2.2 ABAC 的富策略语言与”策略失控”

ABAC 的表达力来自于富属性——NIST SP 800-162 定义了 ABAC 的属性模型，但其工程实现没有统一标准。不同的策略引擎对属性模型和策略语言的定义不同：

XACML（OASIS 标准，v3.0）：XML 策略语言，部署过重，在云计算时代已基本衰落。
OPA/Rego（CNCF Graduated）：在下一篇文章中深入讨论。
AWS Cedar：AWS 推出的开源策略引擎，语法比 Rego 更友好。也在下一篇文章中讨论。

ABAC 的工程风险不是”策略写不对”——单条策略很容易写对。风险是策略之间的交互：

Policy 1: 允许 Finance 部门访问 finance-data
Policy 2: 拒绝 Contractor 访问 finance-data
Policy 3: 允许 Project-Alpha 成员访问项目相关数据

问题：Finance 部门的 Contractor 能不能访问 Project-Alpha 中的 finance-data？

策略数量超过 50 条后，两两之间的交互已经超出单个人的心算能力。ABAC 的运维成本集中在策略审计（“为什么张三能看到这条数据？”——需要求值所有相关策略）和策略冲突检测（有没有两条策略互相矛盾）上。

2.3 ABAC 的工程启动清单

先定义属性源（Identity Provider 的用户属性、资源元数据、环境上下文），再定义策略。
策略默认拒绝——只显式允许。
实现”策略解释”功能——“为什么这次访问被拒绝了？”的输出必须能追溯到具体策略。
策略变更走 CI/CD 和 code review——不要有”在线编辑器直接改生产策略”的管理员入口。

三、ReBAC：把关系变成权限

3.1 ReBAC 的核心思想

RBAC 和 ABAC 都从”主体有什么属性”出发，ReBAC（Relationship-Based Access Control）从”主体和资源有什么关系”出发。核心语法变成了图：

Allow if: requestor -[editor_of]-> document
Allow if: requestor -[member_of]-> group -[owner_of]-> document
Allow if: requestor -[manager_of]-> user -[creator_of]-> document

这就是 Google Zanzibar 论文的核心模型——在下一篇文章中详细拆解。这里只讨论 ReBAC 与前两种模型在概念层面的对比。

3.2 ReBAC 的表达力优势

ReBAC 的独特优势在于”间接关系”——“请求者不是文档的 Editor，但请求者是文档所在 Project 的 Manager”。这在 RBAC 中需要创建一个 Project-Manager-Role，在 ABAC 中需要维护 subject.managed_projects 属性和 resource.project 属性并做 JOIN。在 ReBAC 中，这是一条图查询——从请求者节点出发，走若干条边，看能不能到达资源节点。

3.3 三种模型的工程权衡

维度	RBAC	ABAC	ReBAC
查询复杂度	O(n_roles) ≈ O(1)	依赖策略求值引擎	O(graph depth)
管理员心智模型	“角色=一组权限”	“规则=属性条件”	“关系=图上的路径”
适合的问题维度	1-2 维（角色 + 可选租户）	3+ 维，属性丰富的场景	关系密集型（组织树、文件共享、社交图）
100 条策略时的可维护性	好（角色可归类）	中（需要策略冲突审计）	中-高（取决于关系图的清晰度）
典型适用场景	SaaS 的功能权限	金融合规、医疗数据隐私	Google Drive 分享、企业组织树权限

选型框架： - 如果你的权限问题是”什么人能做什么操作” → RBAC - 如果变成”什么人在什么条件下能做什么操作” → ABAC - 如果变成”什么人和什么资源之间有什么联系从而能做什么操作” → ReBAC

三者可以在同一系统中混合使用——RBAC 管功能权限，ABAC 管数据权限，ReBAC 管分享和协作权限。

上一篇：服务身份：mTLS、SPIFFE/SPIRE 与 Workload Identity 下一篇：Zanzibar 风格权限系统

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-06-13 · architecture / security

【身份与访问控制工程】IAM 全景：为什么这是高价值赛道

从 2020 年 SolarWinds 到 2024 年 Okta 支持系统泄露，身份基础设施的安全失败反复证明一件事：IAM 不是 IT 支撑系统，而是安全架构的承重墙。本文建立现代 IAM 的全景地图——从认证协议、令牌体系、权限模型到身份治理与平台选型，给出 5 个贯穿全系列的核心问题。

2026-06-18 · architecture / security

【身份与访问控制工程】Zanzibar 风格权限系统：Google 的全球授权引擎

Google Zanzibar 论文在 2019 年发布后，引发了开源授权系统的一波重新设计：Auth0 FGA、SpiceDB、Permify、Ory Keto——全都基于 Zanzibar 的'关系图+命名空间配置'模型。但论文本身只讲了 What，没深入 Why。本文从 Zanzibar 的 relation tuple 模型、namespace config 的语义、consistency 模型（Zookie）和工程权衡出发，拆解为什么 Zanzibar 的设计决策是这样的，以及你自己实现时要面对什么。