权限模型概述：RBAC、ABAC、PBAC 原理与对比
做密钥权限审计 SDK 这些年，我碰到最多的坑就是权限模型选型。选错了，后面越权检测的覆盖率直接打折扣。说白了，权限模型就是你给系统定的一套“谁、在什么时候、凭什么、能干什么”的规则。咱们搞审计的人，必须把这套规则吃透，不然写出来的检测逻辑全是漏洞。
RBAC — 基于角色的访问控制
RBAC 应该是现在最普及的模型了。核心思路就一句话：把权限挂到角色上，再把人挂到角色上。你想想看，用户不直接跟权限打交道，省事不少。
- 用户（User）：就是具体的人或系统账号
- 角色（Role）：权限集合的代名词，比如“管理员”、“审计员”、“只读用户”
- 权限（Permission）：具体的操作，比如“读取密钥”、“签发证书”、“撤销权限”
- 会话（Session）：用户激活角色的桥梁
我在一个金融项目里遇到过典型问题：某个同事离职后账号没禁用，但他的角色在审计期内还是“高级管理员”……你懂我意思吧？RBAC 的粗粒度特性让它管理简单，但也容易留下“角色精分”的隐患——一个角色塞了太多权限，结果谁也说不清这角色到底能干嘛。
ABAC — 基于属性的访问控制
ABAC 就比 RBAC 灵活多了。它不用角色，而是靠 一堆属性 拼出决策。属性可以来自用户、资源、环境、操作动作……组合起来能写出非常细的规则。
举个例子：
允许读取 密钥 当且仅当
用户.department == 密钥.owner_department
AND 用户.安全等级 >= 密钥.安全等级
AND 当前时间 IN [09:00, 18:00]
AND 访问来源IP IN 公司网段
看到没？一条策略就把部门、密级、时间、地点全约束了。我曾经给一个云平台做过审计 SDK，他们用 ABAC 定了 200 多条属性规则，越权检测的召回率直接拉到 97% 以上。副作用就是性能压力大——每次鉴权要拉一串属性，延迟容易飙上去。
PBAC — 基于策略的访问控制
PBAC 这个名字容易跟 ABAC 搞混，但它们的侧重点不同。PBAC 的核心是 策略（Policy） 的独立管理和组合。它不限定你用属性还是角色来写策略，而是强调策略的声明式、可重组、可审计。
通常 PBAC 的体系里会有这么几层：
- 策略定义点（PDP）：接收决策请求，根据策略集合做最终裁决
- 策略执行点（PEP）：在资源入口拦截请求，问 PDP 要结果
- 策略管理点（PAP）：给管理员写策略用的界面或 API
- 策略信息点（PIP）：拉数据源（比如 LDAP、数据库）给 PDP 用
XACML 和 OPA 就是 PBAC 的典型实现。我在审计 SDK 里集成过 OPA，策略文件写成 Rego 语言，每次变更只需重载策略文件，不用改代码。这一点对审计来说太香了——策略变更历史可以全部留存，配合版本比对，谁什么时候改了哪条规则一目了然。
三种模型对比
下面这张表是我自己整理的，平时面试和写文档都用它。你看清楚区别在哪。
| 维度 | RBAC | ABAC | PBAC |
|---|---|---|---|
| 核心抽象 | 角色 | 属性 | 策略 |
| 粒度 | 粗（角色级） | 细（属性表达式） | 可粗可细（策略定义） |
| 策略变更方式 | 改角色-权限映射 | 改规则引擎 | 改策略文件/库 |
| 适用场景 | 组织结构稳定的系统 | 多维度、多租户、动态属性 | 策略需频变、合规要求高 |
| 审计友好度 | 一般（角色膨胀后难追溯） | 好（每条规则可记录属性来源） | 最好（策略版本化管理） |
| 性能开销 | 低（缓存角色即可） | 中高（属性收集与计算） | 中（PDP/PEP 通信开销） |
关键点：审计 SDK 里我最关心的是“可审计性”和“变更可追溯”。从这张表看，PBAC > ABAC > RBAC。但也不是，如果业务简单，RBAC 加上操作日志也够用。
模型联动思路
实际生产中没人会只用一个模型。我见过最常用的组合是：
- 基础层用 RBAC：定义粗粒度的角色和权限骨架，比如“管理员”、“操作员”
- 在关键接口叠加 ABAC：比如密钥下载时需要校验 IP 属性、设备属性
- 整个权限层用 PBAC 兜底：策略引擎里既有角色规则也有属性规则，统一由 PDP 决策
这样既控制了复杂度，又保留了灵活性。审计 SDK 的越权检测逻辑也要跟着这种混合模型调整——你不能只检查角色不检查属性，否则就是白忙活。
选型建议
如果让我给刚入行的同学一个建议：别一开始就想上 ABAC 或 PBAC。RBAC 虽然笨，但足够应付 80% 的场景。等到你发现角色膨胀到上千个、或者需要按时间/地点限制权限时，再用 ABAC 做增量补丁。PBAC 更适合那些合规审计极严的场景（比如金融/政务），因为策略版本管理和变更审批流程是刚需。