7*24小时人工服务
400-00-52360
编程模型
以保护数据安全和架构的合理性为出发点，我们基于360云存储服务如何进行开发，提供了一些设计和编码建议。希望开发者在使用360云存储服务之前阅读这些建议，并且尽可能符合这些原则，以免带来不必要的数据安全风险。
基本结构
从上图可以看到以下信息：
1. 360云存储服务
- 以键值对（K/V）的形式，提供非结构化资源（文件）存储服务。向业务服务器提供资源管理服务，向业务客户端提供上传下载服务。
2. 业务服务器
- 生成上传、下载、管理资源的签名信息，这些信息不能在客户端生产，会产生极大的数据安全风险。
- 使用关系型数据库（如MySQL）管理用户资源文件的映射关系（资源文件与360云存储服务之间的对应关系）
3. 业务客户端
- 客户端通常是资源（文件）的生产方和消费方。
- 客户端在上传和下载内容时，先从自己的业务服务器获取上传/下载签名信息，然后使用签名与360云存储服务服务器进行交互，完成后续上传/下载动作。
业务流程
1. 上传
- 客户端在上传资源到360云存储服务之前，要先从业务服务器上获取一个上传签名
- 把上传签名和资源文件，一并上传给360云存储服务
2. 下载
- 下载可以有两种方式，一种通过接口获取资源下载的真实URL，客户端自行处理；另一种直接下载资源，但需要客户端支持302跳转，建议使用后一种方式。
- 对于公共读权限的bucket，下载时不需要签名，客户端可以直接和360云存储服务下载；对于私有权限的bucket，下载时必须有签名，客户端需要用业务服务器计算好签名的地址。
- 在大多数情况下，客户端展示的数据都是从业务服务器获取的。因此，无论公共读还是私有的bucket，都可以在业务服务器下发给客户端前，根据bucket权限，完成逻辑操作。
3. 资源管理
- 为了保证数据安全，资源管理操作仅能通过业务服务器与360云存储服务交互完成。
- 如果客户端进行资源管理，即使将签名信息通过业务服务器计算下发给客户端，仍然容易被第三方截获请求报文，导致重放攻击的风险。
关键原则
- 整个架构中，需要一个业务方的服务器资源，而不是纯客户端和我们进行对接
- 无论如何，SecretKey不能被包含在客户端的安装包中，并且SecretKey不得在任何场景中进行传输。
- 业务服务器端应该维持一个数据库，用于管理资源数据（映射关系）
- 原则上，客户端和360云存储服务服务端之间的交互仅有上传和下载，不应该使用其他任何API
- 我们非常不建议，开发者把用户的数据上传到自己的服务器，然后再从自己的服务器上传到360云存储服务。一旦我们双方服务器之间的网络出现抖动，那么上传效果会大打折扣，在我国网络当前的阶段，这种事情是难以避免的。