IAM 中的安全最佳实践 - AWS Identity and Access Management

IAM 中的安全最佳实践

AWS Identity and Access Management 最佳实践已于 2022 年 7 月 14 日更新。

为了帮助您确保 AWS 资源的安全,请遵循 AWS Identity and Access Management(IAM)的最佳实践。

要求人类用户使用带有身份提供商的联合身份验证才能使用临时凭证访问 AWS

人类用户,也称为人类身份,是应用程序的人员、管理员、开发人员、操作员和使用者。他们必须有身份才能访问您的 AWS 环境和应用程序。作为组织成员的人类用户也称为员工身份。人类用户也可以是您与之协作以及与您的 AWS 资源交互的外部用户。他们可以通过 Web 浏览器、客户端应用程序、移动应用程序或交互式命令行工具执行此操作。

请要求您的人类用户在访问 AWS 时使用临时证书。您可以使用身份提供商来以担任角色的形式提供为人类用户对 AWS 账户的联合访问权限,这将提供临时证书。对于集中式访问权限管理,我们建议使用 AWS IAM Identity Center (successor to AWS Single Sign-On)(IAM Identity Center)来管理对您账户的访问权限以及这些账户中的其他权限。您可以使用 IAM Identity Center 管理您的用户身份,或者从外部身份提供者管理 IAM Identity Center 中用户身份的访问权限。有关更多信息,请参阅《AWS IAM Identity Center (successor to AWS Single Sign-On) 用户指南》中的什么是 AWS IAM Identity Center (successor to AWS Single Sign-On)

有关 角色的更多信息,请参阅角色术语和概念

要求工作负载使用具有 IAM 角色的临时证书访问 AWS

工作负载是一系列资源和代码,它们可提供商业价值,如应用程序或后端过程。您的工作负载可能包含应用程序、操作工具和组件,它们需要身份才能向 AWS 服务 发送请求,例如请求读取数据。这些身份包括运行在您的 AWS 环境(例如 Amazon EC2 实例或 AWS Lambda 函数)中运行的计算机。

您还可以为需要访问权限的外部团体管理计算机身份。要为计算机身份授予访问权限,您可以使用 IAM 角色。IAM 角色具有特定的权限并可通过使用带有角色会话的临时安全凭证提供访问 AWS 的方法。此外,您还可以拥有位于 AWS 以外且需要访问您的 AWS 环境的计算机。对于在 AWS 外部运行的计算机,您可以使用 AWS Identity and Access Management Roles Anywhere。有关 角色的更多信息,请参阅IAM 角色。有关如何使用角色跨 AWS 账户 委派访问权限的详情,请参阅 IAM 教程:使用 IAM 角色委托跨 AWS 账户的访问权限

需要多重身份验证(MFA)

我们建议对访问您 AWS 资源的人类用户和工作负载使用 IAM 角色,以便他们使用临时证书。但是,如果您的账户中需要 IAM 或根用户,则需要使用 MFA 来提高安全性。启用 MFA 后,用户便拥有了一部可生成身份验证质询响应的设备。各个用户的凭证和设备生成的响应是完成登录过程所必需的。有关更多信息,请参阅在 AWS 中使用多重身份验证 (MFA)

如果您使用 IAM Identity Center 来对人类用户进行集中访问管理,则当您的身份源配置了 IAM Identity Center 身份存储、AWS Managed Microsoft AD 或 AD Connector 时,您可以使用 IAM Identity Center MFA 功能。有关 IAM Identity Center 中的 MFA 的更多信息,请参阅《AWS IAM Identity Center (successor to AWS Single Sign-On) 用户指南》中的多重身份验证

对于需要长期凭证的使用场景,请定期轮换访问密钥

在可能的情况下,我们建议使用临时凭证,而不是创建访问密钥等长期凭证。但是,对于需要具有编程访问权限和长期凭证的 IAM 用户情形,我们建议您轮换访问密钥。定期轮换长期凭证有助于您熟悉该流程。这在您遇到必须轮换凭证的情况(例如员工离开公司时)下非常有用。我们建议您使用 IAM 访问上次使用的信息来安全地轮换和移除访问密钥。有关更多信息,请参阅轮换访问密钥

