课程介绍与目标：IAM与KMS权限模型的价值与应用场景
说起云安全，我最常被问到的一个问题是：「到底该怎么管权限？」。嗯，其实这个问题背后，藏着两个核心支柱——IAM（身份与访问管理） 和 KMS（密钥管理服务）。这两者分开说都不难，难的是把它们组合成一个完整的权限体系。
我在前面几家公司的项目中，每次搞权限设计，最后复盘时发现一个问题：谁负责管人，谁负责管密钥，界限模糊。要么是权限策略过于宽松，要么是密钥轮换完全被遗忘。说白了，这堂课要解决的，就是这样一个痛点。
1.1 IAM 与 KMS：不只是「谁」和「能做什么」
咱们先理清楚各自的位置。
- IAM：核心是 身份 和 策略。谁是你的用户、服务、角色？他们能调用哪些 API？
- KMS：核心是 密钥生命周期。密钥的创建、使用、轮换、销毁，谁来授权使用这把密钥？
一句话概括：IAM 管「人」的权限，KMS 管「数据」的权限。
可别小看这个区分。有一次我对接一个金融项目，对方说「我们用 KMS 加密所有敏感文件」。我追问了一句：「那谁有权调用解密 API？」对方沉默了。你看，只有 KMS 没有 IAM，就好比门锁装好了，却把钥匙挂在门外钉子上。
1.2 为什么要把两者放在一起学？
很多人学过 IAM，也听过 KMS，但到实际设计权限模型时就卡住了。原因是：这两个体系在真实世界里是深度耦合的。
举个例子，一个典型的微服务调用链路：
- 服务 A 使用 IAM 角色获取临时凭证
- 通过 KMS 的密钥授权，解密数据库中的敏感字段
- 权限策略既要允许
kms:Decrypt，又要限制Resource到特定密钥
你觉得这个链条里，哪个环节最容易漏？我见过最典型的坑是：IAM 策略允许了 kms:*，结果变成了「凭谁都可用所有密钥」。
我曾经踩过的坑：一个项目的 KMS 密钥被误配为 "Principal": "*"，加上 IAM 策略允许了 "Action": "kms:*"，等于所有服务都能调 KMS。这个配置跑了一周才被发现，幸好是开发环境。
1.3 核心应用场景：谁该关心这个？
这门课不是讲理论，是讲怎么落地。以下场景我都在实际项目中遇到过：
| 场景 | 问题 | 课程对应章节 |
|---|---|---|
| 云原生微服务 | 每个服务之间如何授予最小化密钥权限？ | 第 8-12 章 |
| 多云 / 混合云 | KMS 密钥如何跨账号、跨云共享？ | 第 18-21 章 |
| 合规与审计 | 谁在何时解密了哪些数据？如何追溯？ | 第 24-27 章 |
| 数据湖 / 数仓 | 列级加密与 IAM 细粒度权限如何共存？ | 第 14-16 章 |
你想想看，如果你的职责里包含「云上数据安全」或「基础设施权限管理」，那这套设计方法逃不掉。
1.4 设计中的常见陷阱（先打个预防针）
- 孤立设计：只做 IAM 策略，忽略 KMS 密钥策略；或只管密钥，忘了身份映射。
- 策略爆炸：为每个服务单独写一份 IAM + KMS 策略，最后自己都记不清。
- 密钥共享：多个服务共用一把 KMS 密钥，出了问题无法溯源。
- 审计缺失：没有给 KMS 操作加上
kms:ViaService条件，日志里全是模糊信息。
我的习惯：在设计之初，我就先画一张「身份 + 密钥 + 数据」的三层映射图。哪层脱节，哪层就有风险。
1.5 这张图帮你看清全局
下面这张图，是我自己每次做权限模型设计时都会参考的框架。它展示了 IAM 与 KMS 在整个云上权限体系中的位置：
画完这张图，你就能对齐团队：IAM 决定了「谁可以路过走廊」，KMS 决定了「谁有那把钥匙开哪个房间」。两者缺一不可。
1.6 这门课会怎么帮你避坑？
我不会给你一堆理论框架。每章我都会穿插真实项目里的场景：
- 「某次线上事故，因为 IAM 策略忘了加
kms:ViaService，导致一个实例能解密全账号密钥」 - 「我见过一个团队，KMS 密钥策略写得过于开放，结果实习生误操作删了根密钥」
- 「后来我们怎么用标签加上 IAM 条件，把密钥隔离到每个环境」
说白了，最好的学习就是在别人的坑里长经验。这门课会让你少踩几个实实在在的坑。
1.7 小结：给这个章节收个尾
到这里，你应该能看清 IAM 和 KMS 在整个云权限模型里的位置了。它们不是两个孤立的系统，而是联合控制面。你要做的不是精通其中一个，而是知道怎么让它们协同工作。
从下一节内容开始，我们会正式深入每一个设计细节。但在此之前，我希望你记住这张图——以后每遇到权限问题，先想想：身份、密钥、数据，这三层我设明白了吗？
核心问题自测：
- 你的 IAM 策略有没有限制到具体的 KMS 密钥？
- 密钥策略里是否明确写了哪些 IAM 角色可以调用？
- 操作日志能不能同时关联到身份和密钥？