📚 课程目录第4章密钥生命周期管理

密钥生命周期管理

密钥不是一把“永动机”。它像你手里的钥匙——用久了会磨损，不用的要收好，报废了得熔掉。

密钥的生命周期管理，说白了就是管好这把钥匙从出生到销毁的全过程。我见过不少团队只关注“怎么加密数据”，结果密钥散落各处，轮换靠手工，销毁靠忘记。嗯，这恰恰是泄露的源头。

创建：给密钥一个“干净的出生证明”

创建密钥是整个生命周期的基础。这一步做对了，后面能省掉一半的麻烦。

我个人习惯在创建时就想清楚三件事：

对称还是非对称？ 对称密钥加解密快，适合大量数据加密；非对称密钥适合数字签名、信封加密。你想想看，一个支付系统里，交易报文用对称加密，通信握手用非对称，这才是合理分工。
是否启用自动轮换？ AWS KMS 允许在创建时指定 EnableKeyRotation，但要注意：只对对称密钥生效。非对称密钥必须手动轮换。
密钥用途和别名 别偷懒。我习惯用 alias/prod-payment-encrypt 这种命名，一眼就能看出环境和用途。

代码示例（AWS CLI）：

# 创建对称密钥，启用自动轮换
aws kms create-key \
    --description "PROD Payment Encryption Key" \
    --key-usage ENCRYPT_DECRYPT \
    --origin AWS_KMS

aws kms create-alias \
    --alias-name alias/prod-payment-encrypt \
    --target-key-id <key-id>

我的小技巧：创建时先不分配任何权限，等配置好策略后再启用。避免密钥“裸奔”上线。我在项目中遇到过一个人，创建完密钥直接给了kms:*权限给所有用户，结果被内部审计拦下来了。

启用与禁用：密钥的“开关”控制

密钥创建后默认是已启用状态。有时候你需要临时关掉它——比如检测到异常操作、或者进行密钥迁移时。

禁用后的密钥不能用于任何加密/解密操作，但元数据还在。它可以随时恢复启用。

代码示例：

# 禁用密钥
aws kms disable-key --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

# 重新启用
aws kms enable-key --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

注意：禁用密钥不会自动删除已加密的数据。那些数据会变成“僵尸加密”——你有密钥时能解密，禁用后读不出来了。我曾经处理过一个事故：有人为了“安全”禁用了生产环境的密钥，结果支付系统当天下午全线报错。所以禁用前务必确认没有依赖该密钥的在线服务。

轮换：密钥的“换新”机制

密钥使用久了，泄露风险会累积。定期轮换是合规要求，也是安全底线。

自动轮换 vs 手动轮换

类型	触发方式	适用场景	密钥版本处理
自动轮换	每年一次（AWS KMS 默认）	对称密钥，批量加密	生成新后端密钥，旧版本仍可用于解密
手动轮换	调用 `RotateKeyOnDemand` 或自行创建新密钥	非对称密钥、合规要求更高频的轮换	需要自行管理密钥版本映射

我建议：能开自动轮换的就开。别想着“手动更灵活”，忙起来你真的会忘记。我在一个金融项目中遇到过，合规要求每半年轮换一次非对称签名密钥，结果运维记错了时间，拖了9个月，被审计开了严重不符合项。

代码示例（开启自动轮换）：

# 对已有对称密钥开启自动轮换
aws kms enable-key-rotation --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

# 手动轮换：创建新密钥，并变更别名指向新密钥
aws kms create-key --description "Payment Key v2"
aws kms update-alias \
    --alias-name alias/prod-payment-encrypt \
    --target-key-id new-key-id

销毁：安全“归零”的艺术

密钥到期、废弃或泄露后，必须销毁。但销毁不是单纯删数据库记录——你要确保密钥材料物理不可恢复。

计划删除 vs 立即删除

计划删除：设置等待期（7-30天），期间可以取消。适合生产环境，给自己留后悔机会。
立即删除：部分云厂商不支持立即删除（出于安全设计），AWS KMS 必须经过等待期。

关键点：销毁后，所有用该密钥加密的数据将永久无法解密。你必须在销毁前确认数据已迁移或备份明文。

代码示例：

# 计划删除密钥，等待期 7 天
aws kms schedule-key-deletion \
    --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
    --pending-window-in-days 7

# 取消删除
aws kms cancel-key-deletion \
    --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

我曾经踩过的坑：有次我以为删掉的密钥不会再用了，就把关联的加密数据全删了。结果三个月后业务部门说“那些归档数据还要解密”，我只好赔着笑脸说“对不起，密钥没了，数据也解密不了”。所以销毁前，务必和业务确认数据生命周期。

生命周期状态总览

我把整个过程画成了一张图，方便你对照理解。每一个状态都对应一个操作入口，不会有“偷偷变更”的情况。

图中有两个关键点我强调一下：

创建后可以直接进入启用（实线箭头），也可以直接跳转到禁用（虚线箭头），但这么做通常没什么意义——除非你要立即冻结密钥。
轮换本质是临时状态，轮换完成后密钥重新回到启用，但新版本成为主要密钥。旧版本仍然可用（仅解密）。

总结下来，密钥生命周期管理就是“建、开、关、换、毁”五个动作。每个动作都有配套的API和最佳实践，你按照这个流程走，基本不会出大问题。我记得有次内审，对方拿着这个生命周期框架问我：“你们的销毁流程怎么证明不可逆？”我直接展示了KMS的等待期+资源回收日志，当场满足合规要求。

实操中遇到最多的问题其实是“忘”——忘了轮换、忘了禁用观测不到的密钥、忘了销毁废弃密钥。所以我的建议是：自动化监控。给每个密钥贴标签（环境+用途），配合定时巡检脚本，让机器帮你盯住生命周期，才是最靠谱的。