12个AWS IAM安全最佳实践

AWS Identity and Access Management（IAM）是一个强大的工具集，用于管理对AWS资源的访问，但其配置和管理可能颇具挑战性。但是，通过遵守最佳实践，您可以保证您的 AWS 环境管理良好且安全。

1. 避免将 root 用户凭证用于日常任务

使用 AWS 账户的根用户不是一个好的做法，因为它对账户中的所有 AWS 资源具有不受限制的访问权限。这意味着，如果 root 用户的凭证被盗用，攻击者将完全控制该账户及其所有资源。

使用 root 用户还会使管理访问控制和监控账户内的活动变得困难。建议创建单个具有有限权限的IAM用户，并使用多重身份验证（MFA，稍后将详细介绍）来保护对该账户的访问。在为您的第一个IAM用户分配MFA后，请锁定您的根用户。

通过使用具有适当权限的 IAM 用户，您可以限制对账户中特定资源和活动的访问，从而降低未经授权访问或意外修改的风险。此外，可以根据需要轻松添加或删除 IAM 用户，从而更有效地管理访问控制。

2. 将权限附加到组而不是单个用户

IAM 组是一种同时管理多个用户权限的方法。可以将策略附加到组，然后可以将组分配给用户，而不是将策略直接附加到单个用户。

此方法允许同时更新一组用户的策略，从而简化了权限管理。它还减少了在将策略应用于单个用户时可能出现错误和不一致性的风险。

3. 以最低权限为目标

遵守最低权限原则对于确保 AWS 资源的安全性和正确管理至关重要。如果向用户或角色授予了太多权限，则可能导致他们访问不应访问的 AWS 资源，从而导致数据泄露或其他安全事件。

通过仅赋予用户和服务完成其任务所必需的权限，您可以最大程度地降低未经授权访问的风险，并防止对您的资源造成意外修改。这还可以帮助您遵守安全和数据保护方面的法规要求和行业最佳实践。

定期查看和更新权限以确保它们保持适当和必要非常重要。这可能涉及删除不再需要的权限，以及根据需要添加新权限。通过遵循最低权限原则并定期审查权限，您可以帮助确保 AWS 资源的正确管理和安全性。

4. 注重职责分离

创建为特定或有限任务授予权限的自定义角色是 IAM 最佳实践的一个重要方面。通过避免给予适用于多个任务的宽泛权限或角色，以及防止授予过多的访问权限，您可以最大程度地减少未经授权访问的风险，并防止对您的资源造成意外修改。

请务必根据职责明确区分角色，并根据用户或服务需要执行的特定任务分配权限。这可能涉及为特定应用程序、任务或团队创建角色，并相应地分配权限。通过这样做，您可以确保用户仅拥有执行其特定任务所需的权限，并能够有效防止未经授权的访问您的 AWS 资源。

建议的做法是，为每个函数分别创建一个专用角色，而不是创建一个囊括了每个函数所有可能权限的单一角色。此角色应仅包含完成其特定任务所需的权限，而不应包含更多权限。

有多个指南深入解释了 IAM 的基础知识，包括 AWS IAM 用户、角色和策略。这些指南全面概述了 IAM 及其关键组件，可以帮助您深入了解如何管理对 AWS 资源的访问。

5. 对 IAM 用户实施多重身份验证

为您的根用户或任何其他 IAM 用户启用多重身份验证 （MFA） 是保护您的 AWS 账户 的一个简单而关键的步骤。除了用户密码之外，MFA 还要求使用第二个因素，例如由身份验证器应用程序生成的代码或物理令牌，从而为您的账户增加一层额外的保护。

要为 IAM 用户启用 MFA，您可以导航到 IAM 控制台并按照提示设置 MFA。还可以通过制定专用策略来确保在整个AWS账户或组织中强制使用多因素身份验证（MFA）。

通过要求所有用户使用 MFA，您可以显著降低未经授权访问的风险，并保护您的 AWS 资源免受潜在威胁。请务必注意，MFA 应与其他安全最佳实践结合使用，例如定期检查和轮换访问密钥以及实施强密码策略。

您可以在 AWS 文档中找到有关如何创建策略的专用指南，以便用户在成功设置 MFA 之前能够管理自己的凭证，但不能管理任何其他凭证。

