为什么先把 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:StartInstances；Resource 表示作用于哪些资源；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 用户组、角色和策略。权限越早规范，后续扩展到更多服务、更多成员和更多项目时，账户管理就越可控。