信封加密是什么
信封加密用数据密钥（DEK）加密数据、用主密钥（KEK，通常存放于 KMS 或 HSM）加密数据密钥：批量数据无需逐条调用 KMS，同时保留集中治理与版本化能力。直接收益是减少对 KMS 的调用量，降低限流风险与延迟；代价是要正确管理 DEK 密文与 KEK 版本的对应关系，否则轮换之后可能找不到解密路径。
基本信息
| 层次 | KEK 位于 KMS 或 HSM；DEK 的密文随数据一起存储 |
|---|---|
| 优势 | 减少 KMS 调用量，降低限流风险与延迟 |
| 版本管理 | DEK 密文需记录所用 KEK 版本，轮换时可追溯解密路径 |
| 明文 DEK | 用完即丢弃，绝不与数据一起存储 |
| 轮换方式 | KEK 轮换只需重新包装 DEK 密文，不必重加密全部数据 |
典型使用场景
- 对象存储中海量文件的加密与密钥治理
- 数据库敏感字段的批量加密，按租户或表分配 DEK
- 降低 KMS 调用成本与限流风险
- KEK 轮换：重包装 DEK 密文而不触碰数据本体
- 跨区域复制数据时管理密钥版本对应关系
流程说明
流程说明
生成 DEK → 用 DEK 加密数据 → 用 KEK 加密 DEK
→ 存储（数据密文 + DEK 密文 + KEK 版本号）→ 丢弃明文 DEK
# 解密为反向操作：先解 DEK 密文，再用 DEK 解数据
# KEK 轮换只需重包装 DEK 密文，数据本体不必重新加密层次与职责
| 层次 | 存放位置 | 轮换影响 |
|---|---|---|
| KEK | KMS 或 HSM | 轮换时重新包装 DEK 密文 |
| DEK | 明文仅在内存中短暂存在 | 轮换需重加密对应数据 |
| DEK 密文 | 随数据一起存储 | 需记录 KEK 版本便于追溯 |
| 版本号 | 与密文一同存储 | 缺失会导致无法定位解密路径 |
解密路径是反向操作：先解 DEK 密文，再用 DEK 解数据。如果团队同时维护多套 KEK，务必把版本号与密文一起存储，否则轮换之后就难以确定该用哪把主密钥去解密，历史数据的可恢复性会直接受影响。
实施建议：把「数据密文、DEK 密文、KEK 版本、算法标识」作为一条固定结构一起存储，并写进数据字典。这样即使更换服务实现或迁移存储，历史数据仍能被正确解密。