一、阿里云提供完善且全面的权限管控体系
阿里云提供业内最为完善的权限管控体系，涵盖了“基于资源的权限管理”以及“基于用户的权限管理”层面。并且阿里云“访问控制”采用基于ABAC（Attribute Based Access Control）而不是简单的RBAC（Role Based Access Control），用户可以访问者的当前环境属性（例如，current time、source ip、HTTP访问方式、prefix等参数）判断是否具有相应的操作权限。如下是阿里云OSS的权限管控体系。
- Bucket ACL以及Object ACL是一种非常粗粒度的权限管理方式。当Bucket或者Object设置为“public-read”、“public-read/wirte”时，任何用户都可以访问该资源，并且不需要进行身份认证，这有可能导致您数据外漏、外网下行流量激增，甚至匿名用户有可能向您“public-read/write”的Bucket内写入非法数据，导致您面临法律风险。
【注意】：不建议您设置“public-read”、“public-read/write”访问权限。
- 签名URL：阿里云提供资源级别的签名URL访问方式。用户接收到该签名URL链接后，在指定的时间内都可以访问该对象。阿里云签名URL能够提供一定程度的权限管控，但是该签名URL分享到外部后，也有可能造成数据泄漏。因此，我们建议您在内部使用签名URL或者结合其他安全管控手段并行使用；
- Bucket Policy：阿里云提供的一种基于资源的ABAC权限管理方式。用户能够在OSS控制台实现一键配置。我们建议您通过Bucket Policy进行日常权限管理；
- RAM Policy：阿里云提供了一种基于用户的ABAC权限管控方式，RAM policy功能强大，且配置灵活。用户可以根据实际需要创建精细化权限管控策略。并且支持授予给指定的用户、用户组、角色。我们建议您通过RAM Policy创建个性化权限管理策略；
阿里云提供全面且完善的权限管控措施。我们建议用户日常通过子账号进行RAM Policy或者Bucket Policy授权，而避免直接操作根账号 。但是，由于RAM policy学习成本高，需要编辑个性化RAM policy策略脚本，因此相当一部分用户仅仅使用了阿里云提供的默认RAM policy 授权模板(该授权模板权限过大，并不能实现对象级别细颗粒度授权)，而不是自行编写精细化RAM 授权策略。
为了让更多的用户能够使用上阿里云强大的权限管控能力。阿里云OSS推出了图像化Bucket Policy策略，普通用户可以在OSS控制台进行日常的权限分配，而不需要编辑RAM policy授权脚本。目前OSS的Bucket Policy可以覆盖用户日常80%以上的授权场景。
二、【Bucket Policy】日常使用场景介绍
2.1【Bucket Policy】介绍
Bucket Policy是一种基于资源的管控策略。您可以选中指定的Bucket或者prefix进行授权操作。当前您可以通过OSS控制台进行授权，后续阿里云将逐步在API、SDK层面支持该特性。如下是Bucket Policy的参数说明：
| 字段 | 值 | 描述 |
|---|---|---|
| 授权资源 | 1. 若选中某个对象，直接点击“授权”，则此处会自动填充对应资源的路径; 2. 若点击“操作授权”，则需要输入对应的资源路径。 |
1.若资源为bucket时，“授权操作”作用于bucket以及bucket内所有子对象； 2. 若资源为对象或者目录，“授权操作”作用于该对象或者该目录下所有的子对象； |
| 授权用户 | 输入格式： 1.授权给账号：输入对应账号ID或者选择子账号username； 2.授权给子用户：输入对应子用户的ID |
Bucket Policy支持跨账号授权；若授权给匿名用户，则勾选“所有用户”； |
| 授权操作 | 为了简化授权过程，oss针对常见的授权场景进行了简化操作，目前只提供“只读”、“读写”以及“完全控制”、“拒绝访问”操作。 | 1.“只读” 2.“读写”; 3. “完全控制” 4."拒绝访问" |
| 条件 | IP等于、IP不等于 | 当输入多个IP地址或者IP地址段时，用英文逗号分隔； |
| 条件 | HTTP、HTTPS | 设置请求的访问方式； |
如下我们将介绍几个Bucket Policy的典型使用案例。
2.2通过Bucket Policy进行日常权限管理
2.2.1场景1：向多个子账号授予读写访问权限
如下是向多个子账号授予读写访问权限的操作界面。若针对当前根账号下的多个子账号进行授权，那么直接按照username进行勾选。
说明：
- 目前只有Bucket的Owner才能进行“Bucket Policy”设置操作。也就说该账号必须拥有Bucket的“完全控制”权限，或者拥有默认的RAM “AliyunOSSFullAccess”权限；
- 选择子账号授权时，当前操作的用户必须拥有“ListUsers”权限。默认根账号拥有该权限。若当前操作的用户没有"ListUsers"权限，则需要通过RAM Policy给当前进行Bucket Policy授权操作的账号进行RAM 授权。子账号拥有ListUsers权限的RAM 授权模板;
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ram:ListUsers"
],
"Resource": [
"*"
],
"Condition": {}
}
]
}2.2.2场景2：授权子账号针对目录拥有只读权限
下面的示例策略向子账号“test-user”、“tmp-user”针对figo这个目录授予“只读访问”权限。绝大多数用日常的授权场景都是向指定的目录授予“读写”、“只读”访问权限。因此通过Bucket Policy基本上可以涵盖绝大多数常规的授权操作。我们强烈建议您通过Bucket Policy针对子账号授予细颗粒度访问权限，而不是使用默认的RAM policy模板。
说明：
- 若当前进行Bucket Policy配置操作的账号无法获得"ListUsers"权限，也可以直接输入被授权账号的UID；
- 当针对目录授权时，您需要输入目录的绝对路径，并且以/*结尾；
- 当针对具体的对象授权时，您需要输入该对象的绝对路径以及对象名称即可。此处不需要以/*结尾。如下所示：
2.3场景3：通过Bucket Policy进行跨账号授权
如下Bucket Policy示例策略向其他阿里云账号授予test-hangzhou-2025这个Bucket的只读访问权限。由于跨账号授权无法直接获取“listusers”权限。因此，只能输入对应账号的UID。
说明：若针对多个账号进行授权，请直接输入对应账号的UID，并换行输入下一个账号的UID；3.Bucket Policy高级使用场景介绍
3.1场景4：限制对特定IP地址的访问权限
以下示例向指定的子账号授予对Bucket的只读访问权限，但是访问请求必须来自于条件中指定的IP地址段。当前Bucket Policy仅支持IPV4的条件授权。Bucket Policy条件参数中使用“IpAddress”、“NotIpAddress”以及“SoureceIP”条件值进行过滤。
3.2场景5：向匿名用户授予访问权限
以下授权策略向任何公共匿名用户授权针对Bucket的只读访问权限。此权限允许任何人访问该Bucket内的对象数据。当您将Bucket 设置为网站并期望任何人都可以访问时，这非常有用。
特别注意：请谨慎使用针对匿名用户授予只读访问权限，这将导致您Bucket内对象数据能够被任何人公开的获取。强烈您不要授予匿名用户写入Bucket的权限。
4.Bucket Policy进阶使用场景介绍
4.1场景5：拒绝用户通过HTTP协议访问指定的Bucket
以下策略实现了拒绝所有用户（包括授权的用户以及未授权的匿名用户）通过HTTP协议访问指定的Bucket。我们建议您通过deny的方式拒绝HTTP的访问请求，而不是通过ALLOW方式允许HTTPS访问请求。
5.Bucket Policy与RAM policy关联关系
5.1Bucket Policy 与RAM Policy是什么关系？
- 补充关系：Bucket Policy可以完成跨账号授权、针对匿名用户授权、以及授予带IP条件限制的访问策略；
- Bucket Policy无法代替RAM Policy：例如Bucket Policy不支持递归授权；
5.2相比于RAM Policy，Bucket Policy有哪些优势？
- 操作灵活：直接在OSS控制台进行图形化操作，无需编写策略脚本；
- 授权简单：支持授权用户针对指定的Bucket进行权限管理操作，而无需授予整个RAM Policy编辑权限；
- 满足更多授权场景：支持跨账号授权、针对匿名用户授权、以及设置带IP条件限制的授权策略。