📚 课程目录第1章 IAM简介与核心组件

IAM 简介与核心组件归纳总结

IAM，全称是 Identity and Access Management，说白了就是 AWS 的“门禁系统”。你想想看，云上几十上百种服务，谁能用、能用哪些、能用到什么程度——全靠 IAM 来管。我刚接触 AWS 那会儿，觉得这玩意儿就是“创建一个用户，给个权限”而已，结果第一次生产环境差点因为策略配错把整个 S3 桶暴露出去。嗯，从那以后我对 IAM 再也不敢马虎了。

一句话记住 IAM：IAM 控制 谁（身份） 对 什么（资源） 能 做什么（动作）。

IAM 的定位与作用

IAM 不是一个独立的服务，而是 AWS 所有服务的“权限底座”。每次你调用 AWS API，底层都会经过 IAM 的鉴权判断。我个人习惯把它分成两个层面理解：

身份层：定义谁可以访问 — 用户、组、角色。
策略层：定义访问规则 — 基于身份的策略、基于资源的策略、权限边界。

为什么要有这些分层？说白了就是为了灵活和安全兼顾。我在项目中遇到过一种场景：开发团队需要临时读取生产数据库的慢查询日志。如果给每个开发人员单独配权限，后期回收特别麻烦。后来我用 IAM 角色 + 临时凭证搞定了，既安全又省事。

核心组件一览

IAM 的核心组件我归纳为六个，下面这张图可以帮你快速建立整体认知：

逐一拆解核心组件

1. IAM 用户

一个 IAM 用户代表一个具体的人或应用。每个用户有独立的访问密钥（Access Key ID + Secret Access Key），也可以登录 AWS 管理控制台。注意，IAM 用户默认没有任何权限，你需要通过“附加策略”显式授权。

我的建议：生产环境不要用根账户操作，哪怕只是查看账单。创建一个管理员用户配 MFA，能省掉无数风险。我曾见过有人把根账户密钥写死在代码里，结果被人扫到并用来挖矿…

2. 用户组

用户组就是一个“权限集合”。你把策略挂到组上，组里的用户自动继承权限。这样做的好处很明显：人员变动时只要调整组内成员，不用挨个改策略。我在团队里给“开发者”、“测试”、“运维”各建一个组，配合权限边界，基本覆盖了90%的场景。

3. IAM 角色

角色是一种没有长期凭证的身份。你可以把它理解成“临时工作证”。某人或某服务“扮演”角色后，拿到临时凭证才能干活。角色的核心特征是 信任策略 和 权限策略——前者定义谁能扮演，后者定义扮演后能干什么。

我遇到过一个典型案例：EC2 实例需要读取 S3 桶里的配置文件。做法就是创建一个 EC2 可扮演的角色，附加 S3 只读策略，启动实例时关联该角色。这样密钥永远不在实例里，即使机器被入侵，攻击者也拿不到永久凭证。

4. 策略

策略本质就是一个 JSON 文档，描述“允许”或“拒绝”的规则。两种常见策略类型：

基于身份的策略：附加给用户、组或角色。
基于资源的策略：附加给 S3 桶、KMS 密钥等资源，控制谁可以访问该资源。

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

看到没？Effect 只有 Allow 和 Deny 两种，Action 是具体的 API 调用，Resource 是资源 ARN。你还可以加 Condition 做更精细的控制，比如“仅允许来自公司 IP 的请求”。

5. 权限边界

权限边界是个“天花板”。即使你给用户附加了 AdministratorAccess 策略，如果权限边界限制为“只读”，那这个用户最多也只能做只读操作。注意：权限边界只适用于基于身份的策略，不限制基于资源的策略。

注意：权限边界和会话策略（Session Policy）这两个概念容易混淆。权限边界是“附加给身份的静态上限”，而会话策略是在扮演角色时临时传入的。在实际项目中，我建议用权限边界做基线，会话策略做动态微调。

6. 信任策略

信任策略专门用于角色，它决定哪些主体（AWS 账户、用户、服务）可以扮演该角色。比如想让 EC2 服务能扮演角色，信任策略里就要有类似这样的条目：

{
  "Effect": "Allow",
  "Principal": {"Service": "ec2.amazonaws.com"},
  "Action": "sts:AssumeRole"
}

核心组件对比表

为了让你快速对照，我把六个组件的关键区别整理成了表格：

组件	有无长期凭证	是否可跨账户	典型场景
IAM 用户	有（密钥或密码）	不能直接跨账户	人员日常操作、CI/CD 调用 API
用户组	无	不能跨账户	团队权限批量管理
IAM 角色	无（凭据是临时的）	可以跨账户	EC2 访问 S3、跨账户访问、联合身份
策略	无	取决于附加方式	定义所有权限规则
权限边界	无	只能用于本账户	限制用户/角色的最大权限
信任策略	无	可指定跨账户主体	控制谁可以扮演角色

一个实操小案例

假设你需要让开发人员能用 AWS CLI 列出 S3 桶，但禁止删除。你会怎么做？

创建 IAM 用户 dev-user（或直接放在 dev 组）。
创建策略，只允许 s3:ListAllMyBuckets 和 s3:GetObject（允许读）。
再创建一条显式 Deny 策略，拒绝 s3:DeleteObject 和 s3:DeleteBucket。
把策略附加到用户或组。

看起来很简单对吧？但实际中很多人会忘记给 S3 策略指定 Resource 条件，结果变成了“允许所有资源”，删库跑路风险就来了。我当年就犯过这种低级错误，还好是在测试环境发现的。

最佳实践：始终使用最小权限原则。每次加权限时问自己——这个动作真的是必须的吗？能限 resource 就限，能限 condition 就限，不要偷懒用 "Resource": "*"。

好了，IAM 简介和核心组件就这些。记住这六个组件的关系，后面的章节（KMS 策略、角色代入、策略冲突解析）都建立在这个基础之上。如果你现在脑子里能画出刚才那张结构图，那就算过关了。