3. KMS 密钥类型：对称密钥、非对称密钥、主密钥（CMK）的特性与选择
做密钥管理，第一步就是搞清楚你手里拿的是什么钥匙。三种类型——对称、非对称、主密钥，各有各的脾气。我最早做 KMS 集成时，在密钥类型上栽过跟头，后来才摸清门道。今天咱们就把它们掰开揉碎讲明白。
3.1 对称密钥
对称密钥，说白了就是一把钥匙开一把锁。加密和解密用同一个密钥。性能极好，适合大量数据加密。
- 密钥长度常见 128、192、256 位。
- 算法：AES、SM4、3DES 等。
- 缺点：密钥分发麻烦，双方都要持有同一条密钥。
我的经验：在公司内部大量日志加密的场景下，我几乎都用对称密钥。吞吐量能到 GB/s 级别，CPU 开销低。但注意密钥轮换要自动化，否则人工换钥容易出事故。
我记得有一次，同事把对称密钥直接硬编码在配置文件里。结果密钥泄露，整库数据都得重加。后来我们统一改用 KMS 的对称 CMK，再也没出过类似问题。
3.2 非对称密钥
非对称密钥，相当于一把公钥一把私钥。公钥公开，私钥保密。适合数字签名、密钥交换、小数据加密。
- 常用算法：RSA（2048/4096）、ECC（P-256、P-384）、SM2。
- 性能：比对称慢 100～1000 倍。
- 典型场景：TLS 握手、子密钥分发、代码签名。
避坑：我曾经用 RSA-2048 去加密 1MB 的文件，结果耗时几百毫秒，用户直接投诉。非对称只适合加密对称密钥或小数据，别拿它硬怼大数据。
那么问题来了：什么时候用对称，什么时候用非对称？
我个人习惯：数据传输用对称（AES-GCM），密钥分发用非对称（RSA 或 ECDH）。双向结合，既快又安全。
3.3 主密钥（CMK）
主密钥（Customer Master Key）是 KMS 里的“顶梁柱”。不直接加密业务数据，而是用来加密数据密钥。
- CMK 本身可能是对称或非对称的。
- 在 AWS/GCP/Azure 的 KMS 里，CMK 默认是硬件安全模块（HSM）生成的，无法导出明文。
- 支持自动轮转，一般每年轮换一次。
核心理解：CMK 是密钥体系的根。所有数据加密都通过“数据密钥（DEK）”完成，而 DEK 由 CMK 加密存储。丢了 CMK，等于丢了所有数据。
我曾经在客户那里看到他们把 CMK 的密钥材料直接复制到本地，企图做“灾备”。我当场叫停：CMK 一旦离开 HSM，其安全边界就破了。合规上不允许。
3.4 三者的对比
| 特性 | 对称密钥 | 非对称密钥 | 主密钥（CMK） |
|---|---|---|---|
| 核心用途 | 数据加密/解密 | 密钥交换、签名 | 加密数据密钥 |
| 密钥数 | 1（共享） | 2（公私钥） | 1（根密钥） |
| 性能 | 极快 | 慢 | 中等（仅用于DEK） |
| 密钥管理 | 难分发 | 公钥可公开 | HSM保护，无法导出 |
| 典型场景 | 数据库加密、文件加密 | TLS、CA、数字签名 | KMS信封加密 |
3.5 如何选择？一张图说清楚
下面这张流程图帮我很多次，每次做方案设计前我都看一眼。
流程图帮你理思路：先判断数据量大小，数据量大走对称路线；如果还需要一个根密钥来保护对称密钥，那就上 CMK。数据量小或者需要密钥交换，就用非对称。
3.6 一条实用的推荐原则
- 日志加密、文件加密、数据库 TDE → 对称密钥 + CMK 保护 DEK。
- TLS 证书、代码签名、JWT 签名 → 非对称密钥。
- 跨账号密钥托管 → 用 CMK 加上密钥策略。
小技巧：做新项目时，先画上面那个流程图，再选密钥类型。我每次都用这个套路，基本不会跑偏。