对象存储OSS 客户端签名直传的安全风险和解决方法

1. 前言

阿里云对象存储OSS（Object Storage Service）是一款海量、安全、低成本、高可靠的云存储服务，可提供99.9999999999%（12个9）的数据持久性，99.995%的数据可用性。多种存储类型供选择，全面优化存储成本。

OSS具有与平台无关的RESTful API接口，您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

2.OSS与文件系统的对比

下表为OSS与文件系统在数据模型、数据获取、优势以及劣势的差异对比。

对比项	OSS	文件系统
数据模型	OSS是一个分布式的对象存储服务，提供的是一个Key-Value对形式的对象存储服务。	文件系统是一种典型的树状索引结构。
数据获取	根据Object的名称（Key）唯一的获取该Object的内容。 虽然您可以使用类似test1/test.jpg的名称，但是这并不表示Object是保存在test1目录下。对于OSS来说，test1/test.jpg仅仅只是一个字符串，与example.jpg并没有本质的区别。因此不同名称的Object之间的访问消耗的资源是类似的。	一个名为test1/test.jpg的文件，访问过程需要先访问到test1目录，然后再在该目录下查找名为test.jpg的文件。
优势	支持海量的用户并发访问。	支持文件的修改，例如修改指定偏移位置的内容、截断文件尾部等。也支持文件夹的操作，例如重命名目录、删除目录、移动目录等非常容易。
劣势	OSS保存的Object不支持修改（追加写Object需要调用特定的接口，生成的Object也和正常上传的Object类型上有差别）。用户即使只需要修改一个字节也需要重新上传整个Object。 OSS可以通过一些操作来模拟类似文件夹的功能，但是代价非常高。例如重命名目录，如果希望将test1目录重命名成test2，则OSS的实际操作是将所有以test1/开头的Object都重新复制成以test2/开头的Object，该操作会消耗大量的带宽、存储、计算、时间资源。因此在使用OSS时请尽量避免类似的操作。	受限于单个设备的性能。访问越深的目录消耗的资源也越大，操作拥有很多文件的目录也会非常慢。

从上述表格得知，不建议将OSS映射为文件系统。如果结合您的业务场景需要将OSS挂载为文件系统，建议只执行写入文件、删除文件、读取文件操作。使用OSS应该充分发挥其优点，即海量数据处理能力，优先用来存储海量的非结构化数据，例如图片、视频、文档等。

下表为OSS与文件系统的概念对应说明。

对象存储 OSS	文件系统
Object	文件
Bucket	主目录
Region	无
Endpoint	无
AccessKey	无
无	多级目录
GetService	获取主目录列表
GetBucket	获取文件列表
PutObject	写文件
AppendObject	追加写文件
GetObject	读文件
DeleteObject	删除文件
无	修改文件内容
CopyObject （目标文件和源文件相同）	修改文件属性
CopyObject（目标文件和源文件不同）	复制文件
CopyObject+DeleteObject	重命名文件

3. OSS客户端签名直传的安全风险

3.1 为什么使用客户端直传而非服务端代理上传

在典型的服务端和客户端架构下，常见的文件上传方式是服务端代理上传：客户端将文件上传到业务服务器，然后业务服务器将文件上传到OSS。在这个过程中，一份数据需要在网络上传输两次，会造成网络资源的浪费，增加服务端的资源开销。为了解决这一问题，可以在客户端直连OSS来完成文件上传，无需经过业务服务器中转。

3.2 客户端签名直传方式的风险

客户端签名直传是指在客户端生成签名，使用签名上传文件到OSS。客户端可以直接将文件上传至OSS，减少了中间环节，因此可以加快上传速度。

上传文件到OSS需要使用RAM用户的访问密钥（AccessKey）来完成签名认证，但是在客户端中使用长期有效的访问密钥，可能会导致访问密钥泄露，进而引起安全问题。

4. 客户端签名直传方式风险解决方法

4.1 解决方法1: 服务端生成STS临时访问凭证

对于大部分上传文件的场景，建议您在服务端使用STS SDK获取STS临时访问凭证，然后在客户端使用STS临时凭证和OSS SDK直接上传文件。客户端能重复使用服务端生成的STS临时访问凭证生成签名，因此适用于基于分片上传大文件、基于分片断点续传的场景。需要注意的是，频繁地调用STS服务会引起限流，因此建议您对STS临时凭证做缓存处理，并在有效期前刷新。为了确保STS临时访问凭证不被客户端滥用，建议您为STS临时访问凭证添加额外的权限