摘要本文主要介绍 OSS 安全管理中访问控制相关的基本概念、机制和使用方法。

背景

OSS作为阿里云的对象存储产品具有快速数据存取无限水平扩展数据容灾等优点可满足海量数据存储需求已服务大量的用户。和任何数据存储一样安全是一个关键特性。用户通过HTTP调用OSS提供认证需要的密钥。因为数据可能通过公共互联网传输这些密钥就是身份凭证而非普通的用户/密码组合。OSS利用这些信息进行用户身份认证及鉴权等访问控制操作。除了以上基于身份的资源管理维度OSS还会考虑Bucket权限维度将两者结合起来构建完整的访问控制体系。

基本概念

OSS权限

OSS使用两层模型管理用户数据object作为基层数据单元与用户的数据对应bucket桶作为管理单元管理objectbucket下所有的object都属于bucket owner由此衍生出了两层的权限bucket acl和object acl。目前在OSS中bucket acl的可选项有private、public-read和public-read-writeobject acl在bucket acl基础上增加default。暂时没有对某个人或者某个组的授权概念。
1⃣ bucket acl

权限值	中文名称	权限对访问者的限制
public-read-write	公共读写	任何人包括匿名访问都可以对该Bucket中的Object进行读/写/删除操作所有这些操作产生的费用由该Bucket的Owner承担请慎用该权限。
public-read	公共读私有写	只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作任何人包括匿名访问可以对Object进行读操作。
authenticated-read	授权读私有写	只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行写/删除操作只有通过阿里云身份认证用户可以对Object进行读操作。禁止匿名读
private	私有读写	只有该Bucket的Owner或者授权对象可以对存放在其中的Object进行读/写/删除操作其他人在未经授权的情况下无法访问该Bucket内的Object。

2⃣ object acl

权限值	中文名称	权限对访问者的限制
public-read-write	公共读写	该ACL表明某个Object是公共读写资源即所有用户拥有对该Object的读写权限。
public-read	公共读私有写	该ACL表明某个Object是公共读资源即非Object Owner只有该Object的读权限而Object Owner拥有该Object的读写权限。
authenticated-read	授权读私有写	该ACL表明某个Object是被阿里云认证身份的读资源即禁止匿名用户拥有该Object的读权限而Object Owner拥有该Object的读写权限。
private	私有读写	该ACL表明某个Object是私有资源即只有该Object的Owner拥有该Object的读写权限其他的用户没有权限操作该Object。
default	默认权限	该ACL表明某个Object是遵循Bucket读写权限的资源即Bucket是什么权限Object就是什么权限。

RAM

RAM (Resource Access Management)是阿里云为客户提供的用户身份管理与访问控制服务。使用RAM用户可以创建、管理用户账号比如员工、系统或应用程序并可以控制这些用户账号对资源的操作权限。当企业存在多用户协同操作资源时RAM可以按需为用户分配最小权限从而避免与其他用户共享云账号密钥降低企业的信息安全风险。RAM基于身份进行权限管理目前支持用户、组和角色三种身份身份是管理的核心身份需要赋予相应的授权策略所有的行为都是基于特定的身份来展开。

授权策略

授权策略可以分为RamPolicy和BucketPolicy两种包含以下基本元素
版本version描述授权策略的版本信息。
语句statement描述权限的详细信息。该元素包括授权类型、操作、资源、条件等多个其他元素的权限或权限集合。一条策略可以有一个或多个语句元素。
委托人principal描述策略授权的实体。例如用户云账户、ram子账号、用户组等。
授权类型effect描述声明产生的结果是“允许”还是“显式拒绝”取值为 Allow 或 Deny。该元素是必填项。
操作名称列表action描述允许或拒绝的操作支持多值取值为云服务所定义的API操作名称。该元素是必填项。
资源resource描述授权的具体数据。每款产品的资源定义详情会有所区别。该元素是必填项。
条件condition描述策略生效的约束条件。条件包括操作符、操作键和操作值组成。条件值可包括时间、IP 地址等信息。有些服务允许指定其他值。该元素是非必填项。

image.png | left

在OSS控制台授权页面可以进行BucketPolicy的图形化操作在访问控制控制台可以进行RamPolicy的图形化操作。

权限体系

访问者身份

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

按访问者的角色可分为拥有者访问、RAM用户和STS用户访问。这里的拥有者指的是Bucket的Owner。RAM用户是通过RAM创建的子用户属于云账号不拥有实际的任何资源按照RAM定义的规则去访问Bucket里的资源。STS用户是通过临时访问凭证服务STS颁发的临时用户在一定的生命周期内按照STS定义的规则去访问Bucket里的资源。
按访问者的身份信息可分为匿名访问和带签名访问。对于OSS来说如果请求中没有携带任何和身份相关的信息即为匿名访问。带签名访问指的是按照OSS API文档中规定的在请求头部或者在请求URL中携带签名的相关信息。

请求鉴权

权限管理是管理身份对资源的访问按照权限管理的划分oss将权限验证流程划分为基于身份的策略user-based policy和基于资源的策略resource-based policy。user-based policy是与身份user/role相关的policy只对真实存在的身份有效。而resource-based policy与具体资源相关包括bucket acl、object acl及bucket policy。两者结合可以对usergroup包括匿名用户来实现权限控制。

当OSS收到请求可以分为bucket操作或object操作时首先验证请求者是否拥有必要的权限包括所有user-based policy和resource-based policy进行评估以决定是否对该请求进行授权。为了确定请求者是否拥有执行特定操作的权限OSS会在收到请求时按顺序执行以下操作

在运行时对所有相关访问策略 (身份策略、bucket策略、acl) 按照特定上下文进行评估。

身份认证

OSS对请求者身份进行判定如果是阿里云账户发出的请求则跳过这步。如果是其他账户包括RAM、STS、匿名会对这些身份拥有的策略子集进行评估。

资源权限认证

如果请求是针对bucket操作发出的则请求者必须拥有来自bucket拥有者的权限且不能被bucket policy显式拒绝。如果请求是针对object发出的在没有被bucket policy显式拒绝的情况下即使被bucket acl拒绝OSS会额外检查object acl以判断是否对请求授权。

bucket请求

2018 oss design.001.png | left

object请求

2018 oss design.002.png | left

应用场景

跨账号授权OSS资源

假设企业A账号ID 11223344需要将 OSS 操作权限授予企业B账号ID 12345678的员工Anne。我们使用bucket acl和ram policy 完成授权。
> I. 设置bucket acl为private只允许有bucket owner权限的用户访问。
> II. 企业A创建一个角色角色策略中principal设置为企业B的账户ID以便企业B能够担任该角色。
> III. 企业A将合适的访问授权策略赋予该角色。
> IV. 企业B创建RAM用户Anne并授权其担任该角色。

禁止匿名用户访问

使用PutBucketACL接口设置bucket acl为authenticated-read在此场景下只有正确签名的请求才能访问object实现了除匿名访问外的公共读。

参考链接

授权策略语法
OSS访问控制
BucketPolicy授权

OSS访问控制介绍

背景