KMS 的加密密钥存储在哪里 - 信封加密与 HSM 的工作机制
解析 KMS 主密钥存储在 FIPS 140-2 认证 HSM 内的机制、通过信封加密双重保护数据密钥的设计、密钥轮换的内部运作。
KMS 密钥不以明文存储
在 AWS KMS（Key Management Service）中创建的加密密钥（KMS 密钥，旧称 CMK）绝不会以明文状态存储在磁盘上。KMS 密钥的密钥材料（实际的加密密钥数据）仅在通过 FIPS 140-2 Level 3 认证的 HSM（Hardware Security Module）内以明文形式存在。HSM 是专用于加密处理的硬件设备，具备物理防篡改机制，即使物理拆解也无法提取内部密钥。KMS 密钥在 HSM 外部始终以加密状态存在，由 HSM 内部的域密钥（Domain Key）进行保护。
信封加密 - 为什么要用密钥加密密钥
KMS 加密模型的核心是「信封加密」（Envelope Encryption）。不是直接用 KMS 密钥加密数据，而是先向 KMS 请求生成数据密钥（Data Key），用该数据密钥加密数据，再用 KMS 密钥加密数据密钥本身进行存储。为什么需要这种双重结构？原因有二。第一是性能：KMS API 调用有网络延迟，且 KMS 密钥的加密操作限制为每秒数千次请求。如果每次加密数据都调用 KMS API，大量数据的加密将成为瓶颈。通过在本地使用数据密钥加密，可以高速处理大量数据。第二是安全边界：数据密钥仅在内存中以明文存在，使用后立即丢弃。即使加密后的数据被泄露，没有 KMS 密钥就无法解密数据密钥，数据仍然安全。
密钥轮换的内部运作
启用 KMS 的自动密钥轮换后，每年（可配置为 90 天至 2560 天）会生成新的密钥材料。重要的是，密钥轮换后旧的密钥材料不会被删除。KMS 密钥的 ARN 和 Key ID 保持不变，用旧密钥材料加密的数据会自动使用旧密钥材料解密。新数据的加密使用新密钥材料。这种设计使得密钥轮换对应用程序完全透明，无需重新加密现有数据。每个密钥材料都有唯一的版本标识符，KMS 在解密时根据密文中嵌入的元数据自动选择正确的密钥材料版本。
KMS 与 CloudHSM 的选型
KMS 是在多租户 HSM 上运行的托管服务。多个客户的 KMS 密钥在同一 HSM 集群上处理，但各密钥通过加密学方式隔离，无法访问其他客户的密钥。而 CloudHSM 提供单租户 HSM 服务，专用 HSM 设备部署在 VPC 内，仅客户可以访问。CloudHSM 适用于合规要求必须使用专用 HSM 的场景（如 PCI DSS 的某些要求）、需要 PKCS#11 或 JCE 接口的应用程序、以及需要在 HSM 内执行自定义加密操作的场景。大多数工作负载使用 KMS 即可满足需求，CloudHSM 仅在有特定合规或技术要求时选择。
加密密钥的删除 - 不可撤销的最危险操作
KMS 密钥的删除是 AWS 中最危险的操作之一。删除 KMS 密钥后，用该密钥加密的所有数据将永久无法解密。S3 对象、EBS 卷、RDS 快照等依赖该密钥的所有数据将实质性丢失。AWS 为降低此风险，设置了 7 至 30 天的等待期。计划删除后，密钥在等待期内处于「待删除」状态，此期间可以取消删除。建议启用 CloudTrail 监控密钥使用情况，在计划删除前确认没有服务仍在使用该密钥。