阿里云OSS防盗链方案详解

最新推荐文章于 2024-09-21 11:00:00 发布

NicolasLearner

最新推荐文章于 2024-09-21 11:00:00 发布

阅读量2.7k

点赞数 1

分类专栏：服务器云服务器云主机文章标签：云服务云服务器阿里云腾讯云华为云

原文链接：https://cloud.macloud.tech/post/cs/a-li-yun-o-s-s-fang-dao-lian-fang-an-xiang-jie

版权

服务器同时被 3 个专栏收录

1446 篇文章 23 订阅

订阅专栏

云服务器

1446 篇文章 13 订阅

订阅专栏

云主机

1446 篇文章 7 订阅

订阅专栏

OSS（Open StorageService）非常适合存储静态文件并提供对外访问，例如图片、文档、视频、音频和静态页面等。它是一种海量、安全、低成本、高可靠的云存储服务，并按存储空间和对外流出流量计费。OSS要为网站提供真正意义上的服务，一定要解决防盗链的问题。本最佳实践要解决的主要问题就是如何实现防盗链机制，避免承担因此带来的额外OSS流量费用。
OSS在 Bucket级别提供了防攻击、访问控制、日志审计等三大类安全功能，灵活应用这些安全功能有助于提高防盗链的安全级别。防盗链相关的安全功能简要说明如下：

类别

子项

说明

防攻击

DNS

Bucket级别的域名解析，并进行了尽可能全面的防护

OSS服务

Bucket级别的自动攻击识别并进行四层和七层流量清洗，具备海量的清洗能力。

访问控制

权限类别

Bucket有三种访问权限：public-read-write，public-read和private。

来源验证

HTTP Referer的验证。

源IP地址黑白名单的验证(正在开发中)。

HTTP User-Agent的验证(正在开发中)。

授权访问

通过HTTP Head或URL中包含签名实现授权访问；把包含签名的URL转给第三方实现授权访问。
2. 授权的粒度可为Object级别，并可规定授权时效。
3. 授权项可为任意管理操作，通过是对某Object的读权限(在指定失效时间前)。

行为审计

访问日志

当一个bucket开启访问日志记录功能后，OSS将自动访问这个bucket的请求日志，以小时为单位，按照固定的命名规则，生成一个Object写入用户指定的bucket。

利用以上安全机制，基于OSS的防盗链最佳实践点如下：
1.     绑定三级域名，安全性比绑定二级域名更高。三级域名方式能够提供Bucket级别的清洗和隔离，能够应对被盗链后的流量暴涨的情况，也能避免不同Bucket间的互相影响，最终提高业务可用性。
2.     对Bucket设定尽可能严格的权限类别。例如提供公网服务的Bucket设置为public-read或private，禁止设置为public-read-write。
3.     对访问来源进行验证，最常见的是防盗链方案是Referer验证。正在开发中的源IP地址和User-Agent验证，会对Referer起到很好的补充作用。Referer结合源IP地址黑白名单验证，能够满足多数业务场景的防盗链要求。
4.     更严格的防盗链方案是采用包含签名的URL方案。该方案需要把Bucket权限设定为private，再把Object通过签名URL(含失效时间)的方式授权给第三方访问。
5.     记录Bucket访问日志，能够及时发现盗链活动和验证防盗链方案的有效性。

下面我们将通过一些实际案例来详细描述防盗链最佳实践的三种可选方案，读者可根据自己的业务特点和对防盗链的要求，选择适合自己的方案。建议优先选择方案一，其次才是方案二或三。

方案一

该方案把原业务系统的静态资源转移到OSS上，并通过三级域名CNAME方式直接提供公网访问。这种方案的优点是通过控制台配置就可实现，缺点是因为Referer可以被伪造，所以不能防御所有的盗链。该方案的示意图如下图所示。

实施步骤：Step 1：在Bucket属性中，设定Bucket为“公共读”权限。

tep2：在Bucket属性中，配置防盗链。详细可参考教程“设置防盗链使用指南”：

后续会支持源地址黑白名单和User-Agent规则。

Step 3：根据需要，在Bucket属性中，配置访问日志。

访问日志字段有源IP、时间、Referer、User-Agent、请求者的帐号ID、Access Key ID、错误码等。可与Web Server Log结合分析当时是否存在盗链。
Step 4：绑定三级域名到Bucket，在业务系统中也需要做相应的更改。域名绑定教程参见：https://help.aliyun.com/document_detail/31902.html?spm=5176.8466035.0.0.65101450n5wi22。
Step 5：重新发布应用，并启动。

最佳实践方案一的安全性分析
1. 容易被各种客户端技术伪造，不能防范恶意盗链。安全性低。
2. Referer限制，再结合源IP地址和User-Agent限制(正在开发中)，在多数场景下，也能达到理想的防盗链效果。

方案二

该方案与方案一的区别是通过签名URL，而不是Referer来完成防盗链功能。它最大的优点是因为URL签名无法伪造，防盗链效果比上个方案要好。该方案的示意图如下图所示。

最佳实践方案二的安全性分析
1.     签名URL中没有源IP等信息，它可像普通URL一样被公开使用。相比普通URL，它的安全性表现在：a) URL公开但只在很短的时间内有效；b) 不可伪造，不能把对A的读授权，伪造成对B的读授权。
2.     因为此方案的防盗链体现在授权URL的时效性上，而这也可能被盗链者利用，所以它的安全级别为中。更高级的防盗链需要应用自己实现，需要再增加源IP地址、SessionID等更多对源的检测参数(参见方案三)。
3.     URL过期时间建议初始设置为1小时，后续再根据防盗链效果进行调整。
4.     为了便于日志分析和更高的安全性，建议授权URL专用特定的一个或几个Access Key，不与管理Bucket的Key混用。

方案三

该方案的防盗链判断逻辑完全由业务系统处理。这种方案与上面两种的主要区别是：由反向代理或业务服务器代理静态资源访问，并实现防盗链逻辑；OSS只允许内网指定服务器的授权访问，公网不直接访问OSS。该方案的示意图如下图所示。