发送访问OSS的请求

您可以直接使用OSS提供的RESTful API接口访问或者使用对API接口进行完整封装的SDK开发包。而每一次向OSS的请求根据当前Bucket权限和操作不同要求用户进行身份验证或者直接匿名访问。对OSS的资源访问的分类如下：

  • 按访问者的角色可分为拥有者访问和第三方用户访问。这里的拥有者指的是Bucket的Owner，也称为开发者。第三方用户是指访问Bucket里资源的用户。
  • 按访问者的身份信息可分为匿名访问和带签名访问。对于OSS来说，如果请求中没有携带任何和身份相关的信息即为匿名访问。带签名访问指的是按照OSS API文档中规定的在请求头部或者在请求URL中携带签名的相关信息。

AccessKey 类型

目前访问 OSS 使用的 AK（AccessKey）有三种类型，具体如下：

  • 阿里云账号AccessKey

    阿里云账号AK特指Bucket拥有者的AK，每个阿里云账号提供的AccessKey对拥有的资源有完全的权限。每个阿里云账号能够同时拥有不超过5个active或者inactive的AK对（AccessKeyId和AccessKeySecret）。

    用户可以登录AccessKey管理控制台，申请新增或删除AK对。

    每个AK对都有active/inactive两种状态。

    • Active 表明用户的 AK 处于激活状态，可以在身份验证的时候使用。
    • Inactive 表明用户的 AK 处于非激活状态，不能在身份验证的时候使用。
    说明
    请避免直接使用阿里云账户的 AccessKey。
  • RAM子账号AccessKey

    RAM (Resource Access Management) 是阿里云提供的资源访问控制服务。RAM账号AK指的是通过RAM被授权的AK。这组AK只能按照RAM定义的规则去访问Bucket里的资源。通过RAM，您可以集中管理您的用户（比如员工、系统或应用程序），以及控制用户可以访问您名下哪些资源的权限。比如能够限制您的用户只拥有对某一个Bucket的读权限。子账号是从属于主账号的，并且这些账号下不能拥有实际的任何资源，所有资源都属于主账号。

  • STS账号AccessKey

    STS（Security Token Service）是阿里云提供的临时访问凭证服务。STS账号AK指的是通过STS颁发的AK。这组AK只能按照STS定义的规则去访问Bucket里的资源。

身份验证具体实现

目前主要有三种身份验证方式：

  • AK验证
  • RAM验证
  • STS验证

当用户以个人身份向OSS发送请求时，其身份验证的实现如下：

  1. 用户将发送的请求按照OSS指定的格式生成签名字符串。
  2. 用户使用AccessKeySecret对签名字符串进行加密产生验证码。
  3. OSS收到请求以后，通过AccessKeyId找到对应的AccessKeySecret，以同样的方法提取签名字符串和验证码。
    • 如果计算出来的验证码和提供的一样即认为该请求是有效的。
    • 否则，OSS将拒绝处理这次请求，并返回HTTP 403错误。

对于用户来说可以直接使用OSS提供的SDK，配合不同类型的AccessKey即可实现不同的身份验证。

权限控制

针对存放在Bucket的Object的访问，OSS提供了多种权限控制，主要有：

  • Bucket级别权限
  • Object级别权限
  • 账号级别权限（RAM）
  • 临时账号权限（STS）

Bucket级别权限

  • Bucket权限类型
    OSS提供ACL（Access Control List）权限控制方法，OSS ACL提供Bucket级别的权限访问控制，Bucket目前有三种访问权限：public-read-write，public-read和private，它们的含义如下：
    权限值 中文名称 权限对访问者的限制
    public-read-write 公共读写 任何人（包括匿名访问）都可以对该Bucket中的Object进行读/写/删除操作；所有这些操作产生的费用由该Bucket的Owner承担，请慎用该权限。
    public-read 公共读，私有写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作；任何人（包括匿名访问）可以对Object进行读操作。
    private 私有读写 只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行读/写/删除操作；其他人在未经授权的情况下无法访问该Bucket内的Object。
  • Bucket权限设定和读取方法

    功能使用参考：

