作者简介：samyj，中通信息安全团队安全研发工程师，负责中通SRC、各种后台管理系统开发以及统一安全文件存储服务的开发与维护。

背景

信息化产业的高速发展，使各行各业产生的数据量也呈现出了爆炸性增长的趋势。以快递行业为例，快递业务量相较往年也有了成倍的提升，单是中通双十一当天的订单已经达到了1.5亿件，随之带来的是海量的订单、底单数据、图片等，文件数据的存储也面临了前所未有的机遇与挑战。那我们该如何解决文件存储更多、更快、更安全的需求？传统单机模式的文件存储方案显然不能满足我们对于海量高并发、安全、快速存储的需求，于是分布式文件系统（distributed file system）方案的设计变得愈发重要。结合中通实际业务场景与对安全的思考，我们设计实现了一套基于FastDFS分布式文件系统的安全文件服务解决方案。

面临的问题与挑战

中通早期WEB应用存在的问题

传统WEB应用中，前端、API服务部署在同一台服务器，所有文件都作为静态资源访问，随着业务量的不断增长，久而久之，图片和文件等资源占用的空间变得越来越大。随之带来了各种性能、管理问题与安全风险：

  • 若文件直接置于应用服务器中，难以管理；
  • 昂贵的磁盘空间、高性能服务器大大增加了运维成本；
  • 易发生单点故障；
  • 传统FTP上传文件，存在诸多安全隐患（用户名和口令的明文传输等）；
  • 无法保证文件的机密性，某些敏感文件如身份证照片等以明文存储，文件的授权访问不易控制；
  • 安全没有保障，文件上传、下载、删除、查看依赖于各个业务系统的实现，一个上传功能可能出现“修不完的漏洞”；

分布式文件存储系统

既然传统的文件存储方式存在这么多弊端，那么新的分布式文件系统需要满足哪些需求呢？

1.应用功能需求

2.技术需求

中通安全文件存储解决方案

什么是分布式文件系统？

分布式文件系统（Distributed File System, DFS）是一种允许文件通过网络在多台主机上分享的文件系统，可让多机器上的多用户分享文件和存储空间。客户端并非直接访问底层的数据存储区块，而是通过网络以特定的通信协议与服务器通信，借通信协议来限制客户端对于文件系统的访问。分布式文件存储利用多台存储服务器分担存储压力，利用跟踪服务器定位存储信息，不但提高了系统可靠性、可用性以及读写效率，而且方便水平扩展。分布式文件存储可采用多副本备份机制，分布式存储对数据进行了分片，分片后的数据按照一定规则保存在集群节点上。即使单个集群节点机器发生故障也能保证数据不会丢失，最小化对业务的影响。

分布式文件系统选型

常见的分布式文件系统有GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。它们各自适用于不同的领域，都是应用级的分布式文件存储服务。

图1 典型分布式文件系统对比

FastDFS具有简单易用、维护方便、高性能、稳定性好、满足中通对于海量小文件存储的需求，结合以上优点，我们最终选择了FastDFS作为中通安全文件存储的底层数据存储系统。

FastDFS简介

FastDFS是一个开源的的轻量级分布式文件系统，追求高性能和高扩展性。FastDFS是一种基于文件的key/value pair存储系统，为互联网量身定制，适合存储4KB~500MB之间的小文件，如图片网站、短视频网站、文档、下载站等等。作为一个轻量级分布式文件存储，FastDFS具有以下特性：

  • 文件不分块存储，上传的文件和OS文件系统中的文件一一对应
  • 支持海量文件的存储和读写分离
  • 支持相同内容文件合并，节约磁盘空间
  • 支持备份容错
  • 支持主从文件

FastDFS具有以下优点：

  • 结构简单，元数据节点压力低
  • 扩容简单，扩容后文件自动同步，无需重新平衡
  • 高性能，文件处理速度快，适合海量小文件存储
  • 支持小文件合并

