第2章 AWS KMS 简介：服务架构、核心概念与术语
好，咱们直接进入正题。AWS Key Management Service，简称KMS，是你在云上管理加密密钥的核心服务。说白了，它帮你处理“密钥怎么存、怎么用、怎么轮换、谁能用”这些头疼的问题。我在做金融客户项目时，合规审计第一眼就盯上了KMS——密钥管理不到位，其他安全措施都是白搭。
2.1 核心概念，得先搞明白
KMS里有几个基础概念，你可能在文档里见过，但真正用起来还是有坑。我一个个说。
2.1.1 客户主密钥（CMK）
CMK是KMS里的“根密钥”。它本身不直接加密你的业务数据，而是用来加密其他“数据密钥”（Data Key）的。你可以把CMK看作一把万能钥匙，数据密钥才是真正开锁的。CMK分三种：
- AWS托管CMK： 服务自动创建、自动轮换，你只管用。适合对控制权要求不高的场景。
- 客户管理CMK： 你自己创建，可以配置轮换策略、导入自己的密钥材料（BYOK）、设置启用/禁用。我一般都用这种。
- AWS自有CMK： 服务内部用，你压根看不到。不用管它。
个人习惯： 生产环境一律用客户管理CMK。虽然AWS托管节省精力，但合规审计时你没法证明密钥轮换策略是自己控制的——我曾经被审计员追着问“你们的轮换周期是怎么配置的？”，如果是托管CMK我只能说“AWS自动处理”，这种回复在金融行业基本过不了关。
2.1.2 密钥存储与HSM
CMK到底存哪了？AWS KMS背后用的是FIPS 140-2 Level 2（甚至Level 3）认证的硬件安全模块（HSM）。密钥在HSM内部生成、存储、使用，HSM永远不把明文密钥吐出来。我参加过AWS re:Invent，看过他们展示HSM的物理拆解——芯片上裹着环氧树脂，真要物理破解，密钥会自动销毁。嗯，这层保护比纯软件方案强太多了。
2.1.3 密钥轮换
轮换就是定期生成新密钥材料，同时保留旧版本用于解密历史数据。KMS支持自动轮换（每年一次，仅限客户管理CMK）和手动轮换（你自己创建新CMK，更新引用）。
避坑指南： 自动轮换只换密钥材料，不换Key ID。如果你在IAM策略或应用里硬编码了Key ID，轮换后还能用。但如果你用别名（Alias），记得把别名指向新密钥。我曾经见过一个团队，轮换后忘记更新别名，结果所有加密Lambda函数全部报“AccessDeniedException”——因为旧版本的Key被禁用了。血泪教训。
2.1.4 别名（Alias）
别名叫什么？其实就是CMK的一个友好名称，比如alias/prod-db-key。你可以在代码里用别名代替Key ID，这样轮换时只需要把别名指向新CMK，代码不用改。我之前参与的一个电商项目，密钥轮换流程就是靠别名做到了零停机——生产环境完全没感觉。
2.1.5 权限控制：IAM vs 密钥策略
KMS的权限模型有点特殊：既有IAM策略，又有密钥策略（Key Policy）。两者是“AND”逻辑，也就是两个都得允许才能操作。我总结了一个规则：
| 策略类型 | 控制粒度 | 适用场景 |
|---|---|---|
| IAM策略 | 用户/角色级别 | 适合跨多个CMK的通用权限（如：所有开发人员只能加密，不能解密） |
| 密钥策略 | CMK级别 | 适合单一密钥的精细控制（如：允许跨账号使用） |
你可能觉得“两个一起用很麻烦”，但这是安全设计。我曾经遇到过运维人员不小心把密钥策略改成了“Allow *”，幸好IAM策略里限制了只有特定角色才能解密——双重保险救了我一命。
2.2 服务架构，KMS怎么跑起来的
这张图帮你理清KMS的调用链路：
流程其实很简单：你的应用通过AWS SDK调用KMS API（比如 encrypt），KMS先检查IAM策略和密钥策略，通过后把请求发给HSM集群。HSM用CMK生成数据密钥或执行加解密，整个过程密钥材料从不出HSM。元数据（比如密钥别名、轮换状态）存在KMS自己的后端数据库（DynamoDB）里。
2.3 常用操作与代码示例
这里列出我工作中最常用的KMS CLI操作，记住几个就够了：
# 创建客户管理CMK（带别名）
aws kms create-key --description "Prod DB Encryption Key"
aws kms create-alias --alias-name alias/prod-db-key --target-key-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
# 加密一段明文（返回Base64密文）
aws kms encrypt --key-id alias/prod-db-key --plaintext fileb://plaintext.txt --output text --query CiphertextBlob > ciphertext.b64
# 解密
aws kms decrypt --ciphertext-blob fileb://ciphertext.b64 --output text --query Plaintext | base64 -d
# 启用自动轮换（仅对客户管理CMK有效）
aws kms enable-key-rotation --key-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx小提示： CLI里plaintext参数建议用fileb://读取二进制文件，避免shell里明文内容被记录在历史中。我习惯把密钥操作的CLI命令都写成脚本，统一管理。
2.4 常见误区，我帮你踩过了
- 误区一： 把CMK直接当数据加密密钥用。千万别！每次加密最大4KB，而且没有任何性能优化。正确做法是用CMK生成数据密钥，然后用数据密钥加密你的大文件。KMS的
GenerateDataKeyAPI就是干这个的。 - 误区二： 忽略密钥策略的“默认”部分。当你通过控制台创建CMK时，AWS会自动添加一条“Allow root user”的语句。如果你删了它，连账号管理员都没权管理——我有一次在测试环境手贱删了，结果不得不找AWS Support恢复。
- 误区三： 跨账号使用CMK时只配IAM。跨账号必须同时修改密钥策略，添加
RootPrincipal（对方账号根用户），再在对方账号的IAM里授权。具体配置我在后面章节会细讲。
2.5 何时选择AWS KMS？
一句话：如果你需要纯托管、高合规、深度集成AWS生态的密钥管理，KMS是首选。它和S3、EBS、RDS、Lambda等服务的集成度极高，开箱即用。但如果你希望密钥完全脱离云厂商控制，或者需要非对称密钥的离线签名场景（比如区块链），那可能要考虑CloudHSM或第三方HSM。
嗯，这一章的概念比较多，但都是后面实战的基石。你花十分钟把这些术语刻在脑子里，后面的选型决策会轻松很多。