Object级别权限

  • Object权限类型

    OSS ACL也提供Object级别的权限访问控制。目前Object有四种访问权限：private, public-read, public-read-write, default。Put Object ACL操作通过Put请求中的“x-oss-object-acl”头来设置，这个操作只有Bucket Owner有权限执行。

    权限值 中文名称 权限对访问者的限制
    public-read-write 公共读写 该ACL表明某个Object是公共读写资源，即所有用户拥有对该Object的读写权限。
    public-read 公共读，私有写 该ACL表明某个Object是公共读资源，即非Object Owner只有该Object的读权限，而Object Owner拥有该Object的读写权限。
    private 私有读写 该ACL表明某个Object是私有资源，即只有该Object的Owner拥有该Object的读写权限，其他的用户没有权限操作该Object。
    default 默认权限 该ACL表明某个Object是遵循Bucket读写权限的资源，即Bucket是什么权限，Object就是什么权限。
    说明
    • 如果没有设置Object的权限，即Object的ACL为default，Object的权限和Bucket权限一致。
    • 如果设置了Object的权限，Object的权限大于Bucket权限。举个例子，如果设置了Object的权限是public-read，无论Bucket是什么权限，该Object都可以被身份验证访问和匿名访问。
  • Object权限设定和读取方法

    功能使用参考：

账号级别权限（RAM）

  • 使用场景

    如果您购买了云资源，您的组织里有多个用户需要使用这些云资源，这些用户只能共享使用您的云账号AccessKey。这里有两个问题：

    • 您的密钥由多人共享，泄露的风险很高。
    • 您无法控制特定用户能访问哪些资源（比如Bucket）的权限。

    解决方法：在您的阿里云账号下面，通过RAM可以创建具有自己AccessKey的子用户。您的阿里云账号被称为主账号，创建出来的账号被称为子账号，使用子账号的AccessKey只能使用主账号授权的操作和资源。

  • 具体实现

    有关RAM详情，请参考RAM用户手册。

    对于授权中需要的Policy的配置方式可以参考本章最后一节：RAM和STS授权策略（Policy）配置。

临时账号权限（STS）

  • 使用场景

    对于您本地身份系统所管理的用户，比如您的App的用户、您的企业本地账号、第三方App，也有直接访问OSS资源的可能，将这部分用户称为联盟用户。此外，用户还可以是您创建的能访问您的阿里云资源的应用程序。

    对于这部分联盟用户，通过阿里云STS (Security Token Service) 服务为阿里云账号（或RAM用户）提供短期访问权限管理。您不需要透露云账号（或RAM用户）的长期密钥（如登录密码、AccessKey），只需要生成一个短期访问凭证给联盟用户使用即可。这个凭证的访问权限及有效期限都可以由您自定义。您不需要关心权限撤销问题，访问凭证过期后会自动失效。

    用户通过STS生成的凭证包括安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)。使用AccessKey方法与您在使用阿里云账户或RAM用户AccessKey发送请求时的方法相同。此外还需要注意的是在每个向OSS发送的请求中必须携带安全令牌。

  • 具体实现

    STS安全令牌、角色管理和使用相关内容详情，请参考RAM用户指南中的角色管理。关键是调用STS服务接口AssumeRole来获取有效访问凭证即可，也可以直接使用STS SDK来调用该方法。

RAM和STS应用场景实践

对于不同的应用场景，涉及到的访问身份验证方式可能存在差异。下面以几种典型的应用场景来说明访问身份验证中几种使用方式。

