真实版“删库跑路”？程序员蓄意破坏线上生产环境！

作者 | 阿文

责编 | 伍杏玲

出品 | 程序人生（ID：coder_life）

作为程序员经常相互开玩笑说，公司要是把我逼急了，大不了我们“删库跑路”，这是一句玩笑话，没想到会有一天成为现实。

近日微盟官网发送一则故障通知，该通知称其公司业务系统数据库（包括主备）遭遇其公司运维人员的删除。据悉，目前犯罪嫌疑人已经被宝山区公安局进行刑事拘留，犯罪嫌疑人承认了犯罪的事实。犯罪嫌疑人乃微盟研发中心运维部核心运维人员贺某，贺某于2月23日晚18点56分通过个人VPN上网登入公司内网跳板机，因个人精神、生活等原因对微盟线上生产环境进行了恶意的破坏。

事件回顾

根据该公告对该故障进行回溯，如下：

• 2020年 2 月 23 日晚 18:56 分该企业运维部门核心员工贺某通过 VPN 登入内网，官方称是因为个人精神、生活等原因开始对生产环境进行恶意破坏。

• 2020 年 2 月 23 日 19:00 系统监控发出报警。

• 2020 年 2 月 25 日 7 时，恢复部分生产环境的数据，但是老用户预计还需要 2 月 28 日晚上才能恢复。

• 截至发稿，微盟微商城，智慧零售，微站业务正式恢复服务，新用户可直接注册使用。

为什么会发生删库

通过梳理我们可发现这次的删库事件是非常严重的。事实上，最近几年删除跑路的事情屡见不鲜，有误操作导致的也有恶意的情绪发泄导致的报复性删库：

2018 年 8 月，顺丰公司一员工接到一个变更需求，因为选错了实例，将一数据库删除。因工作不严谨导致该系统上临时车线上发车功能无法使用并持续约590分钟。事后该员工被开除。

