第2章：AWS KMS 服务介绍
好，我们直接进入正题。AWS KMS 到底是什么？
说白了，它就是一个托管密钥服务。你用不着自己搭HSM（硬件安全模块），也用不着操心密钥怎么存、怎么轮换。AWS全帮你干了。我在项目里见过不少团队自己写加密模块，结果密钥硬编码在配置文件里——嗯，后来都老老实实改用KMS了。
2.1 核心概念：密钥才是主角
KMS 里最重要的东西就是密钥，官方叫 KMS Key（旧称 Customer Master Key，CMK）。你可以把它理解成一把“万能钥匙”，但它本身从不离开AWS的边界。
- 对称密钥：同一个密钥既加密又解密。95%的场景用这个。
- 非对称密钥：公钥/私钥对。适合外部系统验签或加密小数据。
- 多区域密钥：跨区域复制的副本，不同Region各有各的独立Key ID。
💡 我个人习惯：能对称就别用非对称。非对称密钥支持的加密数据上限只有1KB，用得多了容易踩坑。
2.2 KMS的架构：一层有一层的道理
你调用 Encrypt、Decrypt 时，KMS并不会把主密钥直接暴露给你。它用的是两层密钥结构：
- 主密钥（KMS Key）—— 永远安全地待在后端HSM里。
- 数据密钥（Data Key）—— 由KMS生成，你可以带走到应用中使用，用完就销毁。
为什么要这样设计？你看，如果你每次加密10GB文件都请求KMS，那就费钱了，性能也慢。正确做法是：先生成一个数据密钥，用它在本地加密文件。数据密钥本身再用主密钥加密存储。我在一个日志归档项目里就是这么干的，成本降了80%。
🔑 记住：数据密钥是“临时工”，主密钥才是“正式编制”。
2.3 加密/解密流程（一张图说清）
2.4 访问控制：谁可以用这把钥匙
KMS 的权限体系可以分成两层：
| 层面 | 控制手段 | 典型用例 |
|---|---|---|
| 密钥策略 | 直接附加在Key上的资源策略 | 指定某个IAM角色或AWS服务可用 |
| IAM策略 | 用户/角色权限中允许调用KMS API | 限制特定开发者只能解密、不能创建密钥 |
| 授权（Grants） | 临时委托权限，可超细粒度控制 | 临时让Lambda解密一批文件，用完自动失效 |
⚠️ 我曾经遇到过一个坑：给IAM角色设了kms:Decrypt权限，但密钥策略里没有放行该角色——结果解密一直报错。记住，密钥策略和IAM策略是与关系，两者都必须允许。
2.5 跨账号场景的先修知识
咱们这门课叫“跨账号共享密钥”，所以你得先理解一个原则：KMS 密钥默认只属于创建它的账号。其他账号根本看不见它的ARN。
要共享，你必须做两件事：
- 在密钥策略里显式授权目标账号。
- 目标账号的IAM角色/用户必须拥有对应的“使用”权限。
听起来简单？我在给两个生产环境做密钥共享时，就漏掉了第二步目标账号里IAM策略的配置，结果又排查了半天……嗯，这两章后面会手把手带你配，别急。
2.6 为什么选择KMS做加密中心？
给你列几个我亲测的好处：
- 自动轮换：每年或自定义周期帮换密钥，你不需要记旧密钥。
- 审计日志：谁、在哪、什么时候调用了你的密钥，CloudTrail里一清二楚。
- HSM保护：密钥材料存放在FIPS 140-2 Level 2（或Level 3）的硬件里，物理安全有保证。
- 按量付费：每月基本费$1，超额调用按次计费，价格透明。
你想想看，如果你自己搭加密服务，要买HSM、写高可用、做备份……成本至少是KMS的5倍。所以我的建议：只要不是政府和军方场景，KMS就是最省心的选择。
2.7 本章小结
这一章，我们把KMS的底牌翻了个遍。你至少应该记住：
- KMS Key是主子密钥两层体系，数据密钥才是你真正在本地用的。
- 权限控制靠密钥策略+IAM策略双保险。
- 跨账号共享必须双方都有权——后面几章会一步步教你怎么配。