如果你已经用过 AWS 的各项服务,可能已经注意到每次创建资源时都会涉及到“权限”问题——EC2 实例需要访问 S3、Lambda 需要写入日志、不同团队需要不同的操作权限。这些权限控制的背后,都离不开同一个服务:AWS IAM

今天这篇文章,就带你彻底搞懂 IAM 是什么、为什么它如此重要,然后手把手教你正确配置用户、角色和策略。

什么是 AWS IAM?

IAM 的全称是 Identity and Access Management(身份与访问管理)。它是 AWS 提供的一项核心服务,用于管理谁(身份)可以访问哪些 AWS 资源,以及可以执行哪些操作

你可以把 IAM 想象成 AWS 云上的一栋大厦的“安保系统”:

  • 能进大厦?(身份验证——Authentication)

  • 进来之后能进哪个房间、能做什么?(授权——Authorization)

IAM 是 AWS 安全体系的基石,几乎所有的 AWS 服务都依赖它来控制访问权限。

IAM 的三大核心实体

要理解 IAM,关键是搞清楚它的三个核心“零件”:用户、组和角色

1. 用户(User):具体的人或应用

IAM 用户代表一个具体的人或应用程序,拥有独立的凭证(密码或访问密钥),用于与 AWS 交互。

根据 AWS 最佳实践,人类用户应优先使用联合身份认证(如 IAM Identity Center)获取临时凭证访问 AWS,而不是创建长期凭证的 IAM 用户。 只有在特定场景(如第三方工具不支持联合认证、CodeCommit 访问、某些运行在非 AWS 环境的工作负载)下,才建议创建 IAM 用户并分发长期凭证。

何时创建 IAM 用户?

  • 你的应用运行在本地或第三方云上,无法使用 IAM 角色

  • 你使用的第三方工具不支持 IAM Identity Center

  • 需要为特定人员创建长期编程访问凭证

2. 组(Group):用户的集合

组是一组 IAM 用户的集合。通过将用户加入组,并给组附加权限策略,可以批量管理用户的权限。例如,可以创建“开发者组”、“运维组”、“只读组”,将权限赋予组而非逐个用户。

3. 角色(Role):用于临时授权

IAM 角色是一种可以被“担任”的身份,不绑定特定用户,而是为需要临时访问 AWS 的场景设计。任何人或服务“担任”角色时,就会获得该角色所拥有的权限。这是 AWS 推荐的核心访问管理方式。

角色适用于哪些场景?

  • EC2 上运行的应用:EC2 实例上的应用需要访问 S3 或 DynamoDB,将角色“附加”给 EC2 实例即可,无需在实例中存储任何长期凭证

  • 跨账户访问:一个 AWS 账户中的用户需要访问另一个账户的资源,可以“扮演”目标账户中的角色

  • 联合身份用户:通过企业 IdP(如 Azure AD、Okta)登录的用户,通过扮演 IAM 角色获得 AWS 访问权限

IAM 策略:权限的核心载体

什么是策略?

策略是 IAM 中定义权限的 JSON 文档,指定了“允许或拒绝哪些操作,在哪些资源上,在什么条件下”。当你把策略“附加”给用户、组或角色时,它们就获得了相应的权限。

策略的组成部分

一个典型的 IAM 策略 JSON 包含以下元素:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example-bucket",
      "Condition": {
        "IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
      }
    }
  ]
}
  • EffectAllowDeny。显式拒绝会覆盖任何允许。

  • Action:要允许或拒绝的具体 API 操作(如 ec2:RunInstancess3:GetObject)。可以使用 * 通配符匹配多个操作。

  • Resource:操作针对的资源,用 Amazon 资源名称(ARN)指定

  • Condition(可选):策略生效的条件,如 IP 地址范围、时间等

策略的类型

策略类型说明典型用途基于身份的策略附加到用户、组或角色日常权限管理基于资源的策略附加到资源(如 S3 存储桶)控制谁能访问该资源权限边界设置用户/角色的最大权限上限权限管控服务控制策略(SCP)在 AWS Organizations 中,对账户设置权限上限多账户统一管控

AWS 托管策略 vs 自定义策略

AWS 托管策略:AWS 预置、维护和更新的策略(如 AdministratorAccessReadOnlyAccessPowerUserAccess)。适合快速上手。

