AWS 账号注册完成后，很多用户的第一反应是直接用根账号登录控制台开始操作。
这个习惯在使用初期感知不到问题，但一旦团队成员增加、需要给程序配置访问权限、或者账号出现异常，权限管理不规范带来的风险就会集中暴露。
IAM（Identity and Access Management）是 AWS 账号权限体系的核心，它解决的不是某一个具体功能，而是”谁能对什么资源做什么操作”这个贯穿所有 AWS 使用场景的基础问题。
根账号不应该用于日常操作
根账号（Root Account）是注册 AWS 时创建的主账号，拥有账号内所有资源的最高权限，任何 IAM 策略都无法对它进行限制。
这意味着根账号凭证一旦泄露，攻击者对账号内的所有资源拥有完全控制权，且没有任何权限层面的防护手段可以阻止损失扩大。
AWS 官方明确建议根账号只用于以下几种操作：
- 开启根账号 MFA（多因素认证）
- 创建第一个具有管理员权限的 IAM 用户
- 管理账单设置和付款方式
- 关闭 AWS 账号
日常操作——创建 EC2 实例、配置 S3、管理 RDS——都应该通过 IAM 用户或角色进行，根账号应该”锁起来”只在必要时使用。
关于 AWS 账号的初始配置步骤，可以参考 AWS 账号注册流程 。
根账号的基本保护措施：
- 立即开启 MFA，根账号不开 MFA 是最常见的安全漏洞
- 不为根账号创建 Access Key，根账号不应用于任何程序化访问
- 不与任何团队成员共享根账号凭证
- 定期检查根账号的登录记录，发现异常立即处理
IAM 的四个核心概念
IAM 的权限体系由四个元素构成：User（用户）、Group（用户组）、Role（角色）和 Policy（策略）。
四者的关系是：Policy 定义了”能做什么”，Policy 附加在 User、Group 或 Role 上，决定对应主体的权限范围。
| 概念 | 代表什么 | 主要用途 | 有固定凭证吗 |
| User | 具体的人或应用程序 | 登录控制台 / 使用 CLI | 有（密码 + Access Key） |
| Group | 用户集合 | 批量分配权限 | 无 |
| Role | 可被扮演的权限集合 | 服务间授权 / 跨账号访问 | 无（临时凭证） |
| Policy | 权限规则文档 | 定义允许 / 拒绝的操作 | — |
User 和 Group：管理真实的人
IAM User 代表一个具体的身份，拥有独立的控制台登录密码和程序化访问的 Access Key。
正确的权限分配方式是通过 Group 而不是直接给每个 User 单独挂策略——当团队成员变动时，只需调整 Group 成员关系，不需要逐一修改每个用户的权限配置。
常见的 Group 划分方式：
- Developers： EC2、S3、Lambda 的完整操作权限，不含账单管理和 IAM 管理
- Ops： CloudWatch 监控、日志查看、实例重启等运维操作权限
- ReadOnly： 全账号只读权限，适合审计人员或财务人员
Role：程序和服务之间的权限桥梁
IAM Role 没有固定的账号密码或 Access Key，而是在被”扮演”时通过 STS（Security Token Service）生成临时凭证，凭证有有效期，到期自动失效。以下场景应该用 Role，而不是创建 User：
- EC2 实例需要访问 S3、DynamoDB 或其他 AWS 服务
- Lambda 函数需要执行对其他 AWS 资源的操作
- 跨账号访问：A 账号的用户需要操作 B 账号的资源
- CI/CD 工具或第三方服务需要操作 AWS 资源
Policy：定义权限范围的规则文档
Policy 分为两类：AWS 托管策略是 AWS 预定义的常用权限集合，可以直接附加使用；客户托管策略是根据业务需求自定义的权限规则，适合精确控制权限范围。
常用的 AWS 托管策略：
- AdministratorAccess： 完整管理员权限，仅给需要管理整个账号的少数用户
- PowerUserAccess： 除 IAM 管理外的完整权限，适合高级开发者
- ReadOnlyAccess： 全账号只读权限，适合审计用户
- 服务专属策略： 如 AmazonS3FullAccess、AmazonEC2ReadOnlyAccess，按服务粒度授权
User vs Role：什么时候该用哪个
判断逻辑只有一条：真实的人用 User，程序和服务用 Role。
这个原则在实际操作中经常被违背——最常见的错误是给 EC2 实例创建一个专用的 IAM User，再把它的 Access Key 写到服务器配置文件里。
为什么不应该在 EC2 上硬写 Access Key
将 Access Key 直接写在代码、配置文件或环境变量里，是 AWS 账号安全事故最常见的来源之一。
Access Key 一旦随代码误提交到 GitHub 或泄露给第三方，攻击者可以立即用它操作账号内所有授权资源，在你发现之前可能已经产生大量费用或造成数据损失。
正确的做法是给 EC2 实例关联 IAM Role：EC2 实例详情页 → 操作 → 安全 → 修改 IAM 角色，选择预先创建好的 Role。
关联 Role 后，实例上运行的应用程序通过 Instance Metadata Service 自动获取临时凭证，凭证定期自动轮换，完全不需要在代码里存储任何静态密钥。
Policy 怎么写：最小权限原则的实际落地
从必要权限开始，而不是从宽泛权限收紧
最小权限原则的核心逻辑是：先明确这个 User 或 Role 需要完成什么任务，只授予完成这些任务所需的最小权限。实际落地步骤：
- 从服务专属的只读策略开始，再根据实际操作需求逐步添加写入权限
- 使用 AWS Access Analyzer 分析现有权限的实际使用情况，识别从未被使用的权限并移除
- Resource 字段尽量指定具体的资源 ARN，避免使用通配符 * 授权所有资源
- 定期审查权限，删除不再需要的 User、过期的 Access Key 和闲置的 Role
自定义 Policy 的基本结构
Policy 是 JSON 格式的文档，由一个或多个 Statement 组成。每个 Statement 包含三个核心字段：Effect（Allow 或 Deny）、Action（操作名称）、Resource（资源的 ARN）。以下是一个只允许对特定 S3 存储桶进行读写操作的策略示例：
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [“s3:GetObject”, “s3:PutObject”],
“Resource”: “arn:aws:s3:::my-bucket/*”
}
]
}
Deny 的优先级高于 Allow：如果同一个 User 同时被 Allow 和 Deny 覆盖了同一个操作，Deny 始终生效，无论 Allow 在哪个 Policy 里配置。在排查权限问题时，这一点经常被忽略。
IAM 安全实践
必须开启 MFA 的几个账号
MFA 是账号权限体系的基础安全配置，以下账号不开 MFA 等同于大门没有上锁：
- 根账号：无条件必须，任何理由都不应例外
- 具有 AdministratorAccess 或 IAM 完整管理权限的 IAM 用户：必须开启
- 所有有控制台登录权限的 IAM 用户：强烈建议
可以通过 IAM 条件策略强制 MFA：要求未开启 MFA 的用户登录控制台后无法执行除绑定 MFA 以外的任何操作，直到完成 MFA 配置为止。这个策略对强制团队统一安全规范非常有效。
Access Key 的管理规范
Access Key 一旦生成就需要纳入管理流程，以下几点是企业账号中最常见的安全漏洞来源：
- 不使用的 Access Key 应立即禁用或删除，不要留着”以后可能用到”
- Access Key 不能出现在代码仓库、配置文件或任何日志文件中
- 定期运行 Credential Report（IAM 控制台 → 凭证报告），找出超过 90 天未轮换的 Key
- 生产环境的程序服务应完全使用 IAM Role，从根源上消除 Access Key 泄露风险
AWS 账号的整体安全配置，包括网络层防护和 DDoS 防御，可以结合 AWS 服务器安全防护教程 一起参考。
常见 IAM 权限报错排查
IAM 的权限报错通常有几种固定模式，每种对应不同的排查方向：
- “User is not authorized to perform: xxx”： 附加在该 User 或 Role 上的 Policy 里缺少对应的 Action，检查所有附加的策略，确认是否包含报错中的具体操作名称
- “Access Denied”： 优先检查是否存在显式 Deny 语句覆盖了 Allow；其次确认 Policy 是否已正确附加到对应的 User 或 Role
- EC2 无法访问 S3 或其他服务： 检查 EC2 实例是否已关联包含对应服务权限的 IAM Role，而不是依赖静态 Access Key
- 跨账号访问失败： 检查目标账号 Role 的 Trust Policy 是否允许来源账号的 Principal，两边都需要正确配置
AWS 提供 IAM Policy Simulator 工具（控制台搜索 “Policy Simulator”），可以模拟特定 User 或 Role 执行特定操作时的权限判断结果，无需反复修改策略再实际测试，是排查复杂权限问题最直接的方法。
在企业账号环境下，权限规划的复杂程度和个人账号有本质区别。
关于企业账号在权限配置、费用控制和稳定性管理上与个人账号的具体差别，可以参考 AWS 企业账号 vs 个人账号
