国产数据助力金融行业维护信息安全

Posted 2022-12-14 dotNET跨平台

金融信息系统作为国家关键信息基础设施，直接关系到国家经济、社会的正常运行。长期以来，我国金融信息化依赖进口设备和系统，金融行业尤其是银行业被IBM、HP、甲骨文等外商捆绑较深，金融行业信息化设备的软硬件系统被外商垄断。这等于是我们的金融行业是由花钱雇来的外国雇佣兵在站岗放哨。这不仅需要花费巨额的外汇，更涉及到我国金融业的安全可控。近年来，金融业不断加大国产软硬件试点力度，国产CPU、国产数据库已经在部分金融机构实现了核心系统的应用突破，为解决金融业数据库供应链安全问题树立标杆、积累经验。

国产数据库三条技术路线

目前，金融系统的数据库根据使用场景划分，可以分为核心系统、办公系统和一般系统。

根据《金融业数据库供应链安全发展报告》，金融业核心系统用到的我国数据库产品主要集中在华为GaussDB和OpenGauss、中兴GoldenDB、腾讯TDSql、达梦数据库、蚂蚁集团OceanBase、阿里Tair及平凯星辰TiDB，另外部分银行基于开源内核自研数据库产品，在核心系统实现了应用。在办公管理及一般系统中，除了核心系统用到的产品外，还用到阿里PolarDB/RDS/ADBPG、人大金仓KingbaseES、巨杉SequoiaDB、南大通用Gbase等。

上述数据库按照技术路线划分，可以分为自研闭源数据库、基于开源软件二次开发数据库和基于国外技术的数据库。

闭源自研须有确定的开发主体和服务提供者，软件的迭代升级能就地实现，数据库开发者完全主导和决策产品的研发方向，甚至可以对特定行业和特定客户提供定制版本，闭源自研最能体现厂商的能力和技术水平。不过，目前国内还没有出现市场能力和技术能力达到甲骨文水平的厂商，且国内能够做到不依赖开源代码，闭源自研的厂商微乎其微，达梦数据库是闭源自研路线的典型代表。

DB-Engines所统计的数据库产品中开源数据库数量占比为52%，开源数据库的流行度和数量都超过商业数据库，正成为技术与市场变革的新引擎。由于基于开源软件二次开发可以站在巨人肩膀上，快速拿出达到市场主流水平的数据库产品，导致开源数据库也已经成为我国数据库实现突围的主要途径，华为、中兴、腾讯、阿里等大公司都选择了这条路线，GaussDB是基于PostgreSQL二次开发，GoldenDB、TDSQL是基于mysql二次开发。不过，目前PostgreSQL、MySQL等开源数据库掌握在国外开发者手中，其升级迭代能力、长期发展能力取决于主导企业/开发者的投入水平和战略定位。我国开源数据库还没有形成足够多的开发者社区和服务者群体，生态圈尚显稚嫩。

基于国外技术的数据库可获得较高的起点，可继承外商的技术和生态优势，增加了企业级特性。但增加了不少风险，如果只继承了外商的源代码，却没有形成自己的技术和能力，那么，在技术演进和技术迭代方面会比较麻烦。

金融业集中式数据库是绝对主流

诚然，无论是传统集中式数据库，还是以分布式数据库为代表的新型数据库，在解决金融业数据库供应链安全问题中都发挥重要作用，特别是部分金融机构实现了核心系统的应用突破，为解决金融业数据库供应链安全问题树立标杆、积累经验。但从实际情况看，集中式数据库更适宜金融行业，《金融业数据库供应链安全发展报告》中也证明了这一点。

一是我国集中式数据库具有自然的技术继承性。金融业长期使用的Oracle、DB2、SQLServer、MySQL、PostgreSQL等数据库均为集中式架构，平移到同类型的其他集中式数据库相对难度小、成本低、风险可控，从而成为很多用户的自然选择。而且我国主要集中式数据库对国外主流成熟数据库进行了大量兼容，这样可确保应用过程中对应用侵入性小，同时无论是开发人员还是运维人员，其原有的技术、技能均可沿用，为我国数据库产品应用规避知识和技能壁垒。

二是我国集中式数据库技术相对成熟。我国集中式关系型数据库经历近30年的研发、优化、应用和成长，已经在政企等不同领域得到较为充分的应用和打磨，初步具备支持金融应用能力，基本满足金融行业对可靠性、可用性、高性能、高安全性的需求。同时，集中式数据库由于其更短的数据流程和决策机制，更容易保障其数据一致性和交易响应时间。

三是集中式数据库更适合业务量适中的交易类业务场景。集中式数据库在严格遵守事务ACID特性、数据强一致性的同时，保证高性能和高可靠性，天然契合交易复杂度高、数据强一致性、响应时间和吞吐量高的金融业OLTP业务场景。如银行的存取款等核心业务对数据的强实时一致性要求；证券业的实时交易对响应时间要求极其苛刻；保险行业核保交易需要核实和校验大量的信息,交易涉及的规则非常多而且多变。

四是我国集中式数据库初步构建应用生态体系。我国集中式数据库厂商经过多年的经营，初步形成可用、部分易用的生态体系，适应金融行业现有IT环境。

