云上密钥管理实战：KMS、密钥轮换与BYOK，钥匙比锁更重要

去年一个客户，被审计问了一个问题：“你们的加密密钥多久换一次？”答：“没换过，三年了。”审计又问：“离职员工的密钥权限回收了吗？”答：“应该回收了吧。”审计说：“‘应该’不够，要能证明。”

后来检查发现，三年前离职的一个开发，他的密钥还在KMS的授权列表里。虽然没人记得这个密钥，但理论上他还能调用。

这是密钥管理最容易被忽视的问题：算法再强，钥匙丢了，什么都没用。

今天聊聊云上密钥管理。不是那种“加密很重要”的入门课，而是帮你理清楚：密钥怎么管？多久换一次？谁有权用？丢了怎么办？

01 先搞懂几个概念

CMK（用户主密钥）：你创建的顶层密钥，用于加密其他密钥或少量数据（4KB以内）。本身不直接加密大量业务数据。

DEK（数据加密密钥）：真正加密业务数据的对称密钥。CMK加密DEK，DEK加密数据。这叫信封加密（Envelope Encryption）。好处是：更换DEK不影响CMK，性能好，云服务可缓存DEK。

信封加密流程：

• 数据加密时：KMS生成DEK，CMK加密DEK返回密文DEK，用DEK加密数据

• 数据解密时：密文DEK送到KMS，CMK解密得到明文DEK，再用DEK解密数据

那家客户三年没换密钥，用的是CMK直接加密少量配置。如果用了信封加密，换DEK即可，不影响CMK。

02 密钥轮换：为什么必须换

密钥用越久，泄露风险越大。

• 内部人员离职，可能还记得密钥

• 日志、备份、内存转储可能残留密钥

• 长期不换，攻击者有更多时间破解（虽然现代加密算法破解极难，但风险随时间累积）

轮换策略：

• 自动轮换：云KMS支持，每年换一次CMK。旧密钥保留用于解密历史数据，新密钥加密新数据。对应用透明。

• 手动轮换：创建新CMK，更新应用配置指向新密钥。需要重启应用，适合不频繁的轮换。

• DEK轮换：信封加密场景，可高频换DEK。换DEK不需要动CMK，应用无感知。

那家客户后来开了自动轮换，每年换一次CMK。旧密钥自动保留，历史数据还能解密。

03 权限控制：谁可以用密钥

KMS权限要遵循最小权限原则。

角色分离：

• KMS管理员：创建、删除、轮换密钥，但不能使用密钥解密数据

• 应用用户：只能使用（加密、解密）指定的密钥，不能管理密钥

• 审计员：只能查看KMS日志，不能操作密钥和加解密

常见坑：把KMS管理员权限给了应用的ServiceAccount。应用被攻破，攻击者可删除所有密钥。

04 审计：谁在什么时候用了密钥

KMS审计日志记录谁调用了哪个密钥、什么操作、什么时间、从哪个IP。

必须审计的操作：

• 加密（Encrypt）、解密（Decrypt）

• 生成数据密钥（GenerateDataKey）

• 启用、禁用、删除、轮换密钥

• 修改密钥权限

审计用途：

• 发现异常调用（凌晨3点有人解密了大量数据）

• 离职审计（某人离职前是否批量解密数据）

• 合规留证

那家客户查审计日志发现，离职员工的密钥三年来一次都没被调用过，没风险。但如果有调用，就能及时发现问题。

05 BYOK：自带密钥

有些客户不放心云厂商管密钥，想用自己的密钥。

BYOK流程：在自己HSM里生成密钥，导入云KMS。云KMS只存储和使用密钥材料，不掌握原始密钥。

优点：密钥根在自己手里，云厂商拿不到。适合对数据主权要求极高的场景。

风险：本地密钥丢了，云上数据也救不回来。要自己备份好密钥材料。

06 云HSM：硬件级保护

KMS底层也是HSM，但共享的。云HSM是独享硬件，合规级别更高。

KMS vs 云HSM：

云HSM适合金融、政务等强合规场景。普通业务KMS够用。

07 一个真实案例：密钥未轮换的代价

一个客户，数据库加密用的是KMS CMK，三年没换。某天一个离职员工声称还能访问数据，公司紧张了。

审计发现：离职员工的IAM权限还在，但KMS调用日志显示他三年没调用过。风险不大。但这事暴露了问题：权限没及时回收、密钥没轮换。

整改：

• 回收所有离职员工权限

• 开启KMS自动轮换，每年换一次

• 配置审计告警，异常调用发钉钉

安全负责人说：“以前觉得有加密就安全，现在知道，管好钥匙才是安全。钥匙丢了，加密形同虚设。”

写在最后

密钥管理不是锦上添花，是安全的基础。

那家客户的安全负责人后来总结：“密钥要轮换，权限要最小，审计要开着。BYOK给控制权，云HSM给合规，但钥匙丢了谁也救不了。”

你的密钥，多久没换了？谁还有权限？谁在用？今天就去看看。