# 身份和访问管理
要使用 AWS 服务，您必须授予用户和应用程序访问 AWS 账户中资源的权限。在 AWS 上运行更多的工作负载时，您需要实施强大的身份管理和权限，确保适当的人员在适当的条件下有权访问适当的资源。AWS 提供了大量功能，有助于您管理人员和机器身份及其权限。这些功能的最佳实践分为两个主要领域。
**Topics**
+ [身份管理](identity-management.md)
+ [权限管理](permissions-management.md)
# 身份管理
在操作安全 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 使用强大的登录机制
当不使用多重身份验证（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 使用临时凭证
进行任何类型的身份验证时，最好使用临时凭证而不是长期凭证，来降低或消除诸如凭证被无意泄露、共享或被盗之类的风险。
**期望结果：**为了降低长期凭证的风险，尽量对人类身份和机器身份使用临时凭证。长期凭证会带来诸多风险，例如通过上传到公共存储库而泄露。使用临时凭证可以大幅降低凭证被泄露的几率。
**常见反模式：**
+ 开发人员使用 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 安全地存储和使用密钥
工作负载需要能够自动向数据库、资源和第三方服务证明其身份。这是使用秘密访问凭证（如 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 依赖集中式身份提供程序
对于工作人员身份（员工和合同工），请依赖允许您在集中位置管理身份的身份提供程序。这样就可以更轻松地跨多个应用程序和系统管理访问权限，因为您可以从单一位置创建、分配、管理、撤销和审核访问权限。
**期望结果：**您有一个集中式身份提供程序，可以在其中集中管理员工用户、身份验证策略 [例如要求多重身份验证（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 定期审计和轮换凭证
定期审计和轮换凭证，以限制凭证可用于访问资源的时间。长期凭证会产生许多风险，可通过定期轮换长期凭证来降低这些风险。
**期望结果：**实施凭证轮换，以帮助降低长期凭证相关风险。定期审计并纠正不符合凭证轮换策略的情况。
**常见反模式：**
+ 不审计凭证的使用情况。
+ 不必要地使用长期凭证。
+ 使用长期凭证，不定期轮换。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
当您无法依赖于临时凭证而需要长期凭证时，请审计凭证，以验证定义的控制措施 [例如[多重身份验证](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 使用用户组和属性
根据用户组和属性来定义权限，可以减少策略的数量和复杂性，这样就更容易实现最低权限原则。您可以通过用户组，根据用户在企业中履行的职能，从一个位置管理多个用户的权限。当用户履行类似的职能但面向的是不同资源子集时，可以利用部门、项目或位置等属性来提供额外的一层权限范围。
**期望结果：**您可以将基于职能的权限更改应用到履行该职能的所有用户。利用组成员资格和属性管控用户的权限，减少在单个用户级别管理权限的需求。您在身份提供者（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)
# 权限管理
管理权限，控制需要访问 AWS 和您工作负载的人员和机器身份的访问权限。权限可让您控制哪些人可以在什么条件下访问哪些内容。通过为特定的人员身份和机器身份设置权限，可以向这些身份授予对特定资源执行特定服务操作的访问权限。此外，您可以为要授予的访问权限指定必须满足的条件。
可通过多种方式向不同类型的资源授予访问权限。一种方式是使用不同的策略类型。
IAM 中[基于身份的策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)属于*托管*或*内联*策略，会附加到 IAM 身份（用户、组或角色）。这些策略可让您指定该身份可执行哪些操作（其权限）。基于身份的策略可以进一步分类。
**托管策略** - 基于身份的独立策略，可附加到您的 AWS 账户中的多个用户、组和角色。有两种托管策略：
+ **AWS 托管策略** – 由 AWS 创建和管理的托管策略。
+ **客户管理型策略** – 您在 AWS 账户中创建和管理的托管策略。与 AWS 托管策略相比，客户管理型策略对策略的控制更精确。
托管策略是应用权限的首选方法。不过，您也可以使用直接添加到单个用户、组或角色的内联策略。内联策略维持策略与身份之间严格的一对一关系。删除身份即会删除内联策略。
大多数情况下，您应按照[最低权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)原则创建自己的客户管理型策略。
[基于资源的策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)附加到某个资源。例如，S3 存储桶策略是一个基于资源的策略。这些策略向一个主体授予权限，该主体既可以位于资源所在的账户中，也可以位于另一个账户中。有关支持基于资源的策略的服务列表，请参阅[使用 IAM 的 AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。
[权限边界](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)使用托管策略来设置管理员能够设定的最高权限。这样，您就可以为开发人员赋予创建和管理权限的能力，例如创建一个 IAM 角色，但限制他们可以授予的权限，让他们无法利用他们创建的角色提升自己的权限。
AWS 中的[基于属性的访问权限控制（ABAC）](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)让您能够根据属性（成为标签）来授予权限。这些标签可以附加到 IAM 主体（用户或角色）和 AWS 资源。管理员可以创建可重复使用的 IAM 策略，这些策略根据 IAM 主体的属性来应用权限。例如，作为管理员，您可以使用单个 IAM 策略，向您所在组织中的开发人员授予对与其项目标签匹配的 AWS 资源的访问权限。当开发人员团队为项目添加资源时，会自动根据属性应用权限，从而消除了对每个新资源进行策略更新的需要。
[Organizations 服务控制策略（SCP）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_scp)为组织或组织部门（OU）的账户成员定义最大权限。SCP *限制*基于身份的策略或基于资源的策略授予账户中实体（用户或角色）的权限，但*不授予*权限。
[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)会担任角色或联合用户。在使用 AWS CLI 或 AWS API 会话策略限制基于角色或用户身份的策略授予会话的权限时，传递会话策略。这些策略*限制*所创建会话的权限，但*不授予*权限。有关更多信息，请参阅[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)。
**Topics**
+ [SEC03-BP01 定义访问要求](sec_permissions_define.md)
+ [SEC03-BP02 授予最低访问权限](sec_permissions_least_privileges.md)
+ [SEC03-BP03 建立紧急访问流程](sec_permissions_emergency_process.md)
+ [SEC03-BP04 持续减少权限](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 为您的组织定义权限防护机制](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 基于生命周期管理访问权限](sec_permissions_lifecycle.md)
+ [SEC03-BP07 分析公共和跨账户访问](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 在组织内安全地共享资源](sec_permissions_share_securely.md)
+ [SEC03-BP09 与第三方安全地共享资源](sec_permissions_share_securely_third_party.md)
# SEC03-BP01 定义访问要求
管理员、最终用户或其他组件都需要访问工作负载的每个组件或资源。明确定义什么人或什么内容应该有权访问每个组件，选择适当的身份类型以及身份验证和授权方法。
**常见反模式：**
+ 在应用程序中进行硬编码或存储密码。
+ 向每个用户授予自定义权限。
+ 使用长期有效的凭证。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
管理员、最终用户或其他组件都需要访问工作负载的每个组件或资源。明确定义什么人或什么内容应该有权访问每个组件，选择适当的身份类型以及身份验证和授权方法。
应提供对组织内 AWS 账户的常规访问，方法是使用[联合身份访问](https://aws.amazon.com/identity/federation/)或集中式身份提供者。您还应将身份管理集中处理，确保对于 AWS 将访问集成到员工访问生命周期中已建立了既定做法。例如，当员工转岗到具有不同访问级别的职位时，该员工的小组成员资格也应进行更改以反映新的访问要求。
在定义非人类身份的访问要求时，请确定哪些应用程序和组件需要访问权限以及如何向其授予权限。建议使用通过最低权限访问模型构建的 IAM 角色。[AWS托管式策略](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)提供了预定义的 IAM 策略，这些策略涵盖了大多数常见使用案例。
AWS 服务（例如 [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) 和 [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)）有助于安全地将密钥与应用程序或工作负载分离。在 Secrets Manager 中，您可以为凭证建立自动轮换。您可以通过使用您在创建参数时指定的唯一名称，使用 Systems Manager 来引用脚本、命令、SSM 文档、配置和自动化工作流中的参数。
您可以使用 [AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 来获取 [IAM 中的临时安全凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)，这种凭证适用于在 AWS 外部运行的工作负载。您的工作负载可以使用与 AWS 应用程序所用的相同 [IAM 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)和 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)来访问 AWS 资源。
如果可能，请优先选择短期临时凭证而不是长期静态凭证。在一些场景中，需要具有编程访问权限和长期凭证的用户，此时请使用[访问密钥上次使用的信息](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)来轮换和删除访问密钥。
如果用户需要在 AWS 管理控制台之外与 AWS 交互，则需要编程式访问权限。授予编程式访问权限的方法取决于访问 AWS 的用户类型。
要向用户授予编程式访问权限，请选择以下选项之一。
****
| 哪个用户需要编程式访问权限？ | 目的 | 方式 |
| --- | --- | --- |
| IAM | （建议）使用控制台凭证作为临时凭证来签署向 AWS CLI、AWS SDK 或 AWS API 发出的编程请求。 | 按照您希望使用的界面的说明进行操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
| 人力身份 （在 IAM Identity Center 中管理的用户） | 使用临时凭证签署向 AWS CLI、AWS SDK 或 AWS API 发出的编程请求。 | 按照您希望使用的界面的说明进行操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
| IAM | 使用临时凭证签署向 AWS CLI、AWS SDK 或 AWS API 发出的编程请求。 | 按照《IAM 用户指南》中[将临时凭证用于 AWS 资源](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)中的说明进行操作。 |
| IAM | （不推荐使用）使用长期凭证签署向 AWS CLI、AWS SDK 或 AWS API 发出的编程请求。 | 按照您希望使用的界面的说明进行操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
## 资源
**相关文档：**
+ [基于属性的访问控制（ABAC）](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/)
+ [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)
+ [IAM Identity Center 的 AWS 托管式策略](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)
+ [AWS IAM 策略条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)
+ [IAM 使用案例](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html)
+ [移除不必要的凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [使用 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [如何根据 AWS 账户、OU 或组织来控制对 AWS 资源的访问](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/)
+ [使用 AWS Secrets Manager 中的增强搜索来轻松标识、安排和管理密钥](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/)
**相关视频：**
+ [在最多 60 分钟的时间内成为 IAM 策略高手](https://youtu.be/YQsK4MtsELU)
+ [职责分离、最低权限、委托和 CI/CD](https://youtu.be/3H0i7VyTu70)
+ [简化身份和访问管理以实施创新](https://www.youtube.com/watch?v=3qK0b1UkaE8)
# SEC03-BP02 授予最低访问权限
仅授予用户在特定条件下对特定资源执行特定操作所需的访问权限。使用组和身份属性来大规模动态设置权限，而不是为单个用户定义权限。例如，您可以允许一组开发人员访问，以便仅管理其项目的资源。使用这种方法，如果某个开发人员离开项目，则可以自动撤销该开发人员的访问权限，而无需更改底层访问策略。
**期望结果：**用户仅拥有其特定工作职能所需的最低权限。可以使用单独的 AWS 账户来将开发人员与生产环境隔离开来。当开发人员需要访问生产环境以执行特定任务时，他们仅在这些任务期间被授予有限和受控的访问权限。在他们完成必要的工作后，他们的生产访问权限会被立即撤销。您可以定期审核权限，并在不再需要时立即撤销权限，例如当用户变更角色或离开组织时。您可以将管理员权限限制在一个小型、受信任的组中，以降低暴露的风险。您仅向计算机或系统账户授予执行其预期任务所需的最低权限。
**常见反模式：**
+ 默认情况下，您向用户授予管理员权限。
+ 您使用根用户账户进行日常活动。
+ 您创建过于宽松的策略，而没有限定适当的范围。
+ 您的权限审核不频繁，这会导致权限蔓延。
+ 您完全依赖基于属性的访问权限控制来实现环境隔离或权限管理。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
[最低权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)原则规定，只应允许身份执行完成特定任务所需的最小一组操作。这样可使可用性、效率和安全性达到平衡。根据此原则运营，有助于限制意外访问，还有助于跟踪谁有权访问哪些资源。默认情况下，IAM 用户和角色没有任何权限。默认情况下，根用户具有完全访问权限，应受到严格控制和监控，并且仅用于[需要根访问权限的任务](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。
IAM 策略用于显式地为 IAM 角色或特定资源授予权限。例如，基于身份的策略可以附加到 IAM 组，而 S3 存储桶可由基于资源的策略控制。
创建 IAM 策略时，可以指定服务操作、资源以及为使 AWS 允许或拒绝访问而必须满足的条件。AWS 支持多种条件以协助您缩小访问权限范围。例如，通过使用 PrincipalOrgID [条件键](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)，如果请求者不属于您的 AWS 组织，则您可以拒绝操作。
您还可以控制 AWS 服务代表您发出的请求，例如要求 AWS CloudFormation 创建一个 AWS Lambda 函数，方法是使用 CalledVia 条件键。您可以对不同的策略类型进行分层，以建立纵深防御并限制用户的总体权限。您还可以限制可以授予哪些权限以及在什么条件下授予权限。例如，可以让工作负载团队为他们所构建的系统创建自己的 IAM 策略，但前提是他们应用[权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)来限制他们可以授予的最大权限。
### 实施步骤
+ **实施最低权限策略**：向 IAM 组和角色分配具有最低权限的访问策略，以反映您所定义的用户的角色或职能。
+ **通过单独的 AWS 账户隔离开发和生产环境**：为开发和生产环境使用单独的 AWS 账户，并使用[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)、资源策略和身份策略来控制它们之间的访问权限。
+ **基于 API 使用情况制定策略**：确定所需权限的一种方法是查看 AWS CloudTrail 日志。您可以使用此审核，根据用户在 AWS 内实际执行的操作来创建权限。[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 可以基于访问活动[自动生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) IAM 策略。您可以在组织或账户级别，使用 IAM Access Advisor 来[跟踪上次访问的关于某个特定策略的信息](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)。
+ **考虑使用[工作职能的 AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)**：当您开始创建细粒度的权限策略时，将 AWS 托管式策略用于常见的工作角色（如计费、数据库管理员和数据科学家）可能会有所帮助。这些策略有助于缩减用户具备的访问权限，同时您可以确定如何实施最低权限策略。
+ **移除不必要的权限：**检测并移除未使用的 IAM 实体、凭证和权限，以实现最低权限原则。可以使用 [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) 来识别外部和未使用的访问权限，而 [IAM Access Analyzer 策略生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)有助于微调权限策略。
+ **确保用户对生产环境的访问权限有限：**用户应只能访问具有有效使用案例的生产环境。在用户执行需要生产访问权限的特定任务后，应撤销访问权限。限制对生产环境的访问可帮助防止发生影响生产的意外事件，并缩小意外访问的影响范围。
+ **考虑权限边界：**[权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)功能使用托管式策略，来设置基于身份的策略可向 IAM 实体授予的最大权限。实体的权限边界仅允许实体执行其基于身份的策略和权限边界同时允许的操作。
+ **使用基于属性的访问权限控制和资源标签优化访问权限：**使用资源标签的[基于属性的访问权限控制（ABAC）](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)可用于优化权限（如果支持）。可以使用将主体标签与资源标签进行比较的 ABAC 模型，根据您定义的自定义维度来优化访问权限。这种方法可以简化组织中的权限策略并减少其数量。
+ 建议仅当主体和资源均归您的 AWS 组织拥有时，才使用 ABAC 进行访问权限控制。外部各方可以为自己的主体和资源使用与您的组织相同的标签名称和值。如果您仅依靠这些名称/值对来授予对外部主体或资源的访问权限，则可能会提供意想不到的权限。
+ **对 AWS Organizations 使用服务控制策略：**[Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 集中控制您组织中成员账户的最大可用权限。重要的是，您可以使用服务控制策略来限制成员账户中的根用户权限。还要考虑使用 AWS Control Tower，它提供可充实 AWS Organizations 的规范性托管控制。您还可以在 Control Tower 内定义自己的控制。
+ **为您的组织制定用户生命周期策略：**用户生命周期策略定义了当用户加入 AWS、更改作业角色或范围或不再需要访问 AWS 时要执行的任务。在用户生命周期的每个步骤中执行权限审核，来验证权限受到适当限制并避免权限蔓延。
+ **制定定期计划来审核权限并移除任何不需要的权限：**您应该定期审核用户访问权限，以验证用户没有过于宽松的访问权限。[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 和 IAM Access Analyzer 可以在审计用户权限时提供帮助。
+ **建立工作角色矩阵：**工作角色矩阵可直观显示您的 AWS 业务覆盖区域中所需的各种角色和访问级别。使用工作角色矩阵，您可以根据用户在组织内的职责来定义和分离权限。使用组，而不是将权限直接应用于各个用户或角色。
## 资源
**相关文档：**
+ [授予最低权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [IAM 实体的权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [用于编写最低权限 IAM 策略的方法](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/)
+ [使用 IAM 权限边界将权限管理委派给开发人员](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)
+ [使用上次访问的信息优化权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [IAM 策略类型及其使用时间](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
+ [使用 IAM policy simulator 测试 IAM policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)
+ [Guardrails in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [零信任架构：AWS 视角](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [如何使用 CloudFormation StackSets 实施最低权限原则](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
+ [基于属性的访问控制（ABAC）](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [查看用户活动以缩小策略范围](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [查看角色访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html)
+ [使用标记来组织环境并推动问责制](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html)
+ [AWS 标记策略](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
+ [为AWS资源添加标签](https://aws.amazon.com/premiumsupport/knowledge-center/tagging-resources/)
**相关视频：**
+ [新一代权限管理](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [零信任：AWS 视角](https://www.youtube.com/watch?v=1p5G1-4s1r0)
# SEC03-BP03 建立紧急访问流程
创建一个流程，便于在集中式身份提供程序偶尔出现问题时紧急访问您的工作负载。
必须针对可能导致紧急事件的不同故障模式设计流程。例如，在正常情况下，您的员工用户使用集中式身份提供程序联合到云端（[SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)）来管理其工作负载。但是，如果您的集中式身份提供程序出现故障，或者云中联合身份验证的配置被修改，则您的员工用户可能无法联合到云中。紧急访问流程允许授权管理员通过其他方式（例如其他联合形式或直接用户访问）访问云资源，以解决联合配置或工作负载的问题。在恢复正常的联合机制之前，将使用紧急访问流程。
**期望结果：**
+ 您已经定义并记录了算是紧急情况的故障模式：考虑您的正常情况以及用户管理其工作负载所依赖的系统。考虑这些依赖项中的每一个在哪些情形下会发生故障并导致紧急情况。您可能会发现[可靠性支柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html)中的问题和最佳实践有助于识别故障模式和构建更具韧性的系统，从而最大限度地降低发生故障的可能性。
+ 您已记录了将故障确认为紧急情况所必须遵循的步骤。例如，您可以要求身份管理员检查主身份提供程序和备用身份提供程序的状态，如果两者均不可用，则宣布身份提供程序故障为紧急事件。
+ 您已针对每种紧急情况或故障模式定义了紧急访问流程。应尽可能明确具体，这样可减少用户针对所有类型的紧急情况过度使用通用流程的倾向。紧急访问流程描述了每个流程的使用情形，以及哪些情况下不应使用该流程，并指出了可能适用的替代流程。
+ 您的流程有详细的说明和行动手册，便于快速有效地遵循。请记住，对用户来说，紧急事件可能让人很煎熬，他们可能面临极大的时间压力，因此流程设计应尽可能简单。
**常见反模式：**
+ 您没有详细记录并经过充分测试的紧急访问流程。您的用户没有为紧急情况做好准备，在出现紧急事件时遵循临时流程。
+ 您的紧急访问流程依赖于与普通访问机制相同的系统（例如集中式身份提供程序）。这意味着，此类系统的故障可能会同时影响您的正常访问和紧急访问机制，并削弱您从故障中恢复的能力。
+ 您的紧急访问流程被用于非紧急情况。例如，您的用户经常滥用紧急访问流程，因为他们发现直接进行更改比通过管道提交更改更容易。
+ 您的紧急访问流程未生成足够的日志用于审核这些流程，或者没有监控日志以提醒可能存在的流程滥用。
**建立此最佳实践的好处：**
+ 通过拥有记录详实且经过充分测试的紧急访问流程，您可以减少用户响应和解决紧急事件所花费的时间。这样可以缩短停机时间，提高您向客户提供的服务的可用性。
+ 您可以跟踪每个紧急访问请求，检测未经授权企图对非紧急事件滥用该过程的行为，并发出警报。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
本节针对与部署在 AWS 上的工作负载相关的几种故障模式，提供创建紧急访问流程的指导，首先是适用于所有故障模式的通用指导，然后是不同故障模式类型的特定指导。
**适用于所有故障模式的通用指南**
在针对故障模式设计紧急访问流程时，请考虑以下几点：
+ 记录流程的先决条件和假设：何时应使用该流程、何时不应使用该流程。它有助于详细说明故障模式并记录假设，例如其他相关系统的状态。例如，故障模式 2 的流程假设身份提供程序可用，但 AWS 上的配置已修改或已过期。
+ 预先创建紧急访问流程所需的资源（[SEC10-BP05](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html)）。例如，预先创建带有 IAM 用户和角色的紧急访问 AWS 账户，并在所有工作负载账户中创建跨账户 IAM 角色。这样可以验证在发生紧急事件时这些资源是否已准备就绪并且可用。通过预先创建资源，您就不必依赖 AWS [控制面板](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) API（用于创建和修改 AWS 资源），在紧急情况下，这些 API 可能不可用。此外，通过预先创建 IAM 资源，您也无需考虑[由于最终的一致性问题而可能出现的延迟。](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)
+ 将紧急访问流程纳入事件管理计划（[SEC10-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html)）。记录如何跟踪紧急事件并将其传达给组织中的其他人，例如同级团队、您的领导层，如果适用，还包括外部的客户和业务合作伙伴。
+ 在现有的服务请求工作流程系统（如果有）中定义紧急访问请求流程。通常，此类工作流程系统允许您创建受理表来收集有关请求的信息，在工作流程的每个阶段跟踪请求，并添加自动和手动审批步骤。将每个请求与事件管理系统中所跟踪的相应紧急事件关联起来。通过拥有统一的紧急访问系统，您可以在单个系统中跟踪这些请求，分析使用趋势并改进流程。
+ 确保您的紧急访问流程只能由授权用户启动，并且需要用户的同事或管理层（视情况而定）的批准。审批流程在工作时间内和工作时间之外应该能够有效运作。明确在主审批人抽不开身的情况下，如何允许辅助审批人审批请求，并沿管理链条上报，直至获得批准。
+ 为紧急访问流程和机制实施稳健的日志记录、监控和警报机制。为所有成功和失败的紧急访问尝试生成详细的审计日志。将活动与事件管理系统中正在发生的紧急事件关联起来，并在预期时间段之外发生操作时发出警报，或者在正常运行期间使用紧急访问账户时发出警报。紧急访问账户仅限在紧急情况下访问，因为“打碎玻璃”程序可视为后门。与安全信息和事件管理（SIEM）工具或 [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) 集成，来报告和审计紧急访问期间的所有活动。恢复正常操作后，自动轮换紧急访问凭证，并通知相关团队。
+ 定期测试紧急访问流程，以确保步骤清楚明了，并快速高效地授予正确的访问级别。您的紧急访问流程应作为事件响应模拟（[SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)）和灾难恢复测试（[REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)）的一部分进行测试。
**故障模式 1：用于联合到 AWS 的身份提供程序不可用**
如 [SEC02-BP04 依赖集中式身份提供程序](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)中所述，我们建议依靠集中式身份提供程序，来联合您的员工用户以授予对 AWS 账户的访问权限。您可以使用 IAM Identity Center 联合到 AWS 组织中的多个 AWS 账户，也可以使用 IAM 联合到单个 AWS 账户。在这两种情况下，员工用户都要先通过集中式身份提供程序进行身份验证，然后才会被重定向到 AWS 登录端点进行单点登录。
万一集中式身份提供程序不可用，员工用户就无法联合到 AWS 账户或管理其工作负载。在这种紧急情况下，您可以为一小部分管理员提供紧急访问流程，让他们访问 AWS 账户，来执行等不及集中式身份提供程序恢复正常的关键任务。例如，您的身份提供程序在 4 小时内不可用，在此期间，您需要修改生产账户中 Amazon EC2 Auto Scaling 组的上限，以应对客户流量意外激增的情况。您的紧急状况管理员应遵循紧急访问流程，以获得对特定生产 AWS 账户的访问权限并进行必要的更改。
紧急访问流程依赖于预先创建的紧急访问 AWS 账户，该账户仅用于紧急访问，并拥有 AWS 资源（如 IAM 角色和 IAM 用户）以支持紧急访问流程。在正常运营期间，任何人都不得访问紧急访问账户，而且您必须对滥用该账户的行为进行监控并发出警报（有关更多详情，请参阅前面的“通用指南”部分）。
紧急访问账户具有紧急访问 IAM 角色，有权在需要紧急访问的 AWS 账户中代入跨账户角色。这些 IAM 角色是预先创建的，并配置有信任策略，可信任应急账户的 IAM 角色。
紧急访问过程可以使用以下方法之一：
+ 您可以在紧急访问账户中为紧急状况管理员预先创建一组 [IAM 用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)，并使用相关的强密码和 MFA 令牌。这些 IAM 用户有权代入 IAM 角色，然后在需要紧急访问时，允许跨账户访问 AWS 账户。我们建议尽可能少地创建此类用户，并将每个用户分配给一个紧急状况管理员。在紧急情况下，紧急状况管理员用户使用其密码和 MFA 令牌码登录紧急访问账户，切换到紧急账户中的紧急访问 IAM 角色，最后切换到工作负载账户中的紧急访问 IAM 角色，以执行紧急更改操作。这种方法的优点是，每个 IAM 用户都分配给一个紧急状况管理员，您可以通过查看 CloudTrail 事件来了解哪个用户已登录。缺点是，您必须维护多个 IAM 用户及其关联的长寿命密码和 MFA 令牌。
+ 您可以使用紧急访问 [AWS 账户根用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)来登录紧急访问账户，代入用于紧急访问的 IAM 角色，并代入工作负载账户中的跨账户角色。建议为根用户设置一个强密码和多个 MFA 令牌。我们还建议将密码和 MFA 令牌存储在安全的企业凭证保管库中，该保管库可执行强身份验证和授权。您应确保密码和 MFA 令牌重置因素的安全：将账户的电子邮件地址设置为由云安全管理员监控的电子邮件分发列表，将账户的电话号码设置为同样由安全管理员监控的共享电话号码。这种方法的优点是只需管理一组根用户凭证。缺点是，由于这是共享用户，多个管理员都能以根用户身份登录。您必须审计企业保管库日志事件，以确定是哪位管理员查看了根用户密码。
**故障模式 2：AWS 上的身份提供程序配置已修改或已过期**
要允许您的员工用户联合到 AWS 账户，您可以使用外部身份提供程序配置 IAM Identity Center，或创建 IAM 身份提供程序（[SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)）。通常，您需要通过导入身份提供程序提供的 SAML 元数据 XML 文档，来配置这些服务。元数据 XML 文档包含一个 X.509 证书，该证书对应于身份提供程序用来签署其 SAML 断言的私钥。
管理员可能会错误地修改或删除 AWS 端的这些配置。在另一种情形下，导入到 AWS 的 X.509 证书可能会过期，而带有新证书的新元数据 XML 尚未导入到 AWS。这两种情形都可能使您的员工用户无法联合到 AWS，从而出现紧急情况。
在这种紧急情况下，您可以向您的身份管理员提供对 AWS 的访问权限以修复联合问题。例如，身份管理员使用紧急访问流程登录紧急访问 AWS 账户，切换到 Identity Center 管理员账户中的角色，并通过从身份提供程序导入最新的 SAML 元数据 XML 文档来更新外部身份提供程序配置，从而重新启用联合。修复联合后，您的员工用户将继续使用正常操作流程联合到其工作负载账户。
您可以按照前面的故障模式 1 中详述的方法来创建紧急访问流程。您可以向您的身份管理员授予最低访问权限，使其只能访问 Identity Center 管理员账户，并使用该账户对 Identity Center 执行操作。
**故障模式 3：Identity Center 中断**
如果发生 IAM Identity Center 或 AWS 区域中断这样的小概率事件，我们建议您设置一个可用于临时访问 AWS 管理控制台的配置。
紧急访问流程使用从身份提供程序到您的紧急账户中的 IAM 的直接联合。有关流程和设计注意事项的详细信息，请参阅《[设置对 AWS 管理控制台的紧急访问](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)》。
### 实施步骤
**针对所有故障模式的通用步骤**
+ 创建专门用于紧急访问流程的 AWS 账户。预先创建账户中所需的 IAM 资源，例如 IAM 角色或 IAM 用户，以及可选的 IAM 身份提供程序。此外，在工作负载 AWS 账户中预先创建跨账户 IAM 角色，并与紧急访问账户中的相应 IAM 角色建立信任关系。您可以将 [CloudFormation StackSets 与 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) 结合使用，在您组织的成员账户中创建此类资源。
+ 创建 AWS Organizations [服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)（SCP），以拒绝删除和修改成员 AWS 账户中的跨账户 IAM 角色。
+ 对紧急访问 AWS 账户启用 CloudTrail，并将跟踪事件发送到日志收集 AWS 账户中的中央 S3 存储桶。如果您使用 AWS Control Tower 来设置和管理您的 AWS 多账户环境，则您使用 AWS Control Tower 创建或在 AWS Control Tower 中注册的每个账户默认情况下都已启用 CloudTrail，并发送到专用日志存档 AWS 账户中的 S3 存储桶。
+ 通过创建 EventBridge 规则来匹配紧急 IAM 角色所执行的控制台登录和 API 活动，来监控紧急访问账户的活动。当事件管理系统中所跟踪的正在发生的紧急事件之外出现活动时，向安全运营中心发送通知。
**针对“故障模式 1：用于联合到 AWS 的身份提供程序不可用”和“故障模式 2：AWS 上的身份提供程序配置已修改或已过期”的其他步骤**
+ 根据您选择的紧急访问机制，预先创建资源：
+ **使用 IAM 用户：**使用强密码和关联的 MFA 设备预先创建 IAM 用户。
+ **使用紧急账户的根用户：**为根用户配置一个强密码，并将该密码存储在您的企业凭证库中。将多个物理 MFA 设备与根用户关联，并将设备存放在紧急状况管理员团队成员可以快速访问的位置。
**针对“故障模式 3：Identity Center 中断”的其他步骤**
+ 如[设置对 AWS 管理控制台的紧急访问](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)中所详述的那样，在紧急访问 AWS 账户中，创建 IAM 身份提供程序，以启用从身份提供程序的直接 SAML 联合。
+ 在 IdP 中创建没有成员的紧急行动组。
+ 在紧急访问账户中创建与紧急行动组相对应的 IAM 角色。
## 资源
**相关的 Well-Architected 最佳实践：**
+ [SEC02-BP04 依赖集中式身份提供程序](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
+ [SEC03-BP02 授予最低访问权限](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html)
+ [SEC10-BP02 制定事件管理计划](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
+ [SEC10-BP07 执行实际演练](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html)
**相关文档：**
+ [设置对 AWS 管理控制台的紧急访问](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)
+ [使 SAML 2.0 联合用户能够访问 AWS 管理控制台](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)
+ [Break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**相关视频：**
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI)
**相关示例：**
+ [AWS Break Glass 角色](https://github.com/awslabs/aws-break-glass-role)
+ [AWS 客户行动手册框架](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS 事件响应行动手册样本](https://github.com/aws-samples/aws-incident-response-playbooks)
# SEC03-BP04 持续减少权限
当您的团队确定所需的访问权限时，删除不需要的权限，并建立审核流程以实现最低权限。持续监控并删除供人类和机器访问的未使用的身份和权限。
**期望结果：**权限策略应遵循最低权限原则。随着工作职责和角色变得更加明确，需要审查您的权限策略以删除不必要的权限。如果无意中泄露或未经授权访问凭证，这种方法会缩小影响范围。
**常见反模式：**
+ 默认为向用户授予管理员权限。
+ 创建过于宽松但没有完全管理员权限的策略。
+ 保留不再需要的权限策略。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
当团队和项目刚刚起步时，可以使用宽松的权限策略来激发创新并提高敏捷性。例如，在开发或测试环境中，开发人员可以获得广泛的访问权限以使用各种 AWS 服务。我们建议您持续评估访问权限，并仅限于访问完成当前作业所必需的服务和服务操作。对于人类和机器身份，均建议进行此项评估。机器身份有时称为系统或服务账户，是让 AWS 访问应用程序或服务器的身份。这种访问权限在生产环境中尤其重要，因为在该环境中，过于宽松的权限会产生广泛的影响，并可能暴露客户数据。
AWS 提供多种方法来帮助识别未使用的用户、角色、权限和凭证。AWS 还可帮助分析 IAM 用户和角色（包括关联的访问密钥）的访问活动，以及对 AWS 资源（如 Amazon S3 存储桶中的对象）的访问。AWS Identity and Access Management Access Analyzer 策略生成可帮助您根据主体与之交互的实际服务和操作来创建限制性权限策略。[基于属性的访问权限控制（ABAC）](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)可以帮助简化权限管理，因为您可以使用其属性向用户提供权限，而不必将权限策略直接附加到每个用户。
### 实施步骤
+ **使用 [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)：**IAM Access Analyzer 帮助您标识企业和账户中[与外部实体共享](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html)的资源，例如 Amazon Simple Storage Service（Amazon S3）存储桶或 IAM 角色。
+ **使用 [IAM Access Analyzer 策略生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)：**IAM Access Analyzer 策略生成可帮助您[基于 IAM 用户或角色的访问活动创建精细的权限策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks)。
+ **在生产之前跨较低环境测试权限：**首先，使用 [less critical sandbox and development environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/understanding-the-devops-environments.html)，通过 IAM Access Analyzer 测试各种工作职能所需的权限。然后，在将这些权限应用于生产之前，在测试、质量保证和暂存环境中逐步收紧和验证这些权限。较低的环境最初可以拥有更宽松的权限，因为服务控制策略（SCP）通过限制所授予的最大权限来强制实施护栏。
+ **确定 IAM 用户和角色的可接受时间范围和使用策略：**使用[上次访问时间戳](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html)可[识别未使用的用户和角色](https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/)并将它们移除。查看关于服务和操作的上次访问情况的信息，以确定和[设置特定用户和角色的权限范围](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)。例如，您可以使用关于上次访问情况的信息，以确定您的应用程序角色需要执行的特定 Amazon S3 操作，并只允许该角色访问这些操作。AWS 管理控制台中提供了上次获取的信息功能，您也可以对这些功能进行编程，以便将它们整合到您的基础架构工作流程和自动化工具中。
+ **考虑[在 AWS CloudTrail 中记录数据事件](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html)：**默认情况下，CloudTrail 不会记录 Amazon S3 对象级活动（例如 `GetObject` 和 `DeleteObject`）或 Amazon DynamoDB 表活动（例如 `PutItem` 和 `DeleteItem`）等数据事件。考虑对这些事件使用日志记录，以确定哪些用户和角色需要访问特定的 Amazon S3 对象或 DynamoDB 表项目。
## 资源
**相关文档：**
+ [授予最低权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [移除不必要的凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [什么是 AWS CloudTrail？](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [使用 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [ 记录和监控 DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [ 对 Amazon S3 存储桶和对象使用 CloudTrail 事件日志记录 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)
+ [ 获取您的 AWS 账户 的凭证报告](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)
**相关视频：**
+ [在最多 60 分钟的时间内成为 IAM 策略高手](https://youtu.be/YQsK4MtsELU)
+ [职责分离、最低权限、委托和 CI/CD](https://youtu.be/3H0i7VyTu70)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive ](https://www.youtube.com/watch?v=YMj33ToS8cI)
# SEC03-BP05 为您的组织定义权限防护机制
使用权限防护机制来减少可向主体授予的可用权限的范围。权限策略评估链包括您的防护机制，用于在做出授权决策时确定主体的*有效权限*。 您可以使用基于层的方法定义防护机制。在整个企业内广泛地应用一些防护机制，而对临时访问会话则以细粒度方式应用另一些防护机制。
**期望结果：**您可以使用单独的 AWS 账户对环境进行明确隔离。 使用服务控制策略（SCP）定义整个企业内的权限防护机制。在更靠近组织根级别的层次结构上设置较为广泛的防护机制，而在更靠近单独账户的级别上设置更严格的防护机制。
在支持资源策略的情况下，使用资源策略定义主体获得资源访问权限必须满足的条件。在适用的情况下，还应使用资源策略缩小允许操作的范围。在管理工作负载权限的主体上设定了权限边界，将权限管理委托给单独的工作负载负责人。
**常见反模式：**
+ 在 [AWS 组织](https://aws.amazon.com/organizations/)内创建成员 AWS 账户，但不使用 SCP 来限制其根凭证的使用和可用权限。
+ 根据最低权限原则分配了权限，但没有对可以授予的最大权限集施加防护机制。
+ 依靠 AWS IAM 的*隐式拒绝*基础来限制权限，相信策略不会授予非预期的*显式允许*权限。
+ 在同一个 AWS 账户中运行多个工作负载环境，然后依靠 VPC、标签或资源策略等机制来强制实施权限边界。
**建立此最佳实践的好处：**权限防护机制有助于建立人们对无法授予不需要的权限的信心，即使权限策略尝试这样做也是如此。 这样便可以减少需要考虑的最大权限范围，从而简化权限的定义和管理。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
我们建议您使用基于层的方法，为企业定义权限防护机制。在应用了额外的层时，这种方法可以系统性地减少可能的最大权限集。利用这种方法，您可以根据最低权限原则授予访问权限，从而减少由于策略配置错误而导致意外访问的风险。
建立权限防护机制的第一步是将您的工作负载和环境隔离到单独的 AWS 账户中。如果没有显式权限，一个账户的主体无法访问另一个账户中的资源，即使两个账户位于同一 AWS 组织或在同一[组织单位（OU）](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html)下也是如此。您可以使用 OU 将要管理的账户分组为一个单位。
接下来，您需要减少可向企业成员账户中的主体授予的最大权限集。为此，您可以使用[服务控制策略（SCP）](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)，您可以将其应用于 OU 或账户。SCP 可以强制执行常见的访问控制措施，例如限制对特定 AWS 区域的访问，防止资源被删除，或者禁用存在潜在风险的服务操作。您应用到组织根的 SCP 仅影响其成员账户，不影响管理账户。 SCP 仅管理企业中的主体。您的 SCP 不管理企业外部访问您资源的主体。
如果您使用的是 [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)，则可以利用其 [controls](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-controls-work) 和 [landing zones](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) 作为权限护栏和多账户环境的基础。登录区提供了一个预先配置的安全基线环境，为不同的工作负载和应用程序提供了单独的账户。这些护栏通过结合使用服务控制策略（SCP）、AWS Config 规则和其它配置，围绕安全性、运营和合规性实施强制性控制措施。但是，在使用 Control Tower 护栏和登录区以及自定义组织 SCP 时，请遵循 AWS 文档中概述的最佳实践来避免冲突并确保适当的治理，这一点至关重要。有关在 Control Tower 环境中管理 SCP、账户和组织单位（OU）的详细建议，请参阅 [AWS Control Tower guidance for AWS Organizations](https://docs.aws.amazon.com/controltower/latest/userguide/orgs-guidance.html)。
通过遵守这些准则，可以有效地利用 Control Tower 的护栏、登录区和自定义 SCP，同时缓解潜在冲突并确保对多账户 AWS 环境进行适当的治理和控制。
下一步是使用 [IAM 资源策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)来限定您可以对其所管理的资源采取的可用操作的范围，以及代理主体必须满足的任何条件。这一点可以很宽泛，只要主体是您的组织的一部分，就可以允许执行所有操作（使用 PrincipalOrgId [条件键](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)），也可以精细到仅允许特定 IAM 角色执行特定操作。对于 IAM 角色信任策略中的条件，您可以采用类似的方法。 如果资源或角色信任策略在所管理的角色或资源的同一个账户中，明确指定了主体，则该主体不需要附加授予相同权限的 IAM 策略。 如果主体与资源位于不同的账户中，则主体就需要附加 IAM 策略来授予这些权限。
通常，工作负载团队需要管理其工作负载所需的权限。 这可能要求团队创建新的 IAM 角色和权限策略。 您可以在 [IAM 权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)内获取允许团队授予的最大权限范围，并将此文档关联到一个 IAM 角色，然后团队可以使用该角色来管理其 IAM 角色和权限。 通过这种方法，团队能够灵活地完成其工作，同时降低拥有 IAM 管理访问权限的风险。
更精细的步骤是实施*特权访问管理*（PAM）和*临时提升的访问权限管理*（TEAM）技术。 PAM 的一个例子是要求主体在采取特权操作之前进行多重身份验证。 有关更多信息，请参阅《[配置受 MFA 保护的 API 访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)》。TEAM 需要一种解决方案，来管理主体在获得提升访问权限时需经过的审批，以及允许获得提升访问权限的时间范围。 一种方法是将主体临时添加到具有更高访问权限的 IAM 角色的角色信任策略中。 另一种方法是，在正常运行情况下，使用[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)缩小 IAM 角色向主体授予的权限范围，然后在批准的时段内暂时取消此限制。要了解有关 AWS 和精选合作伙伴验证的解决方案的更多信息，请参阅《[临时提升访问权限](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html)》。
### 实施步骤
1. 将您的工作负载和环境存放在单独的 AWS 账户中。
1. 使用 SCP 来减少可向企业成员账户中的主体授予的最大权限集。
1. 在定义 SCP 来减少可向组织成员账户中的主体授予的最大权限集时，您可以选择*允许列表* 或*拒绝列表* 方法。允许列表策略显式指定允许的访问权限，并隐式阻止所有其它访问权限。拒绝列表策略显式指定不允许的访问权限，并且默认情况下允许所有其它访问权限。这两种策略都有其优势和权衡，适当的选择取决于您组织的具体要求和风险模型。有关更多详细信息，请参阅 [Strategy for using SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html)。
1. 此外，请查看 [service control policy examples](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)，来了解如何有效地构造 SCP。
1. 使用 IAM 资源策略缩小范围，并指定允许对资源执行操作的条件。 使用 IAM 角色信任策略中的条件来创建对代入角色的限制。
1. 将 IAM 权限边界分配给 IAM 角色，然后工作负载团队可以使用该角色来管理自己的工作负载的 IAM 角色和权限。
1. 根据您的需求评估 PAM 和 TEAM 解决方案。
## 资源
**相关文档：**
+ [ 上的数据边界AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/)
+ [使用数据边界建立权限防护机制](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_data-perimeters.html)
+ [策略评估逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)
**相关示例：**
+ [服务控制策略示例](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
**相关工具：**
+ [AWS 解决方案：临时提升的访问权限管理](https://aws-samples.github.io/iam-identity-center-team/)
+ [经过验证的 TEAM 安全合作伙伴解决方案](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html#validatedpartners)
# SEC03-BP06 基于生命周期管理访问权限
在企业内主体（用户、角色和群组）的整个生命周期中，监控和调整授予主体的权限。在用户更改角色时调整组成员资格，并在用户离开企业时移除访问权限。
**期望结果：**您可以在企业内主体的整个生命周期中监控和调整权限，从而降低不必要权限的风险。在创建用户时授予合适的访问权限。随着用户职责的变化，您会修改访问权限，当用户不再活跃或已离开企业时，您会删除访问权限。您集中管理用户、角色和组的更改。您使用自动化方法将更改传播到 AWS 环境中。
**常见反模式：**
+ 预先向身份授予过多或宽泛的访问权限，这些权限超出了最初的需求。
+ 随着身份的角色和职责随着时间推移而发生变化，您未审核和调整访问权限。
+ 让无效或离职的身份保留有效的访问权限。这样会增加未经授权访问的风险。
+ 没有利用自动化功能来管理身份的生命周期。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
在身份（例如用户、角色、组）的整个生命周期中，谨慎管理和调整授予身份的访问权限。这一生命周期包括初始入职阶段、角色和职责的持续变化以及最终的离职或终止。根据生命周期的阶段主动管理访问权限，维护正确的访问权限级别。遵守最低权限原则，减少授予过多或不必要访问权限的风险。
您可以直接在 AWS 账户中管理 IAM 用户的生命周期，也可以通过从员工身份提供者到 [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 的联合身份验证来进行管理。对于 IAM 用户，您可以在 AWS 账户中创建、修改和删除用户及其关联权限。对于联合用户，您可以使用 IAM Identity Center，通过 [System for Cross-domain Identity Management](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html)（SCIM）协议，从组织的身份提供者同步用户和组信息，从而管理这些用户的生命周期。
SCIM 是一种开放标准协议，用于跨不同系统自动预置和取消预置用户身份。通过使用 SCIM 将身份提供者与 IAM Identity Center 集成，您可以自动同步用户和组信息，这有助于验证访问权限的授予、修改或撤销，而这些操作是基于企业中权威身份来源中的更改而进行的。
随着企业内员工角色和职责的变化，相应地调整员工的访问权限。您可以使用 IAM Identity Center 的权限集来定义不同的工作角色或职责，并将其关联到相应的 IAM 策略和权限。当员工的角色发生变化时，您可以更新向他们分配的权限集以反映他们的新职责。验证他们是否具有必要的访问权限，同时还遵守了最低权限原则。
### 实施步骤
1. 定义并记录访问权限管理生命周期流程，包括授予初始访问权限、定期审查和离职的程序。
1. 实施 [IAM 角色、组和权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)，以便从整体上管理访问权限并实施允许的最高访问权限级别。
1. 使用 IAM Identity Center，与[联合身份提供者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)（例如 Microsoft Active Directory、Okta、Ping Identity）集成，作为用户和组信息的权威来源。
1. 使用 [SCIM](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) 协议，来将用户和组信息从身份提供者同步到 IAM Identity Center 的身份存储中。
1. 在 IAM Identity Center 中创建[权限集](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)，用于表示组织中的不同工作角色或职责。为每个权限集定义相应的 IAM 策略和权限。
1. 实施定期的访问权限审查，及时撤销访问权限，并持续改进访问权限管理生命周期流程。
1. 向员工提供访问权限管理最佳实践的培训，增强员工的意识。
## 资源
**相关最佳实践：**
+ [SEC02-BP04 依赖集中式身份提供程序](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
**相关文档：**
+ [管理您的身份源 ](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)
+ [在 IAM Identity Center 中管理身份](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [使用 AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [IAM Access Analyzer 策略生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)
**相关视频：**
+ [AWS re:Inforce 2023 - Manage temporary elevated access with AWS IAM Identity Center](https://www.youtube.com/watch?v=a1Na2G7TTQ0)
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://www.youtube.com/watch?v=TvQN4OdR_0Y&t=444s)
+ [AWS re:Invent 2022 - Harness power of IAM policies & rein in permissions w/Access Analyzer](https://www.youtube.com/watch?v=x-Kh8hKVX74&list=PL2yQDdvlhXf8bvQJuSP1DQ8vu75jdttlM&index=11)
# SEC03-BP07 分析公共和跨账户访问
持续监控重点关注公共访问和跨账户访问的调查发现。将公共访问和跨账户访问限制为仅限需要此访问的特定资源。
**期望结果：**了解您的哪些 AWS 资源是共享的，以及与谁共享。持续监控和审计您的共享资源，以验证它们仅与授权的主体共享。
**常见反模式：**
+ 不保留共享资源的清单。
+ 跨账户访问或公开访问资源时，没有遵循流程。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
如果您的账户在 AWS Organizations 中，您可以向整个组织、特定组织单位或个人账户授予资源访问权限。如果您的账户不是某个组织的成员，您可以与个人账户共享资源。您可以使用基于资源的策略 [例如 [Amazon Simple Storage Service（Amazon S3）存储桶策略](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)] 或通过允许其他账户中的主体代入您账户中的 IAM 角色来授予直接跨账户访问权限。使用资源策略时，请验证访问权限是否仅授予给经过授权的主体。建立一个流程来审批所有需要可公开访问的资源。
[AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) 使用[可证明安全性](https://aws.amazon.com/security/provable-security/)来标识从账户的外部访问某个资源时的所有访问路径。它持续审核资源策略，并报告公开访问和跨账户访问的调查发现，以使您能够轻松分析可能非常宽泛的访问权限。请考虑将 IAM Access Analyzer 与 AWS Organizations 一起配置，以验证您是否能够查看所有账户。IAM Access Analyzer 还允许您在部署资源权限之前[预览调查发现](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html)。这样，您便可以验证策略更改仅按照意图，授权对您资源的公共和跨账户访问。在设计多账户访问权限时，您可以使用[信任策略](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)来控制在何种情况下可代入某个角色。例如，您可以使用 [`PrincipalOrgId` 条件键拒绝尝试从您的 AWS Organizations 之外代入角色](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)。
[AWS Config 可以报告配置错误的资源](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html)，并可以通过 AWS Config 策略检查来检测配置了公有访问权限的资源。诸如 [AWS Control Tower](https://aws.amazon.com/controltower/) 和 [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 等服务简化了跨 AWS Organizations 的侦测性控制和护栏的部署，可以识别并修复公开暴露的资源。例如，AWS Control Tower 具有托管防护机制，可以检测是否有任何[可由 AWS 账户恢复的 Amazon EBS 快照](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)。
### 实施步骤
+ **考虑将 [AWS Config 用于 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)：**AWS Config 允许您将 AWS Organizations 中多个账户的结果聚合到委派管理员账户中。这样可提供全面的视图，并允许您[跨账户部署 AWS Config 规则以检测可公开访问的资源](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)。
+ **配置 AWS Identity and Access Management Access Analyzer：**IAM Access Analyzer 有助于您识别组织和账户中[与外部实体共享的](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html)资源，例如 Amazon S3 存储桶或 IAM 角色。
+ **在 AWS Config 中使用自动修复来响应 Amazon S3 存储桶的公共访问配置中的更改：**[您可以自动启用 Amazon S3 存储桶的阻止公共访问设置](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/)。
+ **实施监控和警报，以确定 Amazon S3 存储桶是否已变为公共：**您必须具备[监控或警报机制](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/)，以便确定 Amazon S3 屏蔽公共访问权限何时关闭，以及 Amazon S3 存储桶是否变为公共。此外，如果您正在使用 AWS Organizations，您可以创建[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)，以阻止对 Amazon S3 公共访问策略进行更改。[AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html) 可对具有开放访问权限的 Amazon S3 存储桶进行检查。如果向每个人授予“上传/删除”权限，那么任何人都可以向存储桶添加项目或者修改或删除存储桶中的项目，这样会产生潜在的安全问题。Trusted Advisor 检查可检查显式存储桶权限，以及可能覆盖存储桶权限的关联存储桶策略。您也可以使用 AWS Config 来监控 Amazon S3 存储桶是否具有公共访问权限。有关更多信息，请参阅《[如何使用 AWS Config 来监控和响应允许公共访问的 Amazon S3 存储桶](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/)》。
在审核 Amazon S3 存储桶的访问控制时，务必考虑存储在存储桶中的数据的性质。[Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) 是一项旨在协助您发现和保护敏感数据的服务，如个人身份信息（PII）、受保护健康信息（PHI）以及诸如私有密钥或 AWS 访问密钥等凭证。
## 资源
**相关文档：**
+ [使用 AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [AWS Control Tower 控件库 ](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html)
+ [AWS 基础安全最佳实践标准](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+ [AWS Config 托管规则](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)
+ [AWS Trusted Advisor 检查引用](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html)
+ [ 通过 Amazon EventBridge 监控 AWS Trusted Advisor 的检查结果 ](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html)
+ [ 管理组织内所有账户的 AWS Config 规则 ](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)
+ [AWS Config 和 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)
+ [ 将您的 AMI 设为可在 Amazon EC2 中公开使用 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-intro.html#block-public-access-to-amis)
**相关视频：**
+ [保护多账户环境的最佳实践](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [深入了解 IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0)
# SEC03-BP08 在组织内安全地共享资源
随着工作负载数量的增长，您可能需要共享对这些工作负载中资源的访问权限，或者跨多个账户多次预置资源。您可能需要进行构造来划分环境，例如划分成开发、测试和生产环境。但是，采取相互分离的构造并不会限制您安全共享权限。通过共享重叠的组件，您可以降低运维开销，并提供一致的体验，而不必猜测在多次创建同一资源时可能遗漏了什么。
**期望结果：**通过使用安全的方法在组织内共享资源，最大限度地减少意外访问，并帮助实施数据丢失防护计划。与管理单个组件相比，降低了运维开销，减少了多次手动创建同一组件时引起的错误，并提高了工作负载的可扩展性。您可以在多点故障场景中缩短问题解决时间，并在确定何时不再需要某个组件时更有信心。有关分析外部共享资源的规范性指南，请参阅《[SEC03-BP07 分析公共和跨账户访问](sec_permissions_analyze_cross_account.md)》。
**常见反模式：**
+ 缺少对意外的外部共享进行持续监控和自动发出警报的流程。
+ 缺乏关于应分享什么和不应分享什么的基准。
+ 默认采用广泛的开放政策，而不是在需要时明确地分享。
+ 手动创建在需要时重叠的基础资源。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
设计您的访问控制和模式，以安全地管理共享资源的使用，并且仅与可信实体共享。监控共享资源，持续检查共享资源访问权限，并在不适当或意外共享时发出警报。查看[分析公共和跨账户访问](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)，以帮助您建立治理，减少仅对需要访问的资源的外部访问权限，并建立持续监控和自动警报的流程。
AWS Organizations 内的跨账户共享受[多个 AWS 服务](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)支持，比如 [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html)、[Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html) 和 [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html)。这些服务允许将数据共享到中心账户，可从中心账户访问，或从中心账户管理资源和数据。例如，AWS Security Hub CSPM 可将调查发现从个人账户转移到中心账户，在那里您可以查看所有调查发现。AWS Backup 可以对资源进行备份并在多个账户之间共享。可以使用 [AWS Resource Access Manager](https://aws.amazon.com/ram/)（AWS RAM）共享其它公用资源，如 [VPC subnets and Transit Gateway attachments](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc)、[AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) 或 [Amazon SageMaker AI pipelines](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker)。
要限制您的账户只能在组织内共享资源，请使用[服务控制策略（SCP）](https://docs.aws.amazon.com/ram/latest/userguide/scp.html)来防止向外部主体授予访问权限。共享资源时，将基于身份的控制与网络控制结合起来，[为组织创建数据边界](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)，以帮助防止意外的访问。数据边界是一组预防性防护机制，用于帮助验证是否只有您的可信身份才能访问预期网络中的可信资源。这些控制措施会施加适当的限制，确定哪些资源可以共享，并防止共享或暴露不应被外泄的资源。例如，作为数据边界的一部分，您可以使用 VPC 端点策略和 `AWS:PrincipalOrgId` 条件，确保访问您的 Amazon S3 存储桶的身份属于您的组织。请务必注意，[SCP 不适用于服务相关角色或 AWS 服务主体](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions)。
使用 Amazon S3 时，请[关闭您的 Amazon S3 存储桶的 ACL](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html)，并使用 IAM 策略来定义访问控制。为了从 [Amazon CloudFront](https://aws.amazon.com/cloudfront/) [限制对 Amazon S3 来源的访问](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)，请从来源访问身份（OAI）迁移到来源访问控制（OAC），后者支持使用其他功能，包括使用 [AWS Key Management Service](https://aws.amazon.com/kms/) 进行服务器端加密。
在某些情况下，您可能希望允许在组织外部共享资源，或授予第三方访问您资源的权限。有关管理外部共享资源的权限的规范性指南，请参阅《[权限管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html)》。
### 实施步骤
1. **使用 AWS Organizations：**AWS Organizations 是一项账户管理服务，使您可以将多个 AWS 账户整合到您所创建的组织中并集中进行管理。您可以将账户分组为组织单位（OU），并将不同的策略附加到每个 OU，以帮助您满足预算、安全性和合规性需求。您还可以控制 AWS 人工智能（AI）和机器学习（ML）服务收集和存储数据的方式，并使用与 Organizations 集成的 AWS 服务的多账户管理。
1. **将 AWS Organizations 与 AWS 服务集成：**当您使用 AWS 服务在组织的成员账户中代表您执行任务时，AWS Organizations 会在每个成员账户中为该服务创建一个 IAM 服务相关角色（SLR）。您应使用 AWS 管理控制台、AWS API 或 AWS CLI 管理可信访问。有关开启可信访问权限的规范性指南，请参阅《[将 AWS Organizations 与其它 AWS 服务结合使用](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html)》和《[可与 Organizations 一起使用的 AWS 服务](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)》。
1. **建立数据边界：**数据边界提供了明确的信任和所有权边界。在 AWS 上，它通常表示为由 AWS Organizations 管理的 AWS 组织，以及访问您的 AWS 资源的任何本地网络或系统。建立数据边界的目标，是验证如果身份可信、资源可信并且网络符合预期，则支持进行访问。然而，建立数据边界并不是一个放之四海皆准的方法。根据您的特定安全风险模型和要求，评估并采纳 [Building a Perimeter on AWS whitepaper](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/welcome.html) 中概述的控制目标。您应仔细考虑自己独特的风险状况，并实施符合您安全需求的边界控制措施。
1. **在 AWS 服务中使用资源共享并相应进行限制：**许多 AWS 服务支持您与另一账户共享资源，或以另一账户中的资源为目标，比如[亚马逊机器映像（AMI）](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)和 [AWS Resource Access Manager（AWS RAM）](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html)。限制 `ModifyImageAttribute` API 以指定可信账户，从而与之共享 AMI。当需要使用 AWS RAM 来将共享限制于您的组织内部时，请指定 `ram:RequestedAllowsExternalPrincipals` 条件，以帮助防止来自不可信身份的访问。有关规范性指南和注意事项，请参阅《[资源共享和外部目标](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html)》。
1. **使用 AWS RAM 在一个账户中或与其它 AWS 账户安全共享：**[AWS RAM](https://aws.amazon.com/ram/) 有助于您与账户中的角色和用户以及与其它 AWS 账户安全地共享已创建的资源。在多账户环境中，AWS RAM 使您能够一次性创建资源并与其他账户共享。这种方法有助于降低运维开销，同时通过与 Amazon CloudWatch 和 AWS CloudTrail 的集成提供一致性、可见性和可审计性，使用跨账户访问时无法获得这些好处。
如果您拥有以前使用基于资源的策略共享的资源，则可以使用 [`PromoteResourceShareCreatedFromPolicy` API](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) 或等效 API 将资源共享升级为完全 AWS RAM 资源共享。
在某些情况下，您可能需要采取其他步骤来共享资源。例如，要共享加密快照，您需要[共享 AWS KMS 密钥](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key)。
## 资源
**相关最佳实践：**
+ [SEC03-BP07 分析公共和跨账户访问](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP09 与第三方安全地共享资源](sec_permissions_share_securely_third_party.md)
+ [SEC05-BP01 创建网络层](sec_network_protection_create_layers.md)
**相关文档：**
+ [存储桶拥有者向并非其拥有的对象授予跨账户权限](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [如何将信任策略与 IAM 结合使用](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [在 AWS 上构建数据边界](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [如何在向第三方授予对 AWS 资源的访问权限时使用外部 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [可与 AWS Organizations 一起使用的 AWS 服务](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [ 在 AWS 上建立数据边界：仅允许可信身份获取公司数据 ](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)
**相关视频：**
+ [使用 AWS Resource Access Manager 实现精细访问](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [使用 VPC 端点保护您的数据边界](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [ 在 AWS 上建立数据边界](https://www.youtube.com/watch?v=SMi5OBjp1fI)
**相关工具：**
+ [ 数据边界策略示例 ](https://github.com/aws-samples/data-perimeter-policy-examples)
# SEC03-BP09 与第三方安全地共享资源
云环境的安全性不仅仅限于您的组织。您的组织有一部分数据可能要依赖第三方来管理。管理第三方托管系统的权限，应遵循及时访问的做法，使用最低权限原则和临时凭证。通过与第三方密切合作，您既可以缩小影响范围，又可以降低意外访问的风险。
**期望结果：**您避免使用长期 AWS Identity and Access Management（IAM）凭证，例如访问密钥和私密密钥，因为如果滥用，它们会构成安全风险。相反，可以使用 IAM 角色和临时凭证来改善您的安全状况，并最大限度地减少管理长期凭证的运营开销。在向第三方授予访问权限时，请在 IAM 信任策略中将通用唯一标识符（UUID）用作外部 ID，并将附加到角色的 IAM 策略置于您的控制之下，来确保最低权限访问。有关分析外部共享资源的规范性指南，请参阅 [SEC03-BP07 分析公共和跨账户访问](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)。
**常见反模式：**
+ 采用默认的 IAM 信任策略，不附加任何条件。
+ 使用长期 IAM 凭证和访问密钥。
+ 重用外部 ID。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
您可能会希望允许在 AWS Organizations 外部共享资源，或授予第三方访问您账户的权限。例如，第三方提供的监控解决方案可能会需要访问您账户内部的资源。在这些情况下，请创建 IAM 跨账户角色，并仅向该角色提供第三方所需的权限。此外，使用[外部 ID 条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)定义信任策略。使用外部 ID 时，您或第三方可以为每个客户、第三方或租赁生成唯一 ID。创建唯一 ID 后，不应由除您之外的任何人控制它。第三方必须实施具体流程，以一种安全、可审计且可复制的方式将外部 ID 与客户关联起来。
您也可以使用 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 来管理 AWS 之外使用 AWS API 的应用程序的 IAM 角色。
如果第三方不再需要访问您的环境，则删除该角色。应避免向第三方提供长期凭证。了解其它支持共享的 AWS 服务，例如 AWS Well-Architected Tool 支持与其它 AWS 账户[共享工作负载](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html)，而 [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) 有助于您安全地与其它账户共享您拥有的 AWS 资源。
### 实施步骤
1. **使用跨账户角色提供对外部账户的访问。**[跨账户角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)可减少外部账户和第三方为服务客户而存储的敏感信息量。跨账户角色可让您将账户中 AWS 资源的访问权限安全地授予第三方（如 AWS 合作伙伴或组织内的其它账户），同时保持管理和审计该访问权限的能力。第三方可能从混合基础设施向您提供服务，或者将数据提取到一个异地位置。[IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 有助于您使第三方工作负载能够安全地与 AWS 工作负载交互，并进一步减少对长期凭证的需求。
不应使用长期凭证或与用户关联的访问密钥来提供外部账户访问权限。而应使用跨账户角色来提供跨账户访问。
1. **进行尽职调查并确保第三方 SaaS 提供商的安全访问。**当与第三方 SaaS 提供商共享资源时，请进行彻底的尽职调查，来确保他们采用安全和负责任的方法访问您的 AWS 资源。评估他们的责任共担模式，来了解他们提供了哪些安全措施以及哪些方面属于您的责任。确保 SaaS 提供商采用安全且可审计的流程来访问您的资源，包括使用[外部 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) 和最低权限访问原则。使用外部 ID 有助于解决 [confused deputy problem](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/)。
实施安全控制以确保安全访问，并在向第三方 SaaS 提供商授予访问权限时遵守最低权限原则。这可能包括使用外部 ID、通用唯一标识符（UUID）和 IAM 信任策略，从而将访问权限限制在严格必要的范围内。与 SaaS 提供商密切合作，以便建立安全访问机制，定期审查他们对您的 AWS 资源的访问权限，并进行审计以确保符合安全要求。
1. **弃用客户提供的长期凭证。**弃用长期凭证，使用跨账户角色或 IAM Roles Anywhere。如果必须使用长期凭证，请制定相应计划，逐渐转变成基于角色进行访问。有关管理密钥的详细信息，请参阅[身份管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-management.html)。此外，与 AWS 账户团队和第三方合作来建立风险缓解运行手册。有关应对和缓解安全事件潜在影响的规范性指南，请参阅[事件响应](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)。
1. **验证设置是否具有规范性指南，或是否实现了自动化。**外部 ID 不视为密钥，但外部 ID 不能是容易猜测的值，例如电话号码、姓名或账户 ID。将外部 ID 设置为只读字段，这样就无法为了冒充设置而更改外部 ID。
您或第三方可以生成外部 ID。定义一个流程，确定谁负责生成 ID。无论创建外部 ID 的实体是什么，第三方都必须确保客户之间的唯一性和格式一致。
为您账户中的跨账户访问创建的策略必须遵循[最低权限原则](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)。第三方必须为您提供使用 AWS CloudFormation 模板或等效模板的角色策略文档或自动化设置机制。这减少了手动创建策略时出错的机会，并提供了可审计的跟踪。有关使用 AWS CloudFormation 模板来创建跨账户角色的更多信息，请参阅 [Cross-Account Roles](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/)。
第三方应提供一个自动化的、可审计的设置机制。但是，通过使用角色策略文档（此文档大致列出了所需的访问权限），角色设置的自动化应该由您来完成。使用 AWS CloudFormation 模板或等效模板，您应将偏差检测纳入审计实践来监控变更。
1. **对变更做出解释。**您的账户结构、您对第三方的需求或他们提供的服务可能会发生变更。您应预料到可能会发生变动和失败，并进行相应的规划：请安排合适的人员，建立适当的流程并采用正确的技术进行应对。应定期审计您提供的访问级别，并实施检测方法，以便在发生意外变更时向您发出警报。监控并审计角色的使用情况，以及外部 ID 的数据存储状态。若发生意外变更或存在不当访问模式，您应准备暂时或永久撤销第三方访问权限。此外，还要衡量撤销操作造成的影响，包括执行该操作所需的时间、涉及的人员、成本以及对其他资源的影响。
有关检测方法的规范性指南，请参阅《[检测最佳实践](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)》。
## 资源
**相关最佳实践：**
+ [SEC02-BP02 使用临时凭证](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC03-BP05 为您的组织定义权限护栏](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_define_guardrails.html)
+ [SEC03-BP06 基于生命周期管理访问权限](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
+ [SEC03-BP07 分析公共和跨账户访问](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC04 检测](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**相关文档：**
+ [存储桶拥有者向并非其拥有的对象授予跨账户权限](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use trust policies with IAM roles](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [使用 IAM 角色委托跨 AWS 账户的访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [如何使用 IAM 访问其它 AWS 账户中的资源？](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/)
+ [IAM 安全最佳实操](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [跨账户策略评估逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [如何在向第三方授予对 AWS 资源的访问权限时使用外部 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [Collecting Information from AWS CloudFormation Resources Created in External Accounts with Custom Resources](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)
+ [Securely Using External ID for Accessing AWS Accounts Owned by Others](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)
+ [Extend IAM roles to workloads outside of IAM with IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)
**相关视频：**
+ [How do I allow users or roles in a separate AWS 账户 access to my AWS 账户?](https://www.youtube.com/watch?v=20tr9gUY4i0)
+ [AWS re:Invent 2018: Become an IAM Policy Master in 60 Minutes or Less](https://www.youtube.com/watch?v=YQsK4MtsELU)
+ [AWS Knowledge Center Live: IAM Best Practices and Design Decisions](https://www.youtube.com/watch?v=xzDFPIQy4Ks)
**相关示例：**
+ [配置对 Amazon DynamoDB 的跨账户访问](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)
+ [AWS STS Network Query Tool](https://github.com/aws-samples/aws-sts-network-query-tool)