为什么先把 IAM 权限设计清楚在 AWS 上开通 EC2、S3、RDS、CloudFront 等服务之前很多团队会先关注实例规格、区域、网络和预算但真正影响长期安全与协作效率的往往是 IAM 权限设计。IAM 是 AWS Identity and Access Management 的缩写用于管理谁可以访问哪些 AWS 资源以及可以执行哪些操作。对于采购者来说IAM 决定了财务、运维、开发和外部协作方之间的边界对于开发者来说IAM 决定了程序调用 API 时能否只拿到必要权限对于企业技术负责人来说IAM 是审计、合规和故障隔离的基础。权限过大会增加误删资源、泄露密钥、越权操作的风险权限过小又会让部署、排障和自动化流程频繁受阻。进化云面向 AWS 国际站账户注册、充值、代购和代理服务场景接触到的用户常见问题并不是单纯不会创建用户而是账户由多人使用后权限边界越来越模糊。因此本文不只讲按钮在哪里更强调如何围绕子账号、用户组、角色和最小权限建立一套可持续维护的 IAM 规则。先区分根用户、IAM 用户、用户组和角色AWS 账户创建完成后默认存在根用户。根用户拥有账户内所有权限并且可以执行一些高敏感操作例如修改账户级信息、关闭账户、管理部分账单与安全设置。根用户不应该用于日常开发、部署或资源管理。更稳妥的做法是为根用户启用多因素认证并将登录凭证妥善保存只在确有必要时使用。IAM 用户通常对应一个长期身份例如某位运维人员、财务人员或者在旧系统中使用访问密钥的程序。每个 IAM 用户可以设置控制台登录密码也可以生成访问密钥用于调用 API。需要注意的是访问密钥属于长期凭证一旦泄露风险会持续存在除非主动停用或删除。用户组用于把相同岗位或相同职责的人集中管理。例如可以建立 DevOps、Developer、FinanceReadOnly 等用户组再把策略附加到组而不是直接给每个用户逐一分配权限。这样人员入职、转岗、离职时只需要调整用户所属组权限治理更清晰。IAM 角色不是固定属于某个人的身份而是可被受信任主体临时扮演的身份。角色常用于 EC2 实例访问 S3、Lambda 访问 DynamoDB、跨账户运维、第三方工具接入等场景。角色通常依赖临时安全凭证比把长期访问密钥写进服务器或代码仓库更安全。AWS 权限判断的基本逻辑IAM 权限不是只看一条策略而是由多种策略共同决定。常见策略包括基于身份的策略、基于资源的策略、权限边界、服务控制策略以及会话策略。单个普通账户未启用 AWS Organizations 时最常见的是身份策略和资源策略。策略文档通常包含 Effect、Action、Resource 和 Condition。Effect 表示允许或拒绝Action 表示可以执行哪些操作例如 s3:GetObject 或 ec2:StartInstancesResource 表示作用于哪些资源Condition 用于增加条件约束例如限制来源 IP、要求使用 MFA、限定标签或区域。一个重要原则是显式拒绝优先级高于允许。也就是说即使某个用户在一条策略中被允许执行操作只要另一条适用策略明确拒绝该操作仍会被拒绝。理解这一点有助于排查为什么某些操作明明已经授权却仍然无法执行。在实际配置中不建议长期依赖 AdministratorAccess 这类全量权限。它适合初始搭建或紧急排障时由受控管理员使用但不适合作为开发、测试、财务、外包协作的默认权限。最小权限不是一次写完而是逐步收敛最小权限的目标是让身份只拥有完成工作所需的权限。这里的关键不是追求一开始就写出完美策略而是先用合理范围启动再根据实际访问记录逐步收敛。例如一个开发者只负责某个测试环境的 ECS、Lambda 或 S3 资源就不应该拥有全账户的 IAM 管理权限也不应该能删除生产环境数据库。可以通过资源 ARN、标签、区域和条件限制访问范围。对于需要查看账单但不需要管理资源的人员应优先使用只读或账单相关权限而不是给控制台管理员权限。实践中可以先按职责划分权限层级账户安全管理员负责 IAM、MFA、访问密钥和审计设置基础设施管理员负责 VPC、EC2、负载均衡和监控应用开发者负责指定服务和指定环境财务或采购人员负责账单查看、预算和成本分析外部协作方只获得项目所需的临时或受限权限。权限收敛需要记录和复盘。AWS 提供 IAM Access Analyzer、CloudTrail、服务最后访问时间等能力可帮助判断某个身份是否长期未使用某些权限。团队可以定期查看访问记录删除不再需要的策略、访问密钥和用户。子账号与用户组的设置建议很多用户会把 IAM 用户称为子账号。为了便于理解本文中的子账号主要指 IAM 用户或通过身份中心创建的个人登录身份。无论采用哪种方式都建议坚持一人一号不要多人共用同一个登录账号。共用账号会导致审计不清出现误操作时无法判断责任也不利于离职交接。创建子账号时应先判断该身份是否需要控制台登录、是否需要编程访问、是否需要长期存在。只需要临时协助的人不一定要创建长期用户只运行在 AWS 内部服务上的程序也更适合使用角色而不是为程序创建永久访问密钥。用户组适合按照岗位管理。例如开发组可拥有特定环境的只读和部署权限运维组可拥有网络、计算和监控权限财务组可查看账单与成本数据。不要把所有人员都放进一个管理员组也不要为了省事直接给每个用户附加大量独立策略。命名规范也很重要。建议在用户组和策略名称中体现环境、职责和权限级别例如 project-dev-deployer、billing-readonly、security-auditor。这样在权限审计时可以直接看出策略意图减少误判。什么时候应该使用 IAM 角色只要是程序、服务或跨账户访问场景都应优先考虑 IAM 角色。角色最大的优势是使用临时凭证不需要在代码、服务器、镜像或配置文件中长期保存访问密钥。例如EC2 实例需要读取 S3 中的部署包可以为 EC2 附加实例角色并让该角色只允许读取指定存储桶或指定前缀。Lambda 函数需要写入 CloudWatch Logs 和访问 DynamoDB也可以通过执行角色授予必要权限。这样即使实例或函数环境发生变更也不需要手工分发密钥。跨账户场景同样适合使用角色。例如企业有生产账户和测试账户运维人员可以从管理账户扮演目标账户中的受限角色而不是在每个账户中创建一套长期用户。对于第三方工具或服务接入也应尽量使用带外部 ID、条件约束和最小权限的角色并明确其访问范围。角色的信任策略与权限策略需要同时关注。信任策略决定谁可以扮演这个角色权限策略决定扮演后可以做什么。很多权限问题不是出在 Action 写错而是信任主体范围过大导致不该扮演的人也能获取角色权限。策略编写的实用方法写 IAM 策略时可以先从 AWS 托管策略理解服务权限再根据业务需求改为客户托管策略。AWS 托管策略由 AWS 维护适合快速了解某类权限范围客户托管策略由账户自行维护更适合精细控制。生产环境不建议长期使用过宽泛的托管策略来替代权限设计。策略中的 Resource 应尽量写到具体资源而不是全部使用星号。比如 S3 可以限制到具体 bucket 或对象前缀KMS 可以限制到指定密钥CloudWatch Logs 可以限制到特定日志组。对于某些服务或操作确实不支持资源级授权时再结合 Condition 控制区域、标签或请求条件。Condition 是最小权限的重要工具。常见做法包括要求敏感操作必须启用 MFA、限制只能在指定区域创建资源、要求资源带有特定标签、限制来源网络条件等。标签治理要提前规划例如统一使用 Environment、Project、Owner 等标签否则基于标签的权限会难以落地。策略变更前可以使用 IAM Policy Simulator 或 Access Analyzer 进行验证。对于重要生产权限建议先在测试环境验证再逐步应用到生产身份。不要在不理解影响范围的情况下直接修改管理员策略避免造成大面积访问失败。访问密钥与 MFA 的安全要点访问密钥是 AWS 安全事件中最常见的风险点之一。开发者不应把访问密钥写入 Git 仓库、镜像、前端代码、日志或共享文档。对于必须使用访问密钥的场景应设置密钥轮换流程并及时删除不再使用的旧密钥。更推荐的方式是使用角色、AWS CLI 的 SSO 登录、临时凭证或安全的密钥管理机制。CI/CD 系统如果需要访问 AWS也应尽量使用 OIDC 联邦或受限角色而不是在流水线变量中长期保存高权限访问密钥。MFA 应优先覆盖根用户和高权限 IAM 用户。对于能够修改 IAM、删除资源、访问账单或管理安全配置的身份建议通过条件策略要求 MFA。这样即使密码泄露攻击者也更难直接执行高风险操作。同时要关注凭证生命周期。人员离职、项目结束、外包合作终止时应停用或删除对应用户、访问密钥和角色信任关系。权限治理不是只在开户时做一次而是贯穿账户使用周期。采购、充值与代理服务场景下的权限边界使用 AWS 国际站账户注册、充值、折扣代理或产品代购服务时安全边界同样要提前明确。账户的业务资源、根用户凭证、IAM 管理权限和账单查看权限应区分管理避免因为充值或采购协作而扩大技术操作权限。如果企业需要由内部人员管理资源、由采购人员处理费用事项可以为采购角色配置账单查看和必要的成本管理权限而不是提供生产环境运维权限。若需要第三方协助完成账户相关操作应尽量通过受限 IAM 身份或明确的操作流程完成并在协作结束后检查权限、密钥和登录方式。对于通过进化云了解 AWS 国际站账户注册、充值或代购服务的用户建议在账户开始使用前同步规划 IAM谁保管根用户谁负责日常运维谁查看账单哪些系统需要角色访问哪些外部人员只允许临时协作。这样可以把账户采购流程和云上安全治理连接起来减少后续返工。尤其要避免把根用户直接交给多人使用或把 AdministratorAccess 作为所有协作的默认方案。即使只是短期排障也应在操作完成后回收权限并查看 CloudTrail 中的关键操作记录。一个可落地的 IAM 初始化清单第一步保护根用户。为根用户启用 MFA确认恢复邮箱和联系方式可靠避免用于日常登录。根用户凭证应由企业内部授权人员保管并建立使用审批或记录机制。第二步创建管理员身份。为少数可信管理员创建独立 IAM 用户或通过身份中心分配管理权限。管理员也应启用 MFA不建议多人共享同一管理员账号。第三步按职责建立用户组。至少区分安全管理、运维管理、开发部署、只读审计、账单查看等类别。每个用户加入对应组避免直接堆叠大量个人策略。第四步为 AWS 服务创建角色。EC2、Lambda、ECS、CodeBuild 等服务访问其他资源时优先使用角色。角色权限只覆盖所需资源不把长期密钥放入应用配置。第五步建立命名和标签规范。统一项目、环境、负责人等标签为后续按标签授权、成本分析和资源清理打基础。权限策略名称也应能反映用途。第六步开启审计与定期检查。使用 CloudTrail 记录账户活动定期检查访问密钥、未使用权限、高权限用户和异常登录。对于不再使用的身份和策略应及时清理。第七步形成变更流程。新增权限要说明目的、范围和期限临时权限要设置回收时间生产环境高风险权限要经过复核。流程不必复杂但必须可执行、可追溯。常见误区与修正方式误区一是把 IAM 用户等同于普通网站账号随意共享。修正方式是一人一号并用用户组集中授权。误区二是为了省事长期使用管理员权限。修正方式是按岗位拆分权限把管理员权限限定在少数安全负责人和必要场景。误区三是把访问密钥写进代码。修正方式是改用角色、临时凭证或安全的凭证管理方式并清理历史泄露风险。误区四是只控制用户不控制资源。修正方式是在 S3、KMS、SQS 等支持资源策略的服务中同步配置资源侧权限避免单边授权造成空档。误区五是创建权限后不复盘。修正方式是定期使用访问记录和审计日志评估权限是否仍然需要对不活跃用户和多余策略进行清理。总结把权限当作账户基础设施来管理AWS IAM 权限设置的核心不是记住某个菜单路径而是建立清晰的身份、职责和访问边界。根用户负责账户级兜底不参与日常操作IAM 用户或身份中心用于人员登录用户组用于岗位授权角色用于服务、程序和跨账户访问策略和条件用于落实最小权限。对于正在规划 AWS 国际站账户注册、充值、代购或代理服务的团队建议不要等资源上线后再补权限治理。账户交付、充值协作、账单查看、开发部署和运维管理应在一开始就分开设计。这样既能提升协作效率也能降低误操作和凭证泄露带来的风险。如果你正在梳理 AWS 账户开通、充值与权限分工可以先列出参与角色、所需服务、环境边界和预算管理方式再据此设计 IAM 用户组、角色和策略。权限越早规范后续扩展到更多服务、更多成员和更多项目时账户管理就越可控。