2. AWS KMS 核心概念：CMK、密钥层次结构、硬件安全模块(HSM)保护
聊 AWS KMS，有 3 个概念你绕不开：CMK、密钥层次结构 和 HSM。
说白了，这三者构成了 AWS 密钥管理体系的基石。CMK 是你看到的「钥匙」，密钥层次是这把钥匙的「内部构造」，HSM 则是保护这把钥匙的「保险柜」。
我们先从最直观的 CMK 说起。
2.1 什么是 CMK？—— 你手里的那把钥匙
CMK，全称 Customer Master Key，客户主密钥。
在 AWS KMS 里，它就是一切加密操作的起点。
CMK 是一个逻辑对象。它包含以下元素：
- 密钥 ID (Key ID) —— 全局唯一的标识符，比如
1234abcd-12ab-34cd-56ef-1234567890ab - 密钥材料 (Key Material) —— 真正的加密数据，默认由 AWS 的 HSM 生成
- 元数据 —— 创建时间、密钥状态、描述、标签等
- 访问策略 —— 谁可以用、怎么用
关键点：CMK 本身不直接加密你的业务数据。它的主要工作是 加密和解密数据密钥 (Data Key)。这个设计我后面会细讲。
我记得刚接触 KMS 时，我犯过一个错：以为用 CMK 加密一个 1GB 的文件没问题。结果 API 直接报错。原因？CMK 的加密操作限制在 Encrypt 和 Decrypt API，每次最多处理 64KB 的数据。大文件加密，得用数据密钥 + 信封加密。
CMK 的两种类型
| 类型 | 谁管理？ | 我能做什么？ | 典型场景 |
|---|---|---|---|
| AWS 托管 CMK | AWS 服务（如 S3、EBS、RDS） | 不能轮换密钥，不能禁用/删除，不能查看密钥材料 | 一键启用加密，比如 S3 默认加密 |
| 客户管理 CMK | 你 | 可编辑密钥策略，可启用/禁用/轮换/删除 | 需要严格权限控制、合规审计的场景 |
我的建议：生产环境尽量用 客户管理 CMK。虽然 AWS 托管 CMK 很方便，但你想做密钥轮换、跨账号共享、或者自定义密钥策略，它都不支持。
2.2 密钥层次结构 —— 一层套一层
你可能会问：
「我只有一个 CMK，怎么加密几十TB的数据？」
答案就在 KMS 的密钥层次结构里。AWS KMS 用了一个经典的 层级式密钥体系：
- 主密钥 (Master Key) — 也就是 CMK，存储在 HSM 里，从不离开 KMS 服务。
- 数据密钥 (Data Key) — 由 CMK 生成，用来加密你的业务数据。
- 密文 (Ciphertext) — 使用数据密钥加密后的业务数据。
这个结构，你想想看：
- 数据密钥加密速度快，适合海量数据。
- CMK 只负责保护数据密钥，不接触原始数据。
- 数据密钥的密文可以随数据一起存储，解密时再用 CMK 解开。
举个例子：
你上传一个 1GB 的文件到 S3。
S3 调用 KMS 的 GenerateDataKey API。
KMS 返回两个东西：
1. 明文的数据密钥（Plaintext Data Key）—— 只存在于内存，立即用于加密文件。
2. 加密的数据密钥（Encrypted Data Key）—— 由 CMK 加密，随文件一起存储。
文件加密完成后，明文数据密钥从内存中丢弃。
下次读取文件时，S3 拿出加密的数据密钥，调用 Decrypt API 让 KMS 解开它。
再用得到的明文数据密钥解密文件。
整个过程，CMK 从未离开 KMS。注意：AWS KMS 默认使用 信封加密 (Envelope Encryption) 模式。数据密钥的生命周期非常短暂，生成后要立即使用，用完就销毁。千万不要把明文数据密钥持久化到磁盘或日志里。
我曾经接手过一个项目，对方把 GenerateDataKey 返回的 Plaintext 直接写进了日志文件。嗯，那是典型的「安全灾难」，等于把所有加密文件的口令贴在了墙上。
2.3 硬件安全模块 (HSM) —— 真正的保护者
CMK 的密钥材料到底存在哪里？
存在 HSM 里。HSM 是一种专用的硬件设备，专门用来生成、存储和管理密钥。它的物理安全级别很高——如果你强行拆开它，它会自动擦除内部所有密钥。
AWS KMS 用的是 FIPS 140-2 认证的 HSM。分两种级别：
- KMS 标准版：FIPS 140-2 Level 2 或 Level 3（取决于区域）
- CloudHSM + 自定义密钥存储：FIPS 140-2 Level 3
一句话总结：你的 CMK，从生成到使用到销毁，所有操作都在 HSM 内部完成。AWS 工程师和运维人员也看不到明文密钥。因为 HSM 不暴露明文给外部应用。
HSM 保护了什么？
| 保护维度 | 说明 |
|---|---|
| 物理安全 | HSM 设备部署在受控数据中心，有入侵检测、防拆机制 |
| 逻辑隔离 | 每个 CMK 在 HSM 内部是隔离的，不同客户的数据互不可见 |
| 密钥永不离开 HSM | 明文密钥只在 HSM 内部存在，外部只能获得引用 ID 或密文 |
| 操作审计 | 所有 HSM 内部操作都通过 CloudTrail 记录，无法绕过 |
下面这张图，把 CMK、密钥层次结构和 HSM 的关系画了出来：
2.4 为什么这套设计值得信任？
说白了，这套密钥层次结构解决了几个核心矛盾：
- 性能 vs 安全：数据密钥用对称加密，快；CMK 用不对称或对称加密，保护少量关键材料。各取所需。
- 密钥保护范围：一个 CMK 可以衍生出无数个数据密钥，不需要频繁访问 HSM。
- 访问控制粒度：你可以精细控制谁有权调用 CMK，而数据密钥的生命周期完全由应用管理。
- 审计覆盖：每次 CMK 操作都会被记录到 CloudTrail。HSM 内部操作则更严格，只有 AWS 内部高级审计员才能看到操作日志。
一个小技巧：如果你需要更高的隔离级别，比如物理上独立的 HSM 分区，可以用 自定义密钥存储 (Custom Key Store)，它把 CMK 存储在你自己控制的 AWS CloudHSM 集群里。不过成本会高不少，按需选用。
总结一下这一节的核心：CMK 是钥匙但不是最终加密者，它保护数据密钥；HSM 是保险柜，保护着 CMK 的密钥材料。理解了这个三层结构，你才算真正明白了 KMS 的设计哲学。