以一个移动App举例。假设您是一个移动App开发者，打算使用阿里云OSS服务来保存App的终端用户数据，并且要保证每个App用户之间的数据隔离，防止一个App用户获取到其它App用户的数据。

  • 方式一：使用AppServer来做数据中转和数据隔离

    如上图所示，您需要开发一个AppServer。只有AppServer能访问云服务，ClientApp的每次读写数据都需要通过AppServer，AppServer来保证不同用户数据的隔离访问。

    对于该种使用方式，使用阿里云账号或者RAM账号提供的密钥来进行签名验证访问。建议您尽量不要直接使用阿里云账号（主账号）的密钥访问OSS，避免出现安全问题。

  • 方式二：使用STS让用户直接访问OSS

    STS方案描述如下图所示：



    方案的详细描述如下：

    1. App用户登录。App用户和云账号无关，它是App的终端用户，AppServer支持App用户登录。对于每个有效的App用户来说，需要AppServer能定义出每个App用户的最小访问权限。
    2. AppServer请求STS服务获取一个安全令牌（SecurityToken）。在调用STS之前，AppServer需要确定App用户的最小访问权限（用Policy语法描述）以及授权的过期时间。然后通过扮演角色（AssumeRole）来获取一个代表角色身份的安全令牌。
    3. STS返回给AppServer一个有效的访问凭证，包括一个安全令牌（SecurityToken）、临时访问密钥（AccessKeyId, AccessKeySecret）以及过期时间。
    4. AppServer将访问凭证返回给ClientApp。ClientApp可以缓存这个凭证。当凭证失效时，ClientApp需要向AppServer申请新的有效访问凭证。比如，访问凭证有效期为1小时，那么ClientApp可以每30分钟向AppServer请求更新访问凭证。
    5. ClientApp使用本地缓存的访问凭证去请求Aliyun Service API。云服务会感知STS访问凭证，并会依赖STS服务来验证访问凭证，正确响应用户请求。

RAM和STS授权策略（Policy）配置

