如果你已经用过 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"}
}
}
]
}Effect:
Allow或Deny。显式拒绝会覆盖任何允许。Action:要允许或拒绝的具体 API 操作(如
ec2:RunInstances、s3:GetObject)。可以使用*通配符匹配多个操作。Resource:操作针对的资源,用 Amazon 资源名称(ARN)指定
Condition(可选):策略生效的条件,如 IP 地址范围、时间等
策略的类型
策略类型说明典型用途基于身份的策略附加到用户、组或角色日常权限管理基于资源的策略附加到资源(如 S3 存储桶)控制谁能访问该资源权限边界设置用户/角色的最大权限上限权限管控服务控制策略(SCP)在 AWS Organizations 中,对账户设置权限上限多账户统一管控
AWS 托管策略 vs 自定义策略
AWS 托管策略:AWS 预置、维护和更新的策略(如 AdministratorAccess、ReadOnlyAccess、PowerUserAccess)。适合快速上手。
客户管理型策略:用户自己创建的策略。当 AWS 托管策略无法满足你的精准需求时使用。
对于新手,先用 AWS 托管策略起步,再通过 IAM Access Analyzer 等工具分析实际访问行为,逐步生成更精细的最小权限策略。
权限管理的两大黄金原则
原则一:最小权限原则
只授予完成特定任务所需的最小权限,绝不授予多余权限。
新手常见的误区是直接给用户 AdministratorAccess。更安全的做法是:
从 AWS 托管策略起步,选择最接近需求的方案
使用 IAM Access Analyzer 分析访问行为,生成最小权限策略
定期审查并删除未使用的权限
原则二:使用临时凭证
优先使用临时凭证(IAM 角色),尽量避免长期凭证(IAM 用户的访问密钥)。
短期凭证自带有效期,泄露后风险窗口更小
支持自动轮换,无需人工介入
减少因访问密钥泄露导致的安全事件
图文教程:创建 IAM 用户并配置权限
下面演示如何在 AWS 管理控制台中创建一个 IAM 用户,并为其配置管理 S3 的权限。
第一步:进入 IAM 控制台
登录 AWS 管理控制台,在顶部搜索框输入 “IAM” 并点击进入。
第二步:创建用户
在 IAM 控制台左侧菜单点击 “用户” → “创建用户”。
指定用户详细信息:
用户名:输入
developer-s3如果你计划使用 IAM Identity Center,可以勾选“为用户提供管理控制台访问”
设置权限:选择 “直接附加策略”,然后搜索并勾选
AmazonS3FullAccess可选:为用户设置密码策略和 MFA 要求
点击 “创建用户”
第三步:为开发者生成访问密钥(如需要)
如果开发者需要通过 CLI 或 SDK 调用 AWS,则需要生成访问密钥。
在用户详情页,选择 “安全凭证” 选项卡
点击 “创建访问密钥”
选择合适的用例(CLI、SDK 等)
保存好
Access Key ID和Secret Access Key(这是唯一一次能看到 Secret 的机会)
⚠️ 安全提示:仅在特定场景下创建长期访问密钥。多数情况下,推荐使用 IAM Identity Center 或 IAM 角色获得临时凭证。
图文教程:创建 IAM 角色并授予 EC2 访问 S3 的权限
这是一个非常重要的使用场景:让 EC2 实例上的应用安全地访问 S3 存储桶。
第一步:创建 IAM 角色
在 IAM 控制台左侧菜单点击 “角色” → “创建角色”。
第二步:选择信任实体
选择信任实体类型:选择 “AWS 服务”
选择使用场景:选择 “EC2”(表示这个角色是给 EC2 使用的)
点击 “下一步”
第三步:附加权限策略
搜索并勾选 AmazonS3ReadOnlyAccess,点击 “下一步”。
第四步:完成创建
角色名称输入 EC2-S3-ReadOnly-Role,点击 “创建角色”。
第五步:将角色附加给 EC2 实例
进入 EC2 控制台,选择一台实例,点击 “操作” → “安全” → “修改 IAM 角色”
从下拉列表中选择
EC2-S3-ReadOnly-Role点击 “更新”
现在,运行在这台 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"
}
}
}
}测试完成后,为了安全考虑:
删除测试用户:在 IAM 控制台“用户”中选中并删除
删除测试角色:在“角色”中删除
删除访问密钥:在用户的“安全凭证”中停用或删除
IAM 是 AWS 最基础也最重要的安全服务。掌握了用户、角色和策略这三大核心概念,以及最小权限和临时凭证两大原则,你就拥有了构建安全云上架构的根基。