策略模型设计：ABAC、ReBAC 与选型对比
说到权限策略模型，我见过不少团队一上来就拍脑袋选 RBAC，结果业务复杂了才发现改不动。其实，选模型跟选工具一样——你得先搞清楚你要解决什么问题。
今天咱们重点聊两个进阶模型：ABAC（基于属性的访问控制）和 ReBAC（基于关系的访问控制）。再加上经典的 RBAC，我把这三者的选型逻辑一次性讲透。
ABAC：属性驱动的动态策略
ABAC 的核心思想很简单——用属性来描述一切。谁（主体）、对什么（资源）、在什么环境下（上下文），都拆成属性键值对。
举个例子：
策略：允许访问财务报表
条件：
- 主体.部门 = "财务部"
- 主体.职级 >= "高级"
- 资源.密级 = "内部"
- 环境.时间 between 09:00 and 18:00你看，这里没有写死某个用户或角色，而是用属性组合来表达规则。我在项目中遇到过一家金融公司，他们的合规要求是「只有财务部的高级员工才能在上班时间查看内部密级的报表」——用 ABAC 写出来就是上面那样，清晰又灵活。
ABAC 的核心优势：策略与用户身份解耦，新增一个用户不需要改策略，只要他的属性满足条件就行。
ABAC 的典型场景
- 多租户系统：每个租户的资源隔离，通过 tenantId 属性控制
- 数据分级访问：根据文档密级、用户 clearance level 动态放行
- 时间/地点敏感策略：比如「仅限办公时间访问」、「仅限内网 IP」
我的经验：ABAC 的坑主要在属性管理上。属性来源多了（LDAP、自建用户系统、第三方 IdP），一致性很难保证。我建议先统一属性字典，再上策略引擎。
ReBAC：关系驱动的访问控制
ReBAC 是另一种思路——权限由实体之间的关系决定。最典型的例子就是 Google 的 Zanzibar 论文里描述的模型。
你想想看，在社交网络里，用户 A 能不能看用户 B 的照片？这取决于「A 是 B 的好友」这个关系。用 RBAC 或 ABAC 硬写会很别扭，但 ReBAC 天生就适合这种场景。
关系定义：
- 用户:Alice 是 文档:Report-001 的 "owner"
- 用户:Bob 是 文档:Report-001 的 "editor"
- 用户:Charlie 是 用户:Bob 的 "manager"
策略：如果用户是文档的 owner 或 editor，或者用户的 manager 是文档的 editor，则允许编辑这里的关键是「关系可以传递」。Charlie 虽然是 Bob 的 manager，但通过关系链，他也能编辑 Report-001。这种能力在组织架构、社交图谱、资源层级中特别有用。
注意：ReBAC 的关系图如果设计不好，容易变成「蜘蛛网」。我曾经接手过一个项目，关系深度达到了 7 层，每次权限查询都要遍历整个图，性能惨不忍睹。后来我们限制了关系传递的最大深度为 3 层，才把延迟降下来。
ReBAC 的典型场景
- 文档协作：owner、editor、viewer 的关系链
- 组织架构：上级可以查看下级的数据
- 社交网络：好友、好友的好友、群组成员
- 资源继承：文件夹权限自动继承给子文件
三大模型选型对比
我把 RBAC、ABAC、ReBAC 放在一起做了个对比表，方便你快速决策：
| 维度 | RBAC | ABAC | ReBAC |
|---|---|---|---|
| 核心概念 | 角色 | 属性 | 关系 |
| 策略粒度 | 粗（角色级） | 细（属性级） | 中（关系级） |
| 动态性 | 低（需预定义角色） | 高（属性实时计算） | 中（关系变更后生效） |
| 适用场景 | 组织架构稳定、权限变化少 | 多维度、上下文敏感的策略 | 社交、协作、层级资源 |
| 实现复杂度 | 低 | 高（属性管理、策略引擎） | 中（关系存储、图遍历） |
| 性能瓶颈 | 角色爆炸 | 属性查询延迟 | 关系图遍历深度 |
说白了，没有银弹。我个人的选型原则是：
- 能用 RBAC 就别折腾——80% 的业务场景其实角色就够了
- 属性维度多、策略变化快 → ABAC——比如 SaaS 产品的多租户权限
- 权限天然依赖实体关系 → ReBAC——比如文档协作、社交网络
混合模型：现实中的最优解
在实际项目中，我很少只用一种模型。更多时候是混合使用。比如：
- 用 RBAC 做基础的角色划分（管理员、普通用户）
- 用 ABAC 做细粒度的属性约束（部门、时间、IP）
- 用 ReBAC 处理资源之间的继承关系（文件夹权限）
这样做的好处是：各取所长，互不干扰。角色负责「谁可以做什么」，属性负责「在什么条件下可以」，关系负责「资源之间的权限如何传递」。
避坑指南：混合模型最怕「策略冲突」。我曾经遇到过 ABAC 的策略说「允许」，但 ReBAC 的关系说「拒绝」，结果系统不知道该听谁的。后来我们统一了策略评估顺序：先 RBAC 粗筛，再 ABAC 细筛，最后 ReBAC 做关系校验，拒绝优先。
模型选型决策流程
下面这张图是我自己总结的选型流程，每次做权限设计时我都会过一遍：
嗯，这个流程我用了好几年，基本没翻过车。核心原则就是：从简单开始，按需升级。别一上来就上 ABAC 或 ReBAC，除非你确定 RBAC 真的扛不住。
小结
这一章我们聊了 ABAC 和 ReBAC 的核心思想、适用场景，以及如何跟 RBAC 做选型对比。说白了，选模型不是技术竞赛，而是匹配业务复杂度的过程。我见过用 RBAC 撑起千万级用户系统的，也见过用 ABAC 把自己搞到性能崩溃的——关键不在于模型本身，而在于你清不清楚自己要什么。