• 2018年4月，VPS 服务商 Kuriko 因因机房技术人员 rm -rf /*，宿主机上所有数据丢失了。

• 2017年9月，某企业技术工程师帮助广西移动进行扩容割接（即增加系统容量）时，不小心将 HSS 设备里面的用户数据格式化删除，导致广西移动近 80 万用户数据丢失。

• 2017年6月，一家荷兰海牙的云主机商 verelox.com，一名前任管理员删光了该公司所有客户的数据，并且擦除了大多数服务器上面的内容。

对于恶意删库，我国《刑法》第二百八十六条规定：“对计算机信息系统功能进行删除、修改、增加、干扰，造成计算机信息系统不能正常运行，后果严重的，处五年以下有期徒刑或者拘役；后果特别严重的，处五年以上有期徒刑。”

2018 年北京一软件工程师徐某离职后因公司未能如期结清工资，便利用其在所设计的网站中安插的后门文件将网站源代码全部删除。最终徐某因破坏计算机信息系统罪成立，获刑五年。

2018 年杭州科技公司的技术总监邱某因不满企业裁员，该员工从 2014 年入职到 2018 年，公司的主要系统都由他搭建，包括公司的 SaaS 系统、API 系统、电子合同的签署等服务，2018 年初公司大概有 4 万多用户。2018 年 4 月，老板找到邱某，让他尽快离职，后面他也提交了辞职报告，但是心里一直都很不爽。遂心生报复，远程登录服务器删除了数据库上的一些关键索引和部分表格，造成该企业直接经济损失 225 万元，后被判赔偿公司 8 万元，判刑 2 年 6 个月，缓刑三年。

如何防止删库事件发生

类似这种故障，不同于一般的黑客入侵或误操作，而是因为内部发起的恶意破坏，这种其实是最难防范的，大多数中小企业都无法避免这种问题发生，首先是由于企业规模问题，不可能招聘一个专门的 DBA 来进行运维，很多时候都是一个开发兼顾写代码加运维。其次，中小企业要想对一个系统的权限划分的特别细致是不现实的。但是即便如此，我们也要通过一些方案来预防这类事件的发生，那么如何做呢？

1、权限分级，可以根据权限和角色进行划分：

权限划分，适合中小企业，因为中小企业不会单独划分系统运维、业务运维、DBA 这种角色，比如要执行一个删除操作，由发起人发起删除请求，将需要操作的事项详细列出，交由相关负责人进行审批，负责人审批确认命令是否合理，审批通过后在交给专门的执行者去执行操作。

这样可以追根溯源，有备可查，否则一旦出现问题都不知道是谁干的，二来可以防止人为破坏，除非真正的实施者去进行破坏。对于实施者这一层，可以对操作系统和数据库进行权限划分，针对不同的业务系统，对于操作系统本身和数据库进行合理的权限划分，针对不同人设置不同的登录账户，对不同的数据库、表划分不同的操作权限，避免因为误操作导致的删库问题发生。

角色划分，适合有一定规模的企业，对于运维人员分为业务运维、网络运维、DBA 等，每个角色负责自己操作权限，不能越权，比如业务运维只能针对业务的相关进程和服务进行修改操作、系统运维只能对操作系统的权限进行调整，但是不能操作数据库、而 DBA 只能操作数据库，但是不能修改其他服务的配置文件和相关进程数据等等，更不能执行类似rm之类的高位命令。

2、流程规范化

除了角色划分和权限控制，对于运维人员的工作流程要进行规范化，并培养安全意识，禁止一切非流程化的变更。对于生产环境的变更，例如执行什么命令，都要进行审批，最好是在演练环境先测试无误后再进行变更，防止意外事故发生。

此外对于删除、更新这种高危操作一定要进行严格的审核，确认无误后方可操作。在《阿里巴巴JAVA开发手册》中，对于 Mysql 的变更要先执行 select，避免直接执行 delete，防止误删除。

3、定期演练

随着企业规模以及人员变动等因素，要定期按照流程和规范对系统进行故障演练，比如断电恢复、数据删除恢复等场景进行演练，这样一来可以加强对应开发和运维人员对于流程和规范的认识，二来平时参与到这种模拟环境中，可以在真正的故障面前不会手忙脚乱。

4、定期备份

对于备份的重要性，我想不需要多说，对于重要的业务系统中的每一个服务都不能存在单点，要时刻保数据的备份，以 MySQL 为例：

• 选择合适的引擎，比如 MySQL 要支持事务操作，那必然要选择 InnoDB，而不能选择MyISAM。

• 常规备份，要定期对数据库进行备份，除了本地要有备份，还要进行远程备份，或者多机备份。可以通过脚本配合计划任务进行定时备份。

• 主从备份，除采用主从备份可以实时性的对数据进行同步，并保证高可用性。切记不可将主从部署在同一台机器上。

• 异地多活，有条件的还可以采用异地多活，即防止某个区域出现意外导致断电或硬件损坏等导致数据丢失。

但是，从我的从业经历看，很多公司对于数据的备份是重视不够的，我总结起来就是两点：

一个是出于成本考虑，不舍得实行主从备份，这个无可厚非，但是就算不舍得投入成本，本地备份好歹做一个，防范于未然也是好的。

第二个是，安全意识不够，过于的相信云厂商的技术，觉得上云后备份这种事情就交给云厂商去做了，我遇到一些企业竟然直接把数据存储在系统盘，后来遭遇黑客入侵，系统盘被他玩坏了，数据都找不回来了。也没有充分利用云厂商提供的快照和镜像等功能进行数据备份，本地也没有备份。

现在各家云服务商都会提到其平台拥有几个 9 的数据可靠性，并且有快照、异地容灾，多副本存储等容灾策略，但是我们要知道并没有绝对安全的云服务商，即使备灾策略看似完善，但依然很难避免因人为操作不规范而导致的故障。

2018 年，“前沿数控技术”发文称，在使用腾讯云8个月后，在云服务器上的数据全部丢失，腾讯云三备份数据也全部离奇丢失，平台业务全部停运，损失巨大。事后发现该企业竟然直接把数据存储在系统盘，没有做好备份，此外就是过于相信云厂商的三副本安全机制而引发的悲剧。

5、加强人文关怀

虽然我不清楚这个员工为什么会做出这事情，微盟说员工个人精神和生活等原因导致的，这里我也不敢妄加揣测，一切都以法院最终的审判为准。但建议企业加强人文关怀，要对自己的员工好点，尤其是核心员工，比如提供有竞争力的薪资和福利、裁员时给予规定的补偿、关注下员工的精神和生活等方面的问题。

对于员工而言，如果说在工作中遇到了一些不公平的遭遇，比如欠薪、恶意刁难，或者持续的无偿加班尽量选择通过正规的法律途径来解决或者换个工作环境，而不要选择走极端的违法行为。一旦被判刑这将是终身的污点，对于未来的生活和工作都造成不可逆的影响。

“删库跑路”常常是程序员说的段子，但如果这个段子成为了事实，不论是对于企业还是员工都需要付出沉重的代价。希望大家引以为戒。

#欢迎扫码留言#

对于本次事件，你有哪些看法呢？

在中国企业与「远程办公」正面相遇满月之际，2月29日CSDN联合广大「远程办公」工具服务企业共同举办【抗击疫情，科技公司在行动】系列之【远程办公】专题线上峰会活动：中国「远程办公」大考。

扫描下方二维码或点击阅读原文即可免费报名直播+抽取奖品+与大牛交流

如想提前了解峰会详情，可加小助手微信csdnai，回复远程办公进直播群观看

热 文 推 荐

你点的每个“在看”，我都认真当成了喜欢

猛戳“阅读原文”，即可参加上述活动