比较 IAM 用户和组

AWS 身份和访问管理（IAM）是一项用于控制账户中谁可以执行什么操作的服务。它最基本的两个构建模块是用户和组。用户是与人员或应用程序关联的永久身份，而组只是一个用于将用户集中在一起的容器，使这些用户共享相同的权限。理解二者的区别，是掌握考试其他内容的基础。

IAM 用户是在账户内具有唯一名称的长期身份。它可以拥有两类凭证：

• 用于通过 Web 登录的控制台密码。
• 用于以编程方式调用 API 和 CLI 的访问密钥（访问密钥 ID 和秘密访问密钥）。

由于这些凭证的有效期很长，AWS 会将其视为较高风险。最佳实践是优先使用角色和临时凭证，而不是创建许多拥有永久密钥的用户。

IAM 组是通过附加策略共享权限的用户集合。组可以使访问管理实现规模化：与其将同一策略分别附加给十名开发人员，不如将策略一次性附加给“Developers”组，再将这些用户加入该组。考试要求掌握的要点包括：

• 组没有凭证，也不能在策略中充当主体。
• 一个用户可以属于多个组。
• 组不能嵌套在其他组中。

用户发出请求时，IAM 会组合所有适用的策略：直接附加到用户的策略，以及附加到该用户所属每个组的策略。最终结果是所有允许操作的并集，除非任何位置出现显式拒绝。这意味着组成员身份只会增加权限，不会减少权限，除非存在显式拒绝语句。

按用户管理权限容易产生配置漂移：随着时间推移，每个用户都会积累一组略有不同且难以审核的策略。组可以集中管理权限，使对单个策略的更改一致地应用于某个角色中的所有人。对于审核员而言，列出“Admins”组中的成员，比逐一检查几十个用户要容易得多。

您可以通过 CLI 检查成员关系，以审核哪些人拥有提升后的访问权限。下面的命令会列出组中的每个用户，这是响应过度授权访问发现结果时通常采取的第一步。

不要将 IAM 用户与根用户混淆。根用户是在账户创建时生成的账户所有者身份，拥有无法通过 IAM 策略限制的无限制访问权限。AWS 强烈建议您妥善封存根凭证，为其启用多因素身份验证（MFA），并且绝不要将其用于日常工作。请改为创建独立的 IAM 用户，或更好地使用联合身份。

每个 IAM 用户都应启用 MFA，除了密码之外，还需要硬件密钥或身份验证器应用等第二重身份验证因素。您可以通过 aws:MultiFactorAuthPresent 等策略条件强制执行 MFA。考试经常测试如何使用 MFA 保护删除资源或更改安全设置等敏感操作。

一个常见错误是为运行在 EC2（Elastic Compute Cloud）上的应用程序创建带有静态访问密钥的 IAM 用户。这样会嵌入可能泄露的长期密钥。安全做法是将一个 IAM 角色附加到实例上，我们将在下一节介绍这一点。对于人工团队，优先使用 IAM Identity Center 联合身份验证，而不是单独管理用户。

IAM 凭证报告是一个可下载的 CSV 文件，其中列出了每个用户、其密码和访问密钥最后一次使用的时间，以及 MFA 是否处于启用状态。结合 IAM Access Analyzer 和最近访问数据，它可以帮助您找出过时的用户、未使用的密钥以及权限范围过大的组。定期审查是最小权限管理卫生的核心部分，也是考试重点。

当您需要为人员或旧版应用程序提供独立且经过凭证验证的身份时，请使用用户。请使用组来整齐地分配共享权限，避免每个用户的配置逐渐产生差异。在现代设计中，您应尽量完全减少长期存在的用户，依靠角色为工作负载提供身份，并通过联合身份验证为人员提供访问。用户和组仍然是必不可少的术语，但它们只是起点，而不是终点。

测试您对用户和组的理解。

您了解到，IAM 用户是具有长期凭证的身份，而 IAM 组是无凭证的容器，用于将用户归在一起以共享策略。权限是用户策略和组策略的并集，组不能嵌套，并且应通过 MFA 将根用户妥善锁定。对于工作负载，请优先使用角色；对于人员，请使用联合身份验证，以避免长期密钥和配置漂移。