2. 权限模型基础：RBAC与ABAC模型详解及归档包场景选型分析
在构建归档包变更与审批工作流之前，必须理解权限模型的核心原理。权限模型决定了“谁”能对“什么资源”执行“什么操作”。本章聚焦于业界最成熟的两种模型：RBAC（基于角色的访问控制）和ABAC（基于属性的访问控制），并结合归档包场景进行选型分析。
2.1 RBAC（基于角色的访问控制）模型详解
RBAC 是当前企业级系统中最广泛使用的权限模型。其核心思想是将权限授予角色，再将角色授予用户，从而解耦用户与权限的直接关联。
2.1.1 RBAC 核心要素
| 要素 | 定义 | 归档包场景示例 |
|---|---|---|
| 用户 (User) | 系统的操作主体，可以是人、服务账号或自动化工具。 | 张三（运维工程师）、CI/CD 机器人账号 |
| 角色 (Role) | 权限的逻辑集合，代表一类职责或岗位。 | 归档包管理员、审批人、只读审计员 |
| 权限 (Permission) | 对特定资源执行特定操作的许可。 | 创建归档包、下载归档包、审批变更、查看审计日志 |
| 会话 (Session) | 用户激活角色的上下文，控制权限生效范围。 | 张三以“审批人”角色登录，仅激活审批相关权限 |
2.1.2 RBAC 标准层级
NIST（美国国家标准与技术研究院）定义了 RBAC 的四个标准层级，从基础到高级逐步增强控制力：
- Core RBAC（核心RBAC）：用户-角色-权限的基本三元组关系，支持多对多映射。
- Hierarchical RBAC（层级RBAC）：角色支持继承关系，上级角色自动拥有下级角色的所有权限。
- Constrained RBAC（约束RBAC）：引入职责分离（SoD）约束，防止权限滥用。
- Session RBAC（会话RBAC）：用户可在不同会话中激活不同角色，实现最小权限原则。
归档包场景关键约束：在归档包审批流程中，必须实施静态职责分离（SSD）——同一用户不能同时拥有“归档包创建者”和“归档包审批人”角色，以防止自建自批的安全漏洞。
2.1.3 RBAC 模型结构图
下图展示了 RBAC 的核心数据模型与关系：
2.2 ABAC（基于属性的访问控制）模型简介
ABAC 是一种更灵活、更细粒度的权限模型。它不再依赖固定的角色，而是通过评估主体（用户）属性、资源属性、环境属性和操作属性的组合来决定是否允许访问。
2.2.1 ABAC 核心属性维度
| 属性维度 | 说明 | 归档包场景示例 |
|---|---|---|
| 主体属性 | 发起请求的用户或系统特征 | 部门=“SRE团队”、安全等级=“L3”、地理位置=“内网” |
| 资源属性 | 被访问对象的特征 | 归档包类型=“生产配置”、敏感度=“高”、所属项目=“支付平台” |
| 环境属性 | 访问发生时的上下文条件 | 时间=“工作时间”、网络=“VPN”、审批状态=“已通过” |
| 操作属性 | 请求执行的具体动作特征 | 操作=“下载”、频率=“首次”、数据量=“<100MB” |
2.2.2 ABAC 策略示例（伪代码）
ABAC 策略通常以 XACML 或 ALFA 语言描述，以下为简化示例：
Policy "归档包下载控制"
Target: operation == "download"
Condition:
subject.department == "SRE团队" AND
resource.sensitivity == "高" AND
environment.time BETWEEN "09:00" AND "18:00" AND
subject.security_level >= resource.required_level
Effect: Permit
ABAC 优势：无需预定义大量角色，策略可动态组合，非常适合多维度、高动态的权限控制场景。但策略管理复杂度较高，需要配套的策略引擎和审计工具。
2.3 归档包场景下的模型选型分析
在归档包变更与审批工作流中，选择 RBAC 还是 ABAC 取决于业务复杂度、团队规模和合规要求。以下从多个维度进行对比：
2.3.1 模型对比矩阵
| 对比维度 | RBAC | ABAC |
|---|---|---|
| 管理复杂度 | 低，角色定义清晰，权限继承直观 | 高，策略编写与调试需要专业知识 |
| 细粒度控制 | 中等，依赖角色细分（可能产生角色爆炸） | 高，可基于任意属性组合进行控制 |
| 动态适应性 | 弱，角色变更需要管理员手动调整 | 强，策略可随属性值自动生效 |
| 审计可追溯性 | 强，权限来源清晰（用户→角色→权限） | 中等，需记录策略评估上下文 |
| 性能开销 | 低，预计算角色权限集 | 中高，每次请求需实时评估策略 |
| 典型适用场景 | 组织架构稳定、职责划分明确的团队 | 多租户、多云、合规要求频繁变化的场景 |
2.3.2 归档包场景推荐策略：RBAC + 属性扩展
基于归档包工作流的实际工程经验，推荐采用以 RBAC 为基础，辅以关键属性扩展的混合模型。理由如下：
- 职责清晰：归档包操作涉及明确的角色（创建者、审批人、发布者、审计员），RBAC 天然匹配。
- 审批流程固化：审批工作流需要稳定的角色映射，RBAC 的静态约束（SoD）能有效防止权限冲突。
- 属性扩展补充：在审批条件中加入环境属性（如“仅限工作时间审批”）或资源属性（如“仅限非生产环境归档包”），避免纯 RBAC 的僵化。
⚠️ 避免过度设计：对于中小规模团队（<50人），纯 RBAC 通常足够。盲目引入 ABAC 可能导致策略维护成本超过收益。建议在 RBAC 运行稳定后，再逐步引入属性扩展。
2.3.3 混合模型架构图
下图展示了 RBAC + 属性扩展的混合模型在归档包场景中的工作流程：
2.3.4 选型决策清单
在归档包项目启动阶段，建议按以下清单评估模型选型：
- 团队规模与角色数量：角色数 < 20 且职责稳定 → 优先 RBAC；角色数 > 50 或频繁变动 → 考虑 ABAC。
- 审批条件复杂度：仅需“谁审批” → RBAC 足够；需要“谁在什么时间什么地点审批什么类型的包” → 引入属性扩展。
- 合规审计要求：需要精确记录每次权限判断依据 → ABAC 提供更丰富的审计上下文。
- 团队技术能力：运维团队熟悉角色管理 → RBAC；有专门安全策略团队 → ABAC。
- 系统性能要求：高并发下载场景 → RBAC 预计算更高效；低频管理操作 → ABAC 实时评估可接受。