前言
本文主要探讨在支付业务基础设施检测中关于生产数据的保护要求及目前的一些主流的数据保护技术浅析。目前监管机构在不同层次中均对数据的保护提出要求,涵盖物理存储安全、数据备份、应用级灾备等不同方面,正文中将主要对这三块检测内容的技术实践内容进行探讨。
数据物理存储安全
在《JR/T 0123.1—2018非银行支付机构支付业务设施检测规范》中的主机安全部分检测项中对于此部分提出明确要求,在实际检测中对于此检测项的最新判例也保持了一般问题的问题等级。不难理解,目前支付系统中所有数据的存储载体在磁盘空间中,所以主机中的磁盘空间安全是一切数据保护的基础,支付机构对于数据的物理存储空间保护主要通过独立磁盘冗余阵列(RAID)技术来保证物理存储空间的高效存储性能和数据冗余。目前主要支付机构主要采用的RAID模式包含RAID1、RAID5、RAID1 0(RAID0+1)等数据冗余模式。
不同的RAID模式代表了不同的数据冗余模式,不同业务规模的机构根据自身的数据规模及增长情况制定不同的冗余策略,以下简要介绍不同RAID模式的异同。
RAID0:RAID0 是一种简单的、无数据校验的数据条带化技术。实际上不是一种真正的 RAID ,因为它并不提供任何形式的冗余策略。
RAID1:RAID1它将数据完全一致地分别写到工作磁盘和镜像磁盘,它的磁盘空间利用率为 50% 。RAID1 拥有完全容错的能力,但实现成本高。RAID1 应用于对顺序读写性能要求高以及对数据保护极为重视的应用。
RAID5: RAID5 应该是目前最常见的 RAID 等级,校验数据分布在阵列中的所有磁盘上,而没有采用专门的校验磁盘。另外, RAID5 还具备很好的扩展性。
RAID1+0(RAID0+1): RAID01用两块磁盘建立镜像,然后再在镜像内部做条带化。RAID01 的数据将同时写入到两个磁盘阵列中,如果其中一个阵列损坏,仍可继续工作,保证数据安全性的同时又提高了性能。RAID01 和 RAID10 内部都含有 RAID1 模式。具体比较见下表:
RAID 等级 | RAID0 | RAID1 | RAID5 | RAID10 |
容错性 | 无 | 有 | 有 | 有 |
冗余类型 | 无 | 有 | 有 | 有 |
热备份选择 | 无 | 有 | 有 | 有 |
可用容量 | 全部 | 50% | (n-1) | 50% |
部分支付机构采用的新兴技术如分布式存储技术、固态内存RAID等方式本文不再继续做讨论。
数据备份机制
在《JR/T 0123.1—2018非银行支付机构支付业务设施检测规范》中的数据安全部分检测项中对于此部分提出明确要求,在实际检测中对于此检测项的最新判例也保持了严重问题的问题等级。支付机构的核心数据均存放于大型数据库中,因此对于数据备份的技术实现一般都是通过对于数据库的备份策略进行有效配置来实现。本文主要基于Oracle数据库的备份策略进行探讨。
Oracle目前支持多种备份方式,包括冷备份、Export/Import指令、归档日志备份等不同方式,同样Oracle目前主流版本也支持使用Rman备份工具进行备份。
在支付业务中几乎不会采用冷备份这种机制,冷备份数据库是将数据库关闭之后备份所有的关键性文件,将其拷贝到另外的位置。冷备份实际也是一种物理备份,是一个备份数据库物理文件的过程。支付业务的特点决定了不支持数据库频繁关闭,因此冷备份的方式仅存在于一些极小规模的数据库系统。
归档日志备份也偶尔会作为支付机构的备份方式,这种方式可以在数据库运行的情况下(Archive log状态)进行备份,这种可以实现灵活的恢复节点,但是维护也较为困难。
利用Export可将数据从数据库中提取出来,利用Import则可将提取出来的数据送回到Oracle数据库中去,Export备份的是数据库对象,因此被称为逻辑备份。这是支付系统中常见的一种备份方式,但传统的exp与expdp备份工具,只能实现一个完整备份而不能增量备份。
在检测中也常见到增量/全量备份这类备份策略,不同机构根据自身业务情况普遍选择每日增量+定期全量备份的方式来保证生产数据库的有效备份。Oracle通过Rman可以实现这一备份机制,具体实现指令不做详细解释。对于业务规模不大的数据库系统,可以通过每天全量备份来实现数据库的整体备份,但是一般业务规模较大的情况下就需要DBA灵活配置每天的备份任务,使用增量模式来备份每天新增的数据。增量策略之前必须要先做一次全量备份(也称为0级备份),全量备份内容作为标尺,每天只需要备份新增的数据即可。但是之前讨论的通过EXP方式备份的完全备份的文件无法作为增量备份的标尺。
应用级灾备机制
在《JR/T 0123.1—2018非银行支付机构支付业务设施检测规范》中的业务连续性安全部分检测项中对于此部分提出明确要求,在实际检测中对于此检测项的最新判例也保持了严重问题的问题等级。对于支付机构来说,应用级灾备系统的建设是开展支付业务的必要条件,而应用级灾备系统不仅需要备份机房部署承载支付业务的相关应用系统,也同样需要实现数据容灾的策略配置设计。同样讨论Oracle模式下的数据同步机制。
Oracle目前主要有Data Guard、Golden Gate等方式进行数据容灾,Data Guard通过复制归档日志或在线日志来进行数据同步,Golden Gate通过抽取在线日志中的数据变化,转换为GGS自定义的数据格式存放在本地队列或远端队列中来实现数据同步。整理网络中对于二者的具体实现差异情况描述如下:
Oracle DataGuard | Oracle GoldenGate | |
原理 | 复制归档日志或在线日志 | 抽取在线日志中的数据变化,转换为GGS自定义的数据格式存放在本地队列或远端队列中 |
稳定性 | 作为灾备的稳定性极高 | 稳定性不如DataGuard |
备份端可用性 | 备份端处于恢复或只读状态,在只读状态下不能同时进行恢复 | 两端数据库是活动的,备份端可以提供实时的数据查询及报表业务等,从而提高系统整体的业务处理能力,充分利用备份端的计算能力,提升系统整体业务处理性能。可以实现两端数据的同时写入 |
复制方式 | 通过恢复机制实现的,无法实现同步复制 | GoldenGate可以提供秒一级的大量数据实时捕捉和投递,异步复制方式,无法实现同步复制 |
经实际检测中发现,部分机构在满足监管所要求的至少同城应用级灾备基础上,逐步根据自身业务规模逐步实现两地三中心及双活/多活数据中心的建设,保证自身基础设施的业务连续指标进一步提高。
王雨,专注于非银行支付系统检测、认证等工作。2015年至今曾参与起草、修订非银行支付领域相关标准,实施过100多家支付机构业务系统检测工作,对支付业务安全、风险合规管理、支付系统安全、支付数据安全等有较为深入的理解,熟悉我国金融领域信息安全监管要求(网络安全等级保护、电子银行安全评估指引、支付信息安全标准等)。作者邮箱:wangyu02@cfca.com.cn,欢迎大家提出宝贵建议。
声明:本文来自网安前哨,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。