三足鼎立：设计权限模型先分清 DAC、MAC、RBAC
讲密钥边界之前，得先聊聊权限模型。
说白了，搞信息安全这么多年，我见过太多团队一上来就画 RBAC 表，结果业务一跑就崩了。为什么？因为没搞清楚「谁管资源」和「谁管规则」的根本区别。
这一节我们把三种经典模型——DAC、MAC、RBAC——掰开揉碎了讲。顺带提一句，我自己的经验是：选错模型，KMS 的密钥管控基本等于裸奔。
DAC：自主访问控制——资源的主人说了算
DAC（Discretionary Access Control）是「资源所有者说了算」的模式。
什么意思呢？你创建了一个文件，你就是它的主人。你可以把读权限给张三，写权限给李四，甚至可以把所有权转让给王五。
举个例子：Linux 的文件权限就是 DAC 的典型代表。chmod 777，一条命令我就能把我的脚本让所有人执行。
我曾经踩过的坑
项目初期图省事，给开发账号的 SSH 私钥设置了 644 权限。结果一个同事的跳板机被入侵，对方直接把所有 644 的私钥扫走了。DAC 的最大软肋就在这里——权限一旦被主人放出去，系统层面就没法兜底了。
DAC 的核心特征：
- 资源所有者掌握全部控制权
- 权限可以传递（你授权了，对方还能继续授权）
- 系统不干预，只要所有者同意就行
- 典型场景：个人文件夹共享、临时协作
用在 KMS 里合适吗？ 我个人不建议。密钥不是普通文件，一旦密钥的所有者把解密权限「顺手」给了另一个服务，安全审计就是个笑话。
MAC：强制访问控制——系统说了算
MAC（Mandatory Access Control）走了另一个极端。
系统给每个主体（人、进程）和客体（文件、密钥）都打上安全标签。比如：公开、秘密、机密、绝密。
规则很简单：你的标签只有「大于等于」客体的标签，才能访问。 就算你是密钥的主人，你想把密钥读给一个「秘密级别」的服务？系统说不可以，那就一定不可以。
典型场景：政府和军队
我在参与某政务云项目时，对方强制要求 MAC 模型管理根密钥。管理员级别不够，连 KMS 的日志目录都读不了。这种强约束看着死板，但在合规审计时是真的好使。
MAC 的核心特征：
- 安全策略由系统管理员统一制定
- 主体和客体都带标签，谁也不能绕开
- 杜绝了 DAC 的「权限扩散」问题
- 典型场景：机密数据、军事系统、合规要求极高的金融
在 KMS 里的应用： 适合管理超级密钥和密钥自动轮换策略。你想想看，如果你的密钥轮换脚本权限不足，轮换失败可能都没人知道。
个人建议
很多云厂商的 KMS 内部其实埋了 MAC 的影子：密钥管理器禁止用户直接导出主密钥，这就是一种强制控制。不要试图用 DAC 去模拟这个效果，我曾经试过——最后审计的时候哭都哭不出来。
RBAC：基于角色的访问控制——岗位说了算
RBAC（Role-Based Access Control）是目前业界最流行的模型。不直接给「人」授权，而是给「角色」授权，再把「人」放进角色里。
举个例子：你创建了一个「密钥管理员」角色，只允许这个角色执行加密/解密操作。然后你的同事 A 入职了，把他塞进这个角色就行。离职时也简单，按住务角色移除就完事了。
为什么比 DAC 好？ 因为权限跟人解耦了。DAC 时代，一旦人员变动，你要逐条撤销几百条授权记录，想想就头疼。
| 对比维度 | DAC | MAC | RBAC |
|---|---|---|---|
| 谁控制权限 | 资源所有者 | 系统/安全管理员 | 角色定义者（通常是管理员） |
| 权限传递 | 允许 | 禁止 | 通过角色成员变更间接传递 |
| 变更管理 | 麻烦（逐条撤销） | 稳定（标签定了就难改） | 灵活（增删角色成员即可） |
| 审计复杂度 | 高（权限图容易乱） | 中（靠标签） | 低（看角色定义） |
| KMS 适用性 | 低（密钥容易被泄露） | 高（适合根密钥管控） | 极高（日常密钥操作管理） |
避坑：RBAC 也会膨胀
我曾经接手过一个 KMS 系统，里面有 400 多个角色。每个角色绑定了不同的密钥集。到最后谁都能解密，谁都说不清权限是怎么来的。RBAC 不是万能药——角色设计不好，权限爆炸比 DAC 还难治理。
三种模型放在一起看：选型思路
说实话，现代 KMS 不太会只用一种模型。成熟的方案是混搭：
- 根密钥和主密钥用 MAC——强制保护，系统说了算，管理员也不准导出
- 数据密钥的日常调用用 RBAC——按服务角色授权，加人减人灵活
- 临时协作和调试用 DAC（谨慎）——只给有限权限，用完马上回收
你想想看，如果一个密钥既允许所有者在控制台随意共享（DAC），又被系统强制绑定到特定标签（MAC），还允许管理员按角色临时授权（RBAC）——那这个系统保护的就是真的「密钥边界」。
一个小技巧
我在设计 KMS 权限时，习惯先画一张图。把「人」「角色」「密钥」「标签」四个要素画清楚，然后看哪种模型能覆盖。很多时候你会发现，模型之间并不冲突，而是互补。
怎么选？我总结了三句话
- 如果不做强制标签控制，KMS 的主密钥迟早会被误泄露。用 MAC。
- 如果团队经常变动，别用 DAC 给人绑死权限。用 RBAC。
- 如果两个都用上，再加一层角色对应的审计——这个 KMS 基本靠谱了。
嗯，模型就说到这里。记住一点：权限模型不是墙，是门。你选对门，密钥才安全。