4. 密钥管理策略：密钥生成、密钥存储（HSM/Vault）、密钥轮换、密钥吊销
在制品签名链路中，密钥是信任的根。密钥一旦泄露，整个签名链的完整性将瞬间崩塌。因此，密钥管理必须覆盖从生成、存储、轮换到吊销的全生命周期，并遵循最小权限、硬件隔离、自动轮换、即时吊销四大原则。本章将逐一拆解每个环节的工程实践与安全设计。
4.1 密钥生成：熵源、算法与合规
密钥生成是安全链路的起点。生成过程必须确保足够的熵源、强算法以及符合行业合规标准（如 FIPS 140-2/3、PCI DSS）。
| 维度 | 推荐实践 | 避坑指南 |
|---|---|---|
| 熵源 | 使用硬件随机数生成器（HRNG）或操作系统 /dev/urandom（Linux） | 避免在容器启动阶段使用低熵池（如 Docker 早期 /dev/random 阻塞） |
| 算法 | 签名密钥：ECDSA P-384 或 Ed25519；加密密钥：RSA 4096 或 X25519 | 避免使用 DSA（已弃用）或 RSA 1024（强度不足） |
| 合规 | FIPS 140-2 Level 2+ 或 Common Criteria EAL4+ | 云上 KMS 需确认是否通过 FIPS 验证（如 AWS KMS FIPS 140-2） |
| 生成位置 | 在 HSM 或 Vault 内部生成，私钥永不离开安全边界 | 禁止在应用服务器上生成私钥再导入 |
工程建议： 在 CI/CD 流水线中，密钥生成应作为一次性初始化步骤，由安全团队或平台管理员执行，并通过审计日志记录生成时间、操作人、算法参数。生成后立即将公钥导出至公开密钥基础设施（PKI），私钥则直接写入 HSM 或 Vault，不留临时文件。
4.2 密钥存储：HSM vs. Vault 架构对比
密钥存储是密钥管理策略的核心。当前主流方案分为硬件安全模块（HSM）和软件密钥管理服务（如 HashiCorp Vault）。两者并非互斥，在生产环境中常组合使用：Vault 作为策略引擎和密钥分发层，HSM 作为根密钥的物理锚点。
核心原则： 私钥必须存储在专用安全容器内，应用层只能通过 API 调用签名/解密操作，无法直接读取私钥明文。
4.2.1 HSM（硬件安全模块）
- 物理隔离： 专用硬件，防篡改，通过 FIPS 140-2 Level 3/4 认证。
- 性能： 硬件加速签名，适合高吞吐场景（如 CI/CD 批量制品签名）。
- 适用场景： 根 CA 密钥、代码签名根密钥、TLS 终端密钥。
- 成本： 高，需物理部署或云上 HSM 实例（如 AWS CloudHSM、Azure Dedicated HSM）。
4.2.2 Vault（软件密钥管理）
- 逻辑隔离： 基于命名空间和策略的访问控制，支持动态密钥和租约。
- 集成性： 原生支持 Kubernetes、CI/CD 工具，通过 Sidecar 或 Agent 注入密钥。
- 适用场景： 中间签名密钥、应用级加密密钥、短期令牌。
- 成本： 开源免费，企业版提供 HSM 集成和自动解封。
4.3 密钥轮换：自动触发与零停机切换
密钥轮换是降低单点泄露风险的关键手段。在制品签名链路中，轮换策略必须保证：旧密钥签名的制品仍可验证，新密钥立即生效，且轮换过程对 CI/CD 流水线透明。
4.3.1 轮换触发条件
- 时间驱动： 根密钥每 1-2 年轮换，中间密钥每 3-6 个月轮换。
- 事件驱动： 密钥泄露、人员离职、合规审计要求、算法升级（如从 RSA 迁移到 ECDSA）。
- 自动策略： Vault 支持设置密钥 TTL，到期自动生成新版本，旧版本标记为“已轮换”但保留验证能力。
4.3.2 零停机轮换流程
- 生成新密钥对： 在 HSM/Vault 内生成新密钥，分配唯一版本号（如 v2）。
- 双密钥生效： 签名服务同时持有新旧密钥，新签名使用 v2，旧签名仍可用 v1 验证。
- 更新信任锚： 将新公钥发布到公开密钥库（如 TUF 仓库、Kubernetes ConfigMap）。
- 迁移签名任务： 逐步将 CI/CD 流水线的签名配置指向新密钥版本。
- 回收旧密钥： 确认所有下游验证方已更新公钥后，禁用旧密钥的签名权限，仅保留验证权限。
关键风险： 轮换期间若未保留旧密钥的验证能力，将导致历史制品验证失败，引发回滚不可用。务必在密钥管理策略中设置“宽限期”，通常为 30-90 天。
4.4 密钥吊销：即时阻断与 CRL/OCSP 联动
密钥吊销是安全事件的最后防线。当密钥泄露或人员离职时，必须能在分钟级内阻断该密钥的签名能力，并通知所有依赖方。
4.4.1 吊销触发场景
| 场景 | 响应时间要求 | 吊销动作 |
|---|---|---|
| 私钥泄露 | 即时（< 5 分钟） | 立即吊销，生成新密钥，发布安全公告 |
| 人员离职 | 1 小时内 | 吊销该人员可访问的所有密钥，审计日志归档 |
| 算法退役 | 按计划（提前 6 个月通知） | 逐步吊销，配合密钥轮换流程 |
| 合规失效 | 24 小时内 | 吊销不合规密钥，替换为合规密钥 |
4.4.2 吊销技术实现
- CRL（证书吊销列表）： 定期发布吊销列表，客户端缓存并检查。适合离线或低实时性场景。
- OCSP（在线证书状态协议）： 实时查询密钥状态，响应时间 < 1 秒。适合在线验证场景（如 CI/CD 签名验证）。
- Vault 吊销 API： 调用
vault write pki/revoke serial_number=...即时吊销，Vault 自动更新 CRL 并推送 OCSP 响应。
4.5 密钥管理策略清单与自动化集成
将上述策略落地到平台工程中，需要一份可执行的清单，并与 CI/CD 流水线、监控告警系统集成。
| 阶段 | 自动化动作 | 工具/平台 | 验证指标 |
|---|---|---|---|
| 生成 | HSM/Vault 内部生成，公钥自动发布到 PKI | Vault PKI Secrets Engine | 密钥生成审计日志完整 |
| 存储 | 私钥永不落盘，签名 API 调用走 gRPC | Vault Agent + HSM 集成 | 无明文私钥泄露事件 |
| 轮换 | 基于 TTL 自动轮换，旧密钥保留验证权限 | Vault 自动轮换 + CronJob | 轮换成功率 > 99.9% |
| 吊销 | API 触发吊销，CRL/OCSP 自动更新 | Vault Revoke API + OCSP Responder | 吊销到生效时间 < 1 分钟 |
| 审计 | 所有密钥操作记录到 SIEM | Vault Audit Log + Splunk/ELK | 审计日志覆盖率 100% |
平台工程落地检查点：
✅ 密钥生成是否在安全边界内完成？
✅ 私钥是否从未以明文形式出现在应用日志、环境变量或代码仓库中？
✅ 轮换流程是否经过至少一次生产演练？
✅ 吊销后，CI/CD 流水线是否能在 5 分钟内阻断使用已吊销密钥的制品？
✅ 是否所有密钥操作都有不可篡改的审计日志？
✅ 密钥生成是否在安全边界内完成？
✅ 私钥是否从未以明文形式出现在应用日志、环境变量或代码仓库中？
✅ 轮换流程是否经过至少一次生产演练？
✅ 吊销后，CI/CD 流水线是否能在 5 分钟内阻断使用已吊销密钥的制品？
✅ 是否所有密钥操作都有不可篡改的审计日志？