SEC02-BP02 使用临时凭据替代固定凭据

通过给RAM用户或云账号的Root身份创建AccessKey供程序调用，都属于固定凭据类型。一旦创建出来，在删除之前，就是由固定的AccessKey ID和AccessKey Secret组成了该凭据。不合理地使用固定凭据会造成很多风险，比如应用研发人员将固定AccessKey明文写入了代码中，并将其上传到了GitHub等公开仓库，造成了AccessKey泄漏，最终导致业务受损。在阿里云上，建议尽可能通过角色扮演的方式获取临时凭据STS Token，代替固定AccessKey的使用。每个STS Token生成后，在超过角色最大会话时间（小时级）后，自动失效，能够极大降低凭据泄漏的可能。

优先级

高

不推荐做法

• 针对运维、研发等职能人员在本地调试API、执行运维脚本等需求，使用RAM用户AccessKey执行CLI命令或脚本等。在这种情况下，容易将明文AccessKey写在代码、脚本或者配置文件中，且不慎提交到GitHub等公开仓库中，导致AccessKey泄漏。此种情况，建议通过SSO等方式扮演角色，获取STS Token。

• 研发、产品等职能人员使用OSS客户端（如ossbrowser等）管理OSS文件时，使用RAM用户AccessKey做为认证方式，此种情况下，AccessKey存储在本地，当设备遗失或者被入侵，将导致AccessKey泄漏，进而造成数据泄漏。同时，当需要使用该客户端的员工越来越多时，会导致分配更多的AccessKey，泄漏风险大大增加。此种情况，建议让员工通过SSO等方式扮演角色，获取STS Token，使用STS Token作为认证方式在OSS客户端完成登录。

• 研发人员在应用程序的代码中明文配置AccessKey，并且将代码提交到公开仓库如GitHub中。

• 研发人员将AccessKey配置在移动端App，并且将App发布到了公共的应用市场，如App Store里。

• 研发人员在移动端App中使用STS Token，却未对对应的RAM角色进行精细化授权或使用SessionPolicy进一步限制会话级的权限。客户端请求被攻击者劫持，导致STS Token泄漏，造成安全风险。

• 不同的人员共用AccessKey。此种做法会导致泄漏风险增大，并且在审计日志中，无法区分出是谁在使用该AccessKey。如果人员离职时，没有及时回收AccessKey，会进一步导致数据泄漏等安全风险，且很难通过日志定位具体是谁做了该操作。

实施指南

针对不同场景的使用，都应该尽可能地使用STS Token代替RAM用户AccessKey。

员工使用STS Token

针对研发、运维、产品等职能员工，需要使用AccessKey进行运维、管理、调试等操作，建议通过角色SSO的方式，扮演其对应职能的RAM角色，获取STS Token。

• 针对单账号场景，建议在云账号内配置基于SAML的角色SSO，并按职能为员工分配RAM角色。员工可以在命令行中使用saml2alibabacloud工具，完成IdP侧的认证后，即可获取到STS Token。

• 针对多账号场景，建议使用云SSO进行多账号的单点登录配置。配置完成后，员工即可使用CLI登录云SSO并访问阿里云资源。

应用代码中使用STS Token

针对不同类型的云上应用部署方式，选择相应的方案实现STS Token凭据的使用：

• 针对在ECS实例上部署的应用，通过配置ECS实例RAM角色，将RAM角色跟实例进行绑定，应用程序中即可通过ECS实例RAM角色，获取实例RAM角色的临时授权访问凭证。

• 针对在ACK上部署的应用，在容器服务 Kubernetes 版中，一个集群可以部署多个服务，同一个容器节点可能包含多个不同服务的Pod，在多租户场景下，若部署不受信任的服务，该服务可直接访问ECS的元数据服务（Meta Data Server），获取Worker节点关联实例RAM角色的临时令牌STS Token，会造成身份权限的泄露。通过RRSA配置ServiceAccount的RAM权限实现Pod权限隔离和绑定，在Pod维度即可扮演对应角色实现STS Token的获取。

• 针对在函数计算中部署的Serverless应用，可以为对应函数所属服务授予函数计算访问其他云服务的权限，实现STS Token的获取。

无论哪种部署方式，在应用代码中通过阿里云官方提供的SDK，根据部署类型设置相应的身份验证（Credentials）配置，都可以便捷的直接获取STS Token，无需关心具体的凭据缓存以及过期更新逻辑。

移动程序中使用STS Token

对于移动端App来说，在客户端访问阿里云API，也建议使用STS Token，避免将AccessKey放在客户端，导致被黑客逆向或者反编译，获取到明文AccessKey。常见的客户端场景有，用户通过客户端直传方式上传图片等文件到OSS存储空间，此种情况下，可以使用STS临时访问凭证访问OSS。需要特别注意的是：

• 对用于获取临时访问凭证的角色进行精细化授权。如客户端直传OSS图片的场景，只需要对某个OSS存储空间进行上传图片的操作，那么建议的RAM Policy如下：

  {
      "Version": "1",
      "Statement": [
       {
             "Effect": "Allow",
             "Action": [
               "oss:PutObject"
             ],
             "Resource": [
               "acs:oss:*:*:examplebucket/src/*",
               "acs:oss:*:*:examplebucket/dest/*"
             ]
       }
      ]
  }

  避免为该角色赋予OSS系统策略，或者过大的权限策略，如：

  {
      "Version": "1",
      "Statement": [
       {
             "Effect": "Allow",
             "Action": [
               "oss:*"
             ],
             "Resource": [
               "*"
             ]
       }
      ]
  }

• 在获取临时访问凭证这个步骤，需要调用AssumeRole这个API获取STS Token，在调用时，推荐进一步通过Policy参数缩小此次会话的权限范围。在上述客户端直传的场景中，针对某个上传请求，可以根据用户ID、RequestId、访问路径等请求特征生成上传后的OSS存储空间内的文件路径，并进一步缩小STS Token可操作的资源范围。举个例子，用户ID为123的用户需要上传自己的头像到examplebucket中，则生成的路径为oss://examplebucket/avatar/user/123.jpg。那么在Policy中可以进一步限制此次生成的STS Token的权限：

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "oss:PutObject",
        "Resource": [
          "acs:oss:*:*:examplebucket/avatar/user/123.jpg"
        ]
      }
    ]
  }

  通过该方式，可以避免客户端请求被劫持，导致STS Token泄漏后，攻击者拥有整个RAM角色的权限。

STS Token泄漏应急处理

虽然STS Token是临时的身份令牌，但根据其对应的角色最大会话时间，其有效期的区间为15分钟~12小时。如果STS Token发生泄露，依旧存在非常大的安全风险，您可以按以下步骤回收所有已经颁发的STS Token。

1. 使用阿里云账号登录RAM控制台。

2. 移除RAM角色的所有权限策略。

3. 删除RAM角色。删除RAM角色后，所有通过扮演该RAM角色获取的且未过期的STS Token都将立即失效。

如果您还需要使用该角色，在完成泄漏根因的处理后，可以重新创建同名角色并授权相同的权限策略，使用新创建的角色继续完成您的任务。

相关资源

视频教程

云上应用使用临时凭据的最佳实践

相关实践

• 针对无法使用STS Token的场景，建议对AccessKey进行集中化管控，请参考SEC02-BP05 对固定凭据进行集中化管控