缺点在于：

  • 不能自定义文件key，自己定义会降低灵活性
  • 数据恢复效率低：磁盘镜像分布，修复速度取决于磁盘写入速度
  • 大文件冲击问题：大文件没有分片，导致大文件的读写都由单块硬盘承担，对磁盘的冲击很大，由于我们主要以小文件为主，所以影响较小
  • 缺乏自动化故障恢复机制、运维机制和在线配置能力
  • 源storage写一份即返回成功，源storage出现故障，就可能导致数据丢失，建立监控告警机制，对storage进行检测，实现出现故障时及时通知处理
  • 缺乏必要的安全访问控制机制以及文件数据保护措施，通过文件服务网关可以自己实现访问控制与数据保护

FastDFS服务端有三个角色：跟踪服务器（tracker server）、存储服务器（storage server）和客户端（client）。

  • tracker server：跟踪服务器，主要做调度工作，起负载均衡的作用。管理所有的storage server和group，tracker根据storage的心跳信息建立映射表以生成元数据信息。
  • storage server：存储服务器（又称：存储节点或数据服务器），文件和文件属性（meta data）都保存到存储服务器上。以group为单位，每个group内可以包含多台storage server，数据互相备份。
  • client：客户端，作为业务请求的发起方，通过专有接口，使用TCP/IP协议与跟踪器服务器或存储节点进行数据交互。

图2 FastDFS架构介绍

FastDFS存储策略

为了支持大容量，存储节点采用了分卷的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件相互独立，一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。在卷中增加服务器时，系统会自动同步已有的文件，同步完成后，系统将新增服务器切换到线上提供服务。当存储空间不足或即将耗尽时，可以动态添加卷，只需要增加一台或多台服务器，并将它们配置为一个新的卷，就可以完成文件服务器的扩容。

图3 存储策略

架构设计

中通安全文件存储以FastDFS为底层存储，支持浏览器HTTP或者SDK的形式上传、下载和删除文件，网关负责路由访问请求到文件服务Tracker， Tracker服务器返回Storage服务器的地址，网关和Storage通信完成文件上传并记录文件元数据信息到Redis集群和Pika集群。架构图如下：

图4 架构设计

原理/模块介绍：

  • 采用Nginx作为网关处理请求转发和校验，Nginx的多路复用机制和非阻塞IO非常适合业务简单、耗时短的校验操作。Tengine 7层负载，作为L1 cache proxy_cache，大大提升了网关的性能和并发访问能力
  • 文件网关处理图片水印、文件加解密、文件名称自定义、访问权限控制等，并负责与底层文件系统交互
  • Redis集群与Pika集群用作文件元数据的存储，Redis和Pika集群之间数据互相同步，前者作为临时存储，后者作为持久性存储，Pika将数据写入硬盘，易于迁移
  • ZooKeeper集群用于存储应用配置信息

核心实现

  • 认证

用户上传时可以选择上传公开文件以及私有文件。为避免文件盗用，我们采用签名校验和SSO token校验的方式处理对私有文件的上传和访问请求。业务系统需要申请文件服务并配置上传服务器IP白名单后才能使用，申请成功后自动为业务系统创建存储空间，生成appid、secret以及文件系统group（如图5）。文件上传时需携带使用secret生成的一次性签名，文件服务网关校验签名的合法性和时效性。下载时通过内网请求文件网关，返回具有一定时效性的securityToken，浏览器访问文件时携带此token，文件网关校验通过后才能访问到文件。

  • 缓存策略

中通安全文件存储采用二级缓存机制：浏览器缓存和网关层缓存。第一次请求文件时返回完整数据包并在浏览器和Nginx网关层创建缓存；再次请求相同文件时先检查浏览器本地缓存，如本地缓存失效或不存在则尝试读取Nginx中的缓存文件，再次失败则重新请求底层文件服务获取文件。

  • 敏感文件加解密

通过SSL进行上传，防止中间人截获，选择文件加密时，文件网关先将文件流做base64处理，再用aes进行加密后存储到文件服务器，解密同理。

  • 文件上传漏洞防范

