3. 权限模型识别:RBAC、ABAC、PBAC、ACL 的区别与适用场景

3.1 适用场景

权限模型的选择直接影响授权测试用例的设计粒度和覆盖范围。不同模型适用于不同的业务规模、资源复杂度和动态性要求:

模型典型适用场景示例系统
RBAC(基于角色的访问控制)角色固定、职责分层清晰的企业应用ERP、CRM、HR 系统
ABAC(基于属性的访问控制)需根据用户/资源/环境属性动态判定的场景云基础设施、微服务网关、医疗数据共享
PBAC(基于策略的访问控制)集中管控、规则可热更新的合规场景金融风控、政务审批、API 网关
ACL(访问控制列表)资源粒度极细、用户数量少的文件或对象存储文件夹权限、DB 表级权限、IoT 设备
测试注意: 混合架构中常见 RBAC + ABAC 或 PBAC + RBAC 的组合,识别主模型时需关注决策引擎的实际计算入口。

3.2 前置条件

  1. 业务场景文档(含用户角色、资源类型、操作定义)已评审
  2. 系统架构设计说明书已明确权限决策模块
  3. 测试环境已部署权限服务,支持查询策略配置
  4. 测试人员已掌握各模型的核心特征(详见 3.6 记录材料)

3.3 操作步骤

步骤操作内容关键产出物
1 梳理业务中的用户-资源-操作三元组 权限需求矩阵
2 检查权限判定条件是否仅依赖角色(→RBAC) 决策依赖清单
3 若出现属性判定(时间/地点/设备/资源分类)→候选 ABAC 属性字典
4 若出现可组合策略(条件 + 策略集 + 冲突解决)→候选 PBAC 策略拓扑图
5 若出现细粒度资源级条目且用户量 < 1000 → 候选 ACL ACL 条目样例
6 参考 3.6 差异表最终确认模型,并记录在测试计划 模型确认记录
经验原则: 优先检查是否存在动态属性(日期、部门、安全级别)判定;若无,则向 RBAC 或 ACL 收敛。

3.4 输入输出物

类别输入物输出物
文档 业务需求说明书、系统设计说明书、用户角色清单 权限模型选择报告
配置 权限策略配置文件(JSON / YAML) 策略字段标注表
代码 权限判定接口源码或 API 文档 判定逻辑伪代码

3.5 责任边界

  • 业务方: 提供准确的用户-资源-操作映射关系
  • 开发团队: 暴露权限判定模块的日志和配置接口
  • 测试团队: 执行模型识别并输出验证结论,负责在测试用例中体现模型特有的边界条件
  • 安全团队: 审核模型选择是否符合安全合规要求
常见陷阱: 开发声称使用 RBAC 但实际代码中包含大量 if-else 属性判断,这实际上是隐式 ABAC。测试团队应在集成环境中通过触发不同属性组合来验证。

3.6 记录材料

每个模型的关键特征卡片,用于快速识别:

模型决策依据策略存储典型实现框架 / 协议测试关注点
RBAC 用户 ↔ 角色 ↔ 权限 关系数据库表 Spring Security、Shiro 角色继承、互斥角色、会话角色
ABAC 主体属性 + 资源属性 + 环境属性 策略引擎规则库 XACML、OPA、AWS IAM Policy 属性缺失、多属性组合、默认拒绝
PBAC 策略集合 + 条件 + 评估算法 策略文件(YAML/JSON) OPA、Casbin、Azure Policy 策略优先级、冲突消解、策略热加载
ACL 资源维度的用户/组权限条目 资源 ACL 列表 文件系统 DACL、Redis ACL 条目顺序、默认拒绝、继承
权限模型识别框架 业务需求 用户分析 资源分类 决策引擎 检查判定条件来源 是否存在动态属性? 是否存在策略组合? 资源粒度级别? RBAC ABAC PBAC ACL 识别路径:检查是否存在动态属性 → 检查是否存在策略组合 → 检查资源粒度 若无任何特殊判定,默认采用 RBAC;若为细粒度文件级则采用 ACL

3.7 异常处理

异常场景可能原因处理措施
模型识别结果与开发声称明显不符 开发对模型理解偏差,或代码已重构未更新文档 组织三方会议,要求开发提供权限判定核心代码片段,测试构造多元组交叉验证
同一系统内存在多模型混用 不同模块采用不同权限框架(如管理后台用 RBAC,API 层用 ABAC) 按模块分别识别并标注主模型,测试计划分模块编写用例
策略配置文件为空或缺失 权限判定完全硬编码 标记为“隐性模型”,通过逆向工程分析判定语句,提炼出实际模型的决策逻辑

3.8 验收标准

  • 第 3.3 步骤中所有判定条件均通过至少 3 组样本数据验证,且输出模型与系统实际行为一致
  • 权限模型选择报告经业务方、开发、安全三方签字
  • 测试用例中已针对所选模型的关键特征(如 ABAC 的属性缺失、PBAC 的策略优先级)设计覆盖点
  • 所有异常场景已记录并纳入风险跟踪表