6.通过多账户环境和 AWS Organizations 利用 AWS 账户的自然安全边界

将多账户策略与 AWS Organizations 结合使用可以为管理 AWS 资源提供多种好处，包括提高安全性以及改进组织和管理。

每个AWS账户都拥有天然的安全边界，这意味着一个账户内的资源与另一个账户内的资源是相互隔离的。通过为不同的团队、应用程序或环境使用单独的账户，您可以降低未经授权访问或意外修改的风险，并限制安全事件或故障的潜在影响。

此外，使用多个账户可以更轻松地管理和组织您的 AWS 资源。您可以为每个账户分配单独的预算和账单信息，从而对支出进行更精细的控制。您还可以使用单独的账户将开发和测试环境与生产环境隔离开来，从而降低中断或冲突的风险。

AWS Organizations 提供了一个集中式管理控制台，用于管理多个账户，从而可以更轻松地设置和管理整个组织的策略、权限和资源。通过将多账户策略与 AWS Organizations 结合使用，您可以提高 AWS 资源的安全性、组织和管理。

7. 使用 AWS Identity Center 和联合身份验证

为了简化管理身份和访问 AWS 资源的过程，不建议直接在 AWS IAM 上设置用户。相反，AWS 建议使用专门的身份提供商 （IdP） 并依靠角色来分配对这些身份的访问权限。

IdP 是一种仅专注于管理身份的服务，可以通过联合身份验证在整个 AWS 组织中使用。虽然AWS Identity Center可以作为身份提供者（IdP）使用，但对于更大规模的环境而言，选择专门从事身份管理的第三方服务可能更为有利。

通过使用 IdP，您可以简化管理用户访问的过程并降低未经授权访问的风险。此外，AWS Identity Center 还可以促进单点登录 （SSO），使用户能够更轻松地访问多个应用程序、服务和 AWS 账户，而无需输入单独的凭证。

如果您正在处理一个小型项目，并且希望在没有专用外部身份提供商的情况下使用 IAM 用户，那么使用 AWS Identity Center 创建用户非常重要。这将确保您在将来需要时能够轻松地过渡到多账户策略，同时为您的用户提供单点登录的便利以及简化的多账户用户管理。

虽然在没有外部身份提供商的情况下使用 IAM 用户可能适用于小型项目，但必须考虑潜在风险和限制。使用外部身份提供商可以提供额外的安全和管理功能，并且对于更大或更复杂的项目来说可能是必需的。定期查看和更新您的 IAM 策略和配置，以确保它们始终适合您的需求，这一点非常重要。

8. 尽可能多地利用角色

IAM 角色是 IAM 中一个强大而灵活的概念，类似于 IAM 用户，但关键区别在于多个实体可以同时代入一个角色。这允许在没有长期访问凭证的情况下进行更多临时访问授权，从而提供一种授予权限的安全机制。

通过角色的信任策略以 Principal 身份授予权限，IAM 用户等身份可以代入该角色，从而启用安全的访问模式，例如将 IAM 用户保留在具有最低权限的账户中，并允许他们在单独的账户中代入角色。

9. 避免内联策略

内联策略是直接与 IAM 身份集成的策略，可用于确保只有该身份具有特定策略。

但是，广泛使用内联策略可能会导致管理上的困难，并且会阻碍在大量身份上实施统一策略配置和使用。对于复杂的分布式系统而言，将托管策略附加到身份上，对于集中进行更改管理和管理工作会更加有效。

10. 定期审核权限

定期审查 IAM 角色和组的权限对于维护组织资源的安全性至关重要。随着时间的推移，用户的访问需求可能会发生变化，并且可能会添加或删除新资源。

如果不定期审查和更新权限，用户可能会积累不必要的权限，这可能会增加数据泄露或其他安全事件的风险。此外，定期审核有助于识别任何配置错误的权限，例如过于宽松的策略或授予超出必要访问权限的角色。

通过定期审查 IAM 角色和组，组织可以确保用户拥有适当级别的访问权限，以便履行其工作职责，同时还可以最大限度地降低安全事件的风险。

11. 避免常见的 IAM 错误

