SEC02-BP02 使用临时凭证
进行任何类型的身份验证时，最好使用临时凭证而不是长期凭证，以降低或消除诸如凭证被无意泄露、共享或被盗之类的风险。
期望结果：为了降低长期凭证的风险，请尽可能对人类和机器身份使用临时凭证。长期凭证会带来许多风险，例如，它们能够以代码的形式上传到公有 GitHub 存储库。使用临时凭证可以显著降低凭证被泄露的几率。
常见反模式：
-
开发人员使用 IAM users 的长期访问密钥，而不是使用联合身份验证从 CLI 获得临时凭证。
-
开发人员在他们的代码中嵌入长期访问密钥，并将该代码上传到公有 Git 存储库。
-
开发人员在移动应用程序中嵌入长期访问密钥，然后在应用商店中提供这些密钥。
-
用户与其他用户共享长期访问密钥，或员工离开公司时仍持有长期访问密钥。
-
当可以使用临时凭证时，对机器身份使用长期访问密钥。
在未建立这种最佳实践的情况下暴露的风险等级：高
实施指导
对所有 AWS API 和 CLI 请求使用临时安全凭证，而不是长期凭证。在几乎所有情况下，对 AWS 服务的 API 和 CLI 请求都必须使用 AWS 访问密钥进行签名。这些请求可以使用临时凭证或长期凭证进行签名。只有在使用 IAM 用户或 AWS 账户 根用户时，才应该使用长期凭证（也称为长期访问密钥）。当您联合到 AWS 或通过其他方法代入 IAM 角色时，系统将生成临时凭证。即使您使用登录凭证访问 AWS Management Console，系统也会生成临时凭证供您调用 AWS 服务。需要用到长期凭证的情况很少，您可以使用临时凭证完成几乎所有任务。
尽量不要使用长期凭证，多用临时凭证，并且还应该减少采取 IAM 用户形式，多用联合身份验证和 IAM 角色形式进行访问。虽然 IAM 过去常使用用户来访问人类和机器身份，但我们现在建议不要使用它们，以避免使用长期访问密钥所带来的风险。
实施步骤
对于员工、管理员、开发人员、操作员和客户等人类身份：
-
您应该使用集中式身份提供者的服务，并要求人类用户配合使用联合身份验证与身份提供者两种方法，以使用临时凭证访问 AWS。可以通过直接联合到每个 AWS 账户
，或使用 AWS IAM Identity Center（AWS IAM Identity Center 的后继者）和您选择的身份提供者，对用户进行联合身份验证。与使用 IAM 用户相比，联合身份验证除了消除使用长期凭证的情况之外，还具有许多优势。您的用户也可以从直接联合 的命令行或通过使用 IAM Identity Center 来请求获得临时凭证。这意味着能够大幅减少需要使用 IAM 用户或用户长期凭证的情况。 -
如果您需要批准消费者或客户申请访问您的 AWS 资源，可以使用 Amazon Cognito 身份池或 Amazon Cognito user pools 提供临时凭证。通过 IAM 角色配置凭证权限。 对于访客用户未通过身份验证的情况，您还可以定义一个拥有有限权限的单独 IAM 角色。
对于机器身份，您就可能需要使用长期凭证了。在这些情况下，您应该要求工作负载使用具有 IAM 角色的临时凭证来访问 AWS。
-
对于 Amazon Elastic Compute Cloud
（Amazon EC2），您可以使用适用于 Amazon EC2 的角色。
-
AWS Lambda
使您能够配置 Lambda 执行角色，以授权此服务利用临时凭证执行 AWS 操作。AWS 服务还有许多其他类似的模型，可以使用 IAM 角色授予临时凭证。 -
对于 IoT 设备，您可以使用 AWS IoT Core 凭证提供程序来请求临时凭证。
-
对于需要访问 AWS 资源的本地系统或在 AWS 之外运行的系统，您可以使用 IAM Roles Anywhere。
某些情况下不能选择临时凭证，此时您可能需要使用长期凭证。在这些情况下，可以定期审计和轮换凭证，并定期轮换访问密钥以解决需要使用长期凭证的情况。诸如使用 WordPress 插件和第三方 AWS 客户端等情况，都可能需要用到长期凭证。在必须使用长期凭证的情况下，或者对于并非 AWS 访问密钥的凭证（如数据库登录），您可以使用一种专门用于处理密钥管理的服务，比如 AWS Secrets Manager
资源
相关最佳实践：
相关文档：
相关视频：
