3、密钥生命周期管理：创建、激活、过期、吊销、销毁

密钥跟人一样，有出生、有壮年、有退休、也有死亡。很多团队只关心“怎么生成一个强密钥”，却忽略了密钥从生到死的完整路径。我见过不少事故，说白了都是生命周期没管好——密钥过期了没人知道，或者吊销了还在用。

这一章，咱们就把密钥的五个阶段掰开揉碎讲清楚。

3.1 创建：不是随便生成一串随机数

创建密钥，听起来简单。但你真的做对了吗？

我个人习惯，创建密钥时必须明确三件事：

• 用途标签：这个密钥是给哪个服务用的？签名还是加密？
• 算法与强度：RSA 2048？ECDSA P-256？还是 AES-256？
• 元数据：谁创建的？什么时候？有效期多久？

举个例子，我在项目中遇到过有人直接用 openssl rand -base64 32 生成一个密钥就上线了。结果三个月后谁也说不清这个密钥是干嘛的。嗯，这就是典型的“生而不养”。

# 一个带元数据的密钥创建示例（Vault）
vault write -f transit/keys/my-service-key \
  type=rsa-2048 \
  exportable=false \
  metadata=creator=zhang-san \
  metadata=purpose=signing \
  metadata=env=production

3.2 激活：密钥不是生下来就能用

密钥创建后，通常有一个“激活窗口”。为什么？

你想想看，如果你在凌晨三点轮换密钥，所有下游服务都同时去拉新密钥，万一有个服务没准备好呢？

我建议的做法是：

1. 创建时间 ≠ 激活时间：先创建，等所有依赖方确认就绪后再激活。
2. 灰度激活：先让 10% 的流量用新密钥，观察 24 小时没问题再全量。
3. 保留旧密钥：激活新密钥后，旧密钥至少保留一个轮换周期。

3.3 过期：给密钥一个“退休年龄”

密钥为什么要过期？两个原因：

• 密码学安全：使用时间越长，被破解的风险越大。
• 合规要求：PCI DSS、SOC 2 等标准都要求定期轮换。

但过期不是“到期就删”。我见过有人把过期理解成“到期自动销毁”，结果半夜系统全挂了。

密钥类型	建议有效期	说明
TLS 证书	90 天（Let's Encrypt 标准）	越短越安全，自动化轮换
签名密钥	1 年	可保留旧密钥用于验证
加密密钥（数据）	2 年	需考虑数据重加密成本
根密钥（HSM）	5 年	物理安全 + 严格审计

过期前 30 天、7 天、1 天，必须发告警。我曾经因为没设告警，一个根密钥过期了三天才发现，还好只是内部测试环境。

3.4 吊销：紧急情况下的“一键熔断”

吊销跟过期不一样。过期是计划内的，吊销是计划外的。

什么情况下需要吊销？

• 密钥泄露（GitHub 上不小心提交了私钥）
• 员工离职（该员工曾持有密钥管理权限）
• 安全事件（检测到异常解密请求）

吊销后的标准流程：

1. 立即将密钥加入 CRL（证书吊销列表）或 OCSP 响应器。
2. 通知所有依赖方停止使用该密钥。
3. 启动应急轮换，生成新密钥。
4. 事后复盘：为什么泄露？流程哪里有问题？

3.5 销毁：真正的“尘归尘，土归土”

销毁是密钥生命周期的终点。但销毁分两种：

• 逻辑销毁：标记为已销毁，但数据可能还在磁盘上。
• 物理销毁：从内存、磁盘、HSM 中彻底擦除。

对于 HSM 或云 KMS，销毁通常是不可逆的。AWS KMS 的 ScheduleKeyDeletion 有 7-30 天的等待期，就是怕你手滑。

# AWS CLI 调度密钥销毁（7 天后执行）
aws kms schedule-key-deletion \
  --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
  --pending-window-in-days 7

我个人建议：销毁前先确认三件事——

• 所有用该密钥加密的数据是否已重加密？
• 审计日志是否已归档？
• 是否有合规要求必须保留该密钥？

3.6 全生命周期流程图

下面这张图，把五个阶段串起来了。你可以把它贴在墙上，或者放进团队的 Runbook 里。

3.7 避坑指南

最后，分享几个我踩过的坑：

• 坑一：密钥创建后没设过期时间。结果用了三年才发现，换起来成本极高。
• 坑二：吊销了密钥但没通知下游。下游服务继续用旧密钥签名，验证全失败。
• 坑三：销毁了根密钥，但忘了还有一批数据是用它加密的。嗯，那批数据现在还在冷存储里躺着，谁也打不开。