2. 权限矩阵基础

权限矩阵是描述“谁（主体）能对什么（客体）做什么（操作）”的二维结构。在 API 网关场景下，权限矩阵直接决定了请求是否被允许通过，是零信任架构中策略执行点（PEP）的核心判断依据。本节从基本概念、经典模型和数学表示三个层面建立权限矩阵的理论基础。

2.1 核心概念：主体、客体、操作

权限矩阵由三个基本元素构成，任何权限策略最终都可映射为这三者的笛卡尔积子集：

元素	定义	API 网关中的典型实例
主体（Subject）	发起请求的实体	用户、服务账号、客户端应用、设备
客体（Object）	被访问的资源	API 端点、微服务、数据库表、文件
操作（Operation）	对客体执行的动作	GET、POST、PUT、DELETE、READ、WRITE

2.2 权限矩阵的数学表示

权限矩阵可以用集合论和矩阵代数两种方式严格定义：

2.2.1 集合论定义

设主体集合 S = {s₁, s₂, …, s_m}，客体集合 O = {o₁, o₂, …, o_n}，操作集合 A = {a₁, a₂, …, a_k}。权限策略 P 是三元组 (s, o, a) 的子集：

P ⊆ S × O × A

其中 (s, o, a) ∈ P 表示主体 s 被授权对客体 o 执行操作 a。

2.2.2 矩阵代数表示

权限矩阵 M 是一个 m × n 的矩阵，每个元素 M[i][j] 是一个操作权限向量：

M[i][j] = { a ∈ A | (sᵢ, oⱼ, a) ∈ P }

示例（3 主体 × 3 客体）：
        o₁      o₂      o₃
s₁  {GET}   {GET,POST}  ∅
s₂  {GET}   ∅          {DELETE}
s₃  ∅       {GET}      {GET,PUT}

2.3 RBAC：基于角色的访问控制

RBAC 引入“角色”作为主体与权限之间的中间层，避免直接为每个主体分配权限。核心关系如下：

• 用户-角色分配：用户被赋予一个或多个角色
• 角色-权限分配：角色被赋予一组权限（主体-客体-操作三元组）
• 会话控制：用户激活角色子集，获得对应权限

RBAC 的数学表示为：

设角色集合 R = {r₁, r₂, …, rₚ}
用户-角色关系 UA ⊆ S × R
角色-权限关系 PA ⊆ R × O × A
用户 s 的权限集 = { (o, a) | ∃ r ∈ R, (s, r) ∈ UA ∧ (r, o, a) ∈ PA }

2.4 ABAC：基于属性的访问控制

ABAC 使用属性规则动态计算权限，不再依赖固定的角色-权限映射。属性分为四类：

属性类别	示例	API 网关中的来源
主体属性	部门、职级、安全等级、地理位置	JWT 声明、LDAP 属性
客体属性	资源类型、敏感度、所属项目	API 元数据、资源标签
操作属性	请求方法、时间窗口、频率	HTTP 请求头、网关上下文
环境属性	当前时间、网络 IP、设备指纹	网关运行时环境

ABAC 策略规则的一般形式：

IF (主体属性 满足条件) AND (客体属性 满足条件) 
   AND (环境属性 满足条件)
THEN 允许 操作

示例：
IF (user.department == "finance") 
   AND (resource.sensitivity == "high") 
   AND (environment.time BETWEEN "09:00" AND "18:00")
THEN ALLOW (operation == "READ")

2.5 RBAC vs ABAC 对比

维度	RBAC	ABAC
权限计算方式	静态角色映射	动态属性规则
粒度	粗到中（角色级）	细（属性级）
管理复杂度	低（角色数量可控）	高（属性规则多）
适用场景	组织层级清晰、权限变化少	多租户、环境敏感、合规要求高
API 网关典型用法	路由级权限控制	请求级细粒度策略

2.6 权限矩阵的 SVG 结构图

下图展示了 RBAC 和 ABAC 在 API 网关中的权限决策流程对比：

2.7 权限矩阵在 API 网关中的落地要点

• 矩阵压缩：实际网关中权限矩阵可能极大（百万级主体 × 千级客体），需使用位图、前缀树或规则引擎进行压缩存储
• 缓存策略：RBAC 的角色-权限映射适合全量缓存；ABAC 的属性规则需缓存编译后的决策树
• 审计追踪：每次权限决策应记录主体、客体、操作、决策结果和决策依据（角色/规则 ID）
• 最小权限原则：权限矩阵默认全拒绝，仅显式允许的条目才放行