3 权限模型详解：RBAC、ABAC、PBAC
说到权限模型，你肯定听过 RBAC，但实际项目里光靠角色往往不够用。我这些年做过好几个权限系统，从最简单的后台管理到多租户 SaaS，每个阶段都有不同的痛点。这章我们就来掰开揉碎讲讲三种主流模型：RBAC、ABAC、PBAC。
3.1 RBAC 模型（基于角色的访问控制）
RBAC 的核心思想很简单：把权限分配给角色，再把角色分配给用户。你想想看，一个公司里有几百号人，每人单独分配权限管理起来太累了。我们抽象出几个角色，比如「管理员」「编辑」「访客」，然后给角色挂上权限集合。
具体来说，RBAC 里有三个关键概念：
- 角色（Role） —— 职责的集合，例如「审计员」可以查看日志但不能修改
- 权限（Permission） —— 对某个资源的具体操作，比如“删除订单”
- 会话（Session） —— 用户登录后激活的角色实例，可以同时激活多个角色
我记得早年做的一个 ERP 系统，直接用 RBAC 后，权限模块的代码量减少了一半。但有个坑：角色爆炸。业务一复杂，每个项目都要新建角色，最后光角色表就好几千条。嗯，这时候 RBAC 就不太够用了。
3.2 ABAC 模型（基于属性的访问控制）
ABAC 不再纠结于角色，而是把一切决策交给属性。属性无处不在：用户的部门、资源的安全等级、操作时间、IP 地点。说白了，ABAC 就是用属性来描述“谁、对什么、做什么、在什么环境下”。
策略引擎（Policy Engine）是 ABAC 的大脑，它接收一堆属性，然后匹配策略，决定允许还是拒绝。一个典型的 ABAC 规则长这样：
允许操作：当 用户.部门 == 资源.所属部门 且 当前时间 在 09:00~18:00 内我个人习惯把 ABAC 用在多租户系统里。租户 A 和租户 B 的数据混在一套表里，靠属性隔离权限，比建一堆角色省事多了。但要注意：属性值变化可能导致权限突变。比如用户调部门后，以前能访问的资源可能瞬间消失，你得想好前端怎么优雅地提示。
3.3 PBAC 模型（基于策略的访问控制）
PBAC 可以说是 RBAC 和 ABAC 的融合升级版，但核心从角色、属性变成了策略（Policy）。策略是一个独立、可组合的逻辑单元，它把权限决策完全与代码解耦。
在 PBAC 中，策略引擎执行的不是硬编码的 if-else，而是一套策略语言（比如 XACML、ALFA）。管理员可以随时在线修改策略，而无需重启服务。想象一下：你发现某个 API 被滥用，直接在策略控制台上加一条“拒绝凌晨 2 点到 5 点的 API 调用”，秒级生效。
我做过一个 PBAC 的实现，使用了阿里云的 RAM 策略语法。一开始写策略语句不太习惯，但理解「Effect、Action、Resource、Condition」四个要素后就顺手了。举个例子：
{
"Effect": "Allow",
"Action": ["oss:GetObject"],
"Resource": ["acs:oss:*:*:bucketA/*"],
"Condition": {
"IpAddress": {"acs:SourceIp": "10.0.0.0/8"}
}
}这条策略只允许内网 IP 段下载 bucketA 里的文件。你看，策略写出来就跟配置一样清晰，审计和排查问题非常方便。
3.4 三种模型对比
为了方便你做技术选型，我整理了一个表格。选择时别贪大求全，适合当前业务阶段的才是最好的。
| 维度 | RBAC | ABAC | PBAC |
|---|---|---|---|
| 核心概念 | 角色、权限、会话 | 属性、策略引擎 | 策略、策略引擎 |
| 灵活性 | 低，适合角色固化 | 中，依赖属性设计 | 高，策略可动态组合 |
| 维护成本 | 低，角色管理简单 | 中，属性来源需梳理 | 高，需策略语言培训 |
| 适用场景 | 后台管理、传统企业 | 多租户 SaaS、IoT | 云原生、微服务、审计敏感 |
| 典型实现 | Spring Security、RBAC 库 | Open Policy Agent (OPA)、AWS IAM | XACML、阿里云 RAM |
你发现没有？这三种模型不是替代关系，而是互补。在一个大型系统里，不同模块可能混用它们。比如用户模块用 RBAC，资源模块用 ABAC，全局飞行策略用 PBAC。我见过最好的设计是：用 PBAC 做顶层策略，用 ABAC 做业务隔离，用 RBAC 做基础权限骨架。
3.5 模型关系总览
下面这张图帮你理清三个模型的组件和关系。每次我跟团队讨论权限重构时，都会在会议室白板上画这个图，大家一看就明白怎么选型了。