SEC02-BP02 使用临时凭证 - AWS Well-Architected 框架
实施指导资源

SEC02-BP02 使用临时凭证

进行任何类型的身份验证时，最好使用临时凭证而不是长期凭证，来降低或消除诸如凭证被无意泄露、共享或被盗之类的风险。

期望结果：为了降低长期凭证的风险，尽量对人类身份和机器身份使用临时凭证。长期凭证会带来诸多风险，例如通过上传到公共存储库而泄露。使用临时凭证可以大幅降低凭证被泄露的几率。

常见反模式：

  • 开发人员使用 IAM 用户的长期访问密钥，而不是使用联合身份验证从 CLI 获得临时凭证。

  • 开发人员在他们的代码中嵌入长期访问密钥，并将该代码上传到公有 Git 存储库。

  • 开发人员在移动应用程序中嵌入长期访问密钥，然后在应用商店中提供这些密钥。

  • 用户与其他用户共享长期访问密钥，或员工离开公司时仍持有长期访问密钥。

  • 当可以使用临时凭证时，对机器身份使用长期访问密钥。

在未建立这种最佳实践的情况下暴露的风险等级：高

实施指导

对所有 AWS API 和 CLI 请求使用临时安全凭证，而不是长期凭证。在几乎所有情况下，对 AWS 服务的 API 和 CLI 请求都必须使用 AWS 访问密钥进行签名。这些请求可以使用临时凭证或长期凭证进行签名。只有在使用 IAM 用户或 AWS 账户根用户时，才应该使用长期凭证（也称为长期访问密钥）。在联合到 AWS 或通过其他方法代入 IAM 角色时，系统会生成临时凭证。即使使用登录凭证访问 AWS Management Console，系统也会生成临时凭证供您调用 AWS 服务。需要用到长期凭证的情况很少，所以可以使用临时凭证完成几乎所有任务。

尽量不要使用长期凭证，要多用临时凭证，并且还应少用 IAM 用户进行能访问，而应多用联合身份验证和 IAM 角色进行访问。虽然过去常使用 IAM 用户来访问人类身份和机器身份，但现在不建议使用 IAM 用户，避免使用长期访问密钥所带来的风险。

实施步骤

人员身份

对于员工、管理员、开发人员和操作员等员工身份：

对于第三方身份：

通过 Web 浏览器、客户端应用程序、移动应用程序或交互式命令行工具访问 AWS 资源的用户身份：

  • 如果需要批准消费者或客户申请访问 AWS 资源，您可以使用 Amazon Cognito 身份池或 Amazon Cognito 用户池提供临时凭证。凭证的权限是通过 IAM 角色配置的。您也可以为未经身份验证的来宾用户定义一个具有有限权限的单独的 IAM 角色。

机器身份

对于机器身份，您就可能需要使用长期凭证了。在这些情况下，您应该要求工作负载使用具有 IAM 角色的临时凭证来访问 AWS。

某些情况下不支持临时凭证，此时需要使用长期凭证。在这些情况下，可以定期审计和轮换这些凭证和定期轮换访问密钥。对于高度受限的 IAM 用户访问密钥，请考虑以下其它安全措施：

  • 授予高度受限的权限：

    • 遵守最低权限原则（特定于操作、资源和条件）。

    • 考虑仅向 IAM 用户授予针对一个特定角色的 AssumeRole 操作。根据本地架构，此方法有助于隔离和保护长期 IAM 凭证。

  • 在 IAM 角色信任策略中限制支持的网络来源和 IP 地址。

  • 监控使用情况并针对未使用的权限或滥用行为设置警报（使用 AWS CloudWatch Logs 指标筛选条件和警报）。

  • 强制执行权限边界 [服务控制策略（SCP）和权限边界相辅相成 - SCP 是粗粒度的，而权限边界是细粒度的]。

  • 实施用于预置和（在本地保管库中）安全存储凭证的过程。

对于需要长期凭证的场景，其它一些选项包括：

  • 构建自己的令牌出售 API（使用 Amazon API Gateway）。

  • 对于必须使用长期凭证或 AWS 访问密钥以外凭证的场景（如数据库登录），可以使用旨在处理密钥管理的服务，如 AWS Secrets Manager。Secrets Manager 可以简化加密密钥的管理、轮换和安全存储。许多 AWS 服务都支持与 Secrets Manager direct integration。

  • 对于多云集成，可以使用基于源凭证服务提供商（CSP）凭证的身份联合验证（请参阅 AWS STS AssumeRoleWithWebIdentity）。

有关轮换长期凭证的更多信息，请参阅轮换访问密钥。

资源

相关最佳实践：

相关文档：

相关视频：