客户管理型策略:用户自己创建的策略。当 AWS 托管策略无法满足你的精准需求时使用。

对于新手,先用 AWS 托管策略起步,再通过 IAM Access Analyzer 等工具分析实际访问行为,逐步生成更精细的最小权限策略。

权限管理的两大黄金原则

原则一:最小权限原则

只授予完成特定任务所需的最小权限,绝不授予多余权限。

新手常见的误区是直接给用户 AdministratorAccess。更安全的做法是:

  • AWS 托管策略起步,选择最接近需求的方案

  • 使用 IAM Access Analyzer 分析访问行为,生成最小权限策略

  • 定期审查并删除未使用的权限

原则二:使用临时凭证

优先使用临时凭证(IAM 角色),尽量避免长期凭证(IAM 用户的访问密钥)。

  • 短期凭证自带有效期,泄露后风险窗口更小

  • 支持自动轮换,无需人工介入

  • 减少因访问密钥泄露导致的安全事件

图文教程:创建 IAM 用户并配置权限

下面演示如何在 AWS 管理控制台中创建一个 IAM 用户,并为其配置管理 S3 的权限。

第一步:进入 IAM 控制台

登录 AWS 管理控制台,在顶部搜索框输入 “IAM” 并点击进入。

第二步:创建用户

在 IAM 控制台左侧菜单点击 “用户”“创建用户”

  1. 指定用户详细信息

    • 用户名:输入 developer-s3

    • 如果你计划使用 IAM Identity Center,可以勾选“为用户提供管理控制台访问”

  2. 设置权限:选择 “直接附加策略”,然后搜索并勾选 AmazonS3FullAccess

  3. 可选:为用户设置密码策略和 MFA 要求

  4. 点击 “创建用户”

第三步:为开发者生成访问密钥(如需要)

如果开发者需要通过 CLI 或 SDK 调用 AWS,则需要生成访问密钥。

  1. 在用户详情页,选择 “安全凭证” 选项卡

  2. 点击 “创建访问密钥”

  3. 选择合适的用例(CLI、SDK 等)

  4. 保存好 Access Key IDSecret Access Key(这是唯一一次能看到 Secret 的机会)

⚠️ 安全提示:仅在特定场景下创建长期访问密钥。多数情况下,推荐使用 IAM Identity Center 或 IAM 角色获得临时凭证。

图文教程:创建 IAM 角色并授予 EC2 访问 S3 的权限

这是一个非常重要的使用场景:让 EC2 实例上的应用安全地访问 S3 存储桶

第一步:创建 IAM 角色

在 IAM 控制台左侧菜单点击 “角色”“创建角色”

第二步:选择信任实体

  1. 选择信任实体类型:选择 “AWS 服务”

  2. 选择使用场景:选择 “EC2”(表示这个角色是给 EC2 使用的)

  3. 点击 “下一步”

第三步:附加权限策略

搜索并勾选 AmazonS3ReadOnlyAccess,点击 “下一步”

第四步:完成创建

角色名称输入 EC2-S3-ReadOnly-Role,点击 “创建角色”

第五步:将角色附加给 EC2 实例

  1. 进入 EC2 控制台,选择一台实例,点击 “操作”“安全”“修改 IAM 角色”

  2. 从下拉列表中选择 EC2-S3-ReadOnly-Role

  3. 点击 “更新”

现在,运行在这台 EC2 实例上的应用,无需任何 Access Key,就能读取 S3 存储桶中的内容了——AWS SDK 会自动从实例元数据服务中获取临时凭证。

进阶:用条件策略实现更精细的控制

你可以在策略中加入 Condition,实现基于环境或上下文的权限控制。

示例:只允许从公司 IP 访问资源

json

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "ec2:*",
    "Resource": "*",
    "Condition": {
      "IpAddress": {
        "aws:SourceIp": "203.0.113.0/24"
      }
    }
  }
}

测试完成后,为了安全考虑:

  1. 删除测试用户:在 IAM 控制台“用户”中选中并删除

  2. 删除测试角色:在“角色”中删除

  3. 删除访问密钥:在用户的“安全凭证”中停用或删除


IAM 是 AWS 最基础也最重要的安全服务。掌握了用户、角色和策略这三大核心概念,以及最小权限和临时凭证两大原则,你就拥有了构建安全云上架构的根基。