授权的膨胀：从 ACL 到 PBAC 的认知跃迁
1. ACL (Access Control List) - 访问控制列表
诞生年代：1970s (UNIX 文件系统时代)
核心机制：
- 直接绑定：用户 ↔ 资源（一对一或一对多）
- 列表形态：每个资源维护一张"谁可以访问我"的列表
- 典型实现：Linux 文件权限
rwxr-xr-x、早期数据库表级权限
架构隐喻： 像夜总会门卫手里的名单——"张三可以进，李四不可以"，名单贴在门上，每次来人逐条检查。
致命缺陷：
- 规模爆炸：1000 用户 × 1000 资源 = 1,000,000 条权限记录
- 无抽象层：新员工入职需在所有相关资源上手动添加权限
- 无法表达角色：无法定义"所有经理都能查看财报"，只能逐个经理添加
适用边界： 单机系统、用户 < 100、资源粒度粗（整表/整目录）、无复杂组织层级。
2. RBAC (Role-Based Access Control) - 基于角色的访问控制
诞生年代：1996 (Sandhu, Coyne, Feinstein, Youman 的学术论文正式定义)
核心机制：
- 引入中间层：用户 → 角色 → 权限（间接绑定）
- 分离职责：HR 负责"分配角色"，IT 负责"角色绑权限"
- 继承与层次：角色可继承（如"技术总监"继承"开发工程师"所有权限）
架构隐喻： 像军队军衔制度——不直接命令"张三可以开坦克"，而是规定"上尉可以开坦克"，再给张三授上尉军衔。换防时只需调整军衔，无需重写军规。
三类模型演进：
- RBAC0：基础模型（用户-角色-权限）
- RBAC1：增加角色继承（Hierarchy）
- RBAC2：增加职责分离（SoD，如"会计"与"出纳"角色互斥）
解决了什么：
- 组织映射：完美匹配企业科层制（经理→主管→员工）
- 批量管理：1000 员工入职只需赋予"普通员工"角色
- 合规审计：清晰看到"哪些人有权限访问财务系统"（查角色分配）
局限性：
- 静态性：无法处理"工作时间才能访问"或"临时借调"场景
- 角色爆炸：矩阵式组织（员工同时属于项目 A 和部门 B）导致角色组合爆炸（ProjectA-Manager, ProjectB-Manager...）
3. ABAC (Attribute-Based Access Control) - 基于属性的访问控制
诞生年代：2010s (NIST 标准 800-178，随着云原生和动态环境兴起)
核心机制：
- 动态判断：权限 = f(主体属性, 资源属性, 环境属性, 操作属性)
- 策略规则：
IF 部门=技术部 AND 职级≥P5 AND 时间在09:00-18:00 THEN 允许访问 - 上下文感知：结合实时数据（IP 地址、设备健康度、地理位置）
四维属性：
- 主体属性（用户）：部门、职级、项目组成员标签
- 资源属性（数据）：密级（公开/机密/绝密）、所属业务线
- 环境属性（上下文）：时间、网络位置（内网/外网）、威胁等级
- 操作属性：读、写、删除、导出（不同操作不同策略）
架构隐喻： 像智能大厦的门禁——不仅看工牌（角色），还看你从哪来（是否从停车场直接上来）、什么时间（周末禁止进入）、是否携带危险品（设备安全状态）。
解决了 RBAC 的什么痛点：
- 动态权限：临时借调人员无需创建新角色，只需标记
临时归属=项目A - 数据权限："只能查看本大区的销售数据"（资源属性=大区标签）
- 风险自适应：检测到异地登录自动降级权限（环境属性变化）
实现代价：
- 策略引擎复杂：需要规则引擎（Drools）或专用语言（XACML）
- 性能开销：每次访问需实时计算多维度属性（缓存策略至关重要）
- 调试困难：权限被拒绝时，需追溯哪条属性不匹配（可观测性要求高）
4. PBAC (Policy-Based Access Control) - 基于策略的访问控制
诞生年代：2020s (云原生时代，以 OPA - Open Policy Agent 2016 发布为标志)
核心机制：
- 策略即代码（Policy as Code）：用声明式语言（Rego、Cedar、CEL）写权限规则，存 Git 版本控制
- 解耦决策与执行：PDP (Policy Decision Point) 独立部署，PEP (Policy Enforcement Point) 只负责询问
- 分布式决策：Sidecar 模式，每个服务本地 OPA Agent，毫秒级响应
与 ABAC 的关键区别：
| 维度 | ABAC | PBAC |
|---|---|---|
| 表达形式 | 属性键值对 + 规则引擎 | 领域特定语言（DSL） |
| 版本控制 | 数据库表，难追溯 | Git 管理，Code Review |
| 测试能力 | 黑盒测试 | 单元测试、策略模拟（opa test） |
| 复用性 | 规则与应用耦合 | 策略包（Bundle）跨服务复用 |
架构隐喻： 像宪法与法庭——宪法（策略代码）写在纸上公开，法庭（OPA）根据宪法判决每个案件（访问请求），警察（业务服务）只负责执行判决，不参与立法。
Rego 策略示例（OPA 语言）：
# 策略：允许技术部员工在工作时间查看非机密文档
allow {
input.user.department == "技术部"
input.resource.classification != "绝密"
input.action == "read"
time.now_ns >= input.user.work_start_time
time.now_ns <= input.user.work_end_time
}
为什么叫"膨胀" ：
- 概念膨胀：从简单的"列表"到"角色"到"属性计算"再到"图灵完备的策略语言"
- 职责膨胀：授权从 DBA/运维的手工配置，变为开发者的代码工程（需 CI/CD、测试、灰度发布）
- 位置膨胀：授权决策从数据库层上浮到独立的策略引擎（Sidecar），成为与业务服务平级的"一等公民"
架构师洞察：授权模型即组织模型
康威定律在安全领域的投射：
- 当你用 ACL：说明你的组织是作坊式——老板亲自决定谁能进每个房间
- 当你用 RBAC：说明你的组织是科层制——金字塔结构，汇报线清晰（传统企业）
- 当你用 ABAC：说明你的组织是矩阵式——员工身兼多职（项目+部门），需动态协调（现代互联网公司）
- 当你用 PBAC：说明你的组织是平台化——安全策略是公共基础设施，由专门团队治理（大型 SaaS/云厂商）
决策树：
用户数量 < 100 且 组织扁平 ?
→ ACL
需要映射严格层级且 权限相对静态 ?
→ RBAC
需要上下文感知（时间/地点/数据范围）且 权限动态变化 ?
→ ABAC
多团队协作 且 策略需版本控制/自动化测试 且 微服务架构 ?
→ PBAC (OPA/Cedar)
终极趋势： 现代架构（Istio + OPA）正在实现 RBAC + ABAC + PBAC 的融合——用 RBAC 处理粗粒度角色，ABAC 处理动态上下文，PBAC 处理策略的版本治理。这不是替代关系，而是分层治理：
Gateway 层：RBAC（粗筛，快速拒绝）
Service Mesh 层：ABAC（细筛，基于实时属性）
Domain 层：PBAC（业务规则，如"只能查看本部门且非冻结状态的订单"）
