2. 权限模型解析：DAC、MAC、RBAC
权限模型这东西，说白了就是「谁能在什么条件下对什么东西做什么事」。我在做密钥管理系统时，发现很多团队一开始都搞混这三种模型，结果上线后改得焦头烂额。今天咱们就把它们掰开揉碎了讲清楚。
2.1 自主访问控制（DAC）
DAC 是最早出现的权限模型，也是 Linux/Unix 文件权限的基础。它的核心思想是：资源的所有者说了算。
核心特征：文件或密钥的创建者可以自行决定谁有权访问，以及授予什么权限（读、写、执行）。
举个例子。你创建了一个密钥文件 server.key，在 DAC 模型下，你可以直接 chmod 644 server.key 让所有人可读。听起来很方便对吧？但问题也出在这里。
我曾经在审计一个金融系统时发现：开发人员为了方便调试，把生产环境的数据库密钥设成了 777 权限。结果一个实习生误操作，直接把密钥文件删了。DAC 的自主性虽然灵活，但缺乏全局管控——你永远不知道哪个「好心人」会把权限扩散出去。
DAC 的典型应用场景：
- 个人电脑文件系统（Linux chmod / Windows ACL）
- 小型团队内部共享密钥
- 开发测试环境（非生产）
但说实话，在密钥管理领域，DAC 基本只用于「临时授权」。因为它的安全粒度太粗了——你没法控制「用户拿到密钥后会不会复制一份给别人」。
2.2 强制访问控制（MAC）
MAC 和 DAC 正好相反。它不信任任何人，包括资源所有者。所有访问决策都由系统层面的安全策略强制决定，用户无权修改。
我记得第一次接触 MAC 是在做政府项目的密钥管理系统。当时甲方要求：「密钥的访问权限必须由安全管理员统一配置，普通用户连查看权限设置的资格都没有。」
MAC 的核心机制是「标签」和「格」：
- 每个主体（用户/进程）有一个安全标签（如：绝密、机密、秘密）
- 每个客体（密钥/文件）也有一个安全标签
- 访问规则由系统预定义（如：只有标签不低于客体的主体才能读取）
| 安全级别 | 主体（用户） | 客体（密钥） | 能否读取？ |
|---|---|---|---|
| 绝密 | 张三 | 根CA私钥 | ✅ 是 |
| 机密 | 李四 | 根CA私钥 | ❌ 否（级别不够） |
| 秘密 | 王五 | 中间CA密钥 | ❌ 否（级别不够） |
我个人习惯：在密钥生命周期管理中，MAC 最适合保护「根密钥」和「HSM 主密钥」。因为这些密钥一旦泄露，整个信任链就崩了。用 MAC 强制约束，至少能保证「即使管理员想乱来，系统也不允许」。
MAC 的缺点也很明显：配置复杂、灵活性差。你想想看，每次新增一个密钥都要走安全管理员审批流程，在大规模系统中根本跑不动。
2.3 基于角色的访问控制（RBAC）
RBAC 是目前企业级系统中最主流的权限模型。它的思路很简单：不直接给用户授权，而是给角色授权，再把用户分配到角色中。
为什么 RBAC 这么流行？我在项目中遇到过这样一个场景：某公司有 500 个开发人员，每个人都需要访问测试环境的密钥。如果用 DAC，你得给 500 个人逐个授权；如果用 MAC，你得给每个人打标签。但用 RBAC，你只需要创建三个角色：
- 密钥管理员：创建、轮换、吊销密钥
- 密钥使用者：读取、使用密钥（不能导出）
- 审计员：查看密钥操作日志（不能接触密钥本身）
然后把 500 个开发人员全部丢进「密钥使用者」角色，完事。
RBAC 在密钥管理中的典型映射：
角色：密钥管理员
权限：create_key, rotate_key, revoke_key, grant_access
约束：需要双人审批才能执行吊销
角色：密钥使用者
权限：read_key, use_key_for_sign
约束：不能导出明文，每分钟最多调用 100 次
角色：审计员
权限：read_audit_log
约束：只读，不能接触任何密钥材料嗯，这里要注意：RBAC 虽然好用，但容易陷入「角色爆炸」的陷阱。我见过一个系统，光角色就定义了 200 多个，比用户还多。这就本末倒置了。
2.4 三种模型的对比与选择
咱们用一张表把核心差异说清楚：
| 维度 | DAC | MAC | RBAC |
|---|---|---|---|
| 控制主体 | 资源所有者 | 系统安全策略 | 安全管理员 |
| 灵活性 | 高 | 低 | 中 |
| 安全性 | 低（易扩散） | 高（强制约束） | 中高（可审计） |
| 管理成本 | 低 | 高 | 中 |
| 适用场景 | 个人/小团队 | 军事/政府/金融核心 | 企业级系统 |
下面这张图展示了三种模型在密钥管理系统中的典型架构关系：
2.5 混合模型：现实中的密钥权限管理
你可能会问：那实际项目中到底用哪种？我的答案是：全都要。
举个例子。我在设计一个密钥管理平台时，采用了分层策略：
- HSM 内部：使用 MAC 模型。HSM 固件强制规定：主密钥只能由安全官通过物理令牌操作，任何 API 调用都无法直接读取。
- 密钥管理服务：使用 RBAC 模型。定义管理员、操作员、审计员三个角色，每个角色有明确的权限边界。
- 临时授权场景：使用 DAC 模型。比如某个开发人员需要临时调试，管理员可以授予 24 小时有效期的密钥访问权限，到期自动回收。
我曾经踩过一个坑：在 RBAC 中给「密钥使用者」角色授予了 export_key 权限，想着「反正只有管理员才能创建角色」。结果一个开发人员的账号被钓鱼，攻击者利用这个权限导出了所有测试密钥。后来我强制要求：任何导出操作都必须经过 MAC 级别的审批流程，且记录完整的审计日志。
说白了，没有银弹。DAC 灵活但危险，MAC 安全但笨重，RBAC 平衡但需要精心设计角色体系。真正成熟的密钥权限管理，一定是这三种模型的有机组合。