授权模型详解：RBAC、ABAC、PBAC的对比与应用场景
大家好，我是你们这次课程的主讲。说到IAM权限模型，这三个缩写——RBAC、ABAC、PBAC——估计你多少都听过。但真正落地时该怎么选？每种模型到底解决了什么问题？我今天就结合自己踩过的坑，把这三兄弟掰开揉碎讲清楚。
RBAC：基于角色的访问控制
RBAC 是最经典、用得最广的模型。说白了就是“你是什么角色，就能干什么事”。比如“管理员”可以删除用户，“普通员工”只能看自己的信息。角色和权限绑定，用户再挂到角色上。
我在给一家金融客户做权限梳理时，他们最初就是典型的 RBAC，但有 200 多个角色。维护成本极高。不过 RBAC 的优势也很明显：
- 管理简单：角色抽象了权限，新增用户只要分配角色。
- 可审计：谁是什么角色一目了然。
- 适合静态场景：组织架构稳定的话，RBAC 效率很高。
但 RBAC 有个硬伤：粒度粗。比如你是一个部门的经理，RBAC 可能给你“查看本部门所有文档”的权限。可万一你想让某些人只能看某个特定项目文档呢？RBAC 做不到——除非新建角色。这就导致了“角色爆炸”。
ABAC：基于属性的访问控制
ABAC 就灵活多了。它不是看“你是谁”，而是看“你是什么样的人、在什么环境、想操作什么东西”。属性包括：用户属性（部门、职级）、资源属性（文档密级、创建日期）、环境属性（时间、IP、设备类型）等。
举个例子：只有“高级工程师”并且“上午 9 点到下午 6 点”才能“下载”属于“保密级别为内部”的文档。这用 RBAC 得写死多少条策略？ABAC 一行策略就能搞定。
ABAC 的关键挑战：
- 策略治理复杂：属性越多，策略组合爆炸。
- 性能开销：每次访问都要计算属性条件。
- 管理门槛高：需要懂策略语言的运维人员。
PBAC：基于策略的访问控制
PBAC 其实可以看作是 ABAC 的升级版。它不限于属性，而是用更通用的“策略”来定义权限。策略可以是基于属性、角色、甚至上下文规则。说白了，PBAC 是一个更抽象的框架，ABAC 是它的一种具体实现方式。
很多现代 IAM 产品（比如 AWS IAM、Azure RBAC + ABAC 混合）本质上都是 PBAC。策略用类似 JSON 或 YAML 的语言描述，包括“主体、动作、资源、条件”四要素。
三大模型对比
我给你列个表，方便一眼看清楚差异：
| 维度 | RBAC | ABAC | PBAC |
|---|---|---|---|
| 授权依据 | 角色 | 属性（多维度） | 策略（可包含属性、角色） |
| 粒度 | 粗 | 细 | 灵活可调 |
| 管理复杂度 | 低 | 高 | 中高 |
| 适用场景 | 架构稳定、权限简单 | 属性丰富、业务多变 | 混合场景、大型企业 |
| 典型技术 | LDAP 群组 | XACML、ALFA | OAuth2、OPA、AWS IAM Policy |
| 性能 | 优秀 | 一般（需缓存优化） | 取决于策略引擎实现 |
如何选择？——我的实战建议
没一种模型是银弹。我个人习惯这样判断：
- 先看组织规模：少于 500 人，组织架构稳定 → 上 RBAC 足够。
- 再看数据敏感性：如果涉及多级分类、访问时间、地点控制 → 考虑 ABAC。
- 如果你们是大型企业，有专门的 IAM 团队 → PBAC 给足灵活性，同时用策略的版本管理来避免混乱。
知识结构图
下面这张图我把三个模型的关系和应用场景画出来了，方便你记忆：
一点小总结
RBAC、ABAC、PBAC 不是互斥的。实际生产中，我见过很多团队用 RBAC 做主要框架，再在关键资源上叠加 ABAC 策略。比如用户角色是“项目经理”，额外限制只能在“在工作时间”访问“项目所属的服务器”。这其实就是混合模型。
最后提醒一句：模型再漂亮，落地还得看数据。没有准确的用户属性、资源标签、环境上下文，ABAC 就是空中楼阁。先打好基础，再谈灵活——这是我在无数项目里用真金白银换来的教训。