4. 权限模型基础：RBAC、ABAC、PBAC 模型对比与 Go 数据结构设计

权限模型是网关审计事务边界的核心决策依据。不同的模型决定了“谁在什么条件下能对什么资源执行什么操作”的判定逻辑，直接影响事务边界的粒度、性能与可审计性。本节从模型原理、对比分析到 Go 语言中的数据结构实现，建立完整的权限模型知识体系。

4.1 三大权限模型核心原理

4.2 模型对比分析

4.2.1 判定流程对比

• RBAC 判定流程：用户身份 → 获取角色 → 角色权限表查询 → 返回允许/拒绝。时间复杂度 O(1)，适合高频低延迟场景。
• ABAC 判定流程：请求上下文 → 提取主体/客体/环境属性 → 属性匹配引擎 → 布尔表达式求值 → 返回决策。时间复杂度 O(n)，n 为属性规则数。
• PBAC 判定流程：请求上下文 → 策略匹配（条件优先级） → 策略执行（含副作用） → 返回决策 + 审计日志。支持 deny-override 或 permit-override 策略组合。

4.2.2 优缺点对比表

4.3 权限模型关系图

下图展示了三种模型在网关事务边界中的定位与关系：RBAC 提供基础角色映射，ABAC 补充属性维度，PBAC 作为顶层策略引擎统一决策。

4.4 Go 语言权限数据结构设计

在 Go 中设计权限数据结构时，需要兼顾序列化效率、内存占用与可扩展性。以下给出三种模型对应的核心数据结构，并附带事务边界标记。

4.4.1 RBAC 数据结构

// RBAC 核心结构：用户-角色-权限三级映射
type User struct {
    ID       string   `json:"id"`
    Roles    []string `json:"roles"`     // 角色列表，支持多角色
    TenantID string   `json:"tenant_id"` // 租户隔离
}

type Role struct {
    Name        string   `json:"name"`
    Permissions []string `json:"permissions"` // 权限标识，如 "order:read"
    ParentRole  string   `json:"parent_role,omitempty"` // 角色继承
}

// 事务边界标记：资源级
type RBACBoundary struct {
    Resource string `json:"resource"` // 如 "/api/v1/orders"
    Action   string `json:"action"`   // 如 "read", "write"
    Role     string `json:"role"`     // 允许的角色
}

4.4.2 ABAC 数据结构

// ABAC 属性定义：支持主体、资源、环境三维属性
type AttributeSet struct {
    Subject  map[string]interface{} `json:"subject"`  // 用户属性：部门、级别、地区
    Resource map[string]interface{} `json:"resource"` // 资源属性：类型、所有者、敏感等级
    Action   string                 `json:"action"`   // 操作类型
    Context  map[string]interface{} `json:"context"`  // 环境属性：时间、IP、设备指纹
}

// ABAC 规则：属性表达式
type ABACRule struct {
    ID         string `json:"id"`
    Effect     string `json:"effect"`     // "allow" 或 "deny"
    Condition  string `json:"condition"`  // 如 "subject.department == 'finance' && resource.sensitivity <= 3"
    Priority   int    `json:"priority"`   // 规则优先级，数字越小优先级越高
}

// 事务边界标记：字段级
type ABACBoundary struct {
    ResourcePattern string   `json:"resource_pattern"` // 资源匹配模式，支持通配符
    Fields          []string `json:"fields"`           // 允许访问的字段列表
    ConditionExpr   string   `json:"condition_expr"`   // 条件表达式
}

4.4.3 PBAC 数据结构

// PBAC 策略定义：支持条件组合、动作编排、审计追溯
type Policy struct {
    ID        string   `json:"id"`
    Version   int      `json:"version"`   // 策略版本，用于审计追溯
    Name      string   `json:"name"`
    Effect    string   `json:"effect"`    // "permit" 或 "deny"
    Subjects  []string `json:"subjects"`  // 主体匹配列表
    Resources []string `json:"resources"` // 资源匹配列表
    Actions   []string `json:"actions"`   // 操作匹配列表
    Conditions []Condition `json:"conditions"` // 条件列表（AND 逻辑）
    AuditLevel string   `json:"audit_level"` // "none", "basic", "detail"
}

type Condition struct {
    Field    string `json:"field"`    // 属性字段路径
    Operator string `json:"operator"` // "eq", "neq", "gt", "lt", "in", "contains"
    Value    interface{} `json:"value"`
}

// 事务边界标记：操作级+数据级
type PBACBoundary struct {
    PolicyID     string `json:"policy_id"`
    Operation    string `json:"operation"`     // 如 "create_order", "cancel_order"
    DataFilter   string `json:"data_filter"`   // 数据过滤表达式，如 "amount < 5000"
    AuditTrailID string `json:"audit_trail_id"` // 审计追踪 ID
}

4.5 权限模型选择决策树

在实际网关事务边界设计中，可按以下决策树选择主导模型：

4.6 事务边界中的权限模型实践要点

• 缓存策略：RBAC 角色权限表适合全量缓存（如 Redis Hash），ABAC 属性规则适合本地 LRU 缓存，PBAC 策略建议使用 etcd 或 Consul 做分布式配置中心。
• 审计日志：PBAC 策略执行时必须记录策略 ID、版本号、条件快照，以便事后审计时复现决策上下文。
• 性能优化：在网关层，先执行 RBAC 快速过滤（O(1) 角色匹配），再执行 ABAC 属性判定（O(n) 规则匹配），最后执行 PBAC 策略引擎（仅对高风险操作启用）。
• 事务边界标记：每个权限判定结果应携带 BoundaryTag，标明该次判定覆盖的资源范围、字段范围和数据过滤条件，便于事务边界计算。