IAM (身份和访问管理)

什么是 IAM

IAM (Identity and Access Management，身份与访问管理) 是管理"谁"可以对"什么"执行"哪些操作"的系统总称。它以认证 (Authentication，身份验证) 和授权 (Authorization，权限授予) 两大核心功能为中心，控制对组织资源的访问。

在云环境中，IAM 的重要性尤为突出。与存在物理访问控制的本地环境不同，云资源可以通过互联网从任何地方访问，因此通过 IAM 实现的逻辑访问控制成为主要防线。一个 IAM 配置错误就可能使整个云环境面临风险。

最小权限原则与实现模式

IAM 设计中最重要的原则是"最小权限原则" (Principle of Least Privilege)。仅向用户和服务授予执行其任务所需的最小权限。

• RBAC（基于角色的访问控制）：根据职务定义角色，以角色为单位管理权限。定义"开发者"、"运维人员"、"审计员"等角色并赋予相应权限集，将用户分配到角色。比逐个用户分配权限更易管理
• ABAC（基于属性的访问控制）：根据标签、部门、项目等属性控制访问。例如，"带有 project=X 标签的用户只能访问带有相同标签的资源"这样的策略，无需为每个项目创建角色即可实现动态访问控制
• 即时访问 (JIT Access)：仅在需要时授予提升的权限，并在设定时间后自动撤销。最大限度地缩短高权限凭证存在的时间窗口，降低被入侵时的影响范围

云 IAM 设计模式

云环境中 IAM 设计的最佳实践包括：

• 封锁根账户：为云根账户（最高权限）配置 MFA，日常操作中不使用。即使是管理员也应使用独立的 IAM 用户或联合身份认证
• 服务间认证使用角色：服务间通信不使用长期有效的访问密钥。使用 IAM 角色（如 EC2 实例配置文件或 Lambda 执行角色）自动获取临时凭证
• 集中身份管理：在多账户环境中，使用 AWS IAM Identity Center（原 SSO）或 Azure AD 集中管理身份，通过跨账户角色承担进行访问。无需在每个账户中创建 IAM 用户
• 条件访问策略：在 IAM 策略中添加源 IP 限制、MFA 要求、时间限制等条件。例如，将生产环境访问限制为仅限办公室 IP 地址，增加额外的防御层

IAM 运维中常见的陷阱

IAM 不仅在设计时需要关注，在运维阶段也需要持续管理。

• 权限膨胀：反复因为"不工作就加权限"导致权限逐渐过度。故障排除时添加的权限在问题解决后必须删除
• 共享账户：多人共用一个账户无法追踪谁执行了什么操作。始终分配独立账户，通过审计日志追踪操作
• 过期凭证：离职员工或已停用系统的访问密钥和密码仍然有效。定期审计以识别和删除未使用的凭证
• 过于宽泛的策略：使用 Resource: "*" 或 Action: "*" 等通配符的策略授予的权限远超预期。始终指定具体的资源 ARN 和操作名称

常见误解

给管理员授予全部权限 (AdministratorAccess) 没有问题

即使是管理员也应仅授予日常工作所需的权限。如果拥有全部权限的账户被入侵，整个环境都将面临风险。推荐的做法是平时使用受限权限工作，仅在需要时临时提升权限。

IAM 策略一旦配置就不需要更改

随着组织架构变更、新服务引入和安全需求变化，IAM 策略需要持续审查。未使用的权限会扩大攻击面，定期审计和删除不必要的权限不可或缺。

相关术语