oss访问控制
详细解答可以参考官方帮助文档
发送访问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发送请求时,其身份验证的实现如下:
用户将发送的请求按照OSS指定的格式生成签名字符串。
用户使用AccessKeySecret对签名字符串进行加密产生验证码。
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权限设定和读取方法 功能使用参考:
API:Put BucketACL
SDK:Java SDK-设置Bucket ACL
控制台:创建Bucket权限设置
API:Get BucketACL
SDK:Java SDK-获取Bucket ACL
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权限设定和读取方法 功能使用参考:
API:Put Object ACL
SDK:Java SDK-ObjectACL 中设定Object ACL
API:Get Object ACL
SDK:Java SDK-ObjectACL 中读取Object ACL
账号级别权限(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方案描述如下图所示:方案的详细描述如下:
App用户登录。App用户和云账号无关,它是App的终端用户,AppServer支持App用户登录。对于每个有效的App用户来说,需要AppServer能定义出每个App用户的最小访问权限。
AppServer请求STS服务获取一个安全令牌(SecurityToken)。在调用STS之前,AppServer需要确定App用户的最小访问权限(用Policy语法描述)以及授权的过期时间。然后通过扮演角色(AssumeRole)来获取一个代表角色身份的安全令牌。
STS返回给AppServer一个有效的访问凭证,包括一个安全令牌(SecurityToken)、临时访问密钥(AccessKeyId, AccessKeySecret)以及过期时间。
AppServer将访问凭证返回给ClientApp。ClientApp可以缓存这个凭证。当凭证失效时,ClientApp需要向AppServer申请新的有效访问凭证。比如,访问凭证有效期为1小时,那么ClientApp可以每30分钟向AppServer请求更新访问凭证。
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在线图形化便捷配置工具,请单击这里。
最佳实践
RAM和STS使用指南
赞0
踩1