AWS IAM 速查:用户、角色、策略与 IAM 权限最小化实战

每次有人在群里贴一张 AccessDenied 截图问我「这是不是 AWS 抽风」,我心里都知道,九成是策略写窄了或者 ARN 写反了。AWS IAM 不是玄学,它判定一次请求只看四样东西:主体是谁、想做什么动作、动作落在哪个资源、有没有附加条件。把这四样想清楚,大部分权限问题当场就能定位。这篇就按速查的方式,把用户、角色、策略和最小权限原则一次讲透。

用户和角色,到底用哪个

IAM 用户是一个长期身份,带固定的访问密钥(AK / SK),适合给真人或者必须用静态凭证的老系统。角色没有长期凭证,谁需要用谁临时 AssumeRole 换一组有时效的临时凭证。

我的经验是,能用角色就别发用户密钥。EC2 上的程序挂实例角色,Lambda 用执行角色,CI 流水线走 OIDC 联合身份换角色,这些场景都不该出现一串写死在配置里的 AK SK。密钥一旦泄漏到 Git 历史或日志里,排查和轮换的成本远高于一开始就用角色。判断很简单:是人或不可改造的旧系统,才考虑用户;是云上的算力或自动化,一律用角色。

策略 JSON 的三要素:Effect、Action、Resource

一条策略声明(Statement)最核心的就是三个字段:

Effect:Allow 或 Deny,决定这条规则是放行还是拒绝。
Action:具体操作,比如 s3:GetObject、ec2:RunInstances,支持通配但要慎用。
Resource:操作作用的资源 ARN,精确到桶、对象前缀或某个角色。

记住一个评估顺序:只要命中任何一条显式 Deny,请求一定被拒,Deny 永远压过 Allow。没有显式 Deny 时,至少要有一条 Allow 命中,否则默认拒绝。很多「我明明给了权限却报错」的情况,其实是 Allow 根本没匹配上资源 ARN。

一段真实的 IAM 策略示例

下面这段授予对某个桶里对象的读写,注意它怎么区分桶级和对象级 ARN:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListTheBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::toolora-reports"
    },
    {
      "Sid": "ReadWriteObjects",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::toolora-reports/*"
    }
  ]
}

关键在第二条的 /*。s3:ListBucket 是桶级动作,ARN 就是桶本身;而 s3:GetObject、s3:PutObject 是对象级动作,必须带 /* 或更窄的对象前缀。如果把 GetObject 也只写到 arn:aws:s3:::toolora-reports,它匹配不到任何对象,IAM 拒绝得理直气壮。这个坑我见过太多次,贴上去用 AWS IAM 速查表与策略检查器跑一遍,几秒就能看出 Resource 写没写对。

最小权限怎么真正落地

最小权限原则人人都会念,难的是不退化成 Action: "*" 加 Resource: "*"。几个我自己一直守着的做法:

先按工单里真实的 action / resource 组合给权限,而不是先开 AdministratorAccess 让它跑通再说。一旦放宽,基本没人会回头收紧。
通配 Action 要克制,s3:* 看似省事,实际把删除、改桶策略这些危险动作也放出去了。
iam:PassRole 一定钉死到具体 role ARN,再配 iam:PassedToService 限制只能传给预期服务。把它授到 *,等于让一个部署者可能把管理员角色交给自己控制的算力,从而接管整个账号。
警惕 Allow 搭 NotAction 这种反向写法,它的实际范围往往比你想象的宽得多。

部署一个角色前,我习惯把准备上线的 policy 整段复制出来,重点看通配 Action、通配 Resource、PassRole 范围、S3 对象 ARN 这几类高风险点,再放进 PR 让同事二次确认。

顺手要会的 CLI 与 JSON 习惯

排查 AccessDenied 的第一步永远是 aws sts get-caller-identity,先确认当前到底是谁,再定位失败请求的精确 action 和 resource。这一步省掉的话,后面全是瞎猜。常用的 IAM 与其他服务命令可以对照 AWS CLI 命令速查快速回忆参数。

策略 JSON 手写久了容易漏逗号、括号不配对,贴进编辑器前先用 JSON 格式化与校验工具过一遍,确认结构合法再交给 IAM,能少踩一半 malformed 报错。

写策略不是越宽越省事,而是把主体、动作、资源、条件四样对齐到真实需求。把这套速查记进肌肉记忆,AccessDenied 就会从「玄学」变成「五分钟定位」。

Made by Toolora · Updated 2026-06-13