对于RAM或者STS授权中使用Policy，详细规则如下。

  • 示例

    先看下面的一个Policy示例：

    {
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "oss:GetBucketAcl",
                "oss:ListObjects"
            ],
            "Resource": [
                "acs:oss:*:1775305056529849:mybucket"
            ],
            "Effect": "Allow",
            "Condition": {
                "StringEquals": {
                    "acs:UserAgent": "java-sdk",
                    "oss:Prefix": "foo"
                },
                "IpAddress": {
                    "acs:SourceIp": "192.168.0.1"
                }
            }
        },
        {
            "Action": [
                "oss:PutObject",
                "oss:GetObject",
                "oss:DeleteObject"
            ],
            "Resource": [
                "acs:oss:*:1775305056529849:mybucket/file*"
            ],
            "Effect": "Allow",
            "Condition": {
                "IpAddress": {
                    "acs:SourceIp": "192.168.0.1"
                }
            }
        }
    ]
}

    这是一个授权的Policy，用户用这样的一个Policy通过RAM或STS服务向其他用户授权。Policy当中有一个Statement（一条Policy当中可以有多条Statement）。Statement里面规定了相应的Action、Resource、Effect和Condition。

    这条Policy把用户自己名下的mybucket和mybucket/file*这些资源授权给相应的用户，并且支持GetBucketAcl、GetBucket、PutObject、GetObject和DeleteObject这几种操作。Condition中的条件表示UserAgent为java-sdk，源IP为192.168.0.1的时候鉴权才能通过，被授权的用户才能访问相关的资源。Prefix这个Condition是在GetBucket（ListObjects）的时候起作用的，关于这个字段的解释详见OSS的API文档。

  • 配置细则
    • Version

      Version定义了Policy的版本，本文档中sw2q的配置方式，设置为1。

    • Statement

      通过Statement描述授权语义，其中可以根据业务场景包含多条语义，每条包含对Action、Effect、Resource和Condition的描述。每次请求系统会逐条依次匹配检查，所有匹配成功的Statement会根据Effect的设置不同分为通过（Allow）、禁止（Deny），其中禁止（Deny）的优先。如果匹配成功的都为通过，该条请求即鉴权通过。如果匹配成功有一条禁止，或者没有任何条目匹配成功，该条请求被禁止访问。

    • Action

      Action分为三大类：Service级别操作，对应的是GetService操作，用来列出所有属于该用户的Bucket列表。

      • Bucket级别操作，对应类似于oss:PutBucketAcl、oss:GetBucketLocation之类的操作，操作的对象是Bucket，它们的名称和相应的接口名称一一对应。
      • Object级别操作，分为oss:GetObject、oss:PutObject、oss:DeleteObject和oss:AbortMultipartUpload，操作对象是Object。

      如想授权某一类的Object的操作，可以选择这几种的一种或几种。另外，所有的Action前面都必须加上oss:，如上面例子所示。Action是一个列表，可以有多个Action。具体的Action和API接口的对应关系如下：

      • Service级别
        API Action
        GetService（ListBuckets） oss:ListBuckets
      • Bucket级别
        API Action
        PutBucket oss:PutBucket
        GetBucket（ListObjects） oss:ListObjects
        PutBucketAcl oss:PutBucketAcl
        DeleteBucket oss:DeleteBucket
        GetBucketLocation oss:GetBucketLocation
        GetBucketAcl oss:GetBucketAcl
        GetBucketLogging oss:GetBucketLogging
        PutBucketLogging oss:PutBucketLogging
        DeleteBucketLogging oss:DeleteBucketLogging
        GetBucketWebsite oss:GetBucketWebsite
        PutBucketWebsite oss:PutBucketWebsite
        DeleteBucketWebsite oss:DeleteBucketWebsite
        GetBucketReferer oss:GetBucketReferer
        PutBucketReferer oss:PutBucketReferer
        GetBucketLifecycle oss:GetBucketLifecycle
        PutBucketLifecycle oss:PutBucketLifecycle
        DeleteBucketLifecycle oss:DeleteBucketLifecycle
        ListMultipartUploads oss:ListMultipartUploads
        PutBucketCors oss:PutBucketCors
        GetBucketCors oss:GetBucketCors
        DeleteBucketCors oss:DeleteBucketCors
        PutBucketReplication oss:PutBucketReplication
        GetBucketReplication oss:GetBucketReplication
        DeleteBucketReplication oss:DeleteBucketReplication
        GetBucketReplicationLocation oss:GetBucketReplicationLocation
        GetBucketReplicationProgress oss:GetBucketReplicationProgress
      • Object级别
        API Action
        GetObject oss:GetObject
        HeadObject oss:GetObject
        PutObject oss:PutObject
        PostObject oss:PutObject
        InitiateMultipartUpload oss:PutObject
        UploadPart oss:PutObject
        CompleteMultipart oss:PutObject
        DeleteObject oss:DeleteObject
        DeleteMultipartObjects oss:DeleteObject
        AbortMultipartUpload oss:AbortMultipartUpload
        ListParts oss:ListParts
        CopyObject oss:GetObject,oss:PutObject
        UploadPartCopy oss:GetObject,oss:PutObject
        AppendObject oss:PutObject
        GetObjectAcl oss:GetObjectAcl
        PutObjectAcl oss:PutObjectAcl
  • Resource

    Resource指代的是OSS上面的某个具体的资源或者某些资源（支持*通配），resource的规则是acs:oss:{region}:{bucket_owner}:{bucket_name}/{object_name}。对于所有Bucket级别的操作来说不需要最后的斜杠和{object_name}，即acs:oss:{region}:{bucket_owner}:{bucket_name}。Resource也是一个列表，可以有多个Resource。其中的region字段暂时不做支持，设置为*。

  • Effect

    Effect代表本条的Statement的授权的结果，分为Allow和Deny，分别指代通过和禁止。多条Statement同时匹配成功时，禁止（Deny）的优先级更高。

    例如，期望禁止用户对某一目录进行删除，但对于其他文件有全部权限： 
    {
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:*"
      ],
      "Resource": [
        "acs:oss:*:*:bucketname"
      ]
    },
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteObject"
      ],
      "Resource": [
        "acs:oss:*:*:bucketname/index/*",
      ]
    }
  ]
}
  • Condition

    Condition代表Policy授权的一些条件，上面的示例里面可以设置对于acs:UserAgent的检查、acs:SourceIp的检查、还有oss:Prefix这项用来在GetBucket的时候对资源进行限制。

    OSS支持的Condition如下：

    condition 功能 合法取值
    acs:SourceIp 指定ip网段 普通的ip，支持*通配
    acs:UserAgent 指定http useragent头 字符串
    acs:CurrentTime 指定合法的访问时间 ISO8601格式
    acs:SecureTransport 是否是https协议 “true”或者”false”
    oss:Prefix 用作ListObjects时的prefix 合法的object name

更多示例

针对具体场景更多的授权策略配置示例，可以参考教程示例：控制存储空间和文件夹的访问权限和OSS授权常见问题。

Policy在线图形化便捷配置工具，请单击这里。

最佳实践