SEC02-BP02 使用临时凭证
进行任何类型的身份验证时,最好使用临时凭证而不是长期凭证,降低或消除诸如凭证被无意泄露、共享或被盗之类的风险。
期望结果:为了降低长期凭证的风险,尽量对人类身份和机器身份使用临时凭证。长期凭证会带来诸多风险,例如被以代码的形式上传到公有 GitHub 存储库。使用临时凭证可以大幅降低凭证被泄露的几率。
常见反模式:
-
开发人员使用 IAM 用户的长期访问密钥,而不是使用联合身份验证从 CLI 获得临时凭证。
-
开发人员在他们的代码中嵌入长期访问密钥,并将该代码上传到公有 Git 存储库。
-
开发人员在移动应用程序中嵌入长期访问密钥,然后在应用商店中提供这些密钥。
-
用户与其他用户共享长期访问密钥,或员工离开公司时仍持有长期访问密钥。
-
当可以使用临时凭证时,对机器身份使用长期访问密钥。
在未建立这种最佳实践的情况下暴露的风险等级:高
实施指导
对所有 AWS API 和 CLI 请求使用临时安全凭证,而不是长期凭证。在几乎所有情况下,对 AWS 服务的 API 和 CLI 请求都必须使用 AWS 访问密钥进行签名。这些请求可以使用临时凭证或长期凭证进行签名。只有在使用 IAM 用户或 AWS 账户根用户时,才应该使用长期凭证(也称为长期访问密钥)。在联合到 AWS 或通过其他方法代入 IAM 角色时,系统会生成临时凭证。即使使用登录凭证访问 AWS Management Console,系统也会生成临时凭证供您调用 AWS 服务。需要用到长期凭证的情况很少,所以可以使用临时凭证完成几乎所有任务。
尽量不要使用长期凭证,要多用临时凭证,并且还应少用 IAM 用户进行能访问,而应多用联合身份验证和 IAM 角色进行访问。虽然过去常使用 IAM 用户来访问人类身份和机器身份,但现在不建议使用 IAM 用户,避免使用长期访问密钥所带来的风险。
实施步骤
对于员工、管理员、开发人员、操作员和客户等人类身份:
-
您应该依赖集中式身份提供程序,并要求人类用户配合使用联合身份验证与身份提供程序两种方法,以便使用临时凭证访问 AWS。可以通过直接联合到每个 AWS 账户
,或使用 AWS IAM Identity Center 和您选择的身份提供程序,对用户进行联合身份验证。与使用 IAM 用户相比,联合身份验证除了消除使用长期凭证的情况之外,还具有许多优势。用户也可以从直接联合 的命令行或通过使用 IAM Identity Center 来请求获得临时凭证。这意味着能够大幅减少需要使用 IAM 用户或用户长期凭证的情况。 -
如果需要批准消费者或客户申请访问 AWS 资源,您可以使用 Amazon Cognito 身份池或 Amazon Cognito 用户池提供临时凭证。通过 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
资源
相关最佳实践:
相关文档:
相关视频: