准备工作：账号、权限与网络策略
说实话，很多人把密钥托管到KMS的第一步就搞错了。他们直接拿主账号的AccessKey去调接口，或者在代码里写死了密钥ID。嗯，这些都是我在项目里见过的事故现场。
准备工作做得好，后面能省掉80%的排障时间。今天我们就聊聊账号怎么规划、权限怎么切分、网络策略怎么配。这三件事做好了，你的密钥托管才算真正有了基础。
账号体系怎么搭？
我个人的习惯是：永远不要用主账号干活。主账号的权限太大了，一旦泄漏，整个云账号就完蛋。我在某金融客户那里就见过，主账号AccessKey被开发人员写到配置文件里，结果被扫出来了，幸好发现得早。
你应该创建一个专用的子账号，只用来管KMS。这个子账号不要关联到其他云产品，就盯着密钥生命周期那一亩三分地。
账号规划建议
- KMS管理员账号：负责创建密钥、配置轮换、管理别名
- 密钥使用者账号：只能调用加密、解密、生成数据密钥等API
- 审计账号：只读，用来拉操作日志和密钥元数据
你想想看，这三个账号的权限等级是完全不同的。管理员账号一年可能只用几次，使用者账号天天跑在生产流水线上，审计账号则是被安全团队监控着的。千万别图省事用一套账号走天下。
权限配置的三个层次
权限这块，说白了就一句话：谁，在什么样的网络环境里，可以对这个密钥做什么操作。我习惯把权限切成三层来看：
| 权限层次 | 典型策略 | 我踩过的坑 |
|---|---|---|
| 账号级权限 | IAM策略控制谁可以访问KMS服务 | 曾经给了一个开发人员KMS FullAccess…他删了一个生产密钥 |
| 实例级权限 | 谁可以管理KMS实例本身（配置、扩缩容） | 忘了限制实例删除权限，运维手滑差点把测试实例删了 |
| 密钥级权限 | 谁可以使用/管理某个具体的密钥 | 跨账号授权时没配key policy，加密请求一直报AccessDenied |
注意：我曾经历过一个事故——开发人员在测试环境用了一个「放任」的IAM策略，结果不小心调用 DeleteKey 把密钥删了，导致所有用这个密钥加密的备份数据全部不可读取。所以，非必要不给Delete权限，这是铁的纪律。
权限配置的标准步骤
我个人推荐按这个顺序来配：
- 先创建好子账号，并分配最小需要的IAM策略
- 在KMS实例上配置实例级别的访问控制
- 在目标密钥上配置Key Policy，允许哪些主体做什么操作
- 如果涉及跨账号，在资源策略中明确授权
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:acs:kms:cn-hangzhou:123456:key/your-key-id",
"Condition": {
"IpAddress": {
"acs:SourceIp": ["10.0.0.0/8", "172.16.0.0/12"]
}
}
}
]
}上面这个策略，只允许来自内网网段的请求对特定密钥做加密、解密和生成数据密钥。既不会让密钥被误删，也不会被公网扫到。
网络策略：你的第一道防线
不管权限配得多精细，如果网络是敞开的，那一切都白搭。我见过不少团队，KMS实例直接绑定公网IP，然后靠着密码和AccessKey做防护。你想想看，只要密钥泄露一次，攻击者就能从全世界任何地方调用你的KMS。
实用建议：在VPC里给KMS实例分配内网IP，并通过 VPC Endpoint 或者 PrivateLink 提供服务。这样所有KMS流量都跑在阿里云的内网里，不会经过公网。
网络策略配置清单
| 配置项 | 推荐做法 | 不推荐的做法 |
|---|---|---|
| VPC网段 | 使用RFC1918私网地址（10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16） | 混用公网地址段 |
| 安全组/ACL | 只允许需要的应用服务器访问；拒绝所有入方向公网流量 | 开放0.0.0.0/0 |
| 跨账号访问 | 使用VPC Peering + PrivateLink | 直接暴露公网Endpoint |
| 公网紧急通道 | 将KMS实例放在NAT网关或SLB后面，并严格限制源IP | 直连公网IP |
举个例子。我在一个异地容灾项目中，需要让杭州和上海机房的服务器都能访问同一个KMS实例。我们的做法是创建两个VPC，之间用VPC Peering打通，然后KMS实例只暴露内网IP。两边的服务器通过内网路由表就能找到KMS，全程不走公网。
核心原则：让应用服务器朝着KMS走「内网、最短路径、最小延迟」，同时让攻击者面对的是「黑洞」。
网络策略就是你的第一道物理防线，比IAM策略更底层。
跨账号授权怎么办？
这个场景在大型企业里特别常见。比如说，安全团队在一个账号里统一管理密钥，业务团队在另一个账号里跑应用。业务方需要调用安全团队托管的KMS来做加密解密。
我记得有个案例，两个团队跨账号调用KMS时报了AccessDenied。排查了半天，发现是他们在配置Key Policy时，把授权主体的ARN写成了用户ID，而不是角色ARN。这其实是个很细节的错误——跨账号授权时，主体必须写成RAM角色的ARN，不是用户的登录名。
总的来看，准备工作并不复杂，但每一条都有血的教训在背后。把账号切分开，权限一刀刀剁细，网络收进内网——这三件事做完，你的密钥托管才算站在了安全的地基上。