引言：为什么需要重视OSS的访问控制
对象存储服务（OSS），作为阿里云核心的存储产品，支撑着海量企业的图片、视频、文档等静态资源。但随着业务规模扩张，资源被盗链、数据被未授权访问、流量费用激增等问题也频频出现。可以说，如何科学地配置防盗链与权限访问控制，已经成了每个OSS使用者的必修课。
实际上，OSS提供了一套多层次、多维度的安全防护体系：从基础的Referer防盗链，到精细化的Bucket Policy和RAM Policy权限策略，再到临时授权的签名URL与STS机制。接下来，我们就从原理到实践，逐一剖析这些技术手段，帮助大家构建一个完整、安全的OSS访问控制方案。
一、防盗链：基于Referer的第一道防线
1.1 什么是防盗链
防盗链，是OSS基于HTTP请求头中Referer字段提供的一种访问控制机制。当用户通过浏览器或应用访问OSS资源时，请求头会携带来源页面的URL（即Referer）。OSS通过检查这个Referer是否在允许的白名单中，来决定是否放行该请求。这一机制的核心价值在于：防止其他网站将你的OSS资源嵌入自己的页面，从而盗用带宽和流量，给你带来不必要的费用支出。
1.2 防盗链的三种配置要素
在OSS控制台配置防盗链时，有三个核心参数需要关注：
白名单Referer：允许访问的域名列表。只有来自这些域名的请求才会被放行。多个Referer之间使用回车换行分隔。配置时需要注意，白名单中的域名需要同时包含http和https两种协议版本。
黑名单Referer：禁止访问的域名列表。黑名单中的域名发起的请求将被直接拒绝。当白名单和黑名单同时存在时，OSS会先判断黑名单，再判断白名单。这一顺序意味着：即使某个域名同时出现在白名单和黑名单中，它也会被黑名单规则拦截。
空Referer策略：决定是否允许请求头中不带Referer或Referer为空的请求。如果选择“不允许”，那么所有在浏览器中直接输入URL访问OSS文件的行为都会被拒绝。这在某些场景下可能影响正常使用——比如用户从浏览器地址栏直接访问图片，或者某些隐私浏览器不发送Referer时。
1.3 防盗链的生效逻辑
防盗链的判定逻辑可以总结为以下三种情况：
第一种情况：如果Referer白名单为空，则所有请求都会被允许，防盗链功能实际上处于未启用状态。
第二种情况：如果Referer白名单不为空，且不允许空Referer，则只有Referer属于白名单的请求被允许，其他请求（包括Referer为空的请求）都会被拒绝。
第三种情况：如果Referer白名单不为空，但允许空Referer，则Referer为空的请求和符合白名单的请求会被允许，其他请求都会被拒绝。
理解这一逻辑至关重要。很多用户在配置防盗链后发现自己网站无法访问OSS资源，往往是因为没有正确设置空Referer策略——例如，当用户从HTTPS页面引用HTTP资源时，某些浏览器可能不会发送Referer，此时如果防盗链设置为“不允许空Referer”，请求就会被拒绝。
1.4 QueryString截断规则
在防盗链配置中，还有一个容易被忽视的选项——截断QueryString。当选择“允许”截断时，OSS在匹配Referer时会忽略URL中的查询参数。举个例子，将Referer设置为 https://www.example.com/?action=nop，OSS实际会使用 https://www.example.com/ 进行匹配。选择“不允许”时，则会完整匹配带查询参数的URL。这一配置对于使用了动态参数的网站尤为重要，需要根据实际业务场景选择合适的策略。
1.5 通过Ja va SDK配置防盗链
除了控制台图形化操作，OSS也支持通过SDK编程方式配置防盗链。下面是一个使用Ja va SDK设置防盗链的完整示例：
需要注意的是，设置防盗链需要具备 oss:PutBucketReferer 权限。在实际生产环境中，建议通过RAM用户而非主账号进行操作，以遵循最小权限原则。
1.6 通过ossutil命令行配置防盗链
对于运维自动化场景，ossutil命令行工具提供了更高效的配置方式。查看当前防盗链配置：
以JSON格式查看：
设置防盗链则通过 put-bucket-referer 命令完成，需要将配置写入JSON文件后通过 --body 参数传入。
二、权限访问控制：多层次防护体系
防盗链只能解决“谁可以引用”的问题，但无法控制“谁可以读取、写入、删除”。为此，OSS提供了四层权限控制机制，从简单到复杂依次是：ACL、Bucket Policy、RAM Policy，以及临时授权机制（签名URL和STS）。
2.1 ACL：最基础的权限控制
ACL（访问控制列表）是OSS中最简单、最直接的权限控制方式。它通过预定义的权限等级来控制资源的公开或私有状态，支持以下三种等级：
私有（private）：数据完全私有，仅资源拥有者或被授权的用户可访问。这是Bucket的默认配置，也是推荐的安全配置。
公共读（public-read）：任何人都可以读取数据，但只有资源拥有者或被授权用户可以写入。适用于需要对外提供公开静态资源的场景，如图片、CSS、Ja vaScript文件等。
公共读写（public-read-write）：任何人都可以公开读取和写入数据。这种权限等级风险极高，除非有特殊需求，否则强烈不建议使用。
Bucket ACL控制整个存储空间的默认访问权限，而Object ACL可以单独控制某个对象的权限，且优先级高于Bucket ACL。也就是说，即使Bucket设置为私有，也可以为某个特定文件设置公共读权限。
2.2 Bucket Policy：基于资源的精细化授权
当ACL无法满足复杂的授权需求时，Bucket Policy提供了更强大的能力。Bucket Policy是直接附加在Bucket上的授权策略，可以定义谁（Principal）在什么条件下（Condition）可以对哪些资源（Resource）执行什么操作（Action）。
Bucket Policy的核心优势在于：
- 单条策略即可授权多个用户访问同一个Bucket，无需为每个用户单独配置
- 支持基于IP地址、VPC网络、访问时间等条件的精细化控制
- 支持授权给其他阿里云账号的RAM用户
- 支持授权给匿名用户（需谨慎使用）
- 配置简单，在控制台即可完成图形化操作
常见Bucket Policy配置示例
示例一：允许特定IP地址的匿名用户读取Bucket中的所有对象
示例二：授予特定RAM用户对指定目录的只读访问权限
配置Bucket Policy的重要注意事项
当Principal设置为通配符（*）且不包含Condition时，策略仅对Bucket Owner以外的用户生效。当Principal设置为通配符（*）且包含Condition时，策略对所有用户生效——包括Bucket Owner和匿名用户。这意味着，如果配置了拒绝访问的Condition策略，连Bucket Owner自身也会被拒绝访问，可能导致整个Bucket无法访问。因此，配置Bucket Policy时务必谨慎。
另外，acs:SourceIp条件关键字仅匹配请求的源IP地址，不区分该IP来自公网还是VPC内网。如果仅使用acs:SourceIp限制访问，其他VPC中恰好使用相同IP地址段的请求也可能被放行，存在越权访问风险。最佳实践是同时配置acs:SourceVpc来明确请求的网络来源。
2.3 RAM Policy：基于身份的权限管理
RAM Policy是附加在RAM用户、用户组或RAM角色上的授权策略。与Bucket Policy不同，RAM Policy是“基于身份”的——它定义的是“这个用户能做什么”，而非“这个Bucket允许谁访问”。
OSS支持两种RAM Policy类型：
系统策略：由阿里云预置，用户只能使用不能修改。最常用的两个系统策略是 AliyunOSSFullAccess（OSS完全管理权限）和 AliyunOSSReadOnlyAccess（OSS只读权限）。
自定义策略：由用户自行创建和维护，提供最灵活的权限配置能力。自定义策略采用JSON格式编写，核心元素包括：
- Effect：授权效力，取值为
Allow（允许）或Deny（拒绝） - Action：对资源执行的具体操作，支持使用通配符
* - Resource：策略作用的资源范围
- Condition：策略生效的条件（可选）
自定义RAM Policy示例
以下策略允许对 example-bucket 及该Bucket内所有资源执行全部操作：
RAM Policy与Bucket Policy的协同工作
当RAM Policy和Bucket Policy同时存在时，OSS会综合评估所有策略。权限判定的核心原则是：
- 显式拒绝优先：任何策略中存在匹配请求的Deny规则，请求立即被拒绝
- 寻找显式允许：不存在Deny规则时，若存在匹配的Allow规则，请求被允许
- 默认拒绝：既无Deny也无Allow，请求默认被拒绝
这一原则意味着：即使某个RAM Policy允许了某操作，如果某个Bucket Policy明确拒绝了该操作，请求依然会被拒绝。反之亦然。
2.4 OSS扁平化存储结构对权限配置的影响
OSS采用扁平化存储模型，所有文件直接隶属于存储空间，物理上不存在目录层级结构。控制台中看到的“目录”实际上是通过对象Key的前缀和分隔符（/）模拟出来的。目录对象的Key以 / 结尾，这是OSS识别“目录”的标志。
这一结构对权限配置有重要影响：当需要授权访问某个“目录”时，实际上是在授权访问具有特定前缀的所有对象。例如，授权访问 Development/ 目录，等同于授权访问所有Key以 Development/ 开头的对象。
不同操作目标对应的API请求和Resource配置也不同：
- 列举存储空间根目录：调用
ListObjects（prefix为空，delimiter为/），Resource指向Bucket本身 - 进入某个文件夹：调用
ListObjects（prefix为文件夹名/，delimiter为/），Resource指向Bucket本身，通过Condition的oss:Prefix限制可列举范围 - 读写文件内容：Resource可精确到路径，如
acs:oss:*:*:examplebucket/文件夹名/*，支持通配符
通过OSS控制台访问时，用户需要从Bucket列表逐层导航进入目标目录，这比直接使用API/SDK需要更多的权限——除了目标资源的操作权限外，还需要 oss:ListBuckets、oss:GetBucketInfo 等辅助权限。
三、临时授权：签名URL与STS
在实际业务中，我们常常需要让没有OSS账号的第三方临时访问某个文件——比如让用户下载私有文件、让合作方上传数据等。此时，ACL、Bucket Policy、RAM Policy都无法满足需求，因为它们都需要预先定义好“谁”可以访问。签名URL和STS临时凭证正是为解决这一场景而生。
3.1 签名URL：为单个文件生成临时访问链接
签名URL（又称预签名URL）将签名信息和认证参数直接嵌入URL中，让你无需共享访问凭证即可授予对OSS资源的临时访问权限。任何持有该URL的人都可以在有效期内执行指定的操作（如下载、上传），URL过期后自动失效。
签名URL的核心特性
- 有效期可配置：使用V4签名算法时，AccessKey签名URL有效期最长为7天（604800秒），STS临时凭证签名URL最长为12小时（43200秒）
- 支持多次访问：在有效期内，同一个URL可以被多次使用
- 操作绑定：生成URL时指定HTTP方法（GET用于下载，PUT用于上传等），URL只能执行该操作
- 无需凭证：访问者无需持有任何AccessKey，直接使用URL即可
使用Python SDK生成签名URL（下载）
以下示例使用OSS Python SDK V2生成一个用于下载文件的预签名URL：
使用Python SDK生成签名URL（上传）
以下示例生成一个用于上传文件的预签名URL：
上传者获得该URL后，只需发送HTTP PUT请求到该URL即可完成上传，无需任何OSS凭证。
签名URL的V4签名结构
一个完整的V4签名URL包含以下查询参数：
其中 x-oss-credential 包含AccessKeyId、日期、Region和服务名称。需要注意的是，URL中的斜杠需要进行URI编码。
3.2 STS临时凭证：为复杂场景提供临时身份
签名URL适用于单个文件的临时访问，但当需要为第三方应用提供持续的、多操作的OSS访问能力时，STS（Security Token Service）临时凭证是更好的选择。
STS的核心价值在于：
- 无需泄露长期AccessKey给第三方
- 可自定义访问权限和有效期限
- 凭证过期后自动失效，无需手动撤销
STS临时授权的典型流程
以企业A授权企业B上传数据到OSS为例：
步骤一：企业A创建RAM用户，并授予该用户调用STS服务 AssumeRole 接口的权限（AliyunSTSAssumeRoleAccess系统策略）。
步骤二：企业A创建RAM角色，定义该角色被扮演时可以拥有的OSS访问权限。
步骤三：企业A调用STS AssumeRole 接口获取临时访问凭证（包括临时AccessKey ID、AccessKey Secret和SecurityToken），并将其传递给企业B。
步骤四：企业B使用临时凭证构造签名请求，访问OSS资源。临时凭证的有效时间最小为900秒，最大值以角色设定的最大会话时间为准。
使用STS临时凭证的注意事项
当使用STS临时账号生成预签名URL时，有效时长以两者中较小者为准。例如，STS临时凭证有效期为1200秒，预签名URL设置为3600秒，则实际有效期为1200秒。
OSS控制台中默认的URL有效时间为3600秒，最大值为32400秒。如果需要超过32400秒的有效期，必须使用ossutil或OSS SDK生成。
四、综合安全策略与最佳实践
4.1 多层防护的组合使用
单一的安全措施往往不够，建议将多种手段组合使用：
- 第一层：Bucket ACL设置为私有，确保默认情况下所有数据不公开。
- 第二层：配置Referer防盗链，防止其他网站盗用资源。
- 第三层：使用Bucket Policy或RAM Policy进行精细化权限控制，明确谁可以访问什么。
- 第四层：对于临时访问需求，使用签名URL或STS临时凭证，严格控制有效时间。
4.2 成本优化与安全加固
防盗链不仅是安全手段，也是成本控制手段。恶意盗链会导致大量的外网下行流量费用。建议定期检查OSS的流量监控数据，发现异常流量及时排查是否为盗链行为。
同时，建议启用OSS的日志记录功能，分析访问日志中的Referer字段，及时发现未授权的引用来源。
4.3 最小权限原则
无论是RAM Policy还是Bucket Policy，都应遵循最小权限原则——只授予完成工作所必需的最小权限集。避免使用 AliyunOSSFullAccess 这样的高权限系统策略，而是创建自定义策略，精确控制操作和资源范围。
对于生产环境，建议使用RAM角色和STS临时凭证替代长期AccessKey，减少密钥泄露的风险。
五、常见问题解答
问1：配置了Referer白名单后，为什么我的网站还是无法访问OSS图片？
答：最常见的原因是空Referer策略配置不当。如果你的网站使用HTTPS协议引用HTTP资源，或者用户使用隐私模式浏览器，请求可能不携带Referer。请检查防盗链配置中是否选择了“允许空Referer”。另外，请确认白名单中的域名是否同时包含了 http 和 https 两种协议。
问2：Bucket Policy和RAM Policy有什么区别？我应该用哪个？
答：Bucket Policy是基于资源的授权策略，直接附加在Bucket上，适合“谁可以访问这个Bucket”的场景（如跨账号授权、IP限制）。RAM Policy是基于身份的授权策略，附加在用户/角色上，适合“这个用户可以访问什么”的场景（如统一管理某个用户的所有权限）。两者可以同时使用，权限判定遵循“显式拒绝优先”原则。
问3：签名URL的有效期最长可以设置多久？
答：使用V4签名算法时，AccessKey签名URL最长有效期为7天（604800秒）；使用STS临时凭证生成的签名URL最长有效期为12小时（43200秒），且以STS凭证的有效期为准。OSS控制台生成的URL默认有效期为3600秒，最大32400秒。
问4：为什么我配置了Bucket Policy基于IP限制访问后，某些请求仍然被拒绝？
答：首先检查 acs:SourceIp 条件是否正确配置了目标IP地址。其次，acs:SourceIp 仅匹配源IP，不区分公网还是VPC内网。建议同时配置 acs:SourceVpc 来明确网络来源。另外，如果Bucket Owner自身访问也被拒绝，请检查Principal配置——当Principal为 * 且包含Condition时，策略对Bucket Owner也生效。
问5：防盗链中的黑名单和白名单同时存在时，哪个优先？
答：OSS会先判断黑名单，再判断白名单。这意味着即使某个域名在白名单中，如果它也在黑名单中，请求会被黑名单规则拦截。
问6：如何防止OSS资源被恶意刷流量？
答：建议从以下几个方面入手：1）Bucket ACL设置为私有，避免公开可读；2）配置Referer防盗链，限制仅允许特定域名引用；3）使用Bucket Policy限制访问IP范围；4）对敏感文件使用签名URL，控制访问时效；5）开启OSS的监控告警，及时发现异常流量。