除了前面提到的详细建议外，还有一些其他常见的 IAM 错误，这些错误在小型和大型项目中都经常遇到。其中包括：

• 无法使用 IAM 角色：将 AWS 服务用于工作负载时，使用具有自定义权限的角色至关重要。这可确保用户仅拥有执行特定任务所需的权限，并且 AWS 将处理临时凭证的颁发，以防止担心数据库密码泄漏。
• 不定期轮换访问密钥：如果您需要长期访问密钥，请务必定期轮换它们，以最大限度地降低意外泄漏的风险。这有助于防止对您的 AWS 资源进行未经授权的访问。
• 使用根用户执行日常任务：虽然使用 AWS 根用户执行日常任务可能很诱人，但最好避免这样做。root 用户具有广泛的权限，定期使用可能会有风险。相反，请使用具有适当权限的单个 IAM 用户。
• 未能使用 SCP：如果您在一个组织内使用多个账户，则通过服务控制策略 （SCP） 在整个组织中建立防护机制非常重要。服务控制策略（SCP）可以帮助确保用户仅拥有执行其特定任务所需的权限，从而有助于防止对您的AWS资源的未经授权访问。
• 不使用权限边界：IAM 的另一个高级功能是权限边界策略，它可以应用于角色。这些边界不会自行授予权限，但会限制可通过角色委派的最大权限。这有助于确保用户仅拥有执行其特定任务所需的权限，并有助于防止未经授权访问您的 AWS 资源。

虽然这个列表并非详尽无遗，但它是在IAM中实施最佳实践的一个宝贵起点。

12. 将您的 AWS 基础知识扩展到 IAM 之外

要成为一名成功的 DevOps 工程师，首先要了解 AWS IAM 的基础知识，这一点至关重要。AWS生态系统的这一核心组成部分，是管理对AWS资源访问的中央控制枢纽。但是，继续了解其他核心服务（如 Lambda、DynamoDB 和 ECS）也很重要。这些服务构成了许多成功组织和项目的支柱，掌握它们将帮助您在作为 DevOps 工程师的角色中脱颖而出。

如果您希望更熟悉 AWS 核心服务并学习如何为现实世界构建应用程序，您可能需要考虑加入 Sandro Volpicella 和我正在运营的双周新闻通讯。

要点

掌握 AWS IAM 是管理和保护 AWS 资源的关键组成部分。通过遵守最佳实践，您可以帮助确保您的 AWS 环境得到良好管理且安全。

• 避免将根用户凭证用于日常任务，因为根用户对账户中的所有 AWS 资源具有不受限制的访问权限。相反，请创建具有有限权限的单个 IAM 用户，并使用多重身份验证来保护对账户的访问。
• 通过仅授予用户和服务完成其任务所需的权限，以最低权限为目标。这有助于将未经授权访问的风险降至最低，并避免对您的资源造成意外修改。
• 通过创建为特定或有限任务授予权限的自定义角色来研究职责分离。通过避免应用于多个任务的广泛权限或角色，您可以帮助最大限度地降低未经授权访问的风险并防止意外修改您的资源。
• 通过多账户环境和 AWS Organizations 利用 AWS 账户 的自然安全边界。通过为不同的团队、应用程序或环境使用单独的账户，您可以降低未经授权访问或意外修改的风险，并限制安全事件或故障的潜在影响。
• 对 IAM 用户强制实施多重身份验证，为您的账户添加额外的保护层。这能够大幅度降低未经授权访问的风险，并为您的AWS资源提供抵御潜在威胁的保护。
• 尽可能多地利用角色来启用安全的访问模式，例如将 IAM 用户保留在具有最低权限的账户中，并允许他们在单独的账户中代入工作角色。
• 避免使用内联策略，因为它们可能难以管理，并且会阻止对大量身份强制实施同构策略配置和使用。附加到身份的托管策略对于在复杂的分布式系统中集中更改管理和管理更加有效。

通过遵循这些最佳实践，您可以帮助最大限度地降低未经授权访问的风险并防止对资源进行意外修改，从而确保 AWS 资源得到适当的管理和安全性。掌握AWS IAM至关重要，因为它对每个应用程序而言都是核心所在，值得投入时间去学习。

原文链接：https://spacelift.io/blog/aws-iam-best-practices