4. 权限模型概述：DAC、MAC、RBAC、ABAC 模型对比，以及网关中权限模型的选择策略

在构建 Go 权限审计网关时，权限模型是决定系统安全性与可维护性的核心架构决策。不同的权限模型在灵活性、安全性、管理成本上各有优劣。本章将系统对比四种主流模型，并给出网关场景下的选型策略。

4.1 四种主流权限模型核心概念

模型 全称 核心思想 典型场景
DAC Discretionary Access Control 资源所有者自主决定谁可以访问 文件系统、个人网盘
MAC Mandatory Access Control 系统强制规则，用户不可绕过 军事、政府机密系统
RBAC Role-Based Access Control 用户通过角色获得权限 企业管理系统、API 网关
ABAC Attribute-Based Access Control 基于主体/资源/环境属性动态决策 微服务、云原生、IoT
网关视角提示： 网关作为流量入口，权限决策需要兼顾性能与粒度。RBAC 和 ABAC 是当前网关领域最主流的两种选择，DAC 和 MAC 通常作为辅助或底层机制存在。

4.2 模型详细对比分析

4.2.1 DAC（自主访问控制）

  • 特点： 资源所有者可自行授予或撤销其他用户的访问权限。
  • 优点： 灵活、实现简单，适合用户自主管理资源的场景。
  • 缺点： 权限分散，难以统一审计；存在信息泄露风险（如木马程序利用所有者权限）。
  • 网关适用性： 低。网关通常需要集中管控，DAC 的分散性不利于审计基线落地。

4.2.2 MAC（强制访问控制）

  • 特点： 系统根据安全标签（如机密、秘密、绝密）强制决定访问，用户无法改变。
  • 优点： 安全性极高，抗篡改能力强。
  • 缺点： 灵活性差，管理成本高，不适合快速变化的业务。
  • 网关适用性： 中。适用于高安全等级网关（如政务、金融核心），但日常业务网关很少直接使用。

4.2.3 RBAC（基于角色的访问控制）

  • 特点： 用户与权限解耦，通过角色作为中间层。支持角色继承、职责分离（SoD）。
  • 优点： 管理简单、易于审计、符合企业组织架构。
  • 缺点： 角色爆炸（Role Explosion）问题；对细粒度、动态属性支持不足。
  • 网关适用性： 高。是大多数网关的首选模型，尤其适合 API 级别权限控制。

4.2.4 ABAC（基于属性的访问控制）

  • 特点： 利用主体属性（用户部门、安全等级）、资源属性（API 路径、数据分类）、环境属性（时间、IP、设备）组合策略。
  • 优点： 粒度极细、动态性强、支持复杂策略。
  • 缺点： 策略引擎复杂、性能开销大、策略管理难度高。
  • 网关适用性： 高。适合需要动态、上下文感知权限的云原生网关，常与 RBAC 结合使用。
关键对比指标：
维度 DAC MAC RBAC ABAC
管理集中度 低 高 高 中
灵活性 高 低 中 高
审计可追溯性 低 高 高 中
性能开销 低 中 低 高
策略复杂度 低 中 中 高

4.3 权限模型关系与演进 SVG 图

权限模型演进与关系图 DAC 自主访问控制 MAC 强制访问控制 RBAC 基于角色 ABAC 基于属性 网关选型推荐：RBAC（基础）+ ABAC（扩展）组合策略 兼顾管理简洁性与动态细粒度控制 主体属性（用户/角色） 资源属性（API/数据） 环境属性（时间/IP） ABAC 策略引擎 策略组合 → 决策 审计日志输出

4.4 网关中权限模型的选择策略

在 Go 权限审计网关中，没有一种模型能完美适配所有场景。推荐采用 分层组合策略：

  1. 基础层：RBAC 作为核心骨架
    • 定义标准角色（如 admin、developer、viewer），管理 80% 的常规权限。
    • 角色与 API 路由、HTTP 方法直接绑定，性能最优。
    • 审计日志清晰记录“谁通过什么角色访问了什么资源”。
  2. 扩展层：ABAC 处理动态与细粒度场景
    • 当需要“仅允许本部门在 9:00-18:00 访问敏感数据”时，引入属性策略。
    • ABAC 策略引擎作为插件集成，仅在复杂策略时触发，避免全量性能损耗。
  3. 安全增强：MAC 思想用于审计基线
    • 对关键操作（如删除审计日志、修改权限策略）实施强制访问控制。
    • 即使拥有 admin 角色，也不能绕过审计基线规则。
  4. 避免：DAC 在网关核心路径中使用
    • DAC 的分散授权特性会破坏审计的完整性，仅可用于非关键配置（如个人偏好）。
选型避坑指南：
  • 不要一开始就追求 ABAC 全量覆盖——策略引擎会成为性能瓶颈，且策略维护成本急剧上升。
  • 不要忽略 RBAC 的角色爆炸问题——建议引入角色分组（Role Group）或层级角色（Hierarchical RBAC）来缓解。
  • 审计网关必须记录每一次权限决策的模型类型和决策依据，否则无法追溯权限漏洞。

4.5 网关权限决策流程 SVG 图

Go 审计网关权限决策流程 API 请求到达 身份认证（JWT/OAuth2） RBAC 角色匹配 角色 → 权限集 ABAC 属性评估 属性 → 策略匹配 策略组合 & 决策 审计日志记录

4.6 实战建议：Go 网关中的模型实现要点

模型 Go 实现关键点 性能优化策略
RBAC 使用 map[RoleID]map[Resource]Action 缓存角色权限 角色权限全量缓存，变更时通过事件刷新
ABAC 基于 cel-go 或 gval 实现策略表达式引擎 策略预编译 + 属性索引，避免运行时解析
MAC 在中间件中硬编码安全标签检查逻辑 标签匹配使用位运算加速
审计 使用 context.Context 传递决策上下文 异步批量写入审计日志，避免阻塞请求路径
Go 代码片段示例：RBAC 核心决策结构 
// RBAC 权限检查核心结构
type RBACEngine struct {
    rolePermissions map[string]map[string]ActionSet // roleID -> resource -> actions
    mu              sync.RWMutex
}

type ActionSet struct {
    CanRead   bool
    CanWrite  bool
    CanDelete bool
}

func (e *RBACEngine) CheckPermission(roleID, resource string, action Action) bool {
    e.mu.RLock()
    defer e.mu.RUnlock()
    if actions, ok := e.rolePermissions[roleID][resource]; ok {
        return actions.Has(action)
    }
    return false
}

4.7 本章小结

  • DAC 灵活但分散，不适合网关审计场景。
  • MAC 安全但僵化，仅用于高安全基线。
  • RBAC 是网关权限的基石，管理简单、审计友好。
  • ABAC 提供动态细粒度控制，适合复杂业务。
  • 推荐策略： RBAC 为主体 + ABAC 为扩展 + MAC 思想保护审计基线。
← 上一章 📖 返回目录 下一章 →