第三章：权限模型选型权衡——RBAC、ABAC、PBAC的适用边界与组合策略

在审批流系统中，权限模型决定了“谁能在什么条件下对什么资源执行什么操作”。选型不当会导致权限爆炸、维护困难或安全漏洞。本章从边界、分层、组件职责、数据/控制流、信任链路、选型权衡、风险点、落地步骤及验收标准九个维度，剖析三种主流模型——RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）、PBAC（基于策略的访问控制）——的适用场景与组合策略。

3.1 适用边界与核心差异

3.2 分层与组件职责

推荐分层架构如下：

• 身份层：用户、组、角色元数据（LDAP / OIDC 提供者）。
• 属性层：环境属性（时间、IP、客户端）、资源属性（文档密级、部门）、上下文属性（审批阶段、金额区间）。
• 策略层：策略库管理（PBAC 核心），存储策略定义并支持版本控制。
• 决策层：策略决策点（PDP）——根据策略和属性计算授权结果（allow/deny）。
• 执行层：策略执行点（PEP）——拦截请求，调用 PDP 并实施结果。

3.3 数据流与控制流

• 控制流：用户发起审批动作 → PEP 拦截请求 → PDP 获取主体/资源/环境属性 → PDP 匹配策略规则（RBAC/ABAC/PBAC混合） → 返回 allow/deny → PEP 放行或拒绝。
• 数据流：PDP 通过接口从身份服务获取角色，从属性服务获取实时属性（如审批金额），从策略库加载策略定义。决策日志异步写入审计数据库。

3.4 选型权衡矩阵

实际项目中，需根据以下变量综合选择：

• 角色数量：超过 50 个角色时，RBAC 易出现角色膨胀，需引入 ABAC 垂直切片。
• 属性维度：超过 4 个独立属性（如时间、地域、金额、部门）时，ABAC 优于纯 RBAC。
• 策略变更频率：每周变更 > 3 次，建议 PBAC 策略中心 + 灰度发布。
• 审计要求：需追溯“为何拒绝”时，PBAC 提供结构化策略日志优于硬编码。

3.5 组合策略推荐

1. 基础层（RBAC）：定义核心角色（财务经理、法务、采购专员），分配基础 CRUD 权限。
2. 条件层（ABAC）：在角色之上叠加条件，如“仅限周一至周五 09:00-18:00 可提交审批金额 > 10万”。
3. 治理层（PBAC）：使用 OPA（Open Policy Agent）或类似引擎定义全局策略，如“任何审批均需最终复核人签名确认”。

策略示例：

package approval
default allow = false
allow {
    input.role in ["finance_manager", "legal_approver"]
    input.action == "approve"
    input.amount <= 100000
    time.weekday >= 1
    time.weekday <= 5
    time.hour >= 9
    time.hour < 18
}

3.6 风险点与应对

• 策略覆盖遗漏：混合模型中，ABAC 条件可能被 PBAC 策略绕过，需建立策略冲突检测。
• 性能退化：ABAC 属性查询过多导致 PDP 响应超时，建议对角色和静态属性做本地缓存，动态属性使用异步刷新。
• 权限循环：PBAC 策略规则中若存在互相引用的 allow/deny，容易死锁，需做规则拓扑排序预防。

3.7 落地步骤

1. 权限需求梳理：与业务方确认至少 10 个典型审批场景（工单、报销、合同等）。
2. 模型基线选择：角色数 ≤ 30 且属性简单 → 纯 RBAC；否则采用 RBAC+ABAC 混合。
3. 策略引擎选型：部署 OPA 或内置策略引擎，确保支持热加载。
4. 属性源接入：打通 HR 系统（部门、职级）、CRM（客户等级）、财务系统（金额段）。
5. 全链路测试：覆盖边界条件（午夜、跨时区、角色缺失、属性为空）。
6. 灰度上线：先让 5% 用户切到新权限模型，监控 PDP 延迟与决策正确率。

3.8 验收标准