在 AWS 中,有一些特定的使用场景需要带有 IAM 用户的长期凭证。部分使用场景包括:

  • 无法使用 IAM 角色的编程用例 – 您可以从需要访问 AWS 的位置运行代码。在某些应用场景中,您无法使用 IAM 角色提供临时凭证,例如 WordPress 插件。在这些情况下,请使用该代码的 IAM 用户长期访问密钥对 AWS 进行身份验证。

  • 第三方 AWS 客户端 – 如果您正在使用的工具不支持访问 IAM Identity Center,如不在 AWS 上托管的第三方 AWS 客户端或供应商,请使用 IAM 用户长期访问密钥。

  • AWS CodeCommit 访问 – 如果您正在使用 CodeCommit 来存储您的代码,则可以使用具有 SSH 密钥或服务特定凭证的 IAM 用户对 CodeCommit 进行存储库身份验证。我们建议您除了使用 IAM Identity Center 中的用户进行普通身份验证之外,再执行此操作。IAM Identity Center 中的用户是您的员工队伍中需要访问您的 AWS 账户或您的云应用程序的人员。要在不配置 IAM 用户的情况下授予用户访问您 CodeCommit 存储库的权限,您可以配置 git-remote-codecommit 实用工具。有关 IAM 和 CodeCommit 的更多信息,请参阅 将 IAM 与 CodeCommit 结合使用:Git 凭证、SSH 密钥和 AWS 访问密钥。有关配置 git-remote-codecommit 实用工具的更多信息,请参阅《AWS CodeCommit 用户指南》中的连接到具有轮换凭证的 AWS CodeCommit 存储库

  • Amazon Keyspaces (for Apache Cassandra) access(Amazon Keyspaces(Apache Cassandra 兼容)访问)– 在您无法使用 IAM Identity Center 中的用户的情况下,如出于测试 Cassandra 兼容性的目的,您可以使用具有服务特定凭证的 IAM 用户向 Amazon Keyspaces 进行身份验证。IAM Identity Center 中的用户是您的员工队伍中需要访问您的 AWS 账户或您的云应用程序的人员。您还可以使用临时凭证连接到 Amazon Keyspaces。有关更多信息,请参阅《Amazon Keyspaces(Apache Cassandra 兼容)开发人员指南》中的使用临时凭证连接到使用 IAM 角色和 SigV4 插件的 Amazon Keyspaces

保护您的根用户凭证,不要将其用于日常任务

在创建 AWS 账户 时,您将创建根用户名和密码,以登录 AWS Management Console。请像保护其他敏感个人信息一样保护您的根用户凭证。您可以通过为根用户凭证配置 MFA 来完成此操作。我们不建议您为根用户生成访问密钥,因为它们允许完全访问您的所有 AWS 服务 资源,包括您的账单信息。请不要将根用户用于日常任务。仅将根用户用于完成仅限根用户开展的任务。有关这些任务的完整列表,请参阅《AWS 一般参考》中的需要根用户凭证的任务。有关更多信息,请参阅《AWS Account Management 用户指南》中的保护账户根用户的最佳实践

应用最低权限许可

在使用 IAM policy 设置权限时,请仅授予执行任务所需的许可。为此,您可以定义在特定条件下可以对特定资源执行的操作,也称为最低权限许可。在探索工作负载或使用场景所需的权限时,您可以从较广泛的权限开始。随着使用场景逐渐成熟,您可以努力减少授予许可,直至达到最低权限的标准。有关使用 IAM 应用权限的更多信息,请参阅 IAM 中的策略和权限。

AWS 托管策略及转向最低权限许可入门

要开始向用户和工作负载授予权限,请使用 AWS 托管策略来为许多常见使用场景授予权限。您可以在 AWS 账户 中找到这些策略。请记住,AWS 托管策略可能不会为您的特定使用场景授予最低权限许可,因为它们可供所有 AWS 客户使用。因此,我们建议通过定义特定于您的使用场景的客户管理型策略来减少许可。有关更多信息,请参阅AWS托管策略。有关专为特定任务函数制定的 AWS 托管策略的更多信息,请参阅 工作职能的 AWS 托管策略

使用 IAM Access Analyzer 根据访问活动生成最低权限策略

