2. RBAC基础模型（RBAC0）：用户-角色-权限三元组、角色继承与分离、最小权限原则

2.1 模型边界与核心定义

RBAC0是RBAC系列模型的基础层，定义了权限管理的本质边界：用户不直接与权限关联，而是通过角色作为中间层实现授权。该边界将权限系统的复杂度收敛到角色管理上，避免用户-权限直连带来的爆炸性维护成本。

• 用户（User）：系统操作主体，仅持有其身份标识。
• 角色（Role）：一组权限的集合，是权限分配的原子单元。
• 权限（Permission）：对受保护资源的操作许可，通常表现为“资源+操作”的对偶（如“订单-读取”、“用户-删除”）。
• 三元组关系：用户←多对多→角色←多对多→权限。该关系构成RBAC0的核心数据模型，不允许用户直接挂载权限。

2.2 分层与组件职责

从架构视角，RBAC0权限系统分为三个逻辑层：身份层、策略层、执行层。每层具有明确的组件职责和交互接口。

2.3 数据流与控制流

权限校验的典型数据流如下：

1. 请求到达：用户携带Session Token发起业务操作请求（如POST /api/orders）。
2. 拦截认证：执行层（API Gateway或拦截器）验证Token有效性，提取用户ID。
3. 查询角色：执行层调用策略层接口，传入用户ID，获取该用户所有活动角色。
4. 获取权限：策略层根据角色集合，从数据存储中合并去重后返回该用户的完整权限列表（含继承权限）。
5. 校验判决：执行层检查请求的“资源+操作”是否在用户权限列表中。若命中，放行；否则返回403。

2.4 角色继承与分离约束

角色继承：允许一个角色从另一个角色中继承权限，形成层级关系。例如“高级审核员”继承“基础审核员”的所有权限，再附加“撤销审核”权限。继承关系使用有向无环图（DAG）组织，不允许循环继承。

职责分离（SoD）：防止单个用户获得冲突权限组合。有两种实现方式：

• 静态职责分离（SSD）：在角色分配时强制约束。如禁止同一用户同时拥有“采购申请创建”和“采购申请审批”角色。
• 动态职责分离（DSD）：在会话运行时检查。用户可同时拥有两个角色，但同一会话中不能同时激活。

2.5 最小权限原则

最小权限原则（Principle of Least Privilege, PoLP）要求每个主体仅被授予完成其任务所必需的最少权限。在RBAC0中的落地方法：

2.6 选型权衡

RBAC0适用于多数企业级应用，但在以下场景需谨慎：

• 优点：模型简单易推行，管理成本低，审计清晰，支持分层授权。
• 缺点：角色数量膨胀时管理困难；细粒度权限（如按数据行的权限控制）无法直接支持，需要通过额外属性或ABAC补充。
• 权衡决策：如果系统权限维度超过两个（如资源+操作+数据范围），考虑RBAC+ABAC混合模型；若角色小于100且权限变动频率低，RBAC0是最优选择。

2.7 风险点

1. 越权继承风险：继承链设计不当，导致低级角色自动获得高级权限。需限制继承深度（建议不超过3层）。
2. 角色爆炸：为每个用户创建专属角色，违背RBAC初衷。通过合理设计“部门+职能”组合角色避免。
3. 会话劫持利用权限：攻击者窃取Token后直接拥有该用户所有角色权限。需配合MFA、操作二次确认。
4. 职责分离缺失：未实施SoD可能引发欺诈风险（如财务人员同时拥有制单和审核权限）。

2.8 落地步骤

1. 盘点业务资源与操作，建立权限原子列表（每个权限编码唯一）。
2. 设计角色清单，基于组织架构梳理继承关系，绘制DAG图。
3. 依据最小权限原则分配每个角色所需的权限，审查是否有冗余。
4. 建立角色分配审批流程（使用工单系统或自动化审批）。
5. 开发或配置权限管理控制台，支持角色CRUD、用户-角色绑定、权限查询。
6. 在业务API网关或框架层植入权限拦截器，实现执行层校验。
7. 集成审计日志：记录每次角色分配变更、权限校验结果。
8. 进行渗透测试：尝试绕过角色中间层直接访问资源，验证模型完整性。

2.9 验收标准