4、权限模型基础：RBAC、ABAC模型简介，以及在网关中的映射关系
权限模型是权限审计网关的核心决策依据。在生产环境中，网关需要根据请求携带的身份与上下文，快速判定“谁（Who）能否对什么（What）执行什么操作（Action）”。本章聚焦两种主流模型——RBAC（基于角色的访问控制）与ABAC（基于属性的访问控制），并阐述它们在网关中的映射落地方式。
4.1 RBAC 模型：角色驱动的权限管理
RBAC 将权限授予“角色”，再将角色授予“用户”。用户通过角色间接获得权限，简化了权限分配与回收。
| 核心概念 | 说明 | 网关映射示例 |
|---|---|---|
| 用户（User） | 访问系统的实体，如 API 调用方 | JWT 中的 sub 或 client_id |
| 角色（Role） | 权限的集合，如 admin、editor、viewer | JWT 中的 role 声明 |
| 权限（Permission） | 对资源的操作许可，如 read:order |
网关策略中的 action + resource 规则 |
| 会话（Session） | 用户激活的角色集合 | 请求上下文中的角色列表 |
网关实践要点：RBAC 在网关层通常通过 JWT 中的
roles 数组传递。网关从 Token 中提取角色，与预加载的策略缓存进行匹配，无需每次回源查询用户-角色关系，延迟可控制在 1ms 以内。
4.2 ABAC 模型：属性驱动的动态决策
ABAC 使用任意数量的属性（用户属性、资源属性、环境属性、操作属性）组合成策略，支持细粒度、上下文敏感的访问控制。
| 属性类别 | 常见属性 | 网关映射示例 |
|---|---|---|
| 用户属性 | 部门、职级、安全等级、IP 段 | 从 JWT 或请求头提取 |
| 资源属性 | 资源类型、所属项目、数据敏感度 | 从请求路径、参数或元数据服务获取 |
| 环境属性 | 访问时间、地理位置、设备指纹 | 从请求上下文或网关插件采集 |
| 操作属性 | HTTP 方法、API 版本、请求频率 | 从请求行或网关统计模块获取 |
性能风险提示：ABAC 策略引擎需要在每次请求时评估多个属性组合，计算复杂度高于 RBAC。网关层应使用预编译的策略表达式（如 CEL、Rego）和属性缓存，避免在热路径上执行字符串解析或远程属性查询。
4.3 RBAC 与 ABAC 对比
| 维度 | RBAC | ABAC |
|---|---|---|
| 粒度 | 粗粒度，基于角色 | 细粒度，基于属性组合 |
| 灵活性 | 低，角色变更需管理员操作 | 高，策略可动态调整 |
| 管理成本 | 低，角色数量有限 | 高，属性与策略数量可能爆炸 |
| 性能 | 高，仅需查表匹配 | 中等，需属性解析与表达式求值 |
| 适用场景 | 组织层级稳定、权限变化少 | 多租户、数据级权限、合规审计 |
4.4 网关中的映射关系
权限审计网关作为统一入口，需要将 RBAC 和 ABAC 模型映射为可执行的策略规则。下图展示了两种模型在网关请求处理流程中的映射位置。
4.5 网关中的策略数据结构
在 Go 网关中，权限策略通常以结构化配置存储。以下是一个同时支持 RBAC 和 ABAC 的策略定义示例：
// Policy 定义网关权限策略
type Policy struct {
ID string `json:"id" yaml:"id"`
Description string `json:"description" yaml:"description"`
// RBAC 字段：匹配角色
Roles []string `json:"roles,omitempty" yaml:"roles,omitempty"`
// ABAC 字段：匹配属性表达式
Conditions []Condition `json:"conditions,omitempty" yaml:"conditions,omitempty"`
// 资源与操作
Resources []string `json:"resources" yaml:"resources"`
Actions []string `json:"actions" yaml:"actions"`
Effect string `json:"effect" yaml:"effect"` // allow / deny
}
// Condition 定义 ABAC 属性条件
type Condition struct {
Attribute string `json:"attribute" yaml:"attribute"` // 如 user.dept
Operator string `json:"operator" yaml:"operator"` // eq, neq, in, contains
Value string `json:"value" yaml:"value"` // 如 "engineering"
}
映射规则总结：
- RBAC 映射：网关从 JWT 中提取
roles→ 匹配策略中的Roles列表 → 命中则检查Resources与Actions。 - ABAC 映射：网关构建属性上下文（用户、资源、环境） → 对策略中的
Conditions逐条求值 → 全部通过则放行。 - 混合模式：策略可同时包含
Roles和Conditions，网关先校验角色，再校验属性条件，实现分层控制。
4.6 网关权限决策流程
以下 SVG 展示了网关在一次请求中执行 RBAC + ABAC 混合决策的完整流程。
性能优化建议：对于纯 RBAC 策略，网关可在启动时构建
map[role]map[resource][]action 哈希表，实现 O(1) 匹配。对于 ABAC 策略，建议将常用属性（如部门、项目）预提取到请求上下文，避免在策略引擎中重复解析。