📚 课程目录第4章 IAM策略管理

4、IAM策略管理：创建、编辑、删除策略归纳总结

说实话，很多团队把IAM策略管理想得太简单了。不就是创建个策略、改两下、不用了就删掉吗？我早期也是这么想的，直到有一次线上事故让我彻底改了观念——一个策略删了，结果整个服务挂了两个小时，因为那个策略还被十几个角色引用着。

这一章咱们就把创建、编辑、删除这三个操作掰开揉碎讲清楚。嗯，别看都是基础操作，里面的门道不少。

4.1 创建策略：两条路，看场景选

创建策略通常有两条路：可视化创建和JSON直接编写。我个人习惯在简单场景用可视化，复杂策略直接写JSON。为啥？你想想看，可视化界面虽然友好，但选项一多反而容易漏。

我在项目中遇到过一件事：一个开发同学用可视化创建了一个S3策略，勾选了所有只读操作，结果"不小心"把s3:GetObject和s3:ListBucket写成了s3:*——界面上的通配符提示太不显眼了。所以啊，可视化适合简单策略，复杂策略还是写JSON靠谱。

对比维度	可视化创建	JSON直接编写
上手难度	低，适合新手	高，需熟悉语法
灵活性	受界面限制	完全可控
可重复性	低，依赖UI	高，可代码管理
适合场景	简单策略、快速验证	复杂策略、生产环境

小提示：不管用哪种方式创建，创建后一定要用策略模拟器验证一下。我习惯写一个"最小权限"版本先跑几天，再逐步放宽。

来看一个典型的策略JSON。这个例子允许对指定桶进行只读操作：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ]
    }
  ]
}

注意几个关键点：Version字段一定要写2012-10-17，这是最新的策略语言版本。Resource里的桶和对象要分开写，很多人只写了桶忘了加/*，结果GetObject一直报错。

4.2 编辑策略：版本管理是你的救命稻草

编辑策略是最容易出事儿的操作。你改了一个策略，以为只是加了个Action，结果影响了所有关联的权限。为什么会这样？因为IAM策略是"增量叠加"的，你加了一条Allow，可能就把之前没开放的权限全放开了。

我建议所有编辑操作都走"版本管理"流程。AWS IAM每个策略最多保留5个版本，你可以随时回滚到任意旧版本。这个机制我用了很多年，救过我好几次。

警告：不要在未创建新版本的情况下直接覆盖编辑生产环境策略。我曾经见过有人直接在控制台修改了默认版本，结果回不去了——因为没有保存旧版本。

编辑策略时，我通常会遵循"权限收敛"原则：每次编辑，不只是看你要加什么，更要看能不能把不用的权限收回来。说白了，策略就像衣柜，只往里塞不往外扔，迟早出问题。

举个例子：一个策略里原来有ec2:StartInstances和ec2:StopInstances，后来业务变了，只需要ec2:DescribeInstances。那就应该把前两个删掉，而不是继续往上堆。

我自己的习惯做法是：

先复制当前版本，创建新版本进行编辑
用策略模拟器跑一遍影响分析
设置新版本为默认版本（先别删旧版本）
观察24小时，确认没问题再清理旧版本

4.3 删除策略：安全回收，别留尾巴

删除策略是最容易被低估风险的操作。很多人觉得"这个策略没用了，删掉吧"，结果一删就出事儿。我以前在一个项目中就踩过这个坑——删了一个"看起来没用"的策略，结果三个服务同时报403。

删除前必须做三件事：

检查哪些角色、用户、组引用了这个策略
确认引用方是否还有其他策略覆盖相同权限
先解除引用，再删除策略

    核心原则：先解绑，再删除。解绑之后观察一段时间，确认没有告警，再执行删除操作。

删除操作的流程可以归纳为：

步骤	操作	说明
1	列举引用关系	使用`ListEntitiesForPolicy`API或控制台查看
2	逐一解除引用	从角色、用户、组中移除策略
3	创建备份版本	导出策略JSON，保存到版本控制系统
4	观察期	建议至少等待24小时
5	执行删除	使用控制台或API删除

备份习惯：我所有删除的策略都会在Git里留一份JSON，命名格式是"策略名_删除日期.json"。这样万一需要恢复，直接拿回来重新创建就行了。

4.4 策略生命周期全景图

下面这张图把创建、编辑、删除以及版本控制和审计检查串在一起，展示了策略的完整生命周期：

这张图展示了策略从创建到删除的完整闭环。你会发现，版本控制贯穿编辑过程，而审计检查则覆盖了整个生命周期。我之前很多项目都是按照这个流程来设计的，效果不错。

4.5 避坑指南与最佳实践

最后，我把自己这些年踩过的坑和总结的经验列出来，希望能帮你少走弯路。

我曾经犯过的错：有一次我直接在控制台删除了一个策略的旧版本，结果发现新版本有bug，想回滚却回不去了。所以我现在一定会保留至少两个稳定版本，绝不删最后一个旧版本。

几条关键建议：

创建时：用最小权限起步，逐步放宽。别一开始就给*，后面收不回来的。
编辑时：永远先创建新版本再修改。默认版本不要直接动。
删除时：先解绑再删除，解绑后观察至少24小时。
日常：所有策略JSON都纳入Git管理，注释写明用途和创建人。
定期：每季度做一次策略清理，把没用的大权限策略收回来。

一个小技巧：用iam:PolicyUsageCount这个条件键可以限制策略被引用的次数。我在给多个团队分配权限时经常用这个，防止一个策略被挂到太多实体上，出了问题影响面太大。

嗯，差不多就这些了。策略管理看起来是基础操作，但把这些基础做扎实了，整个IAM体系才能稳得住。你想想看，权限这事儿出问题往往不是因为你不会写策略，而是因为你没管好策略的生命周期。