4. 权限模型基础：RBAC、ABAC、PBAC 模型对比与企业级权限策略常见模式

在企业系统集成环境中，权限模型决定了“谁”能对“什么资源”执行“哪些操作”。选择错误的模型会导致权限爆炸、维护成本激增，甚至成为安全审计的盲区。本节从基础模型出发，对比三种主流权限模型，并提炼企业级权限策略的常见模式。

4.1 三大权限模型核心对比

4.2 RBAC：角色驱动的权限分层

RBAC 是当前最广泛应用的权限模型，其核心思想是将权限分配给角色，再将角色分配给用户。用户与权限之间通过角色解耦，极大简化了权限管理。

4.2.1 RBAC 的三种标准层级

• RBAC0（基础模型）： 用户 ↔ 角色 ↔ 权限，三者关系为多对多。
• RBAC1（角色继承）： 角色之间支持层级继承，子角色自动拥有父角色的所有权限。
• RBAC2（约束模型）： 引入职责分离（SoD）约束，如互斥角色、基数约束、先决条件角色。

4.2.2 RBAC 在企业集成中的典型问题

• 角色爆炸： 当业务场景复杂时，角色数量可能膨胀到数百个，管理成本急剧上升。
• 权限僵化： 无法表达“仅在工作时间允许访问”或“仅允许查看本部门数据”等动态约束。
• 审计困难： 用户权限由角色间接决定，审计时需逐层追溯角色-权限映射关系。

4.3 ABAC：属性驱动的动态授权

ABAC 通过评估主体（Subject）、资源（Resource）、环境（Environment）的多维属性来决定是否授权。授权决策不再依赖固定的角色，而是基于属性表达式。

4.3.1 ABAC 属性分类

4.3.2 ABAC 策略示例（伪代码）

策略：仅允许财务部员工在工作时间（09:00-18:00）查看本部门的财务报表
条件：
  subject.department == "财务部"
  AND resource.type == "财务报表"
  AND resource.department == subject.department
  AND environment.time >= "09:00:00"
  AND environment.time <= "18:00:00"
动作：允许（Permit）

4.4 PBAC：策略驱动的统一决策

PBAC 将授权逻辑完全抽象为独立的策略（Policy），由策略引擎统一评估。PBAC 通常与 ABAC 结合使用，但更强调策略的集中管理、版本控制和自动化测试。

4.4.1 PBAC 核心架构

• 策略管理点（PAP）： 策略的创建、编辑、版本管理界面。
• 策略决策点（PDP）： 接收授权请求，根据策略集做出 Permit/Deny 决策。
• 策略执行点（PEP）： 拦截请求，调用 PDP 获取决策并强制执行。
• 策略信息点（PIP）： 提供属性数据源，如 LDAP、数据库、外部 API。

4.4.2 PBAC 策略示例（OPA Rego 语言）

package example.authz

default allow = false

allow {
    input.method == "GET"
    input.path == "/api/orders"
    input.user.role == "admin"
}

allow {
    input.method == "GET"
    input.path == "/api/orders"
    input.user.department == input.resource.department
    input.environment.time >= "09:00"
    input.environment.time <= "18:00"
}

4.5 企业级权限策略的常见模式

在实际企业集成项目中，单一模型往往无法覆盖所有场景。以下四种模式是经过验证的常见组合策略。

4.6 权限模型选择决策流程

4.7 权限模型与契约测试的协同点

在集成环境回放中，权限模型直接影响契约测试的覆盖范围。以下三个协同点需要特别关注：

• 权限契约验证： 每个 API 契约必须声明其所需的权限模型类型（RBAC 角色 / ABAC 属性 / PBAC 策略），并在回放测试中验证权限决策的正确性。
• 属性依赖模拟： ABAC/PBAC 场景下，契约测试需要模拟主体属性、资源属性和环境属性，确保 PDP 在不同属性组合下返回预期的 Permit/Deny。
• 策略版本对齐： PBAC 策略的版本变更必须与 API 契约版本同步，避免生产环境策略与测试环境策略不一致导致的权限漏洞。