从微盟删库,谈谈身边'删库跑路'的大神
今天互联网圈子最火的一件事就是‘微盟被恶意删库’...
微盟公告
当然，该类事件在圈子内屡见不鲜，只是36小时恢复期比较长了...
运维人员恶意删除核心数据这种操作确实是有可能发生，但是在正常情况下又不应该发生。当然由于管理的不规范、权限的控制等问题依然可能造成某些人员恶意或非恶意的制造出‘删库跑路’事件。
下面盘点一下在我身边发生过的‘删库跑路’事件：
核心研发 应用服务器 4小时恢复
工作以来第一次接触的‘删库跑路’事件，当时公司的权限设置还是比较好的。除了部门leader其他任何人无生产环境的直接操作权限。日志只能通过一个日志服务来进行查看。所以正常情况下开发人员是无法接触到生产服务器的。
某一天生产环境出现异常，但是在测试环境还真的没有复现，加班到深夜跟leader讨论是不是可以进入生产服务器去看一下？然后leader就给开启了权限并且在旁边盯着。
排查了半个小时没有什么进度，leader就转身去弄自己的东西了。
研发又研究了大概十几分钟，突然跟leader说:
‘X哥，你看这是咋啦？’
leader回头看了一眼发现一切都已经空了...一脸黑线的问：你干啥了!!!
回答: rm -rf /* 可能也是群里的大佬教的
当天晚上两个人都没回家，当时还没有客户使用，并且还是晚上。所以影响不大，四个小时恢复。
核心研发 删除数据库 3小时恢复
后来又发生一次删库事件，确实是删库，不存在争议！ 研发收到leader的通知要删库某个数据库，相关数据已经迁移至其他平台存储。所以数据库要进行物理删除。 删除的数据库名称为 X_DATA，但是该研发其实本身没有该库的权限。他的权限列表里可见的只有XX_DATA。 收到命令后一直很纠结，很奇怪为啥要删了。但是还是忠实的执行了命令删除XX_DATA库。
业务模块直接瘫痪...
不过很厉害的是,由于该研发不知道为啥要删除这个数据库。觉得可能有需要就把数据进行了本地备份他的硬盘是够大的
马上从本地恢复数据，由于网络原因，三小时回复。
运维人员 禁用云密钥 4小时恢复
事情仅发生在几天前。周末，在家悠哉悠哉的看电视，玩游戏。
突然收到服务器告警，负载飚高。赶紧进入服务器进行查看。这点小权限还是有的
发现有个服务的资源占用非常高，而这个服务是往阿里云数据通道写入数据的。排查日志发现数据一直写入失败重试，当时已经重试了几千次，四个小时没有数据写入成功。 之前由于其他原因直接把重试次数修改为了无限次，并且已经稳定运行了半年多，没有任何的修改与操作，所以当出现问题时马上进入阿里云。没看到有变更的公告，去企业相关群询问了一下。 阿里云的人还没有回复，运维私聊我了:访问密钥(AK/SK)我禁用了，核心就这么一句话。 我当时就疯了，当时就想过去抽他。但是还是先恢复业务再说。
别说为啥禁用，先给我开启了再说。 几分钟后，取消禁用，数据正常写入！由于使用了MQ，所以数据无丢失。影响较小。无实时计算内容，指标无异常。 排查其他使用该访问密钥的服务均受到不同程度影响!
more...
整体上来说，无论是在什么样的企业都会存在恶意或非恶意的删库事件。都是由于我们对于权限的控制与规则的控制没有做好。 之前经历过较为严格的生产环境控制，研发人员对于生产环境无权操作。日志只能通过采集到日志系统中进行展现。修改数据？提交SQL，审核，执行。工作到最后，我好像都不知道生产环境有没有公网，因为一切都是内网host..
大数据环境下还经历过提交了Job之后,等Job执行完成后你才能拿到一份压缩好的日志。而执行时的数据都是通过文档进行解释，无法看到原始存储。甚至存储位置..每天执行一次，执行完成去ftp上下载执行日志。痛苦！
其实在生产环境切换到root还是很担心的，问一下自己:
- 你有root权限你怕吗？
- 你的SQL条件准确吗?
- 你的敏感命令可以执行吗？
- rm -rf /* 了解一下... 看到了？不错，说的就是你...!