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

2023-02-27

权限 saas 备份

2月23日19:00左右，来自微盟官网的消息，微盟的业务系统数据库(包括主备)遭遇其公司运维人员的删除。目前微盟技术团队正在努力恢复数据，但数据恢复较慢。目前对新用户服务已经恢复正常，但老用户数据官方预计要到2月28日才有结果。微盟官网截图据悉，目前犯罪嫌疑人已经被宝山区公安局进行刑事拘留，犯罪嫌疑

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 /"这样的操作。