|
|
51CTO旗下网站
|
|
移动端

突发!又一起恶意删库事件,涉事员工已被拘留

2 月 23 日 19:00 左右,来自微盟官网的消息,微盟的业务系统数据库(包括主备)遭遇其公司运维人员的删除。

作者:叶金荣来源:51CTO|2020-02-26 08:00

2 月 23 日 19:00 左右,来自微盟官网的消息,微盟的业务系统数据库(包括主备)遭遇其公司运维人员的删除。

目前微盟技术团队正在努力恢复数据,但数据恢复较慢。目前对新用户服务已经恢复正常,但老用户数据官方预计要到 2 月 28 日才有结果。

微盟官网截图

据悉,目前犯罪嫌疑人已经被宝山区公安局进行刑事拘留,犯罪嫌疑人承认了犯罪的事实。

犯罪嫌疑人乃微盟研发中心运维部核心运维人员贺某,贺某于 2 月 23 日晚 18 点 56 分通过个人 VPN 登入公司内网跳板机,因个人精神、生活等原因对微盟线上生产环境进行了恶意的破坏。

腾讯云官方称,微盟运维事故发生后,腾讯云技术团队已第一时间与微盟对齐,研究制定修复方案。工程师们正在日夜赶工,将尽最大努力协助微盟降低损失。

微盟集团成立于 2013 年,是一家主要通过 SaaS 产品和精准营销为商户提供云端商业和营销解决方案的提供商。

截止 2019 年 6 月 30 日,微盟的 SaaS 产品及精准营销服务拥有 300 万注册商户,SaaS 产品的付费商户有 70006 名。

根据财报显示,2019 年上半年微盟收入 6.57亿元(人民币),毛利 3.65 亿元,其中 SaaS 业务收入 2.19 亿元,毛利 1.77 亿元。

可以看出,其两大核心业务之一的 SaaS 业务(另一核心业务为精准营销服务)对微盟业绩具有举足轻重的影响。

微盟认为,此次 SaaS 生产环境和数据破坏对整体财务状况的影响视修复程度和速度而定,预计将对 SaaS 业务营运带来一定的负面影响。

针对这起删库事件,网友们都炸了:

删库跑路事件屡发,在这里特别提醒各个公司,注意做好两项工作:

  • 更严密的权限管理:大部分公司对运维的权限都放得比较宽,容易造成事故。
  • 更可靠的备份机制:主备都是可以被删的,一旦需要从磁盘恢复,恢复时间会很慢。

作为技术人员,千万不要因为一时脑热,做出错误的决定,让自己身陷囹圄。

最后,我们跟一位老 DBA,一起来回顾和深入反思下这个事件。

事件回顾

时间回顾如下:

  • 2020.2.23 日 18:56,员工通过 VPN 登入服务器并实施破坏。
  • 2020.2.23 日 19 时,系统监控报告故障并启动应急方案。
  • 2020.2.24 日,微盟公司向警方报案。
  • 2020.2.25 日 7 时,恢复部分生产环境和数据,并预计到凌晨 0 点能完成恢复,并向新用户恢复业务,但老用户预计还要到 2 月 28 日晚上才能恢复。

为什么会发生"删库"

从官方发布的公告来看,是因为运维部的核心员工刻意进行的破坏,也就是说,这是人为的、恶意的、有计划的破坏行为,而不是我们最常见的误操作或黑客入侵所致。

不过,从我的经验来看,这起事件未必是真的人为破坏,具体分析就不贴了。总之,我对官方的公告存疑。不过也不能改变人为破坏这个事实,就看公安机关怎么定性了。

我们要做的是,进行反思和预防此类事件一再发生,这也是本文的用意。

此外这种意外事故受害的除了公司、员工,更无辜的是客户,我们祝福微盟能救回更多数据,将损失最小化。

事故恢复的速度如何

从上面的回顾时间点来看,我认为恢复的速度并不算快。

我经过侧面了解,这起事件主要的影响是数据库的主备库都被删了,并且执行的是类似"rm -fr /"这样的操作。这种行为,基本上只能通过其他备库,或物理备份来恢复了。

从事后恢复情况来看,应该是没有更多可用的备库了,但备份数据应该是还有的,所以才需要花费这么长时间。

此外,备份数据恢复完后,通常还需要有一个校验核对的过程,所以一般会先发公告安抚客户的情绪。

