非FTP的批量文件传输方案设计.docx
《非FTP的批量文件传输方案设计.docx》由会员分享，可在线阅读，更多相关《非FTP的批量文件传输方案设计.docx（11页珍藏版）》请在冰豆网上搜索。
非FTP的批量文件传输方案设计
非FTP的批量文件传输方案设计
产品与技术路线如何选型
前言
目前，在银行IT架构中，批量文件传输过程中设计的服务器及网络节点众多，同时由于银行分支机构及用户遍布各地，随着银行与外部单位合作加强，规模不断扩张。
使其对数据传输的效率、可靠性、安全等方面提出了诸多要求。
出于以上各类原因，很多银行原则上规定数据传输要加密和防篡改，不允许使用FTP，行内服务器不允许使用SFTP，跨行内网络域因为防火墙效率问题，只允许规定ip间进行大文件传输等。
由于以上存在的各类痛点及相关问题，使用传统的文件传输工具已经无法胜任企业级应用环境的需求。
因此，专业的传输工具的建设需求日益出现。
批量文件传输的专业产品和技术框架选型就显得十分重要，社区特别组织线上交流探讨活动，帮助大家学习和了解，如何进行银行大文件传输的专业产品和技术框架选型。
活动中，业内专家和社区会员对产品与技术路线进行了深入探讨，IBM专家则以SterlingConnectDirect产品为案例，从各个方面介绍了如何使用专业的文件传输工具实现合规性及高效性等。
现由来自银行业的社区专家willow，根据本次活动中大家关心的问题和有参考价值的解答、分享，分别从文件传输产品的选型、适用的场景范围、部署方案、合规性与审计、安全性、高效性、功能性以及Sterling系列其他产品功能，这八个方面进行详细总结：
一、文件传输产品选型的几个关键要素
1、【Q】文件传输平台的选择问题？
场景概述：
我们现在的文件传输还在使用nfs和ftp方式。
NFS不够稳定，经常受到网络环境的影响。
上级单位在使用GTP文件传输软件，但是部署上又太复杂，不灵活。
不知道现在有没有简单易用，稳定性强的传输产品可以推荐呢？
【A】：
IBMSterlingConnect:
Direct（C:
D）本身在大陆有将近30家银行使用，台湾与香港80%银行在使用，全球800多家银行，其中香港的清算中心在使用C:
D,所以目前大陆的支付机构如果在香港有业务都需要使用C:
D与之传输。
所以C:
D的稳定性、安全性、审计性是经过20多年的实践考验的。
C:
D支持自动化安装，我们的合作伙伴利用这一特性开发了集中部署的方式实现自动化部署。
同时，利用C:
D自身的可配置性、可管理性可以很容易地运维C:
D。
2、【Q】统一文件传输平台的技术指标和实施要点？
【A】：
除了包括传输本身的稳定性，安全性，审计性，完整性外，还包括可管理性，审计，可视化等上层应用。
实施方面主要考虑贵公司的传输需求，与系统的集成要求，系统接口现状，安全规范，应用场景，运维场景，监管要求等，另外要考虑可靠的实施商，他必须有丰富的文件传输项目的经验，可以少走很多弯路。
3、【Q】文件传输方式和产品，能不能对比一下各自的优劣势？
【A】：
ftp传输效率高，但是纯明文的，安全性低。
sftp是基于ssh协议，使用加密方式进行传输，安全性高但效率比ftp低。
东方通的GTP和IBM的C:
D都属于商用的文件传输工具，能够实现安全性高、高效率的可靠传输，文件传输场景较为复杂。
二、文件传输产品适用的场景范围？
1、【Q】统一文件传输平台在对外交互场景下的应用？
场景概述：
面向行外系统交互时，统一文件传输平台是否也能发挥作用，是否有解决方案？
与互联网企业合作中，发现批量数据文件的场景越来越少，甚至使用联机报文的方式进行文件传输，这种模式是否有问题，要如何应对这种变化，统一文件传输平台是否支持这种场景？
【A】：
首先我们要看对外传输的要求是什么，安全？
审计？
不可抵赖性？
大文件？
我倾向于如果没有明确的需求就可以使用现在的传输，如果现有传输不满足监管或业务伙伴要求时可以考虑使用传输平台。
IBMSterlingFileGateway可以支持多种传输协议，安全的传输方式，审计等特性。
目前大部分公司的IT是服务于业务，满足业务的需求及协议业务满足最终用户的需求。
联机报文更多的是希望尽快确认交易，把文件传输作为交易的一环也纳入到了整个交易中，这种处理最简单，这种方式在数据量不大的情况下可以，但量很大的情况下，个人还是倾向于把文件传输与整个交易分离，异步处理，但这会对你们目前的架构及整个程序的思考方式发生很大的变化，像目前的互联网公司大量的消息机制、时间机制处理业务都是为了应付大数据量的处理。
毕竟同步处理在编程、架构及思维上比异步处理要简单。
统一的传输平台尽量保证传输发生在两个节点之间，不要因为第三方，比如管理平台，配置平台对传输产生影响，尽可能保证传输效率，保证联机交易的时间窗口。
与行外系统进行文件传输的过程中，往往外联机构的系统不支持行里现有的传输工具，通常要充分与该单位进行沟通，确定合适的传输机制。
OLTP交易类的系统大多是通过报文的方式直接交互的，只要保证对报文有相关的加密算法，使其满足CIA原则大部分是没问题的。
个人了解，目前还没有明确的监管办法对该方式提出具体要求。
2、【Q】联机交易类的文件传输，一般采用什么方式进行文件传输？
【A】：
如果是对响应时间要求高的都不采用文件传输，而是通过socket,mq等方式。
一般传统的ESB或MQ等负责联机交易，而文件传输平台是另外一套，主要负责批量。
但目前确实是联机交易中有文件传输，基本都是2s到5s之间就行，而且即便超了这个时间也没事，那可以用同一套文件传输平台，前提是管理平台不对传输产生影响，传输发生在两个点之间。
但如果真是一定要在2s之内响应的我个人不建议用文件。
3、【Q】联机交易中的文件传输与批量数据传输是否有较大差异？
【A】：
原则上只要是文件传输都可以纳入统一文件传输平台，但需要注意的是联机交易对时间的敏感度比批量更高。
一般批量关注很多文件在某个时间窗口内传输完成即可，而联机往往要求单笔传输的及时响应。
所以纳入一个平台要关注批量是否会影响联机，如果不影响就可以纳入。
4、【Q】目前大数据处理过程中使用的流数据传输方式，与文件传输平台的关系是什么？
【A】：
目前商用的批量传输都要求文件落地。
IBMSterlingConnect:
Direct（C:
D）目前已经与AWS做了融合可以直接从AWS下载或向AWS上传数据，如果是与本地的大数据融合需要在C:
D基础上做定制。
如果不做定制的实现方式是C:
D先读取文件把文件传到大数据可以访问到的机器，然后C:
D主动调用大数据的接口把文件放入大数据平台。
三、文件传输平台的部署方案？
1、【Q】文件传输平台部署架构及数据流向问题探讨
场景概述：
目前我行数据交换系统，通过在各服务器上部署代理节点，根据配置监听指定目录下的指定文件，发现文件就绪后，将文件传输回主服务器，再根据配置传输到消费方系统。
疑问：
当前文件传输时，是采用文件传输到中心服务器，再进行分发的方式，是否有更具效率，并兼顾安全的解决方案？
当前部署是采用在各服务器新增交换系统用户，单独部署代理节点，将需文件传输的目录权限放开，感觉权限管理与运维均较为麻烦，是否有更优解决方案？
目前系统不支持多中心多活部署，在此方面是否有较好的解决方案？
【A】：
这种方式的中心节点可能会成为瓶颈，一般我们建议传输与管理分开的方式。
IBMSterlingConnect:
Direct（C:
D）产品的传输与管理是分开的。
C:
D使用操作系统用户，但C:
D不需要知道对方的密码，而且发送方不要知道接收方的用户信息，而是接收方根据发送的节点信息及用户名决定使用哪个系统用户处理此请求。
权限的管理由基础运维人员负责。
C:
D支持静默安装及自动化部署。
C:
D支持多活部署。
C:
D的多活节点对外面的节点看是一个节点并且多活的节点支持断点续传。
2、【Q】IBMSterlingConnect是否支持分布式部署？
【A】：
IBMSterlingConnect:
Direct（C:
D）本身是点对点的应用，也就是每个需要传输的机器上都安装C:
D。
但C:
D仅做传输，C:
D本身需要能够访问得到需要传输得文件，其它就由文件系统及后面得存储负责。
对于存储在多台服务器上的文件，用户必须要知道哪些文件存在了哪些服务器上，然后向C:
D发命令进行传输，也就相当于你自己做个NameNode。
向Hadoop之类的分布式文件系统自身拥有了NameNode你不关心到底文件存储在哪里及怎么存储，但C:
D仅为仅做传输，而且文件不切片，所以其它的事情你要定制开发，C:
D提供了多中语言的API及详细的接口让你控制及使用C:
D。
3、【Q】IBMSterlingConnect:
Direct（C:
D）在文件交互传输方式有何优势？
【A】：
IBMSterlingConnect:
Direct（C:
D）支持多种操作系统，并且可以实现各种系统之间的文件互传及编码转换。
C:
D支持Java,C,C++,.Net,Shell等多种语言的API，可以尽量做到应用系统不改动或少改动.
C:
D本身支持TLS及SSL的加密传输，用户、IP、证书、节点等认证体系保证传输的安全。
C:
D本身记录的详细的传输日志，不论是发送端还是接收端，而且此日志可以通过命令行、API等方式获取。
同时IBM提供IBMControlCenter可以集中提取日志，可视化日志，并监控日志内容并及时发出告警。
国产化是一个现实，是一个我们国内企业开发能力提升的主要表现之一。
不过开发本身及后续的运维成本及不断增加的需求的成本都很高，每个企业可以根据自己的需求考量。
针对IBM而言，为了及时地支持客户，IBM针对C:
D的合作伙伴在中国有3家以上，之所以说3家是他们收入的一大部分利润来自与这个产品的支持及增值服务，他们有丰富的经验。
而且他们有的可以与IBM实验室直接沟通定期开会，所以这块的支持大家可以放心。
四、文件传输的合规性与审计
1、【Q】如何满足等级保护的相关要求？
如何解决目前应用中存在的FTP文件传输方式？
场景概述：
近期我们一直在做等级保护等方面的工作，上级部门也发文要求禁止使用3389，21，23等端口。
对于21的使用，就我了解，我们一些应用肯定在使用，也了解一些FTP的安全问题。
问题：
对于我们来说，首先，如何做才能达到等级保护和上级部门的要求？
其次是如何选择这个安全的文件传输方案，并与应用开发商共同解决的问题？
【A】：
首先，FTP传输在合规上肯定是无法满足等保要求的。
但，就您目前现有的问题:
需要使用ftp，同时又要禁止使用21233389这些端口，个人建议您可以利用工具搭建统一的ftp服务器，同时将ftp服务对外监听端口修改为非周知端口，同时ftp脚本里面也不要出现明文。
同理，3389和23端口也可以通过修改注册表和配置文件更改其端口。
而以上这种方式，并不能从本质上改变ftp或telnet传输明文的痛点，仅能比原有方式稍提升安全性。
长久上看，还是要选用利用CD等适合企业IT架构的专用传输工具或考虑在基于FTP协议之上，开发特色的传输工具，封装ftp协议，同时增加密文传输等功能。
一般的安全要求还包括数据的加密，传输的认证及审计，单独的禁止端口不可以。
SFTP可以实现一定意义上的数据加密及证书认证，但不具备审计及集中管理、配置、监控的要求。
尤其是审计，目前我遇到大陆、香港及台湾的银行都在做审计，这个对上市公司尤其重要。
2、【Q】文件的分级存放？
【A】：
数据存放的问题，可以考虑使用专用的数据保护产品来实现。
比如，近期在学习GDPR通用数据保护条例过程中，就了解到相关的数据保护类产品，能够将敏感数据进行标签化、一体化实现不同安全级别数据的不同保存方式，以满足相关监管政策的要求。
IBMSterlingConnect:
Direct仅负责传输，至于存放到哪些位置属于存放策略及文件管理范畴，目前C:
D上无法配置，需要IBM的业务伙伴根据用户的需求制定方案。
3、【Q】如何实现文件合理合规传输？
场景概述：
当前应用系统之间的文件传输，包含图片，文档，xml等类型，需要跨网络区域，unix和windows系统之间，甚至是定制的linux，环境十分复杂，监管要求越来越高。
但是开发的能力无力改变现有的应用架构。
面对这样的局面，如何实现文件合理合规传输？
【A】：
目前我们常见的合规主要由安全、审计及可管理性组成，安全主要是用户名及密码不能明文，应该用其它的认证方式，如果保证文件的安全。
审计就是要看这个文件是谁在什么时候发送给谁了，及文件的位置信息等。
管理就是能够统一的管理所有的传输，有问题能够及时发现，及时找到原因。
unix和windows系统之间的传输方式，除了使用跨平台的传输工具外，目前我们也没有找到合规的传输方式。
在无法安装传输工具的前提下，大多情况下还是利用ftp、sftp等方式。
4、【Q】非FTP方式文件访问权限怎么控制的，是不是有白名单的机制？
【A】：
IBMSterlingConnect:
Direct（C:
D）作为文件传输的工具可以严格控制谁及哪些IP可以传输文件。
五、文件传输的安全性
1、【Q】文件传输防篡改也可以使用数字签名验签的方式，更为简单有效？
【A】：
如果是通道加密的方式，不是针对整个文件进行签名而是针对读取到传输通道的内容签名，这样就不会对真个系统的CPU由很大的开销，尤其是针对大文件。
其实数字签名本身不能防止文件被篡改，而是说别人篡改了你能发现。
另外数字签名还具有不可抵赖性的特性，尤其是文件本身的签名，这个在B2B集成的场景下特别有用，但对于内部传输而言，必要性就不大了。
在不使用第三方传输工具的情况下，发送方和接收方通过数字签名方式，也能够实现文件的完整性（防篡改）和身份验证。
2、【Q】文件传输过程中如何对文件加密解密？
【A】：
IBMSterlingConnect:
Direct（C:
D）有两种方法实现加密解密：
1、传输通道加解密：
使用TLS，SSL传输协议，C:
D可以针对不同的传输开启加解密，这个是对传输通道加密，文件的发送方与接收方感知不到加解密。
2、文件本身加解密：
传输前调用用户自己的加密程序，传输完毕调用用户的解密程序，利用C:
D的流程语言把此过程写成流程，每次向C:
D发明令调用此流程即可。
3、【Q】非FTP的方式是如何保证传输过程中文件不被篡改的？
【A】：
IBMSterlingConnect:
Direct（C:
D）目前通过TLS协议保证传输过程中文件内容不被看到，因为看不到，所以即便其他人想改文件内容也是盲目改，而C:
D的另外一端就会马上感知到文件被修改，那这个传输就是错误的。
C:
D的安全主要体现在认证、授权及传输本身的安全，具体而言：
认证。
C:
D的认证分为用户认证、IP认证、节点名认证、证书认证等。
而用户认证可以不通过用户名与密码，这与传统的FTP不同。
对端节点通过判断你是不是从某个节点使用某个用户来进行传输，从而决定滋生通过哪个用户做处理，这也是用户代理的概念。
通过多层次认证增强安全。
而FTP主要是用户名与密码认证
授权。
C:
D除了对用户做基本的目录授权外，还包括对传输的提交、查询、暂停、删除等操作的授权，同时每个节点还可以针对其它与之交互的每个节点单独授权同时传输的文件个数、断点重试的次数及时间间隔、读取文件的速度等。
而FTP通常只有简单的目录授权。
传输。
FTP都是明文传输，而C:
D支持TLS及SSL加密传输。
同时C:
D对断点续传、完整性校验也是传输安全的另外一种增强，而FTP不具备。
同时C:
D还可以实现在传输前调用用户的加密、签名程序对文件进行加密及签名，进一步与用户的安全体系融合从而增强安全。
六、文件传输的高效性
1、【Q】非FTP方式的批量传输效率如何保障呢？
【A】：
IBMSterlingConnect:
Direct（C:
D）通过以下方式提升效率：
并发。
C:
D本身具备传输队列，用户仅提交传输任务给C:
D，本身不用关注并发。
集群。
C:
D支持集群，可以把多个传输节点作为一个节点接收文件，并支持一个节点失败另外一个节点接管传输并实现断点续传。
断点续传。
不用从头传输失败的文件。
自动化。
C:
D支持流程脚本，可以把文件相关的操作统一写入流程，C:
D自动执行。
比如备份文件，传输文件，删除源文件，通知目标应用等
支持优先级，保证高优先级的文件优先传输。
对文件的传输大小无限制，不用拆分文件。
2、【Q】非FTP的方式有什么机制能保证文件的正常传输？
【A】：
IBMSterlingConnect:
Direct（C:
D）通过记录断点的方式记录已经传输的文件大小，如果传输失败会从断点重新传输。
而FTP本身不记录断点，所以客户端与服务端都无法知道从哪里开始重传。
一般的商用传输软件的重传仅针对与网络中断，而C:
D提供了10000个以上的返回消息码，用户可以针对这些消息码定义哪些错误操作可以断点续传。
3、【Q】文件传输如何解决东西向流量，防火墙，大文件等限制？
【A】：
目前，国内银行在东西向流量的大文件传输时，因为网络安全域的跨域防火墙限制，效率难以有效提升，也一定程度限制了大数据等分布式技术的价值发挥，想了解一下，国外和国内同业在这方面实践的案例和先进经验。
这方面更多的是让传输流程自动化，尽量减少人工的干预。
有时为了文件的安全防火墙是必须的，那如果让流程自动化后减少文件在每道防火墙停留的时间，甚至不落地，那么效率就会提升。
在国内我们利用IBMSterlingFileGateway与IBMSterlingConnect:
Direct及用户的OA系统做成统一的文件借用平台，让整个文件流程可视化、自动化。
4、【Q】文件传输如何限流呢？
【A】：
IBMSterlingConnect:
Direct有两种方案进行限流：
1、通过限制读取文件的速度限流。
2、直接配置发送方及接收方的带宽使用率。
比如限制接收端仅能使用30M带宽。
5、【Q】异步传输方式下，如何判断文件是否传输或接收完毕，产品本身是否可以保障完整性？
【A】：
如果是使用专用的传输工具，大多会有完整性校验。
传输完成后，通过日志即可判断是否传输和接收完成。
七、文件传输功能性
1、【Q】上层有没有好的管理工具，比如性能展示，报表展示，用来分析文件传输系统的性能问题？
【A】：
IBMSterlingConnect:
Direct（C:
D）的上层由IBMControlCenter可以审计所有的传输、告警，并生成报表。
审计及报表内容包括某个时间端的数据量，为性能提供一定的信息支撑。
另外，还可以针对某些文件建立预警，如果在规定时间没有完成或没有开始，就发出告警。
2、【Q】是否提供API，可以在应用程序中直接对文件服务器中的指定文件或者指定的某些文件进行检索或者修改操作？
【A】：
IBMSterlingConnect:
Direct（C:
D）提供传输，所以提供了C,C++,JAVA,Shell,.Net等API供用户提交传输请求，查询传输记录，控制传输任务，配置C:
D。
但对于文件服务器上的文件的检索与修改不在C:
D的功能范围内。
3、【Q】文件传输平台的监控管理？
【A】：
目前，大部分ELK日志处理平台都可以满足该需求，可以将备份结果的日志传输到平台中，通过日志平台判断是否成功并通过api将结果传送至短信平台，实现短信提醒。
4、【Q】请问IBMSterlingConnect:
Direct如何控制并发请求？
【A】：
IBMSterlingConnect:
Direct（C:
D）可以单独控制每个与之进行交互的节点的上传与下载的并发数。
所有的传输请求都会放入传输队列，根据优先级及请求到达的顺序进行传输。
这里需要注意的是C:
D可以实现异步传输，也就是传输请求与传输本身分开，用户仅需要保证请求提交成功既可，后面由C:
D调度。
5、【Q】多个系统使用文件传输平台进行相互之间的文件传输，有何高效的方法管理彼此之间的依赖关系？
【A】：
在严格的依赖关系控制下实现可视化及集中管理是我认为的有效方法：
依赖关系的控制意味着不能随便用用户名与密码就可以使用传输服务，否则依赖关系会陷入混乱，就像目前的FTP一样。
可以通过控制IP，控制传输节点的名称，控制证书，控制用户，控制目录权限等严格控制谁可以与谁进行传输及传输方向、权限。
可视化意味着所有的需要传输的节点及连接关系可视化，让你知道目前有多少个系统在进行传输以及与谁有交互关系。
集中管理意味着你不必登陆每个系统去做配置，可以在可视化的基础上配置连接关系，配置权限等。
对于IBM的解决方案而言，IBMSterlingConnect:
Direct（C:
D）可以严格控制依赖关系及权限，IBMControlCenter可以可视化C:
D及连接关系，并作具体的配置。
同时，C:
D提供全面的传输、查询，配置等API,用户可以根据子所需开发自己的方案并与之融合。
八、Sterling系列其他产品功能探讨
1、【Q】SterlingB2BIntegrator如何实现企业信息自动化和供应链管理功能？
【A】：
IBMSterlingB2BIntegrator（SBI）集成了目前主流的传输协议，从而可以帮助企业打通与业务伙伴的系统对接，再加上自身的调度、流程引擎、格式转换引擎等，可以在对接的基础上把传输自动化。
也就是从企业自身的系统到SBI到业务伙伴的系统是自动化的，企业仅关心发送内容，而不用关心业务伙伴的协议及数据格式，从而让企业内部的系统更容易考虑业务而不是技术对接。
SBI本身作为企业与企业之间的对接中间件本身集成了供应链所需的传输协议（SFTP,AS2/3/4,OFTP,WebServer等）及数据格式标准（X12,EDIFact等）及行业标准（RosettaNet,SWIFT等），目的是为了实现供应链上下游及相关企业的信息集成的自动化、低成本及高效率，从而提供提供供应链所需的数据，而怎么利用数据、管理数据、生成数据是需要专业的供应链业务系统负责。
2、【Q】SFGSSPCD如何进行协同工作，构建数据交换平台？
【A】：
如果按照数据的流向看这三个产品在企业的部署顺序可以为：
外部企业<->SSP<->SFG<->CD，也就是SSP负责安全代理，通常部署在DMZ区域，保证所有外部企业必须在DMZ先完成认证再进入内网，同时保证文件再DMZ不落地；SFG作为文件网关部署在内网，负责与SSP及内部的系统集成，CD作为内部文件传输协议负责内部的文件传输。
对于一家企业如果考虑对内，对外所有的文件传输时就可以可以利用这几个产品打造一个统一的传输平台，在加上IBMControlCenter统一管理SSP,SFG及CD。
3、【Q】数据传输过程中，数据需求方和提供方如何对源数据进行标准化？
【A】：
如果双方都是初建系统，大家可以商量使用一种业界标准的格式或根据需要商定一个大家都认可的统一格式，这样有利于降低总体的开发成本。
如果其中一方已经有了数据格式，那么另外一方可以使用此数据格式或利用数据格式转换的工具把对方的格式转换成自己所需的格式。
IBMSterlingB2BIntegrator及IBMTransformationeXtender都可以作为数据格式转化的中间件。
升级会员 