微盟被员工删库这事到底有多严重?

[图片]
关注者
258
被浏览
362,754

37 个回答

先说下不同级别的数据破坏后,恢复的难度把,以微盟这种使用云服务的为例。

1。 rm -rf /

这个是最常见的一个被调侃的东西。但是实话对于基于云服务的系统来说,这个威力并没有想象起来的那么大。因为一般来说,现在的云服务系统都不会把需要持久化的数据直接放在一个可以通过terminal登录的服务器上。大多数时候,这个操作会使得一台服务器崩溃无法提供服务,但是不会直接破坏数据

2。 git push origin master --force --no-verify

这个的破坏力会比上面那个大很多,它会导致云端的git repo代码库被破坏,但是对于git这类分布式代码库来说,只要用的人够多,代码还是能从其他人的电脑重新还原回来的。同时,这个操作不会破坏服务器本身的服务。


上面两个知道的人比较多而且不会产生致命后果,后面的一些我就不列举具体的代码了,因为后果要严重的多。


3。 删库 / 删表 / 随机删改数据

数据库上数据丢失恢复一直是个难点问题,其中最容易解决的可能反而是删库:因为一旦数据库删除那么后续所有数据都无法变化了,也就是说这个系统被“冻结”在了某个状态,如果有冷热备份的化,还原到这个时间点还是可以做到的。


相比之下,删表的破坏力比删库要大,因为表间数据的不一致会导致出现脏数据,并且不一定会导致服务整个停止,从而使得这种破坏变成了一种“持续失血“的伤害。除了数据恢复,还需要做数据修复。


删除/修改随机数据的影响更大。


4。变更权限、安全配置、有目的的修改数据等

这种会造成隐性的长期安全隐患,不一定会立刻产生作用,但是会是一个长期的风险点。

而目的的修改数据的情节其实更严重,因为意味着操作者并不仅仅是一时发泄,而是有精确计划的黑客攻击了。



微盟这次的操作看起来更像是第三类中的随机删除数据 + 随机修改数据,并且很可能不但删除了生产环境数据,还删除/修改了相应的备份,并且没有被第一时间阻断导致产生了脏数据。这些脏数据会严重干扰数据修复工作。微盟的做法:重新部署生产环境提供新的服务也侧面验证了这一点 - 代码库没有受到攻击(即使被攻击也很容易恢复),服务器部署应该也有快速部署/扩容的机制。但是数据看起来恢复起来很困难,疑似的脏数据阻塞(甚至是永久性的破坏)了数据恢复。



至于有多严重


第二百八十六条 违反国家规定,对计算机信息系统功能进行删除、修改、增加、干扰,造成计算机信息系统不能正常运行,后果严重的,处五年以下有期徒刑或者拘役;后果特别严重的,处五年以上有期徒刑。
违反国家规定,对计算机信息系统中存储、处理或者传输的数据和应用程序进行删除、修改、增加的操作,后果严重的,依照前款的规定处罚。
故意制作、传播计算机病毒等破坏性程序,影响计算机系统正常运行,后果严重的,依照第一款的规定处罚。

单看微盟的公告内容

1、新商家恢复,好做,只产生新数据

25日24时前,微盟从本地把代码和数据结构重新搭建新的数据库,新商家注册开新店,消费者进店访问、购买,产生新的数据,是有可能实现的。(从系统正式恢复起,之前的所有商家都算老商家)

2、老商家恢复,难,数据量大。如果数据结构混乱,就更难了

老商家的商品、订单、会员、营销、店铺装修、数据分析等模块的数据,在28日24时前,有可能恢复。也就是说,像森马、洽洽、百草味、林清轩这些微盟老商家,从23日19时到28日24时,使用微盟服务开设的店铺,需要停摆5天多时间。按照微盟的公告,是需要瘫痪125个小时的。5天无法正常做生意,对于商家来说,是非常难受的。

3、数据是不是能有序、完整修复,高度存疑!

23日19时发生问题,最初对外说是腾讯云的问题,这是不诚信的。微盟的公告表示,被核心运维人员进行了严重破坏。注意,“核心”运维、“严重”破坏,这哥们下手太狠了。作为非常了解最底层、最核心数据库的核心岗位人员,删线上数据库,估计连备份数据都一口气删除了。不然,微盟不会拖了几十个小时还啥都没恢复回来。

既然线上数据库和备份数据都删干净了,那么,老商家的商品、订单、会员、营销、店铺装修、数据分析等模块的数据,想要完整恢复,就很难了。微盟创办于2013年,7年的数据量应该不小,恢复的过程中,部分数据模块、数据字段因为备份机制不完善,是有可能无法彻底、完整修复的。这对于商家来说,是更大的一个灾难。

4、微盟的运维管理、技术管理存在严重问题

1个只有2年运维经验的员工,在运维圈基本上算是初级运维。但,这个人在微盟的公告里,竟然是“核心运维”,而且一次删库的破坏力如此巨大。这次出事,数据库镜像都没起作用,微盟作为上市公司,不可能数据库没有镜像机制,只有一个可能:这哥们的权限太高了。也客观上反应出:微盟的运维权限管控不足,没有做权限隔离,竟然被一锅端了;微盟运维的高危操作没有审批机制;微盟的数据备份机制也失效了;监测和恢复能力不足,36小时才找到原因,且没有恢复预案。