上传漏洞就是攻击者通过上传木马文件，直接得到webshell。提供文件上传SDK进行前端校验的同时，服务器本身不解析任何动态语言文件，文件网关也对用户提交的数据进行严格的检验与过滤，设置文件格式白名单与上传IP白名单。同时严格设置输出文件的文件类型，除图片类型外所有的Response Content-Type设置为application/octet-stream 防止用户访问时直接打开HTML或TXT，阻止XSS攻击。

  • 统计监控与日志

为保证文件服务的运行可靠性与可用性，系统的监控告警是必不可少的。服务网关使用Prometheus+Grafana作为监控告警工具，通过HTTP协议周期性抓取文件服务器的运行状态以及接口调用情况。

图5 监控

文件用量根据应用来做统计分析，记录每天的接口调用情况，文件服务器容量的使用情况等。文件服务网关将每一个上传动作记录下来，统计文件的大小与数量，将统计信息写入到Redis集群中。当文件占用空间超过为当前应用分配总空间的阈值时给业务系统的相关负责人发送邮件通知，及时扩容。中通安全文件存储对敏感文件进行严格的日志记录，保存访问人的IP、帐号等信息，一旦发生信息泄露可以做到及时定位文件信息与访问人信息。

实践效果

自中通安全存储开始在内部使用以来，系统一直平稳运行，现已接入业务系统80余个，日均上传量300W+，读取量1000W+，并且根治了危害性极高的上传漏洞。

图6 整体使用情况

图7 应用使用情况

如何使用

我们提供了一套流程化接入方案：用户先到管理后台申请使用文件存储服务，申请通过后会获得appid、secret等信息，开发人员接入我们的上传SDK后只需简单配置secret与appid等信息后即可使用。简要流程如下所示：

图8 创建工单

图9 申请文件存储服务

图10 部分SDK代码

总结和展望

中通安全文件存储服务上线以来，在性能、安全性、高可用等方面都获得了不错的评价，我们在多个方面也做了些设计上的权衡，但仍然面临一些挑战。第一，易用性方面，安全性和易用性某种程度上是有一定的矛盾，提高易用性的同时也要兼顾安全，比如提供在前端直接上传文件的jssdk，就需要综合考虑各方面因素；第二，统一服务和定制化服务方面的冲突，如某些应用需要对图片文件进行特殊的定制化处理或者支持特定的交互流程，这个原则上文件存储本身只提供基础的通用服务；第三，效率持续提升方面，需要研究使用更安全高效的文件加解密算法以及实施端到端的加密传输，在保证安全的同时提升存储、传输效率，节省服务器、带宽、存储资源。

另外随着中通生态圈业务量的不断飙升和业务多样化，目前单租户的架构设计已经逐渐无法满足日益变化的业务需求，因此我们正在设计规划支持多租户的统一安全文件存储服务平台，支持多租户模式的同时支持对接业界流行的底层文件存储框架，如Ceph、S3等，提供更多云平台的对接支持，结合服务容器化等云原生技术，支持混合云架构下的应用对接和使用，帮助多租户下的不同应用可以自动化部署以及灵活的水平扩展，以支持不同业务场景下文件存储服务的定制化需求，实现对文件资源进行更细粒度的访问管控。

团队介绍

中通信息安全团队是一个年轻、向上、踏实以及为梦想而奋斗的大家庭，我们的目标是构建一个基于海量数据的全自动信息安全智能感知响应系统及管理运营平台。我们致力于支撑中通快递集团生态链全线业务（快递、快运、电商、传媒、金融、航空等）的安全发展。我们的技术栈紧跟业界发展，前有 React、Vue，后到 Golang、Hadoop、Spark、TiDB、AI 等。全球日均件量最大快递公司的数据规模也将是一个非常大的挑战。我们关注的方向除了国内一线互联网公司外，也关注 Google、Facebook、Amazon 等在基础安全、数据安全等方面的实践。

声明：本文来自中通安全应急响应中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。