不过新旧用户恢复服务的时间并不同,我们由此甚至可以猜测,备份机制可能不合理,新数据的备份更及时,旧数据的备份有延误,或者比如因为旧数据的量太大了导致延迟更久。

这次更糟糕的是,赶上特殊情况,大家都在家远程办公,协同起来肯定更慢,也影响了恢复速度,真是祸不单行。

幸运的是,听说腾讯云已有多位技术专家参与了拯救工作,希望能尽快恢复。

事件反思和预防

这次的事件,不同于常见的黑客入侵或误操作,而是源于内部发起的破坏,这种是最可怕、最难防范的行为。

我相信绝对超过 80% 甚至 90% 的中小型公司,都无法避免这个问题。毕竟中小型公司的人员规模有限,想要进行非常细致的权限分级也不太现实,更容易因此降低工作效率和员工的积极性。

尽管如此,我们也尝试做点什么来预防此类事件再次发生。

首先,是权限分级

我们知道,为了提高工作效率,会部署自动化运维工具。但这样一来,也极大增加了误操作带来的风险。

本次事件中,短时间内造成大面积服务器故障,基本可以断定是因为工具批量分发命令导致的。

所以,一定要进行权限分级,也包括业务范围分级。例如可以尝试以下方案:

①角色分级

区分业务运维、系统运维、网络运维、DBA 等多重角色,每个角色都只能接触自己所负责的那票业务服务器,以及相应可执行的权限。

例如,业务运维、网络运维、DBA 等都不能执行系统层的 rm 指令,系统运维也不能执行数据库的指令。

②权限分级

区分一级执行权限、二级执行权限及审批权限。

例如,我们可以实施这样一套方案,一级权限的人发起某个操作请求,有审批权限的审核校验这个命令是否合理,再由二级权限的人去真正实施。

这样基本可以防范人为破坏了,除非最后落地时是由同一个人来承担所有角色,或者嫌麻烦绕过这个规范。

分级措施想做到位,就得有足够的人员,公司上市的目的就是通过融资以改善运营状况,该招人就招人吧。

其次,备份、备份、备份

备份的重要性无需多言。但其实,不只是做了备份就可以的,还有如下几点要注意:

  • 除了本地备份,还应该有异地备份,并且要区分本地备份和异地备份责任人的权限,交由不同等级的人管理,防止恶意破坏时,把全套备份都一把火烧了。
  • 除了逻辑备份外,还应该有物理备份,物理备份恢复起来会更快一些。
  • 除了备份,还应该做好备份校验,确保备份的有效性,也就是随机抽取备份集进行恢复测试,确保备份文件的可用性(我多年运维从业经历,仅有一次比较严重的故障,就是栽在没及时进行备份恢复测试校验)。

最后,做好防灾演练

防灾演练的确比较难做,毕竟没几个人敢真的在线上全盘执行"rm -fr /"这样的操作。

不过依然可以模拟各种可能的情况,以及不同情况的组合,再针对这些情况制定不同的预案,然后在开发、测试环境尝试进行演练。

而且要不定期的进行演练,让各个岗位的责任人熟悉整套流程。就像在日本,中小学总是不定期进行防灾演练一样,演练次数多了,真遇到问题时,自然就不慌了,恢复起来也会更快。

最后的最后,多给员工一些必要的关怀和培训吧。还有,作为管理者,对负责后端的运维部门也多给些重视,运维部门一旦出个事故,是真的有可能会搞垮一家上市公司的,这并不是没有前车之鉴。

【编辑推荐】

  1. PyTorch终于能用上谷歌云TPU,推理性能提升4倍,该如何薅羊毛?
  2. 删库跑路”这件事情真的发生了 ,还是技术总监干的!
  3. 又一起删库跑路事件 —— 微盟系统遭遇运维破坏
  4. 从微盟“删库”事件来谈谈企业的信息安全伪壁垒
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢
24H热文
一周话题
本月获赞

订阅专栏+更多

Docker一键部署,3小时学以致用

Docker一键部署,3小时学以致用

Docker学以致用
共3章 | jextop

100人订阅学习

高并发互联网消费金融领域架构设计

高并发互联网消费金融领域架构设计

应对高并发架构
共5章 | jayslife

91人订阅学习

Kubernetes:21天完美通关

Kubernetes:21天完美通关

从小白到修神
共29章 | 断水流大师兄

920人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微