正是因此，集中式数据库成为金融行业绝对主流，占比高达89%。这主要是因为传统集中式数据库具有高效的数据存储效率和优异的系统稳定性，有力支持数据共享集中处理系统建设，在数据大集中时期形成绝对的主导地位。在金融业很多应用实践中，我国优秀的集中式数据库产品顺利实现对国外商用数据库的替换，既是发展规律和技术特点共同作用的结果，也是市场的自然选择。

开源软件风险不可小觑

近年来，本土互联网产业和软件产业蓬勃发展，虽然取得了不少成绩，但在基础软件方面往往习惯于依赖开源，普遍对Linux、openstack、MySQL、ceph等开源软件有所依赖。虽然一些厂商把开源和自主、安全划等号，但实际上，开源软件风险不可小觑，其存在的知识产权风险和安全风险，必须予以重视。

一是开源许可协议约束风险。目前被OSI认可的开源许可协议已超过100种，不同种类的许可协议约束各不相同。当前全球最流行的六大开源协议（GPL、BSD、MIT、Mozilla、Apache、LGPL）中，其约束规定差别很大。如有些开源协议具有传染性，要求使用许可协议的代码再发布时必须提供源代码的GPL许可协议，有些许可协议对产品所包含的专利并未包含明确的专利许可条款，如BSD、MIT等。当用户不当使用这些许可协议的开源技术或者产品时，就存在侵权的风险。

二是开源许可协议的变更风险。开源许可协议是脆弱的，协议本身可以通过协商、修订、补充等方式进行修改，使得使用规则存在不确定性。自2018年以来，多个开源软件开发商(如Redis、MongoDB、Kafka等)已经对其过去使用的开源许可证进行了修改。Oracle则宣布2019年1月以后发布的OracleJavaSE8的公开更新将不再向没有商用许可证的业务、商用或生产用途提供。

三是开源许可协议的法律风险。开源相关的法律约束除了开源许可协议的约束条款，还包括出口管制和司法管辖权，以往较少被关注。有些开源基金会和托管平台的条款中如果明确说明遵循该国的出口管制，一旦所在国政策出现变化，修改出口管制条例，相关的开源代码或国内企业托管在其上的源代码资产将受到出口管制。如GitHub托管平台在2019年7月因美国贸易管制政策限制了克里米亚开发者帐户，同样的情况也发生在2022年俄乌冲突中。司法管辖权在开源知识产权纠纷中也很关键。一旦一个开源项目或者开源组织指定司法管辖权的归属地，就意味着围绕该条款展开的知识产权纠纷只能在该地法院展开，这将给国内企业带来非常大的困扰，胜诉的几率也非常低。

四是开源许可协议的兼容性风险。在当前开源技术大流行的背景底下，企业在研发过程中使用众多的开源技术和产品，这些开源技术和产品中有可能也使用其他的开源技术和产品，这些不同开源产品所遵循的开源许可协议有可能不兼容，不但带来开源组件传统漏洞类的安全管理问题，相关开源许可协议不兼容及许可协议的依赖传递性也带来知识产权风险。

开源软件的安全性也值得关注。据美国网络安全公司Snyk发布的《2019年开源安全现状调查报告》显示，78％的漏洞存在于间接依赖关系中；37％的开源开发者在持续集成期间没有实施任何类型的安全测试，54％的开发者没有对Docker镜像进行任何安全测试；两年内应用程序的漏洞数量增长了88％。据新思科技《2021开源安全与风险分析报告》显示，84%的代码库至少含有一个漏洞，近三年漏洞比例逐年增高，60%的已审核代码库包含高风险漏洞。据开源网安SourceCheck工具对热门开源项目的扫描结果看，53.8%的项目存在超危风险。另外，开源软件涉及源代码共享，很多配置信息中会涉及账号密码等敏感信息，如果不对代码进行审核检查，可能会造成大量敏感信息与数据随着代码的共享而泄露。同时，开源软件公开的源代码，如果包含对企业数据库的访问代码，则可能导致整个数据库面临数据泄露的危险，也可能导致企业内部文件与用户信息的泄露。

结语

目前，金融IT基础设施安全创新已经是金融系统的共识，也做了不少的试点工作，特别是国有大行，其国产数据库比例非常高，办公系统和核心系统的国产数据库使用比例达到83%，一般系统的占比达到100%。根据《金融业数据库供应链安全发展报告》内容，梅州客商银行将核心业务系统由原来的Oracle RAC + Data Guard迁移至达梦数据共享存储集群（DM DSC）+ 达梦数据守护集群（DM DataWatch）+ 达梦数据实时同步软件（HS）上，不仅提升了数据库整体处理能力，还实现了两地双中心高可用容灾架构。中国人寿则将企业年金系统（受托管理达千亿规模）迁移到达梦数据上，该项目于2020年12月正式上线，基于达梦数据库的年金系统，年终结算批作业、精算等业务上，处理时间大幅缩短50%以上，综合性能超客户预期30%以上。基于达梦在线增量迁移方案，业务系统在上线窗口期，耗时5小时快速完成TB级数据从原生产数据库到DM的同步，开发团队针对性修改代码不到10行，快速完成应用系统从原生产数据库到DM的移植，既有效降低客户运维成本，又保证了系统的高可用性。

诚然，国产数据库尚存在一些不足，金融机构也面临数据库选型难、应用不充分、实施难度大、管理与运维复杂、人才队伍短缺等困难。希望相关各方还需针对性地弥补短板、改进不足、统筹推进，全面提升金融业数据库供应链安全水平。