# IAM 的安全防御最佳实操
为了帮助您确保 AWS 资源的安全，请遵循 AWS Identity and Access Management（IAM）的这些最佳实践。
**Topics**
+ [要求人类用户使用带有身份提供商的联合身份验证才能使用临时凭证访问 AWS](#bp-users-federation-idp)
+ [要求工作负载使用具有 IAM 角色的临时凭证访问 AWS](#bp-workloads-use-roles)
+ [需要多重身份验证（MFA）](#enable-mfa-for-privileged-users)
+ [对于需要长期凭证的用例，应在需要时更新访问密钥](#update-access-keys)
+ [遵循最佳实践以保护根用户凭证](#lock-away-credentials)
+ [应用最低权限权限](#grant-least-privilege)
+ [AWS 托管策略及转向最低权限权限入门](#bp-use-aws-defined-policies)
+ [使用 IAM Access Analyzer 根据访问活动生成最低权限策略](#bp-gen-least-privilege-policies)
+ [定期查看并移除未使用的用户、角色、权限、策略和凭证](#remove-credentials)
+ [使用 IAM policy 中的条件进一步限制访问权限](#use-policy-conditions)
+ [使用 IAM Access Analyzer 验证对资源的公共和跨账户访问](#bp-preview-access)
+ [使用 IAM Access Analyzer 验证您的 IAM 策略，以确保权限的安全性和功能性](#best-practice-policy-validation)
+ [跨多个账户建立权限护栏机制](#bp-permissions-guardrails)
+ [使用权限边界在账户内委派权限管理](#bp-permissions-boundaries)
## 要求人类用户使用带有身份提供商的联合身份验证才能使用临时凭证访问 AWS
人类用户，也称为*人类身份*，是应用程序的人员、管理员、开发人员、操作员和使用者。他们必须有身份才能访问您的 AWS 环境和应用程序。作为组织成员的人类用户也称为*员工身份*。人类用户也可以是您与之协作以及与您的 AWS 资源交互的外部用户。他们可以通过 Web 浏览器、客户端应用程序、移动应用程序或交互式命令行工具执行此操作。
请要求您的人类用户在访问 AWS 时使用临时凭证。您可以使用身份提供程序来以代入角色的方式，为人类用户提供对 AWS 账户 的联合访问权限，这样将提供临时凭证。对于集中式访问权限管理，我们建议使用 [AWS IAM Identity Center（IAM Identity Center）](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)来管理对您账户的访问权限以及这些账户中的其他权限。您可以使用 IAM Identity Center 管理您的用户身份，或者从外部身份提供者管理 IAM Identity Center 中用户身份的访问权限。有关更多信息，请参阅*《AWS IAM Identity Center 用户指南》*中的[什么是 AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)。
有关角色的更多信息，请参阅 [角色术语和概念](id_roles.md#id_roles_terms-and-concepts)。
## 要求工作负载使用具有 IAM 角色的临时凭证访问 AWS
*工作负载*是一系列资源和代码，它们可提供商业价值，如应用程序或后端过程。您的工作负载可能包含应用程序、操作工具和组件，它们需要凭证才能向 AWS 服务 发送请求，例如请求从 Amazon S3 读取数据。
当您在 AWS 计算服务（例如 Amazon EC2 或 Lambda）上进行构建时，AWS 会向该计算资源提供 IAM 角色的临时凭证。使用 AWS SDK 编写的应用程序将发现并使用这些临时凭证来访问 AWS 资源，并且无需将 IAM 用户的长期凭证分配给在 AWS 上运行的工作负载。
在 AWS 外部运行的工作负载，例如您的本地服务器、来自其他云提供商的服务器或托管式持续集成和持续交付（CI/CD）平台，仍然可以使用临时凭证。但是，您需要将这些临时凭证提供给工作负载。以下是向工作负载提供临时凭证的方法：
+ 您可以使用 IAM Roles Anywhere 通过公有密钥基础设施（PKI）的 X.509 凭证为工作负载申请临时 AWS 凭证。
+ 您可以使用在 AWS 账户 内部配置的外部身份提供者（IdP）的 SAML 断言来调用 AWS AWS STS `AssumeRoleWithSAML` API，为工作负载请求临时 AWS 凭证。
+ 您可以调用 AWS AWS STS `AssumeRoleWithWebIdentity` API，使用在您的 AWS 账户 中配置的 IdP 的 JSON 网络令牌（JWT）为您的工作负载请求临时 AWS 凭证。
+ 您可以使用 AWS IoT Core 通过双向传输层安全 (MTLS) 身份验证向物联网设备请求临时 AWS 凭证。
有些 AWS 服务 还支持集成，以便为在 AWS 之外运行的工作负载提供临时凭证：
+ 借助 [Amazon Elastic Container Service（Amazon ECS）Anywhere](https://aws.amazon.com/ecs/anywhere/)，您可在自己的计算资源上运行 Amazon ECS 任务，并为在这些计算资源上运行的 Amazon ECS 任务提供临时 AWS 凭证。
+ 借助 [Amazon Elastic Kubernetes Service Hybrid Nodes](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-overview.html)，您能够将在 AWS 之外作为节点运行的计算资源加入 Amazon EKS 集群。Amazon EKS 可以向在您的计算资源上运行的 Amazon EKS 容器组（pod）提供临时凭证。
+ 借助 [AWS Systems ManagerHybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html)，您可以通过 SSM 管理在 AWS 之外运行的计算资源，并为在您的计算资源上运行的 SSM 代理提供临时 AWS 凭证。
## 需要多重身份验证（MFA）
我们建议对访问您 AWS 资源的人类用户和工作负载使用 IAM 角色，以便他们使用临时凭证。但是，如果您的账户中需要 IAM 用户或根用户，则需要使用 MFA 来提高安全性。有了 MFA，用户就有了一个可以生成身份验证质询响应的设备。各个用户的凭证和设备生成的响应是完成登录过程所必需的。有关更多信息，请参阅 [IAM 中的 AWS 多重身份验证](id_credentials_mfa.md)。我们建议您尽可能使用防网络钓鱼的 MFA，例如通行密钥和安全密钥。有关更多信息，请参阅 [在 AWS 管理控制台 中分配密钥或安全密钥](id_credentials_mfa_enable_fido.md)。
如果您使用 IAM Identity Center 来对人类用户进行集中访问管理，则当您的身份源配置了 IAM Identity Center 身份存储、AWS Managed Microsoft AD 或 AD Connector 时，您可以使用 IAM Identity Center MFA 功能。有关 IAM Identity Center 中的 MFA 的更多信息，请参阅*AWS IAM Identity Center《用户指南》*中的[多重身份验证](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)。
## 对于需要长期凭证的用例，应在需要时更新访问密钥
在可能的情况下，我们建议使用临时凭证，而不是创建访问密钥等长期凭证。但对于需要具有编程访问权限和长期凭证的 IAM 用户的场景，我们建议在需要时更新访问密钥，例如在员工从公司离职时。我们建议利用*上次使用 IAM 访问信息*来安全地更新和移除访问密钥。有关更多信息，请参阅 [更新访问密钥](id-credentials-access-keys-update.md)。
在 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 的更多信息，请参阅 [CodeCommit 的 IAM 凭证：Git 凭证、SSH 密钥和 AWS 访问密钥](id_credentials_ssh-keys.md)。有关配置 **git-remote-codecommit** 实用工具的更多信息，请参阅《AWS CodeCommit 用户指南》**中的[连接到具有轮换凭证的 AWS CodeCommit 存储库](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html#temporary-access-configure-credentials)。
+ **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 插件](https://docs.aws.amazon.com/keyspaces/latest/devguide/access.credentials.html#temporary.credentials.IAM)的 Amazon Keyspaces。
## 遵循最佳实践以保护根用户凭证
在创建 AWS 账户 时，您将创建根用户凭证，以登录 AWS 管理控制台。请像保护其他敏感个人信息一样保护您的根用户凭证。要更好地了解如何保护和扩展根用户进程，请参阅 [您的 AWS 账户 的根用户最佳实践](root-user-best-practices.md)。
## 应用最低权限权限
在使用 IAM policy 设置权限时，请仅授予执行任务所需的权限。为此，您可以定义在特定条件下可以对特定资源执行的操作，也称为*最低权限权限*。在探索工作负载或使用场景所需的权限时，您可以从较广泛的权限开始。随着使用场景逐渐成熟，您可以努力减少授予权限，直至达到最低权限的标准。有关使用 IAM 应用权限的更多信息，请参阅 [AWS Identity and Access Management 中的策略和权限](access_policies.md)。
## AWS 托管策略及转向最低权限权限入门
要开始向用户和工作负载授予权限，请使用 *AWS 托管策略*来为许多常见使用场景授予权限。您可以在 AWS 账户 中找到这些策略。请记住，AWS 托管策略可能不会为您的特定使用场景授予最低权限权限，因为它们可供所有 AWS 客户使用。因此，我们建议通过定义特定于您的使用场景的[客户管理型策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)来减少权限。有关更多信息，请参阅 [AWS托管策略](access_policies_managed-vs-inline.md#aws-managed-policies)。有关专为特定任务函数制定的 AWS 托管策略的更多信息，请参阅 [工作职能的 AWS 托管策略](access_policies_job-functions.md)。
## 使用 IAM Access Analyzer 根据访问活动生成最低权限策略
如果仅授予执行任务所需的权限，您可以根据记录在 AWS CloudTrail 中的访问活动生成策略。[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 会分析您的 IAM 角色使用的服务和操作，然后生成您可以使用的精细策略。测试每个生成的策略后，可以将该策略部署到生产环境中。这可确保您仅向工作负载授予所需的权限。有关策略生成的更多信息，请参阅 [IAM Access Analyzer 策略生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)。
## 定期查看并移除未使用的用户、角色、权限、策略和凭证
您的 AWS 账户 中可能存在不再需要的 IAM 用户、角色、权限、策略或凭证。IAM 提供了*上次访问的信息*来帮助您识别不再需要的用户、角色、权限、策略和凭证，以便您将其删除。这有助于减少必须监控的用户、角色、权限、策略和凭证的数量。您可以使用此信息优化 IAM policy 以更好地遵循最低权限权限。有关更多信息，请参阅 [使用上次访问的信息优化 AWS 中的权限](access_policies_last-accessed.md)。
## 使用 IAM policy 中的条件进一步限制访问权限
您可以指定策略语句在何种条件下生效。这样，您就可以授予对操作和资源的访问权限，但前提是访问请求满足特定条件。例如，您可以编写策略条件来指定必须使用 TLS 发送所有请求。您也可以使用条件来授予对服务操作的访问权限，但前提是它们是通过特定的 AWS 服务 使用的，例如 CloudFormation。有关更多信息，请参阅 [IAM JSON 策略元素：Condition](reference_policies_elements_condition.md)。
## 使用 IAM Access Analyzer 验证对资源的公共和跨账户访问
在 AWS 中授予公共或跨账户访问权限之前，我们建议您验证是否需要此类访问权限。您可以使用 IAM Access Analyzer 来帮助您预览和分析对受支持资源类型的公共和跨账户访问。您可以通过查看 IAM Access Analyzer 生成的[结果](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html)来完成此操作。这些结果可帮助您验证资源访问控制是否授予了期望的访问权限。此外，在更新公共和跨账户权限时，您可以在对资源部署新的访问控制之前验证更改的效果。IAM Access Analyzer 还会持续监控受支持的资源类型，并为允许公共或跨账户访问的资源生成结果。有关更多信息，请参阅[使用 IAM Access Analyzer API 预览访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-preview-access-apis.html)。
## 使用 IAM Access Analyzer 验证您的 IAM 策略，以确保权限的安全性和功能性
验证您创建的策略以确保它们符合 [IAM policy 语言](access_policies.md#access_policies-json)（JSON）和 IAM 最佳实践。您可以使用 IAM Access Analyzer 策略验证来验证您的策略。IAM Access Analyzer 提供 100 多项策略检查和可操作的建议，以帮助您制定安全且功能性强的策略。在控制台中创作新策略或编辑现有策略时，IAM Access Analyzer 会提供一些建议，帮助您在保存策略之前对其进行优化和验证。此外，我们还建议您查看和验证所有现有策略。有关更多信息，请参阅 [IAM Acess Analyzer 策略验证](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。有关 IAM Access Analyzer 提供的策略检查的更多信息，请参阅 [IAM Access Analyzer 策略检查参考](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-reference-policy-checks.html)。
## 跨多个账户建立权限护栏机制
在扩展工作负载时，请使用由 AWS Organizations 托管的多个账户将工作负载分离。建议您使用 AWS Organizations [服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)（SCP）建立权限护栏，以控制账户中所有主体（IAM 角色和用户）的访问权限。建议您使用 AWS Organizations [资源控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)（RCP）建立权限护栏，以控制组织中 AWS 资源的访问权限。SCP 和 RCP 是组织策略类型，可用于在 AWS 组织、组织单元（OU）或账户级别管理组织中的权限。
然而，单凭 SCP 和 RCP 不足以授予您组织中的主体和资源权限。SCP 和 RCP 不授予任何权限。要授予权限，您必须将[基于身份或基于资源的策略](access_policies_identity-vs-resource.md)附加到 IAM 用户、IAM 角色或者您账户中的资源。有关更多信息，请参阅 [SRA 构建块 – AWS Organizations、账户和护栏](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/organizations.html)。
## 使用权限边界在账户内委派权限管理
在某些场景中，您可能需要将账户中的权限管理委派给其他用户。例如，您可以允许开发人员为其工作负载创建和管理角色。将权限委派给其他人时，请使用*权限边界*以设置您委派的最大权限数量。权限边界是一个高级功能，用于使用托管策略设置基于身份的策略可授予 IAM 角色的最大权限。权限边界自己不授予访问权限。有关更多信息，请参阅 [IAM 实体的权限边界](access_policies_boundaries.md)。