权限模型基础：RBAC、ABAC、ACL 模型对比、常见权限框架、选型参考表

1. 适用场景

本流程适用于以下场景的权限模型选型与评估：

• 新系统启动时需要确定访问控制模型
• 现有系统因越权漏洞或运维成本过高需要重构权限体系
• 安全审计团队对已上线系统进行模型合规检查
• 多租户、微服务架构下统一权限策略设计

2. 前置条件

3. 操作步骤

1. 梳理业务权限需求：收集功能权限、数据权限、操作类型（增删改查），绘制实体关系图。
2. 评估模型复杂度：根据用户数、角色数、资源种类、动态属性数量判断适用模型。
3. 对比三种核心模型：参照 表1 进行特征匹配。
4. 选定常见框架：基于技术栈选择社区活跃的框架（如 RBAC → Spring Security；ABAC → OPA；ACL → Linux ACL）。
5. 编写选型参考报告：输出模型决策矩阵与风险说明，见 表2。

表1 RBAC / ABAC / ACL 核心对比

维度	RBAC（基于角色）	ABAC（基于属性）	ACL（访问控制列表）
授权依据	用户 ↔ 角色 ↔ 权限	主体属性 + 资源属性 + 环境属性	用户/组 ↔ 对象 ↔ 操作
粒度	中粒度（角色级）	细粒度（属性级）	粗粒度（对象/用户级）
动态性	静态（需管理员修改角色）	动态（根据运行时属性）	静态（需直接修改 ACL 条目）
扩展性	角色爆炸后维护困难	策略可组合，扩展性好	对象量增大后条目暴增
典型框架	Spring Security、Apache Shiro	OPA、AWS IAM（基于策略）	Linux iptables、文件系统 ACL
适用场景	企业内部系统、用户-功能权限	多租户、动态数据权限、IoT	文件系统、网络设备控制

表2 选型参考矩阵

需求特征	推荐模型	推荐框架示例
用户量 < 1 万，角色固定 < 20	RBAC	Spring Security（Java）/ Casbin
需要动态根据时间/地理位置/风险等级控制	ABAC	OPA / AWS IAM Policy
以文件或对象为粒度的严格访问	ACL	Linux ACL / NFS ACL
混合需求（角色 + 属性）	RBAC + ABAC 混合	Pex（Kubernetes）+ 自定义策略引擎
审计导向，要求每笔操作可追溯	ABAC + 日志增强	OPA + 审计系统（如 Auditd）

4. 输入 / 输出物

环节	输入	输出
需求梳理	功能需求文档、安全需求文档	权限实体关系图、操作类型列表
模型对比	模型对比表（表1）	模型初选建议（RBAC/ABAC/ACL）
框架选择	技术栈清单、社区活跃度报告	框架选型报告（含版本、依赖、许可证）
最终决策	选型参考矩阵（表2）	权限模型设计文档（含策略伪代码）

5. 责任边界

• 系统架构师：确定模型选型方向，评审技术方案。
• 安全工程师：提供合规要求，验证模型安全边界。
• 开发工程师：实现模型集成，编写策略配置。
• QA / 测试：编写越权测试用例，验证模型拦截效果。

6. 记录材料

7. 异常处理

异常现象	典型原因	补救动作
模型选型后难以满足细粒度场景	业务属性多变，纯 RBAC 无法覆盖	考虑升级为 RBAC + ABAC 混合模型；或引入属性注入框架
引入 ABAC 后策略调试困难	属性定义不清晰，策略冲突	建立策略冲突检测工具（如 OPA 的 --strict 模式）；进行策略单元测试
ACL 条目过多导致性能下降	对象数 > 10 万，ACL 表膨胀	改用 RBAC 分组权限；或对常用 ACL 做缓存分层
框架社区停止维护	选型时未评估社区生命周期	立即准备迁移计划，优先选择 CNCF 或 Apache 基金会项目

8. 验收标准

1. 模型覆盖度：所有业务权限需求（功能+数据）均有对应的授权规则。
2. 可审计性：每个权限判定可追溯到模型执行日志（时间、触发者、策略 ID、结果）。
3. 性能基线：模型判定延迟在 99 分位不超过 50ms（需进行压力测试）。
4. 可维护性：角色/属性/策略修改后，生效时间 ≤ 30 秒（热更新能力）。
5. 越权隔离：审计团队使用越权攻击工具（如 Burp Suite）测试后，未发现非授权访问。