3. 权限模型选型对比：DAC、MAC、RBAC、ABAC、ReBAC 适用场景与权衡矩阵
在模块间权限隔离设计中，选择恰当的权限模型直接决定了系统的安全性、可维护性以及未来扩展的灵活性。本章深入对比五种主流权限模型——自主访问控制（DAC）、强制访问控制（MAC）、基于角色的访问控制（RBAC）、基于属性的访问控制（ABAC）和基于关系的访问控制（ReBAC），从定义、适用场景、核心权衡三个维度建立选型矩阵，并提供架构层面的决策路径。
核心观点：没有最优的模型，只有与业务结构和信任模型最匹配的模型。多模型组合在大型系统中十分常见，例如“RBAC 策略主体 + ABAC 动态属性过滤”或“ReBAC 管理组织关系 + RBAC 管理功能权限”。
3.1 模型定义与特征速览
| 模型 | 核心概念 | 授权决策依赖 | 典型粒度 |
|---|---|---|---|
| DAC | 资源所有者自行决定权限分配 | 资源 Owner 身份、ACL 列表 | 粗粒度（文件/目录） |
| MAC | 系统根据全局安全标签强制控制 | 主体/客体安全级别（如机密、绝密） | 极粗粒度（安全分类） |
| RBAC | 角色作为权限载体，用户被赋予角色 | 用户-角色-权限三元组 | 粗到中（角色级） |
| ABAC | 基于主体、资源、环境、操作属性动态判定 | 任意属性的布尔组合（JSON Path / XACML） | 细粒度（属性级） |
| ReBAC | 权限基于资源之间的关系图（如 Google Zanzibar） | 关系元组 |
细粒度（关系路径级） |
3.2 核心权衡维度分析
选型时需在以下六个维度上做权衡：
- 管理复杂度：模型机制越灵活，配置管理和运行时规约复杂度通常越高。
- 运行时性能：动态属性解析（ABAC）或关系图遍历（ReBAC）引入额外延迟。
- 安全确定性：模型能否严格防止权限扩散（如 DAC 的粗放授权易导致越权）。
- 迁移与审计成本：更换模型需要重写策略和迁移存量数据。
- 多租户支持：隔离粒度是否满足 SaaS 或微服务环境。
- 团队认知匹配：开发团队对非 RBAC 模型的学习曲线。
架构风险点：在微服务架构中滥用 ABAC 属性解析会导致授权决策分散且难以统一审计；ReBAC 的关系图若未设计索引优化，在大规模社交类场景下可能成为性能瓶颈。建议在架构设计阶段就引入策略变更的版本控制与回滚机制。
3.3 适用场景与权衡矩阵
下表从场景特征导出推荐模型，并标明关键风险：
| 场景特征 | 推荐模型 | 主要优势 | 主要风险 |
|---|---|---|---|
| 个人文档/笔记系统，所有者全权管理 | DAC | 实现简单，用户自主性强 | 资源膨胀后 ACL 维护成本高，易出现权限泄漏 |
| 军事/政企多级定密系统，分级管控 | MAC | 安全强度最高，防数据泄露 | 灵活性最差，不适合无结构化权限需求 |
| 企业后台管理系统、OA、ERP | RBAC | 角色结构清晰，业界成熟度高 | 角色爆炸时权限管理转交后难以收敛 |
| 电商/金融/物联网，需组合多维度条件（时间、地理位置、信用分） | ABAC | 极高灵活性，一行策略覆盖大量用例 | 策略爆炸，性能敏感，难以预判所有属性组合 |
| 社交网络、内容社区、多级组织成员系统 | ReBAC | 天然表达“好友可见”、“上级部门可读”等关系型权限 | 关系图存储和查询复杂度高，缓存策略设计难度大 |
3.4 模型组合示例：策略定义片段
下面展示一个真实项目中“RBAC + ABAC”组合的权限策略配置片段（以 YAML 风格呈现），用于说明混合使用时的边界划分：
# RBAC 层级：定义角色与静态权限
roles:
- name: editor
permissions:
- action: update_article
resource: article
- action: delete_article
resource: article
# ABAC 层级：在 RBAC 基础上补充动态条件
dynamic_filters:
- name: can_delete_if_author
rule: "resource.creator_id == subject.id and time.between(08:00, 20:00)"
applicable_to:
- role: editor
action: delete_article
该策略确保：editor 角色默认拥有删除权限，但实际生效时还需要满足“文章创建者是当前用户”且“操作时间在工作时间段”。这是典型的用 RBAC 控制主体范围，用 ABAC 控制生效条件的架构手法。
3.5 选型决策路径
在架构评审阶段，可按照以下决策树快速收敛：
- 团队对关系型权限（如组织树、好友关系）有强依赖 → ReBAC
- 权限控制需跨越多个独立属性维度（如地理位置+信用分+设备类型） → ABAC
- 只需按业务角色划分且角色稳定（少于 100 个） → RBAC
- 必须由系统强制防止信息泄露（政府、军事、金融合规） → MAC
- 资源所有者自行管理分享场景（个人网盘、协作白板） → DAC
架构建议：如果当前系统初始阶段采用 RBAC，但预见到未来需要细粒度属性过滤，建议在数据层预留属性标识字段（如 context_attributes JSON 列），并在政策管理器设计上支持未来无缝切换至 ABAC 策略引擎。参考 Open Policy Agent (OPA) 等策略引擎的模块化设计思路。
3.6 五种模型架构对比图
3.7 验收标准
当团队完成权限模型选型后，可通过以下检查项验证设计质量：
- 权限扩散验证：随机选取 100 个用户-资源对，模拟攻击路径，不应出现越权。
- 模型转换成本测算：现有策略结构是否能够在不超过 2 人周的工作量内迁移到备选模型。
- 性能基准：在最坏负载下，权限判定延迟不超过业务容忍上限（如 API 侧 < 5ms）。
- 审计链路：所有策略变更均可追溯至变更人、时间与变更内容。
- 团队协同：至少 2 名核心成员能在 3 天内独立完成新模型的策略配置。
完成选型后，下一个章节将聚焦“模块边界划分与接口权限契约设计”，把选定的权限模型落实为具体的模块间调用约束。