一家国内SaaS企业在AWS上运行了半年后，某天收到了一封来自AWS的异常账单邮件——单月账单突然从2000美元飙升到1.8万美元。
排查后发现：一名离职员工的账号没有及时删除，其AccessKey被泄露，黑客用这个密钥在多个区域批量启动了高性能GPU实例挖矿。
这次事故完全可以避免——如果他们当初正确配置了AWS IAM。
IAM（Identity and Access Management）是AWS账户安全的第一道防线，也是最容易被忽视的一道防线。
一、AWS IAM是什么？它解决什么问题？
AWS IAM是AWS提供的身份和访问管理服务，核心功能是控制谁能访问你的AWS资源，以及能做什么。
没有IAM的世界会发生什么：
- 所有人共用Root账号的用户名和密码
- 一个实习生有和CTO相同的权限
- 外部合作商访问你的S3桶时，顺便能看到所有RDS数据库
有了IAM之后，你可以精确控制：
- 谁（人员/系统）能访问
- 哪些AWS服务和资源
- 什么操作（读/写/删除/管理）
- 在什么条件下（IP限制/时间限制/MFA验证）
IAM是免费服务，不需要额外付费。
二、IAM的四个核心概念
在实操之前，必须先弄清楚IAM的基本组成：
1. IAM用户（User）
代表一个具体的人或应用程序。每个IAM用户有独立的登录凭证（用户名+密码，或AccessKey）。
适合场景：
- 给开发团队每个成员创建独立账号
- 给自动化脚本/CI/CD工具创建专属账号
2. IAM用户组（Group）
将多个用户归为一组，统一管理权限。给用户组分配策略，组内所有用户自动继承。
适合场景：
- 开发组、运维组、数据组分别赋予不同权限
- 新员工加入直接加入对应组，无需单独配置权限
3. IAM策略（Policy）
策略是权限规则的JSON文档，定义”允许或拒绝什么操作”。
AWS提供两类策略：
- AWS托管策略：AWS预置的常用策略，如 AdministratorAccess、ReadOnlyAccess
- 客户托管策略：你自己创建的自定义策略，更精细
4. IAM角色（Role）
角色是可以被”临时扮演”的权限身份，没有固定的用户名和密码。
适合场景：
- EC2实例需要访问S3（给EC2绑定角色，而不是在代码里写AccessKey）
- 跨账号访问（A账号的服务访问B账号的资源）
- 第三方服务（如GitHub Actions）部署到你的AWS账户
| 概念 | 类比 | 核心用途 |
|---|---|---|
| IAM用户 | 员工工牌 | 具体人员/系统的登录身份 |
| IAM用户组 | 部门 | 批量管理同类用户的权限 |
| IAM策略 | 权限清单 | 定义能做什么/不能做什么 |
| IAM角色 | 临时访客证 | AWS服务间/跨账号的临时权限 |
三、最小权限原则：IAM安全的核心思想
在配置任何IAM权限之前，必须记住一个原则：
最小权限原则（Principle of Least Privilege）
只给每个用户/角色/服务恰好够用的权限，不多给一分。
这意味着：
- 开发人员只需要访问开发环境的EC2和RDS，不需要生产环境权限
- 数据分析师只需要S3读取权限，不需要EC2启动权限
- Lambda函数只需要写DynamoDB的权限，不需要读S3
很多企业图省事，给所有人 AdministratorAccess 全管理员权限，这是最危险的做法。
四、实操配置：从零搭建安全的IAM体系
第一步：保护Root账号
Root账号是AWS账户的”最高权限”账号，一旦被盗，后果不可控。
Root账号安全三件事：
- 开启MFA（多因素认证）：在AWS控制台 → 安全凭证 → 激活MFA，绑定手机Authenticator App
- 不创建AccessKey：Root账号不要生成编程访问密钥
- 只用于账单管理：日常操作全部切换到IAM用户完成
第二步：创建管理员IAM用户
在IAM控制台创建一个管理员用户，用于日常运维，代替Root账号登录。
配置要点：
- 用户名建议用真实姓名或工号，如 admin-zhangsan
- 访问类型：勾选”AWS管理控制台访问”
- 权限策略：附加 AdministratorAccess（仅限真正的管理员）
- 同样为此用户开启MFA
以后登录AWS一律使用这个IAM用户，Root账号封存备用。
第三步：创建用户组并分配权限
按团队职能建立用户组，并为每组分配对应策略。
推荐的基础用户组配置：
| 用户组名称 | 适合人员 | 建议附加策略 |
|---|---|---|
| Developers | 开发工程师 | AmazonEC2FullAccess + AmazonS3FullAccess（限开发环境） |
| DataAnalysts | 数据分析师 | AmazonS3ReadOnlyAccess + AmazonAthenaFullAccess |
| DevOps | 运维工程师 | PowerUserAccess（排除IAM管理权限） |
| Billing | 财务/管理层 | AWSBillingReadOnlyAccess |
| ReadOnly | 审计/合规 | ReadOnlyAccess |
第四步：为EC2/Lambda配置IAM角色
这是最容易被遗漏的步骤，也是安全事故的高发点。
错误做法：在EC2实例的代码或配置文件里直接写入AccessKey ID和SecretKey。这些密钥一旦被提交到GitHub或泄露，攻击者可以立即使用。
正确做法：创建IAM角色并绑定到EC2实例。
具体步骤：
- 在IAM控制台 → 角色 → 创建角色
- 选择”AWS服务” → “EC2″作为信任实体
- 附加需要的策略（如AmazonS3ReadOnlyAccess）
- 给角色起名，如 ec2-s3-readonly-role
- 在EC2实例设置中，将此角色附加到实例
EC2实例上的代码通过实例元数据自动获取临时凭证，无需在代码中硬编码任何密钥。
第五步：创建自定义精细化策略
当AWS托管策略粒度不够细时，需要创建自定义策略。
一个典型场景：允许用户只读取特定S3桶，而不是所有S3桶。
自定义策略的核心要素包括四个字段：
- Effect：Allow（允许）或 Deny（拒绝）
- Action：具体的API操作，如 s3:GetObject、ec2:DescribeInstances
- Resource：具体资源的ARN（Amazon资源名称），支持通配符
- Condition（可选）：额外条件，如IP限制、MFA要求
以”只读特定S3桶”为例，策略逻辑是：允许执行 s3:GetObject 和 s3:ListBucket 两个操作，但将资源限定为特定桶的ARN，而不是所有S3资源。
五、IAM安全进阶：4个容易忽略的关键设置
设置密码策略
在IAM控制台 → 账户设置 → 密码策略，建议配置：
- 最小密码长度：12位以上
- 要求包含大写字母、小写字母、数字、特殊符号
- 密码有效期：90天
- 禁止重复使用最近5次密码
定期审查和轮换AccessKey
通过IAM的”凭证报告”功能，可以导出所有用户的AccessKey使用情况，包括：
- Key是否超过90天未轮换
- Key是否从未被使用（应立即删除）
- 用户上次登录时间（长期未登录可能需要禁用）
建议每季度做一次凭证审计。
启用AWS CloudTrail记录所有IAM操作
CloudTrail会记录账户内所有API调用，包括IAM配置变更、用户登录、资源访问等。
这是安全事故溯源的核心工具。发生异常时，可以精确定位是哪个用户/角色/服务在什么时间做了什么操作。
建议将CloudTrail日志同步到S3并开启加密存储，保留至少一年。
使用权限边界（Permission Boundary）
当你需要授权给下属管理员（如DevOps Leader）创建IAM用户，但又担心他创建的用户权限超过自己的权限时，可以使用”权限边界”功能。
权限边界定义了某个用户或角色最多能拥有的权限上限，即使策略里写了更高权限，实际执行时也受边界限制。
六、IAM常见问题排查
问题1：用户登录时提示”无权访问”
排查顺序：
- 检查用户是否被附加了策略（或所在用户组有策略）
- 检查资源ARN是否写对（很多人ARN写错）
- 检查是否有显式的Deny策略覆盖了Allow（Deny优先级更高）
问题2：EC2无法访问S3
最常见原因：EC2实例没有绑定IAM角色，或绑定的角色策略不包含S3权限。
问题3：跨账号访问失败
需要在两边都配置：被访问账号的资源策略中允许另一个账号的ARN，且访问方账号的用户/角色有假设目标角色的权限（sts:AssumeRole）。
写在最后
AWS IAM配置看似复杂，但核心逻辑其实很简单：最小权限、角色代替密钥、定期审计。
做到这三点，80%的云安全风险就可以规避。
开头那家差点损失近2万美元的企业，如果当时做到了”为每人创建独立IAM用户+离职立即删除账号”，这次事故完全不会发生。
云安全的代价，往往在疏忽的那一刻已经注定。
如果你正在搭建AWS环境，或者不确定现有IAM配置是否安全，欢迎联系 aws-oncloudai.com 的技术团队，我们提供免费的AWS账户安全评估服务。
本文由 aws-oncloudai.com 云架构团队原创，转载请注明来源。
