基本概念
访问控制列表(ACL)使用XML语言描述,它是与资源关联的一个指定被授权者和授予权限的列表,每个存储桶和对象都有与之关联的ACL,支持向匿名用户或其他腾讯云的主账号授予基本的读写权限,需要注意的是使用与资源关联的ACL管理有一些限制:
-
资源的拥有者始终对资源具备FULL_CONTROL权限,无法撤销或修改
-
匿名用户无法成为资源拥有者,此时对象资源的拥有者属于存储桶的创建者(腾讯云主账号)
-
不支持对权限附加条件,不支持显示拒绝的权限,一个资源最多可以拥有100条ACL策略
-
仅可对腾讯云访问管理(Cloud Access Management,CAM)主账号或预设用户组授予权限,无法授予自定义用户组权限,不推荐授予子用户权限
适用场景
当您仅需要为存储桶和对象设置一些简单的访问权限或开放匿名访问时可以选择ACL,但在更多的情况下推荐您优先使用存储桶策略或用户策略,灵活程度更高,ACL的适用场景包括:
-
仅设置简单的访问权限
-
在控制台快速设置访问权限
-
需要将某个对象、目录或存储桶开放给所有互联网匿名用户访问,ACL操作更为便捷
元素介绍
身份Grantee
支持的被授权身份可以是某个CAM主账号或者是某个预设的CAM用户组
-
当您授予了其他腾讯云主账号访问权限时,这个被授权的主账号可以授权其名下的子用户、用户组或角色的访问权限
-
COS完全不建议您对匿名用户或CAM用户组授予WRITE、WRITE_ACP或FULL_CONTROL权限,一旦授权许可后,用户组可以对您的资源进行上传、下载、删除等行为,这将会给您带来数据丢失、扣费等风险
在存储桶或对象的ACL中支持授予的身份包括:
-
跨账号:请使用主账号的ID,通过账号中心的账号信息获得账号ID,例如:100000000001
-
预设用户组:请使用URI标签标记预设的用户组,支持的用户组包括:
-
匿名用户组:-http://cam.qcloud.com/groups/global/AllUsers该组代表了任何人都可以无需授权而访问资源,无论请求已签名或者未签名
-
认证用户组:-http://cam.qcloud.com/groups/global/AuthenticatedUsers该组代表所有经过腾讯云 CAM 账户认证的用户都可以访问资源
操作Permission
腾讯云COS在资源ACL上支持的操作实际上是一系列的操作集合,对于存储桶和对象ACL来说分别代表不同的含义
A、下表列出了支持在存储桶ACL中设置的操作列表:
操作集 | 描述 | 许可的行为 |
---|---|---|
READ | 列出对象 | GetBucket,HeadBucket,GetBucketObjectVersions,ListMultipartUploads |
WRITE | 上传、覆盖和删除对象 | PutObject,PutObjectCopy,PostObject,InitiateMultipartUpload, UploadPart,UploadPartCopy,CompleteMultipartUpload, DeleteObject |
READ_ACP | 读取存储桶的 ACL | GetBucketACL |
WRITE_ACP | 写入存储桶的 ACL | PutBucketACL |
FULL_CONTROL | 以上四种权限的集合 | 以上所有行为的集合 |
备注:请谨慎授予存储桶WRITE、WRITE_ACP或FULL_CONTROL权限,授予存储桶WRITE权限将允许被授权者覆盖或删除已有的任何对象
B、下表列出了支持在对象 ACL 中设置的操作列表:
操作集 | 描述 | 许可的行为 |
---|---|---|
READ | 读取对象 | GetObject,GetObjectVersion,HeadObject |
READ_ACP | 读取对象的 ACL | GetObjectACL,GetObjectVersionACL |
WRITE_ACP | 写入对象的 ACL | PutObjectACL,PutObjectVersionACL |
FULL_CONTROL | 以上三种权限的集合 | 以上所有行为的集合 |
COS预设的ACL
COS支持一系列预设的ACL进行授权,方便简单权限的描述,使用预设ACL描述时,需要在PUT Bucket/Object或PUT Bucket/Object acl中携带x-cos-acl头部并描述所需权限,如果同时在请求正文中携带了XML的描述内容,我们将优先选择头部中的描述并忽略请求正文中的XML描述
A、存储桶的预设ACL
预设名称 | 描述 |
---|---|
private | 创建者(主账号)具备 FULL_CONTROL 权限,其他人没有权限(默认) |
public-read | 创建者具备FULL_CONTROL权限,匿名用户组具备READ权限 |
public-read-write | 创建者和匿名用户组都具备 FULL_CONTROL 权限,通常不建议授予此权限 |
authenticated-read | 创建者具备 FULL_CONTROL 权限,认证用户组具备READ权限 |
B、对象的预设ACL
预设名称 | 描述 |
---|---|
default | 空描述,此时根据各级目录的显式设置及存储桶的设置来确定是否允许请求(默认) |
private | 创建者(主账号)具备 FULL_CONTROL 权限,其他人没有权限 |
public-read | 创建者具备 FULL_CONTROL 权限,匿名用户组具备 READ 权限 |
authenticated-read | 创建者具备 FULL_CONTROL 权限,认证用户组具备 READ 权限 |
bucket-owner-read | 创建者具备 FULL_CONTROL 权限,存储桶拥有者具备 READ 权限 |
bucket-owner-full-control | 创建者和存储桶拥有者都具备 FULL_CONTROL 权限 |
简易示例
存储桶ACL
在创建存储桶时COS将创建一个默认的ACL赋予资源拥有者对资源的完全控制权限(FULL_CONTROL),示例如下:
<AccessControlPolicy>
<Owner>
<ID>Owner-Cononical-CAM-User-Id</ID>
</Owner>
<AccessControlList>
<Grant>
<Grantee>
<ID>Owner-Cononical-CAM-User-Id</ID>
</Grantee>
<Permission>FULL_CONTROL</Permission>
</Grant>
</AccessControlList>
</AccessControlPolicy>
对象的ACL
在创建对象时COS默认不会创建ACL,此时对象的拥有者为存储桶拥有者,对象继承存储桶的权限与存储桶的访问权限一致,由于对象没有默认的ACL,其将遵循存储桶策略(Bucket Policy)中对访问者和其行为的定义,来判断请求是否被许可,如果您需要对对象授予其他访问权限,您可以在此基础上添加更多的ACL来描述对象的访问权限,例如:授予匿名用户只读单个对象的权限,示例如下
<AccessControlPolicy>
<Owner>
<ID>Owner-Cononical-CAM-User-Id</ID>
</Owner>
<AccessControlList>
<Grant>
<Grantee>
<ID>Owner-Cononical-CAM-User-Id</ID>
</Grantee>
<Permission>FULL_CONTROL</Permission>
</Grant>
<Grant>
<Grantee>
<URI>http://cam.qcloud.com/groups/global/AllUsers</URI>
</Grantee>
<Permission>READ</Permission>
</Grant>
</AccessControlList>
</AccessControlPolicy>
风险展示
Step 1:进入存储桶控制面板查看对象存储列表选择存储桶
Step 2:依次点击\\”权限管理-Policy权限设置\\”
Step 3:配置写ACL策略
Step 4:直接访问存储桶域名
Step 5:查看对象可以看到\\”AccessDenied\\”
Step 6:查看存储桶的ACL策略,可以看到有配置\\”FULL_CONTROL\\”权限
<AccessControlPolicy>
<Owner>
<ID>qcs::cam::uin/100018226706:uin/100018226706</ID>
<DisplayName>qcs::cam::uin/100018226706:uin/100018226706</DisplayName>
</Owner>
<AccessControlList>
<Grant>
<Grantee xmlns:xsi=\\\"http://www.w3.org/2001/XMLSchema-instance\\\" xsi:type=\\\"CanonicalUser\\\">
<ID>qcs::cam::uin/100018226706:uin/100018226706</ID>
<DisplayName>qcs::cam::uin/100018226706:uin/100018226706</DisplayName>
</Grantee>
<Permission>FULL_CONTROL</Permission>
</Grant>
</AccessControlList>
</AccessControlPolicy>
Step 7:通过PUT ACL写入策略,将存储桶的访问权限配置为公有读写,这里直接通过请求头来修改
PUT /?acl HTTP/1.1
Host: al2ex-1305322268.cos.ap-chengdu.myqcloud.com
x-cos-acl: public-read-write
Connection: close
Cache-Control: max-age=0
sec-ch-ua: \\\"Chromium\\\";v=\\\"92\\\", \\\" Not A;Brand\\\";v=\\\"99\\\", \\\"Google Chrome\\\";v=\\\"92\\\"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Step 8:之后可以看到存储桶的访问权限从\\”私有读写\\”变成了\\”公有读写\\”
Step 9:之后可以查看存储桶对象
文末小结
在配置存储桶的ACL时应该遵循最小权限策略,同时对于一些读写操作,例如:ACL的写操作应该慎之又慎
原创文章,作者:七芒星实验室,如若转载,请注明出处:https://www.sudun.com/ask/34385.html