# SEC 2. 如何管理人员和计算机的身份验证？ 在操作安全 AWS 工作负载时，您需要管理两类身份。 + **人员身份：**需要访问 AWS 环境和应用程序的人员身份可以分类为三个组：员工、第三方和用户。 *员工* 组包括作为组织成员的管理员、开发人员和操作员。他们需要访问权限才能管理、构建和运营您的 AWS 资源。 *第三方* 是外部协作者，如承包商、供应商或合作伙伴。他们与您的 AWS 资源交互，这是他们与您的组织互动的一部分。 *用户* 是应用程序的使用者。他们通过 Web 浏览器、客户端应用程序、移动应用程序或交互式命令行工具访问您的 AWS 资源。 + **机器身份：**工作负载应用程序、操作工具和组件需要拥有身份，才能向 AWS 服务发出请求，例如读取数据。这些身份还包括在您的 AWS 环境（例如 Amazon EC2 实例或 AWS Lambda 函数）中运行的机器。您还可以管理需要访问 AWS 环境的外部方或 AWS 外部的机器的机器身份。 **Topics** + [ # SEC02-BP01 使用强大的登录机制 ](sec_identities_enforce_mechanisms.md) + [ # SEC02-BP02 使用临时凭证 ](sec_identities_unique.md) + [ # SEC02-BP03 安全地存储和使用密钥 ](sec_identities_secrets.md) + [ # SEC02-BP04 依赖集中式身份提供程序 ](sec_identities_identity_provider.md) + [ # SEC02-BP05 定期审计和轮换凭证 ](sec_identities_audit.md) + [ # SEC02-BP06 使用用户组和属性 ](sec_identities_groups_attributes.md) # SEC02-BP01 使用强大的登录机制 SEC02-BP01 使用强大的登录机制 当不使用多重身份验证（MFA）等机制时，登录（使用登录凭证的身份验证）可能会带来风险，特别是在登录凭证被无意泄露或很容易猜到的情况下。使用强大的登录机制，通过要求使用 MFA 和强密码策略来降低这些风险。 **期望结果：**通过为 [AWS Identity and Access Management（IAM）](https://aws.amazon.com/iam/)用户、[AWS 账户根用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)、[AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 和第三方身份提供者使用强大的登录机制，降低意外访问 AWS 中凭证的风险。这意味着需要 MFA，强制执行强密码策略，并检测异常登录行为。 **常见反模式：** + 没有为身份执行强密码策略，包括复杂密码和 MFA。 + 在不同的用户之间共享相同的凭证。 + 不对可疑的登录使用检测性控制。 **在未建立这种最佳实践的情况下暴露的风险等级：**高 ## 实施指导 实施指导 有几种方法可以让人员身份登录到 AWS。在向 AWS 进行身份验证时，AWS 最佳做法是依赖于使用联合身份验证的集中式身份提供者（AWS IAM 和集中式 IdP 之间的直接 SAML 2.0 联合身份验证，或使用 AWS IAM Identity Center）。在这种情况下，请与身份提供者或 Microsoft Active Directory 建立安全登录过程。 第一次开设 AWS 账户时，您会从 AWS 账户根用户开始。您应仅使用账户根用户为用户（以及为[需要根用户的任务](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)）设置访问权限。在开设 AWS 账户后立即为账户根用户开启多重身份验证（MFA），并使用 [AWS 最佳实践指南](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html)来保护根用户的安全，这一点至关重要。 AWS IAM Identity Center 专为员工用户设计，您可以在服务中创建和管理用户身份，并使用 MFA 保护登录流程。另一方面，AWSCognito 专为客户身份和访问管理（CIAM）而设计，它为应用程序中的外部用户身份提供用户池和身份提供者。 如果您在 AWS IAM Identity Center 中创建用户，请确保该服务中的登录过程安全，并[开启 MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)。对于应用程序中的外部用户身份，可以使用 [Amazon Cognito 用户池](https://docs.aws.amazon.com/cognito/index.html)并确保该服务中的登录过程安全，也可以通过 Amazon Cognito 用户池中支持的身份提供者之一进行登录。 此外，对于 AWS IAM Identity Center 中的用户，可以使用 [AWS Verified Access](https://docs.aws.amazon.com/verified-access/latest/ug/what-is-verified-access.html)，通过在向他们授予访问 AWS 资源的权限之前验证用户的身份和设备状态，来提供一层额外的安全性。 如果您使用的是 [AWS Identity and Access Management（IAM）](https://aws.amazon.com/iam/)用户，请使用 IAM 来保护登录过程。 可以同时使用 AWS IAM Identity Center 和直接 IAM 联合身份验证来管理对 AWS 的访问权限。可以使用 IAM 联合身份验证来管理对 AWS 管理控制台和服务的访问权限，并使用 IAM Identity Center 来管理对诸如 Quick 或 Amazon Q Business 等业务应用程序的访问权限。 无论采用何种登录方法，执行强登录策略都非常关键。 ### 实施步骤 实现步骤 以下是一般的强登录建议。应根据公司策略或使用 [NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html) 等标准，对配置的实际设置进行设定。 + 需要 MFA。对于人员身份和工作负载，[要求使用 MFA 是 IAM 最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users)。启用 MFA 提供了一层额外的安全保障，这会要求用户提供登录凭证和一次性密码（OTP），或从硬件设备加密验证和生成的字符串。 + 强制执行最小密码长度，这是密码强度的主要因素。 + 强制执行密码复杂性，使密码更难以猜到。 + 允许用户更改其密码。 + 创建个人身份而不是共享凭证。通过创建个人身份，您可以为每个用户提供一组唯一的安全凭证。个人用户可以审计每个用户的活动。 IAM Identity Center 建议： + IAM Identity Center 在使用默认目录时提供了预定义的[密码策略](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)，该策略确定了密码长度、复杂性和重用要求。 + 当身份源为默认目录、AWS Managed Microsoft AD 或 AD Connector 时，[启用 MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html) 并为 MFA 配置“上下文感知”或“始终开启”设置。 + 允许用户[注册自己的 MFA 设备](https://docs.aws.amazon.com/singlesignon/latest/userguide/how-to-allow-user-registration.html)。 Amazon Cognito 用户池目录建议： + 配置[密码长度](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html)设置。 + 对于用户，[要求使用 MFA](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html)。 + 使用 Amazon Cognito 用户池[高级安全设置](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html)可实现[自适应身份验证](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html)（可阻止可疑登录）等功能。 IAM 用户建议： + 最好是使用 IAM Identity Center 或直接联合。不过，您可能需要 IAM 用户。在这种情况下，为 IAM 用户[设置密码策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)。您可以使用密码策略来定义诸如最小长度、密码是否需要非字母字符之类的要求。 + 创建 IAM 策略来[强制执行 MFA 登录](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1)，允许用户管理自己的密码和 MFA 设备。 ## 资源 资源 **相关最佳实践：** + [SEC02-BP03 安全地存储和使用密钥](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html) + [SEC02-BP04 依赖集中式身份提供程序](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) + [SEC03-BP08 在组织内安全地共享资源](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html) **相关文档：** + [AWS IAM Identity Center 密钥策略](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) + [IAM 用户密码策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) + [设置 AWS 账户根用户密码](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) + [Amazon Cognito password policy](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html) + [AWS 凭证](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html) + [IAM 安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) **相关视频：** + [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) + [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) # SEC02-BP02 使用临时凭证 SEC02-BP02 使用临时凭证 进行任何类型的身份验证时，最好使用临时凭证而不是长期凭证，来降低或消除诸如凭证被无意泄露、共享或被盗之类的风险。 **期望结果：**为了降低长期凭证的风险，尽量对人类身份和机器身份使用临时凭证。长期凭证会带来诸多风险，例如通过上传到公共存储库而泄露。使用临时凭证可以大幅降低凭证被泄露的几率。 **常见反模式：** + 开发人员使用 IAM 用户的长期访问密钥，而不是使用联合身份验证从 CLI 获得临时凭证。 + 开发人员在他们的代码中嵌入长期访问密钥，并将该代码上传到公有 Git 存储库。 + 开发人员在移动应用程序中嵌入长期访问密钥，然后在应用商店中提供这些密钥。 + 用户与其他用户共享长期访问密钥，或员工离开公司时仍持有长期访问密钥。 + 当可以使用临时凭证时，对机器身份使用长期访问密钥。 **在未建立这种最佳实践的情况下暴露的风险等级：**高 ## 实施指导 实施指导 对所有 AWS API 和 CLI 请求使用临时安全凭证，而不是长期凭证。在几乎所有情况下，对 AWS 服务的 API 和 CLI 请求都必须使用 [AWS 访问密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)进行签名。这些请求可以使用临时凭证或长期凭证进行签名。只有在使用 [IAM 用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)或 [AWS 账户根用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)时，才应该使用长期凭证（也称为长期访问密钥）。在联合到 AWS 或通过其他方法代入 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)时，系统会生成临时凭证。即使使用登录凭证访问 AWS 管理控制台，系统也会生成临时凭证供您调用 AWS 服务。需要用到长期凭证的情况很少，所以可以使用临时凭证完成几乎所有任务。 尽量不要使用长期凭证，要多用临时凭证，并且还应少用 IAM 用户进行能访问，而应多用联合身份验证和 IAM 角色进行访问。虽然过去常使用 IAM 用户来访问人类身份和机器身份，但现在不建议使用 IAM 用户，避免使用长期访问密钥所带来的风险。 ### 实施步骤 实施步骤 #### 人员身份 人员身份 对于员工、管理员、开发人员和操作员等员工身份： + 您应该[依赖集中式身份提供程序](https://docs.aws.amazon.com//wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)，并[要求人类用户配合使用联合身份验证与身份提供程序两种方法，以便使用临时凭证访问 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)。可以通过[对每个 AWS 账户进行直接联合身份验证](https://aws.amazon.com/identity/federation/)或使用 [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 和您选择的身份提供者，来完成用户的联合身份验证。与使用 IAM 用户相比，联合身份验证除了消除使用长期凭证的情况之外，还具有许多优势。用户也可以从[直接联合](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/)的命令行或通过使用 [IAM Identity Center](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) 来请求获得临时凭证。这意味着能够大幅减少需要使用 IAM 用户或用户长期凭证的情况。 对于第三方身份： + 在授予软件即服务（SaaS）提供商等第三方访问 AWS 账户中资源的权限时，您可以使用[跨账户角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)和[基于资源的策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)。此外，可以为 B2B SaaS 客户或合作伙伴使用 [Amazon Cognito OAuth 2.0 grant](https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints-oauth-grants.html) 客户端凭证流。 通过 Web 浏览器、客户端应用程序、移动应用程序或交互式命令行工具访问 AWS 资源的用户身份： + 如果需要批准消费者或客户申请访问 AWS 资源，您可以使用 [Amazon Cognito 身份池](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html)或 [Amazon Cognito 用户池](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)提供临时凭证。凭证的权限是通过 IAM 角色配置的。您也可以为未经身份验证的来宾用户定义一个具有有限权限的单独的 IAM 角色。 #### 机器身份 机器身份 对于机器身份，您就可能需要使用长期凭证了。在这些情况下，您应该[要求工作负载使用具有 IAM 角色的临时凭证来访问 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles)。 + 对于[Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/)（Amazon EC2），您可以使用[适用于 Amazon EC2 的角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)。 + [AWS Lambda](https://aws.amazon.com/lambda/) 让您能够配置 [Lambda 执行角色授予权限](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)，以便利用临时凭证执行 AWS 操作。AWS 服务还有许多其他类似的模型，可以使用 IAM 角色授予临时凭证。 + 对于 IoT 设备，您可以使用 [AWS IoT Core 凭证提供程序](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)来请求临时凭证。 + 对于需要访问 AWS 资源的本地系统或在 AWS 之外运行的系统，您可以使用 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)。 某些情况下不支持临时凭证，此时需要使用长期凭证。在这些情况下，可以[定期审计和轮换这些凭证](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html)和[定期轮换访问密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials)。对于高度受限的 IAM 用户访问密钥，请考虑以下其它安全措施： + 授予高度受限的权限： + 遵守最低权限原则（特定于操作、资源和条件）。 + 考虑仅向 IAM 用户授予针对一个特定角色的 AssumeRole 操作。根据本地架构，此方法有助于隔离和保护长期 IAM 凭证。 + 在 IAM 角色信任策略中限制支持的网络来源和 IP 地址。 + 监控使用情况并针对未使用的权限或滥用行为设置警报（使用 AWS CloudWatch Logs 指标筛选条件和警报）。 + 强制执行[权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) [服务控制策略（SCP）和权限边界相辅相成 - SCP 是粗粒度的，而权限边界是细粒度的]。 + 实施用于预置和（在本地保管库中）安全存储凭证的过程。 对于需要长期凭证的场景，其它一些选项包括： + 构建自己的令牌出售 API（使用 Amazon API Gateway）。 + 对于必须使用长期凭证或 AWS 访问密钥以外凭证的场景（如数据库登录），可以使用旨在处理密钥管理的服务，如 [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/)。Secrets Manager 可以简化加密密钥的管理、轮换和安全存储。许多 AWS 服务都支持与 Secrets Manager [direct integration](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html)。 + 对于多云集成，可以使用基于源凭证服务提供商（CSP）凭证的身份联合验证（请参阅 [AWS STS AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)）。 有关轮换长期凭证的更多信息，请参阅[轮换访问密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)。 ## 资源 资源 **相关最佳实践：** + [SEC02-BP03 安全地存储和使用密钥](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html) + [SEC02-BP04 依赖集中式身份提供程序](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) + [SEC03-BP08 在组织内安全地共享资源](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html) **相关文档：** + [临时安全凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) + [AWS 凭证](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html) + [IAM 安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [ IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) + [IAM Identity Center](https://aws.amazon.com/iam/identity-center/) () + [身份提供程序和联合身份验证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) + [轮换访问密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) + [安全合作伙伴解决方案：访问和访问控制](https://aws.amazon.com/security/partner-solutions/#access-control) + [AWS 账户根用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) + [Access AWS using a Google Cloud Platform native workload identity](https://aws.amazon.com/blogs/security/access-aws-using-a-google-cloud-platform-native-workload-identity/) + [How to access AWS resources from Microsoft Entra ID tenants using AWS Security Token Service](https://aws.amazon.com/blogs/security/how-to-access-aws-resources-from-microsoft-entra-id-tenants-using-aws-security-token-service/) **相关视频：** + [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) + [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) # SEC02-BP03 安全地存储和使用密钥 SEC02-BP03 安全地存储和使用密钥 工作负载需要能够自动向数据库、资源和第三方服务证明其身份。这是使用秘密访问凭证（如 API 访问密钥、密码和 OAuth 令牌）完成的。使用专门构建的服务来存储、管理和轮换这些凭证，有助于降低这些凭证泄露的可能性。 **期望结果：**实施安全管理应用程序凭证的机制来实现以下目标： + 确定工作负载需要哪些密钥。 + 尽量使用短期凭证代替长期凭证，从而减少所需长期凭证的数量。 + 建立安全存储并自动轮换剩余的长期凭证。 + 审核对工作负载中存在的密钥的访问。 + 持续监控，验证开发期间没有在源代码中嵌入任何密钥。 + 降低凭证被无意中泄露的可能性。 **常见反模式：** + 不轮换凭证。 + 将长期凭证存储在源代码或配置文件中。 + 在未加密状态下静态存储凭证。 **建立此最佳实践的好处：** + 对存储的凭证进行静态和传输中加密。 + 通过 API 来把关对凭证的访问（可将 API 看作*凭证自动售货机*）。 + 审核和记录对凭证的访问（包括读和写）。 + 关注点分离：凭证轮换由一个单独的组件执行，该组件可与架构的其余部分隔离开来。 + 密钥自动按需分发给软件组件，并在中心位置进行轮换。 + 可以精细地控制对凭证的访问。 **在未建立这种最佳实践的情况下暴露的风险等级：**高 ## 实施指导 实施指导 过去，用于对数据库、第三方 API、令牌和其他密钥进行身份验证的凭证，可能已嵌入到源代码或环境文件中。AWS 提供了几种机制来安全地存储这些凭证，自动轮换凭证，并审核凭证的使用情况。 妥善管理密钥的方法是遵循相关指导，正确地删除、替换和轮换密钥。最安全的凭证是不必存储、管理或处理的凭证。某些凭证可能不再是正常运行工作负载所必需的，可以安全地删除。 对于仍然是正常运行工作负载所必需的凭证，可能有机会用临时或短期凭证替换长期凭证。例如，相较于对 AWS 秘密访问密钥进行硬编码，不妨考虑使用 IAM 角色将长期凭证替换为临时凭证。 可能无法删除或替换某些长期密钥。这些密钥可以存储在 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 等服务中，在其中得到集中存储、管理和定期轮换。 对工作负载的源代码和配置文件进行审计，可以发现许多类型的凭证。下表总结了处理常见凭证类型的策略： | 凭证类型 | 描述 | 建议采取的策略 | | --- | --- | --- | | IAM 访问密钥 | 用于在工作负载内代入 IAM 角色的 AWS IAM 访问密钥和私有密钥 | 替换：改用分配给计算实例（例如 [Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) 或 [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)）的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios.html)。为了与需要访问 AWS 账户中资源的第三方实现互操作性，请询问他们是否支持 [AWS 跨账户访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)。对于移动应用程序，请考虑通过 [Amazon Cognito 身份池（联合身份）](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html)使用临时凭证。对于在 AWS 之外运行的工作负载，请考虑使用 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 或 [AWS Systems Manager 混合激活](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html)。对于容器，请参阅 [Amazon ECS 任务 IAM 角色](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)或 [Amazon EKS 节点 IAM 角色](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html)。 | | SSH 密钥 | 用于登录 Linux EC2 实例的 Secure Shell 私有密钥，可手动登录或作为自动流程的一部分登录 | 替换：使用 [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) 或 [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html)，通过 IAM 角色提供对 EC2 实例的编程访问权限和人类访问。 | | 应用程序和数据库凭证 | 密码 – 纯文本字符串 | 轮换：将凭证存储在 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 中，并尽量建立自动轮换机制。 | | Amazon RDS 和 Aurora 管理数据库凭证 | 密码 – 纯文本字符串 | 替换：使用 [Secrets Manager 与 Amazon RDS 集成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html)或 [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html)。此外，在某些应用场景中，一些 RDS 数据库类型可以使用 IAM 角色代替密码（有关更多详细信息，请参阅 [IAM 数据库身份验证](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html)）。 | | OAuth 令牌 | 密钥令牌 – 纯文本字符串 | 轮换：将令牌存储在 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 中并配置自动轮换。 | | API 令牌和密钥 | 密钥令牌 – 纯文本字符串 | 轮换：存储在 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 中，并尽量建立自动轮换机制。 | 一种常见的反模式是在源代码、配置文件或移动应用程序中嵌入 IAM 访问密钥。当需要 IAM 访问密钥与 AWS 服务通信时，请使用[临时（短期）安全凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)。可以通过 [EC2 实例的 IAM 角色](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)、Lambda 函数的[执行角色](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)、移动用户访问的 [Cognito IAM 角色](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html)和 IoT 设备的 [IoT Core 策略](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html)，提供这些短期凭证。与第三方进行交互时，最好[将访问权限委托给 IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)，授予对账户资源的必要访问权限，而不是配置 IAM 用户并向第三方发送该用户的秘密访问密钥。 在许多情况下，工作负载需要存储与其他服务和资源进行互操作所必需的密钥。[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 旨在安全地管理这些凭证，以及 API 令牌、密码和其他凭证的存储、使用和轮换。 AWS Secrets Manager 提供五个关键功能，确保敏感凭证的安全存储和处理：[静态加密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)、[传输中加密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html)、[全面审核](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html)、[精细访问控制](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html)和[可扩展凭证轮换](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)。AWS 合作伙伴提供的其他密钥管理服务或提供类似功能和保证的本地开发的解决方案，也可以接受。 在检索密钥时，可以使用 Secrets Manager 客户端缓存组件来缓存密钥，以备将来使用。检索已缓存密钥比从 Secrets Manager 中检索密钥的速度要快。此外，由于调用 Secrets Manager API 会产生费用，因此使用缓存可以降低成本。有关检索密钥的所有方法，请参阅 [Get secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)。 **注意** 某些语言可能要求您实施自己的内存加密来进行客户端缓存。 ### 实施步骤 实施步骤 1. 使用自动化工具（如 [Amazon CodeGuru](https://aws.amazon.com/codeguru/features/)）识别包含硬编码凭证的代码路径。 1. 使用 Amazon CodeGuru 扫描代码存储库。审核完成后，在 CodeGuru 中按 Type=Secrets 进行筛选来查找有问题的代码行。 1. 识别可以删除或替换的凭证。 1. 识别不再需要的凭证并标明要删除。 1. 对于嵌入到源代码的 AWS 私有密钥，将其替换为与必要资源相关的 IAM 角色。如果部分工作负载在 AWS 之外，但需要 IAM 凭证才能访问 AWS 资源，请考虑采用 [IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) 或 [AWS Systems Manager 混合激活](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html)。 1. 对于其他需要使用轮换策略的第三方、长期密钥，请将 Secrets Manager 集成到代码中，以便在运行时检索第三方密钥。 1. CodeGuru 控制台可以使用发现的凭证[在 Secrets Manager 中自动创建密钥](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/)。 1. 将 Secrets Manager 的密钥检索集成到应用程序代码中。 1. 无服务器 Lambda 函数可以使用与语言无关的 [Lambda 扩展](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html)。 1. 对于 EC2 实例或容器，AWS 用几种流行的编程语言提供了示例[客户端代码，用于从 Secrets Manager 检索密钥](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)。 1. 定期检查代码库并重新扫描，验证代码中没有添加新的密钥。 1. 考虑使用诸如 [git-secrets](https://github.com/awslabs/git-secrets) 之类的工具，防止向源代码存储库提交新的密钥。 1. [监控 Secrets Manager 活动](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html)，发现意外使用、不适当的密钥访问或试图删除密钥的迹象。 1. 减少人类接触凭证的机会。将读取、写入和修改凭证的权限仅授予专用于此目的的 IAM 角色，并仅向一小部分操作用户提供代入该角色的权限。 ## 资源 资源 **相关最佳实践：** + [SEC02-BP02 使用临时凭证](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html) + [SEC02-BP05 定期审计和轮换凭证](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) **相关文档：** + [AWS Secrets Manager 入门](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) + [身份提供程序和联合身份验证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) + [Amazon CodeGuru 推出 Secrets Detector](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) + [AWS Secrets Manager 如何使用 AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html) + [Secret encryption and decryption in Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html) + [Secrets Manager 博客系列文章](https://aws.amazon.com/blogs/security/tag/aws-secrets-manager/) + [Amazon RDS 宣布与 AWS Secrets Manager 集成](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-rds-integration-aws-secrets-manager/) **相关视频：** + [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale](https://youtu.be/qoxxRlwJKZ4) + [Find Hard-Coded Secrets Using Amazon CodeGuru Secrets Detector](https://www.youtube.com/watch?v=ryK3PN--oJs) + [Securing Secrets for Hybrid Workloads Using AWS Secrets Manager](https://www.youtube.com/watch?v=k1YWhogGVF8) **相关讲习会：** + [Store, retrieve, and manage sensitive credentials in AWS Secrets Manager](https://catalog.us-east-1.prod.workshops.aws/workshops/92e466fd-bd95-4805-9f16-2df07450db42/en-US) + [AWS Systems Manager Hybrid Activations](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html) # SEC02-BP04 依赖集中式身份提供程序 SEC02-BP04 依赖集中式身份提供程序 对于工作人员身份（员工和合同工），请依赖允许您在集中位置管理身份的身份提供程序。这样就可以更轻松地跨多个应用程序和系统管理访问权限，因为您可以从单一位置创建、分配、管理、撤销和审核访问权限。 **期望结果：**您有一个集中式身份提供程序，可以在其中集中管理员工用户、身份验证策略 [例如要求多重身份验证（MFA）]，以及对系统和应用程序的授权（例如根据用户的群组成员资格或属性分配访问权限）。您的员工用户登录到中央身份提供程序并联合身份验证（单点登录）到内部和外部应用程序，这样用户就无需记住多个凭证。您的身份提供程序已与您的人力资源（HR）系统集成，因此人事变动会自动与身份提供程序同步。例如，如果有人离开组织，您可以自动撤消对联合应用程序和系统（包括 AWS）的访问权限。您已在身份提供程序中启用了详细的审核日志记录，并且正在监控这些日志，以便发现异常用户行为。 **常见反模式：** + 不使用联合身份验证和单点登录。员工用户在多个应用程序和系统中创建单独的用户账户和凭证。 + 尚未实现员工用户身份生命周期的自动化，例如将身份提供程序与 HR 系统集成。当用户离职或变换角色时，您使用手动流程来删除或更新他们在多个应用程序和系统中的记录。 **建立此最佳实践的好处：**通过使用集中式身份提供程序，您可以在一个位置管理员工用户身份和策略，可以向用户和群组分配应用程序的访问权限，还可以监控用户登录活动。通过与您的人力资源（HR）系统集成，当用户的角色发生更改时，这些更改会同步到身份提供程序，并自动更新为他们分配的应用程序和权限。当用户离职时，其身份将在身份提供程序中自动被禁用，从而撤消他们对联合应用程序和系统的访问权限。 **在未建立这种最佳实践的情况下暴露的风险等级：**高 ## 实施指导 实施指导 **员工用户访问 AWS 的指南**：员工用户（如组织中的员工和合同工）可能需要使用 AWS 管理控制台或 AWS Command Line Interface（AWS CLI）来访问 AWS，以便履行工作职能。您可以通过从集中式身份提供程序联合到 AWS，在两个层面上向员工用户授予对 AWS 的访问权限：直接联合到每个 AWS 账户，或联合到 [AWS 组织](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)中的多个账户。 要将员工用户与每个 AWS 账户直接联合，可以使用集中式身份提供程序来联合到该账户中的 [AWS Identity and Access Management](https://aws.amazon.com/iam/)。IAM 的灵活性允许您启用单独的 [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) 或 [Open ID Connect（OIDC）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html)身份提供程序（针对每个 AWS 账户），并使用联合用户属性进行访问控制。员工用户会使用网络浏览器，通过提供凭证（如密码和 MFA 令牌码）来登录身份提供程序。身份提供程序向浏览器发出 SAML 断言，该断言将提交到 AWS 管理控制台登录 URL，以便允许用户[通过代入 IAM 角色单点登录 AWS 管理控制台](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)。用户还可以获取临时 AWS API 凭证用于 [AWS CLI](https://aws.amazon.com/cli/) 或 [AWS SDK](https://aws.amazon.com/developer/tools/)（从 [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)），方法是[使用身份提供程序的 SAML 断言代入 IAM 角色](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)。 要对员工用户和 AWS 组织中的多个账户进行联合身份验证，可以使用 [https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/) 来集中管理员工用户对 AWS 账户和应用程序的访问权限。组织启用 Identity Center 并配置身份源。IAM Identity Center 提供一个默认身份源目录，可用来管理用户和组。您也可以选择外部身份源，方法是使用 SAML 2.0 [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)并使用 SCIM [自动预置](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html)用户和组，或使用 [Directory Service](https://aws.amazon.com/directoryservice/) [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html)。配置身份源后，即可通过以下方法为用户和组分配对 AWS 账户的访问权限：在[权限集](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)中定义最低权限策略。员工用户可以通过中央身份提供程序进行身份验证，登录 [AWS 访问门户](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html)并单点登录到 AWS 账户以及分配给他们的云应用程序。用户可以配置 [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) 来使用 Identity Center 进行身份验证，并获取用于运行 AWS CLI 命令的凭证。Identity Center 还支持通过单点登录访问 AWS 应用程序，例如 [Amazon SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) 和 [AWS IoT Sitewise Monitor portals](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html)。 遵循上述指导后，员工用户在 AWS 上管理工作负载时，将不再需要使用 IAM 用户和组来进行通用的操作。相反，用户和组是在 AWS 外部进行管理，并且能够以*联合身份*访问 AWS 资源。联合身份使用集中式身份提供程序定义的组。您应该识别并删除 AWS 账户中不再需要的 IAM 组、IAM 用户和长期用户凭证（密码和访问密钥）。您可以[查找未使用的凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html)（使用 [IAM 凭证报告](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)）、[删除相应的 IAM 用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html)和[删除 IAM 组。](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html)您可以将[服务控制策略（SCP）](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)应用于组织，帮助防止创建新的 IAM 用户和组，并强制通过联合身份访问 AWS。 **注意** 您负责处理 SCIM 访问令牌的轮换，如[自动预置](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html)文档中所述。此外，您还负责轮换支持身份联合验证的证书。 **应用程序用户的指南**：通过将 [https://aws.amazon.com/cognito/](https://aws.amazon.com/cognito/) 用作集中式身份提供者，您可以管理应用程序（例如移动应用程序）用户的身份。Amazon Cognito 支持对 Web 和移动应用程序进行身份验证、授权和用户管理。Amazon Cognito 提供可扩展到数百万用户的身份存储，支持社交网络和企业身份联合验证，并提供高级安全功能来协助保护用户和业务。您可以将自定义 Web 或移动应用程序与 Amazon Cognito 集成，以便在几分钟内为应用程序添加用户身份验证和访问控制。Amazon Cognito 以 SAML 和 Open ID Connect（OIDC）等开放式身份标准为基础构建，支持各种合规性法规，并与前端和后端开发资源集成。 ### 实施步骤 实施步骤 **员工用户访问 AWS 的步骤** + 通过以下某种方法，使用集中式身份提供程序向 AWS 联合验证员工身份： + 通过与身份提供程序联合，使用 IAM Identity Center 来允许单点登录到 AWS 组织中的多个 AWS 账户。 + 使用 IAM 将身份提供程序直接连接到每个 AWS 账户，从而实现精细的联合访问。 + 识别并移除被联合身份取代的 IAM 用户和群组。 **适用于应用程序用户的步骤** + 将 Amazon Cognito 用作应用程序的集中式身份提供程序。 + 使用 OpenID Connect 和 OAuth 将自定义应用程序与 Amazon Cognito 集成。您可以使用 Amplify 库开发自定义应用程序，这些库提供了与各种 AWS 服务（例如用于身份验证的 Amazon Cognito）集成的简单接口。 ## 资源 资源 **相关最佳实践：** + [SEC02-BP06 使用用户组和属性](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_groups_attributes.html) + [SEC03-BP02 授予最低访问权限](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html) + [SEC03-BP06 基于生命周期管理访问权限](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html) **相关文档：** + [AWS 中的身份联合验证](https://aws.amazon.com/identity/federation/) + [IAM 安全最佳实操](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [AWS Identity and Access Management 最佳实践](https://aws.amazon.com/iam/resources/best-practices/) + [IAM Identity Center 委派管理入门](https://aws.amazon.com/blogs/security/getting-started-with-aws-sso-delegated-administration/) + [How to use customer managed policies in IAM Identity Center for advanced use cases](https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanced-use-cases/) + [AWS CLI v2: IAM Identity Center credential provider](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html) **相关视频：** + [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI) + [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y) + [AWS re:Invent 2018: Mastering Identity at Every Layer of the Cake](https://youtu.be/vbjFjMNVEpc) **相关示例：** + [Workshop: Using AWS IAM Identity Center to achieve strong identity management](https://catalog.us-east-1.prod.workshops.aws/workshops/590f8439-42c7-46a1-8e70-28ee41498b3a/en-US) **相关工具：** + [AWS 安全能力合作伙伴：身份和访问管理](https://aws.amazon.com/security/partner-solutions/) + [saml2aws](https://github.com/Versent/saml2aws) # SEC02-BP05 定期审计和轮换凭证 SEC02-BP05 定期审计和轮换凭证 定期审计和轮换凭证，以限制凭证可用于访问资源的时间。长期凭证会产生许多风险，可通过定期轮换长期凭证来降低这些风险。 **期望结果：**实施凭证轮换，以帮助降低长期凭证相关风险。定期审计并纠正不符合凭证轮换策略的情况。 **常见反模式：** + 不审计凭证的使用情况。 + 不必要地使用长期凭证。 + 使用长期凭证，不定期轮换。 **在未建立这种最佳实践的情况下暴露的风险等级：**高 ## 实施指导 实施指导 当您无法依赖于临时凭证而需要长期凭证时，请审计凭证，以验证定义的控制措施 [例如[多重身份验证](https://aws.amazon.com/iam/features/mfa/)（MFA）] 得以实施、定期轮换并具有适当的访问级别。 （最好通过自动化工具）定期验证，以确保实施正确的控制措施。对于人员身份，您应要求用户定期更改他们的密码并停用访问密钥，以支持临时凭证。从 AWS Identity and Access Management（IAM）用户转向集中式身份时，您可以[生成凭证报告](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)来审计您的用户。 我们还建议您在身份提供者中实施并监控 MFA。您可以设置 [AWS Config 规则](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)或使用 [AWS Security Hub CSPM 安全标准](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-iam-3)来监控用户是否配置了 MFA。考虑使用 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 为机器身份提供临时凭证。在无法使用 IAM 角色和临时凭证的情况下，需要经常审计和轮换访问密钥。 ### 实施步骤 实施步骤 + **定期审计凭证：**对您的身份提供者和 IAM 中配置的身份进行审计，这有助于验证只有经过授权的身份才能访问您的工作负载。此类身份可能包括但不限于 IAM 用户、AWS IAM Identity Center 用户、Active Directory 用户或不同上游身份提供者中的用户。例如，删除离开组织的人员，并删除不再需要的跨账户角色。制定流程，以定期审计 IAM 实体所访问服务的权限。这有助于您确定需要修改的策略，以删除任何未使用的权限。使用凭证报告和 [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 来审计 IAM 凭证和权限。您可以使用 [Amazon CloudWatch 为 AWS 环境中调用的特定 API 调用设置警报](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html)。[Amazon GuardDuty 还可以提醒您注意意外活动](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html)，出现这种提醒，可表明对 IAM 凭证的访问过于宽松，或出现了意外访问情况。 + **定期轮换凭证：**当您无法使用临时凭证时，请定期轮换长期 IAM 访问密钥（最多每 90 天一次）。如果在您不知情的情况下无意中泄露了访问密钥，这将限制凭证用于访问资源的时间。有关轮换 IAM 用户的访问密钥的信息，请参阅《[轮换访问密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)》。 + **查看 IAM 权限：**要增强您的 AWS 账户的安全性，请定期查看和监控每个 IAM 策略。验证这些策略是否遵循最低权限原则。 + **考虑自动创建和更新 IAM 资源：**[IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 自动执行许多 IAM 任务，比如角色和策略管理。或者，AWS CloudFormation 可用于自动部署 IAM 资源（包括角色和策略），以减少人为错误的机会，因为可以验证模板和控制版本。 + **对于机器身份，使用 IAM Roles Anywhere 替换 IAM 用户：**[IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 将使您能够在传统上无法使用角色的领域（例如本地服务器）使用角色。IAM Roles Anywhere 使用可信的 [X.509 certificate](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/trust-model.html#signature-verification) 向 AWS 进行身份验证并接收临时凭证。使用 IAM Roles Anywhere 便无需轮换这些凭证，因为长期凭证不再存储在本地环境中。请注意，您需要监控 X.509 证书，并在该证书即将到期时轮换它。 ## 资源 资源 **相关最佳实践：** + [SEC02-BP02 使用临时凭证](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html) + [SEC02-BP03 安全地存储和使用密钥](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html) **相关文档：** + [AWS Secrets Manager 入门](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) + [IAM 最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [身份提供程序和联合身份验证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) + [安全合作伙伴解决方案：访问和访问控制](https://aws.amazon.com/security/partner-solutions/#access-control) + [临时安全凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) + [获取您的 AWS 账户的凭证报告](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) **相关视频：** + [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale](https://youtu.be/qoxxRlwJKZ4) + [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) + [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) # SEC02-BP06 使用用户组和属性 SEC02-BP06 使用用户组和属性 根据用户组和属性来定义权限，可以减少策略的数量和复杂性，这样就更容易实现最低权限原则。您可以通过用户组，根据用户在企业中履行的职能，从一个位置管理多个用户的权限。当用户履行类似的职能但面向的是不同资源子集时，可以利用部门、项目或位置等属性来提供额外的一层权限范围。 **期望结果：**您可以将基于职能的权限更改应用到履行该职能的所有用户。利用组成员资格和属性管控用户的权限，减少在单个用户级别管理权限的需求。您在身份提供者（IdP）中定义的组和属性会自动传播到您的 AWS 环境。 **常见反模式：** + 分别管理每个用户的权限，然后在多个用户之间复制。 + 定义过于宽泛的组，授予过于宽泛的权限。 + 定义过于精细的组，造成成员重复和混淆。 + 对不同资源子集使用具有重复权限的组，但其实可以改为使用属性来进行控制。 + 在管理组、属性和成员资格时，没有使用与您的 AWS 环境集成的标准化身份提供者。 + 使用 AWS IAM Identity Center 会话时使用角色链 **在未建立这种最佳实践的情况下暴露的风险等级：**中 ## 实施指导 实施指导 在称为*策略* 的文档中定义 AWS 权限，这些策略与某个主体关联，例如用户、组、角色或资源。可以根据工作职能、工作负载和 SDLC 环境来组织权限分配（组、权限、账户），从而扩展权限管理。对于员工团队，通过这种方法，您可以根据用户在企业中履行的职能来定义组，而不是根据所访问的资源来定义。例如，WebAppDeveloper 组可能附有策略，用于在开发账户中配置 Amazon CloudFront 等服务。`AutomationDeveloper` 组可能与 `WebAppDeveloper` 组具有一些重叠的权限。可以将这些共有的权限放置在单独的策略中并与这两个组关联，而不是将来自这两个职能部门的用户都放在同一个 `CloudFrontAccess` 组中。 除了使用组之外，您还可以使用*属性*来进一步限定访问范围。例如，您可以为 `WebAppDeveloper` 组中的用户设置“项目”属性，用来限定对其项目特定资源的访问权限。使用这种技巧，您就无需为处理不同项目的应用程序开发人员设置不同的组，因为他们除了项目不同外，所需的权限其实并无不同。在权限策略中引用属性的方式取决于权限的来源，这些权限可能包含在联合身份验证协议（例如 SAML、OIDC 或 SCIM）中，可能是自定义的 SAML 断言，也可能是在 IAM Identity Center 中设置。 ### 实施步骤 实施步骤 1. 确定要在何处定义组和属性： 1. 按照 [SEC02-BP04 依赖集中式身份提供者](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)中的指南，您可以确定是要在身份提供者中或 IAM Identity Center 中定义组和属性，还是在特定账户中使用 IAM 用户组。 1. 定义组： 1. 根据职能和所需访问权限范围来确定组。考虑使用分层结构或命名约定来有效地整理组。 1. 如果在 IAM Identity Center 中定义，则创建组并使用权限集关联所需的访问权限级别。 1. 如果在外部身份提供者中定义，请确定该提供者是否支持 SCIM 协议，并考虑在 IAM Identity Center 中启用自动预置。此功能可在您的提供者和 IAM Identity Center 之间同步组的创建、成员指派和删除。 1. 定义属性： 1. 如果使用外部身份提供者，则默认情况下，SCIM 和 SAML 2.0 协议都提供一些属性。使用 `https://aws.amazon.com/SAML/Attributes/PrincipalTag` 属性名称，可以通过 SAML 断言来定义并传递其它属性。有关定义和配置自定义属性的指南，请咨询身份提供者的文档。 1. 如果在 IAM Identity Center 中定义角色，请启用基于属性的访问权限控制（ABAC）功能，然后根据需要定义属性。考虑符合组织的结构或资源标签策略的属性。 如果您需要从通过 IAM Identity Center 代入的 IAM 角色中获得的 IAM 角色链，则诸如 `source-identity` 和 `principal-tags` 的值将不会传播。有关更多详细信息，请参阅[启用并配置访问控制属性](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)。 1. 根据组和属性限定权限范围： 1. 考虑在权限策略中加入条件，将主体的属性与所访问资源的属性进行比较。例如，您可以定义一个条件，仅当 `PrincipalTag` 条件键的值与相同名称的 `ResourceTag` 键的值匹配时，才支持访问资源。 1. 定义 ABAC 策略时，请遵循 [ABAC 授权](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)最佳实践和示例中的指导。 1. 随着组织需求的发展，请定期审核和更新组和属性结构，以确保最佳的权限管理。 ## 资源 资源 **相关最佳实践：** + [SEC02-BP04 依赖集中式身份提供程序](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) + [SEC03-BP02 授予最低访问权限](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html) + [COST02-BP04 实施组和角色](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_groups_roles.html) **相关文档：** + [IAM 最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [在 IAM Identity Center 中管理身份](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) + [什么是适用于 AWS 的 ABAC？](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) + [在 IAM Identity Center 中使用 ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html) + [ABAC 策略示例](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_abac.html) **相关视频：** + [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) + [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)