在对象存储OSS的访问场景中，有很常见的一种场景是移动应用使用临时安全令牌访问OSS。在这个场景中，有不止一个用户遇到过在配置初始时，测试发现上传下载报错，而这时候检查令牌对应的授权，发现给到的OSS访问授权是没有的问题的。而且错误提示基本都是："You are not authorized to do this action. You should be authorized by RAM."

针对这个报错，一句话总结解决办法，就是给使用该安全令牌的RAM用户（注意是RAM用户，不是RAM角色）授予权限“AliyunSTSAssumeRoleAccess”。然后就可以正常工作了。

然而这里要指出，这个办法有些简单粗暴，有可能会导致授权放大，使得RAM用户可以得到权限范围更大的令牌。更好的做法，是让RAM用户只能得到特定的令牌。这个文章最后会给出办法。

为了更好的理解导致这个问题的原因和为什么通过这样的授权来解决问题，本文对这里的权限策略逻辑进行了简单梳理，给各位参考。首先把一些基本概念在这里在列一下。

• RAM（访问控制）：使用阿里云服务的客户，一定会使用到阿里云的访问控制（RAM）功能。RAM允许在一个云账号下创建并管理多个身份，并允许给单个身份或一组身份分配不同的权限，从而实现不同用户拥有不同资源访问权限的目的。

针对本文提到的场景，重点说明下RAM用户和RAM角色两个身份。

• RAM用户：是RAM的一种实体身份类型，有确定的身份ID和身份凭证。RAM用户必须在获得云账号（主账号）的授权后才能登录控制台或使用API操作云账号下的资源。
• RAM角色：RAM角色是一种虚拟用户，不是实体用户。RAM角色可以被赋予一组权限策略，但没有确定的登录密码或访问密钥。RAM角色需要被一个受信的实体用户（RAM用户）扮演，扮演成功后实体用户将获得RAM角色的安全令牌，使用这个安全令牌就能以角色身份访问被授权的资源。

在RAM角色里，有个概念是角色的令牌。这个令牌是通过阿里云的STS服务来提供的。

• STS（Security Token Service），是阿里云提供的一种临时访问权限管理服务。通过STS服务，您所授权的身份主体（RAM用户、用户组或RAM角色）可以获取一个自定义时效和访问权限的临时访问令牌。STS令牌持有者可以通过API或者控制台操作被授权的云资源
• 角色令牌：是角色身份的一种临时访问密钥。角色身份没有确定的访问密钥，当一个实体用户要使用角色时，必须通过扮演角色来获取对应的角色令牌，然后使用角色令牌来调用阿里云服务API。

所以，扮演角色，就是RAM用户访问STS服务获取临时访问令牌。RAM用户调用STS API AssumeRole可以获得角色的安全令牌，使用安全令牌可以访问云服务API。

有了以上的逻辑，我们再看文章开始提到的问题就很明白了。

在文章开始的场景中，同一个主账号下，创建了一个RAM用户和一个RAM角色，并给了RAM角色对应的授权（例如OSS的完全控制权限）。当RAM用户去拿这个角色临时令牌的时候，他必须要有权限扮演这个角色，这样他去调用STS AssumeRole，携带角色名称参数时，才不会被STS服务鉴权失败。而“AliyunSTSAssumeRoleAccess”这个授权，给到RAM用户的权限，其实就是允许该RAM用户扮演主账号下的角色。所以，通过文章一开始提到的解决办法，可以解决对应的报错问题。

然而，这里又引发出了一个新问题，假设主账号下有A角色和B角色，其中A角色的权限范围大于B角色（例如A角色具备OSS的完全控制权限，B角色只有OSS的只读权限）。而用户只想授权某个RAM用户扮演B角色，不想过度授权其可以扮演A角色。这个时候，如果赋予RAM用户“AliyunSTSAssumeRoleAccess”可能就无法达到目的。

可以从RAM用户或者RAM角色两个维度来设定细化的策略。

• RAM用户的角度：比如通过自定义策略，使得该RAM用户只可以扮演指定的RAM角色，而不再使用文章开始的办法，简单的赋予该RAM用户“AliyunSTSAssumeRoleAccess”这样的通用权限。自定义策略示例如下所示：
  {

  "Statement": [
      {
          "Action": "sts:AssumeRole",
          "Effect": "Allow",
          "Resource": "acs:ram:*:$accountId:role/$roleName"
      }
  ],
  "Version": "1"

  }

• RAM角色授权的角度：比如A角色创建时，指定该角色的可信实体为该主账号下的某个或某些特定RAM用户。策略示例如下：
  {

  "Statement": [
      {
          "Action": "sts:AssumeRole",
          "Effect": "Allow",
          "Principal": {
              "RAM": [
                 "acs:ram::123456789012****:user/ramuser1"
              ]
          }
      }
  ],
  "Version": "1"

  }。

基于自定义策略，限制RAM用户具体可以扮演的RAM角色，可以更细粒度的控制RAM用户的权限范围，将权限限制到最小可用程度，是更推荐的一种安全做法。

最后总结一下：本文针对移动APP开发客户在使用OSS过程中遇到的一个常见的权限错误问题，进行了分析说明，并在说明过程中引用了阿里云官方文档里RAM的部分解释。实际上，阿里云RAM功能非常的丰富，搭配云存储等阿里云产品可以有很多种不同的用法，有兴趣的同学可以好好研究一下。