4. KMS体系结构深入

KMS（Key Management Service）并不是“一个存密钥的数据库”，而是一套把密钥的生成、使用、轮换、销毁与访问控制组织成分层结构的服务。理解 KMS 的关键，是看清两条主线：一条是密钥层级，即根密钥、密钥加密密钥、数据密钥之间的保护关系；另一条是服务分层，即接口层、密钥逻辑层、密码运算层与存储后端之间的职责边界。两条主线交汇处，就是信封加密与 HSM 的位置。

一、密钥层级：谁保护谁

KMS 中通常存在三层密钥，保护方向是自上而下的：上层密钥保护下层密钥，下层密钥保护业务数据。

• 根密钥（Root Key / Master Key）：层级最高，生命周期最长，通常永不离开 HSM，只用于加密下层密钥，不直接加密业务数据。
• 密钥加密密钥（KEK，Key Encryption Key）：按租户、应用或用途划分，由根密钥保护，用于封装数据密钥。
• 数据密钥（DEK，Data Key）：由 KMS 随机生成，直接用于 AES-GCM 等对称加密业务数据，用完即弃或短期缓存。

这种层级带来两个直接好处：一是根密钥极少使用，暴露面小；二是轮换 KEK 时只需重新封装 DEK，不必重新加密海量业务数据。

二、信封加密：数据密钥如何被安全传递

信封加密（Envelope Encryption）解决的核心问题是：数据密钥本身也是敏感信息，不能明文传输或落盘。典型过程如下：

1. 客户端向 KMS 请求数据密钥，指定 KEK 标识与用途。
2. KMS 生成一个随机 DEK（例如 256 位），用指定 KEK 加密 DEK，得到密文 DEK。
3. KMS 将明文 DEK与密文 DEK一并返回给客户端，明文 DEK 只在内存中使用。
4. 客户端用明文 DEK 加密业务数据，得到数据密文。
5. 客户端将“数据密文 + 密文 DEK + KEK 标识”一起存储，明文 DEK 从内存中清除。
6. 解密时，客户端把密文 DEK 交回 KMS，KMS 用 KEK 解出明文 DEK 返回，客户端再解密数据。

这里有一个容易混淆的点：密文 DEK 可以随数据一起存储，因为它已被 KEK 保护；而明文 DEK 绝不能落盘。判断一次信封加密实现是否正确，就看明文 DEK 是否只存在于内存、是否在加密完成后被及时清除。

三、服务分层与存储后端

从工程实现看，KMS 通常分为四层：

• 接口层：提供 GenerateDataKey、Encrypt、Decrypt、CreateKey、RotateKey 等 API，负责鉴权、限流与审计。
• 密钥逻辑层：管理密钥元数据（密钥 ID、用途、状态、版本、轮换策略），决定用哪个 KEK 封装哪个 DEK。
• 密码运算层：执行真正的加解密，通常由 HSM 或软件密码模块承担。
• 存储后端：保存密钥元数据与密文密钥，可以是数据库、KV 存储或专用密钥库。

HSM 与存储后端的关系需要特别说明：HSM 保护的是根密钥和密码运算过程，存储后端保存的是被保护的密钥材料与元数据。根密钥本身通常不以明文形式出现在存储后端中，而是以 HSM 内部封装或密钥句柄的形式存在。若使用软件 KMS，根密钥可能以加密形式落盘，此时其安全性依赖主密钥的保护，风险明显高于 HSM 方案。

四、一个可参考的密钥参数示例

下面给出一组教学示例参数，用于说明 KMS 中密钥对象通常需要记录哪些字段。这些数值属于合理假设，不是实测结果。

五、轮换与销毁的判断依据

轮换 KEK 时，KMS 生成新版本 KEK，新产生的 DEK 用新版本封装，旧密文 DEK 仍可用旧版本解封。判断轮换是否完成，应检查：新写入数据的密文 DEK 是否已带新版本标识、旧版本是否仍处于可解密状态、以及旧版本是否在确认无引用后才进入禁用或销毁流程。销毁根密钥或 KEK 前，必须确认没有仍依赖它的密文 DEK，否则相关数据将永久无法解密。

把以上内容串起来看：接口层负责“谁能请求”，密钥逻辑层负责“用哪个密钥”，密码运算层负责“在哪里算”，存储后端负责“存什么”。信封加密把数据密钥的明文使用限制在内存中，HSM 把根密钥限制在硬件边界内，二者共同构成 KMS 安全性的两个支点。