新闻中心

0512-87776578

szsl@sl2500.com

【测试分享】如何用企业级云CDP防数据库勒索病毒?

时间:2019-12-06 00:00:00   作者:   来源:

 「防数据库勒索病毒测试记录」

1.jpg

前言

最近数据库勒索病毒又开始出现了,有用户已经中招。主要是因为客户在连接数据库时使用了被人恶意篡改的盗版PL/SQL Developer 导致。在正版的PL/SQL Developer软件里面,有一个文件叫做afterconnect.sql,从名字上来看,该文件将在客户连接数据库之后来执行SQL脚本,该文件正常情况下是空的。还有一个文件叫做login.sql,这个文件当中应该只有一句注释。使用了盗版的,被别有用心的人利用,当病毒触发时,就会将整个数据库加密或删除。

 

如何做勒索病毒防护呢?

当然,首先还是要注意使用正版和可信任来源的工具,其次要要有数据的兜底机制,在最坏的情况下也要有方案去尽可能减少数据丢失的损失,减少业务中断时间。

 

这里以用友NC,使用自带的中间件,使用AD屏蔽底层的oracle主备库的差异,用友NC的应用层采用企业级云的灾备功能,数据库层面采用Oracle rac + dg单机备机容灾+平台CDP功能保护单机备机,进行业务层的高可用设计,同时进行容灾、备份保护。

 

用友NC业务高可用+容灾拓扑如下:

2.jpg

AD负载均衡设备可选,负载将数据库请求负载到主库,备库只读可做报表查询,减轻主库压力,当前未使用。

 

◆预期实现效果

使用Oracle  rac 2节点为了做高可用,宿主机任意一台物理主机故障,任意物理主机的任意磁盘故障,导致oracle节点故障,均有oracle高可用保障切换到其他rac节点,切换时间在40s左右。

 

Dg为了容灾切换,主数据中心发生灾难、断电等导致服务不可用,可进行一键切换,快速回复业务,1分钟左右的切换RTO,无数据丢失。    平台CDP保护能够防止误删、勒索病毒等各类逻辑错误,具有数据安全保护的功能。

 

◆测试

1、正常使用场景

按照拓扑图实际搭建进行测试,正常情况下,用友NC访问数据库。

测试结果:

正常

 

2、用友NC应用故障

用友NC虚拟机修改配置改坏了应用,需要进行恢复,本地有备份,直接恢复,检查是否能够快速业务恢复

测试结果:

直接恢复备份,检查业务恢复,耗时3分钟,业务恢复正常

 

数据库rac故障(实例故障)

3.1 构造数据库RAC1所在主机1断电故障,导致RAC1故障,检查业务是否受影响

测试结果:

NC客户端连接,自动恢复,耗时40s左右恢复正常,业务不受影响。

另,使用swingbench测试100用户并发,发现rac切换耗时也只有40s左右。

 

3.jpg

 

3.数据库集群故障

3.1数据库所在主机1、2同时出现断电宕机。

检查切换是否正常进行,本地rac集群全部故障无法工作,检查数据库是否能够快速恢复。

测试结果:

进行异地恢复,发现故障前的数据全部都在异地机房,没有数据丢失,由于才有了AD负载均衡进行负载,并不感知到已经负载到了备库,应用无感知。耗时1分钟左右。

这里其实不需要AD设备也行,就需要修改NC应用的连接IP了,不过后面想想使用DNS域名连接或许方案更优一些,主备库切换后修改DNS记录即可完成切换。

 

3.2 恢复测试

检查是否能够正常恢复。主机房断电恢复了业务,需要进行dg重建,有两个主库了当前,我们先前开了闪回数据库,闪回数据库,旧主库变成新备库了,业务正常,这里注意,切换回来之后,需要进行手动调整。

测试结果:

主库变备库切换正常,2分钟切换完成,主库重新手动切换为备库,耗时1分钟,效果较好。

 

4.  数据库误删数据(介质故障)

4.1 模拟人为误格式化数据盘数据场景,检测切换

测试结果:

备库中有存在此数据,dataguard能够防护此类逻辑错误,业务恢复正常,耗时1分钟。

 

4.2 模拟误删场景与勒索病毒场景

模拟勒索病毒场景,误删数据,检查是否能够恢复数据。

在维护数据库过程误删,或者直接中了勒索病毒,导致数据库被加密或者删除,如下

 create or replace procedure proc1

as

begin

  for i in 1 .. 100000 

  loop

    execute immediate

    'insert into t values ( '||i||')';

    commit;

  end loop;

end;

/

create table t (x int);

exec proc1;

查看备库已经有10万条记录

测试结果:

Truncate删除模拟勒索病毒删除数据,这里是直接操作数据库,所以备库也没有相关的数据了,dataguard也不能防止这种问题。

4.jpg

此时恢复备库CDP到5分钟前的数据,发现数据还是坏的,测试失败

5.jpg

后面又回滚到10分钟之前,新建一个数据库,把虚拟机网络接到不同的子网,以防IP冲突。拉起后发现数据存在,恢复正常,由于是快速拉起,基本上备份拉起速度很快,几分钟就开机了,failover强制切换主库后,检查数据还在。业务恢复,耗时30分钟左右。

6.jpg

 

7.jpg

恢复了数据,勒索病毒,兜底机制终于派上了用场...

 

5、主数据中心正常,灾备演练

数据中心整体故障,需要进行灾备恢复,模拟数据中心断电场景。演练直接在备库拉起,检查数据是否丢失

测试结果:

NC虚拟机在备机房拉起,3分钟;数据库切换耗时1分钟,调试确认等耗时10分钟,总计耗时15分钟,NC业务恢复。

 

6、业务回迁

主数据中心恢复了,做业务回迁。

测试结果:

耗时10分钟,NC业务在主机房正式上线,恢复工作。

文章来源:深信服社区,申浪科技综合整理