第4章：AWS KMS入门——创建CMK、授权策略与控制台基本操作
聊到KMS（Key Management Service），说白了就是AWS生态里管密钥的大管家。很多新手以为KMS就是一键生成密钥，再一键调用加密就行了。实际上，我当年做第一个加密合规项目时就在这上面栽过跟头——光AWS的文档就啃了好几天，才把CMK（Customer Master Key）和授权策略的逻辑理清楚。
那今天咱们就亲手走一遍。用KMS控制台，从零创建一个CMK，再把权限策略配明白。我保证，这章走完，你再看KMS文档就不会觉得头大了。
4.1 创建CMK：不是点一下“生成密钥”那么简单
CMK是KMS的核心。所有加密、解密、签名、验证，说到底都靠这个主密钥。注意，它不是你直接拿来加密明文的那个密钥——CMK是用来保护下级数据密钥（Data Key）的根密钥。嗯，这点区分很重要。
4.1.1 创建流程（控制台）
- 登陆KMS控制台，默认进到“客户托管密钥”页面。
- 点击“创建密钥”——注意有两个选项：“对称” 和 “非对称”。
- 填写别名和描述。我个人习惯把别名写成
alias/项目-环境-用途，比如alias/payment-prod-encrypt，时间一长也好检索。 - 选择密钥管理员——哪些IAM用户可以管理这个密钥（开启、禁用、轮转）。
- 选择密钥使用者——哪些IAM用户或角色能用这个密钥进行加密/解密操作。
- 预览确认，点击完成。
创建出来的CMK默认处于已启用(Enabled) 状态。但别急，这时候它还不能用——你得先想好谁有权限碰它。
4.1.2 对称 vs 非对称：我建议你选对称
| 属性 | 对称CMK | 非对称CMK |
|---|---|---|
| 密钥用途 | 加密/解密 | 加解密、签名/验签 |
| 密钥材料在KMS内 | 是（不可导出） | 是（不可导出私钥） |
| 适合场景 | 大量数据加密、S3 SSE-KMS | 数字签名、外部用户公钥加密 |
| 轮转支持 | 自动轮转（每年一次） | 手动轮转 |
| API操作 | Encrypt / Decrypt | Sign / Verify / Encrypt / Decrypt |
大多数场景下，我建议直接用对称CMK。原因很简单：自动轮转省心，API调用统一。非对称CMK我只在需要对外分发公钥的签名场景里才用。你想想看，如果你的微服务和外部系统做加解密，对方只持有你的公钥，那非对称确实更优雅；但内部服务间全是IAM可控的，对称完全是第一选择。
KeyId参数——不用alias，用KEY ID——这样即使轮转了也不会拿错密钥版本。
4.2 授权策略：密钥策略 vs IAM策略，到底听谁的？
KMS的授权模型刚开始看确实绕。它不像S3那样只有资源策略，它有两套策略体系——密钥策略（Key Policy）和IAM策略（IAM Policy）。说白了，一套是“谁可以怎么用这把锁”，另一套是“谁能碰这台服务器”。两套加一起，才决定最终权限。
4.2.1 密钥策略（Key Policy）
这是CMK自带的资源策略。每个CMK创建时必须指定一个密钥策略（最少提供一个默认的）。它直接绑定在CMK上，不管IAM那边怎么说，密钥策略说不允许就不允许。
4.2.2 IAM策略（IAM Policy）
这是挂在用户/角色上的身份策略。如果CMK的密钥策略已经允许了某个IAM用户，那这个用户必须还要有IAM层面的kms权限才能实际调用。两者是“与”关系：必须两边的allow都匹配，才算有权限。
kms:Encrypt永远是AccessDenied。我当时排查了半小时才意识到——IAM账号没给权限，资源策略给的再宽也没用。
4.2.3 核心决策规则
- 密钥策略没有显式Allow → 直接Deny（哪怕IAM策略给了Allow也不行）
- 密钥策略有Allow + IAM策略也Allow → 最终Permit
- 密钥策略Allow + IAM策略Deny → 最终Deny
- 密钥策略默认拒绝所有非根用户（创建时只能选账户根用户或指定IAM ARN）
4.2.4 实战写法：密钥策略片段
{
"Version": "2012-10-17",
"Id": "key-policy-payment-prod",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/PaymentAppRole"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*"
}
]
}
看到第二条没？我只给了PaymentAppRole三个操作，没给kms:ScheduleKeyDeletion——这样一来，即使有安全事件，应用层也删不了CMK。这是我在生产环境中建议的做做法：最小化使用者权限，永远不给删除和禁用。
4.3 控制台基本操作：该知道的几个入口
把CMK创建出来只是第一步。KMS控制台里还有几个高频操作，我简单说一下。
4.3.1 查看密钥状态
密钥列表里能直接看到五种状态：已启用、已禁用、待删除、已轮转、不可用。其中“待删除”的密钥可以指定7~30天的等待期——我建议至少设30天，给自己留够回退时间。
4.3.2 别名管理
你可以在密钥详情页的“别名”标签里添加、修改、删除别名。别名的好处是应用层可以用别名调用KMS，不需要关心KEY ID。万一哪天重新建了CMK，把别名指向新KEY ID，应用无须改代码。
4.3.3 启用/禁用/计划删除
- 禁用：立即生效，所有加解密API调用都失败。生产环境慎用。
- 计划删除：设一个等待期，到期自动删除。删除后数据不可恢复（除非你有备份密钥材料）。
4.3.4 轮转
对称CMK支持自动轮转（每年一次，免费）。如果你需要更细粒度的轮转周期，可以走自定义密钥轮转——不过那就得自己管版本了。
4.4 本章知识脉络图
下面这张图把CMK创建、授权策略、控制台操作串成一个完整的逻辑链路。我建议你先看一遍，再回到小节里对应着查漏补缺。