如果仅授予执行任务所需的许可,您可以根据记录在 AWS CloudTrail 中的访问活动生成策略。IAM Access Analyzer 会分析您的 IAM 角色使用的服务和操作,然后生成您可以使用的精细策略。测试每个生成的策略后,可以将该策略部署到生产环境中。这可确保您仅向工作负载授予所需的权限。有关策略生成的更多信息,请参阅 IAM Access Analyzer 策略生成

定期查看并移除未使用的用户、角色、权限、策略和凭证

您的 AWS 账户 中可能存在不再需要的 IAM 用户、角色、许可、策略或凭证。IAM 提供了上次访问的信息来帮助您识别不再需要的用户、角色、许可、策略和凭证,以便您将其删除。这有助于减少必须监控的用户、角色、许可、策略和凭证的数量。您可以使用此信息优化 IAM policy 以更好地遵循最低权限许可。有关更多信息,请参阅使用上次访问的信息优化 AWS 中的权限

使用 IAM policy 中的条件进一步限制访问权限

您可以指定策略语句在何种条件下生效。这样,您就可以授予对操作和资源的访问权限,但前提是访问请求满足特定条件。例如,您可以编写策略条件来指定必须使用 SSL 发送所有请求。您也可以使用条件来授予对服务操作的访问权限,但前提是它们是通过特定的 AWS 服务 使用的,例如 AWS CloudFormation。有关更多信息,请参阅IAM JSON 策略元素:Condition

使用 IAM Acess Analyzer 验证对资源的公共和跨账户存取

在 AWS 中授予公共或跨账户存取许可之前,我们建议您验证是否需要此类访问权限。您可以使用 IAM Access Analyzer 来帮助您预览和分析对受支持资源类型的公共和跨账户存取。您可以通过查看 IAM Access Analyzer 生成的结果来完成此操作。这些结果可帮助您验证资源访问控制是否授予了期望的访问权限。此外,在更新公共和跨账户权限时,您可以在对资源部署新的访问控制之前验证更改的效果。IAM Access Analyzer 还会持续监控受支持的资源类型,并为允许公共或跨账户存取的资源生成结果。有关更多信息,请参阅使用 IAM Access Analyzer API 预览访问权限

使用 IAM Access Analyzer 验证您的 IAM policy,以确保许可的安全性和功能性

验证您创建的策略以确保它们符合 IAM policy 语言(JSON)和 IAM 最佳实践。您可以使用 IAM Access Analyzer 策略验证来验证您的策略。IAM Access Analyzer 提供 100 多项策略检查和可操作的建议,以帮助您制定安全且功能性强的策略。在控制台中创作新策略或编辑现有策略时,IAM Access Analyzer 会提供一些建议,帮助您在保存策略之前对其进行优化和验证。此外,我们还建议您查看和验证所有现有策略。有关更多信息,请参阅 IAM Acess Analyzer 策略验证。有关 IAM Access Analyzer 提供的策略检查的更多信息,请参阅 IAM Access Analyzer 策略检查参考

跨多个账户建立许可防护机制

在扩展工作负载时,请使用由 AWS Organizations 托管的多个账户将工作负载分离。建议您使用 Organizations 服务控制策略(SCP)建立权限防护机制,以控制账户中所有 IAM 用户和角色的访问许可。SCP 是一种组织策略,可用于在 AWS 组织、OU 或账户级别管理组织中的权限。您建立的许可防护机制适用于账户中涵盖的所有用户和角色。然而,单凭 SCP 不足以授予您组织中的账户许可。要实现此目标,管理员仍然必须将基于身份或基于资源的策略附加到 IAM 用户、IAM 角色或者您账户中的资源。有关更多信息,请参阅 AWS Organizations、账户和 IAM 防护机制

使用许可边界在账户内委派权限管理

在某些场景中,您可能需要将账户中的许可管理委派给其他用户。例如,您可以允许开发人员为其工作负载创建和管理角色。将许可委派给其他人时,请使用许可边界以设置您委派的最大许可数量。许可边界是一个高级功能,它使用托管策略设置基于身份的策略以为 IAM 角色授予的最大许可。许可边界自己不授予访问权限。有关更多信息,请参阅IAM 实体的权限边界