据中国基金报，近日，记者自北京裁判文书网上获悉，百度某“95后”校招员工金某某在任职期间，私自建立隧道进入数据库“删表”。最终因犯破坏计算机信息系统罪…

早上爆出一条数据安全的大新闻，微盟被删库了.......大家先来看看新闻：

很震惊！很震撼！吓得我赶紧召集全公司服务端小伙伴Review了我们所有的安全部署！！！

彻底检查完之后，我放心了，我们即便被删库也可以快速恢复！

解决完隐忧之后，作为一个在业内安全大厂360工作五年的伪安全人士，今天跟广大做技术的小伙伴聊聊数据库安全那点事：

公告透露出两个重大信息！我们来看看：

第一，恢复时间长，公告是这么说的：「和您一样，我们度过了漫长的36小时，我们预计此次故障还会持续一段」。

那么为什么需要这么久的时间来恢复？

以我的经验推测，一定是生产环境的主备数据库都被删库了！并且大概率应该是做了rm -rf类型的极端操作。不用怀疑就是传说中的删库跑路！当然影响是产生了，人肯定跑不了！

大家可能要问了，那数据库恢复下不就好了吗？没这么简单！

第二，更重要的信息！大家看看这句：「犯罪嫌疑人乃微盟研发中心运维部核心工作人员贺某」。原来是内部人员！

那为什么一个普通运维人员有如此大能量？

很简单，不少互联网的运维人员基本都会有root权限。基本就是公司业务上帝级别的存在。

说实话，我做管理这么多年，对运维岗位工作人员一直是格外尊敬彬彬有礼。当然如果是大厂可以在安全方面做的更完善，数据库操作权限分层分级，就很难出现这种情况。

现实是很多中小公司，运维就那么几个人，甚至一个人。对这样的公司来说，责备团队没做好权限管理就是正确的废话。

（公众号回复 666，带你入圈）

除了微盟这次安全事故，关于删库跑路，一直是互联网的黑传说。

IT界有一个老梗，某论坛的数据库管理员抱怨自己老板一直虐待他，结果他一气之下就删库跑路了……

再假设一种情况，如果在服务器维护的时候不小心执行了 rm -rf 命令……现在整台服务器被删光了肿么办？？？

对于中小公司来说，想把权限做完善做复杂，基本没有可能！想依赖运维人员本身素质和心理状态，那就是靠天吃饭！

中小公司防删库真正的答案是：做好备份！做好最小程度权限管理！

先来看看一个标准的数据库架构图：

从上图中大家可以分析一下关键点：

主库：对应线上实时的业务，如果出现故障，整个系统和网站的访问将受到影响。从库：一般用于查询和主从切换。

备份数据：备份方式常用全量备份和增量备份的方式。备份的策略包括跨机器、跨机房、跨区备份。数据是企业第一生产力，数据备份尤其重要。

数据备份问题也有2个层次。最低层次的，有些公司压根就没有做备份，那出问题一定很麻烦，只能从磁盘做恢复，这个过程非常漫长！

不做数据备份的公司，长点心吧！特别是CTO或者技术负责人，淘汰的就是您这种呐！

高点层次的，有备份但只有全量备份没有增量备份。全量备份当然不能天天做，每个公司有自己的策略，可能是一个月一次也可能是一周一次。如果是这种情况，那这中间的一个月或者一周的增量数据还得从磁盘做恢复，一样很慢！

微盟虽然不是大厂，也算有一定规模了，备份肯定是做了。根据公告的信息，恢复需要这么久，我推断要么是全量是很久前做的，增量数据丢失了，要么是删除者做了极端操作都给干掉了！

2.做好最小程度权限管理

BAT级别的权限管理，咱就不谈了，其实咱也不懂。懂了也没资源做。我谈谈中小厂怎么做好最小程度权限管理。

数据库操作权限和备份权限分离

DBA负责日常主从库的管理和维护。运维负责备份数据的保存。采用全量和增量备份的方式。

如果DBA抽风删除主库，主从同步，则重库数据被删除。业务系统受到影响，运维能马上收到业务报警，运维同事接管数据库，进行备份恢复。

权限申请、权限审批和操作执行分离

控制DBA人员的操作权限，开发人员做数据库表的删除或修改操作的申请。技术主管或负责人审批，生成审批密码。DBA根据密码登录特定服务器，进行相关的操作。

关掉DBA操作数据库终端权限，通过Yearning等审计平台执行数据库命令，高风险命令直接拒绝执行，并发出报警。技术总监或CTO确认没问题之后，才能执行。

以上三点，用最小资源去做，完全可行。如果还做不到，那就采用云解决方案，基本上用好云的方案，问题不大。

技术管理这件事，不能完全依赖人。看公告怎么说的：「因个人工作、生活等原因」。具体什么原因咱也不知道，反正人是不可控的！

技术管理要有抓手！合理结合公司资源做一些限制是很有必要的！

虽然没经历过删库跑路的情况，但是身边的程序员update语句不加where条件的情况发生过2次。

第一次，所在的公司是自建机房，由DBA团队管理数据库集群。某程序员把所有账户的积分字段改了，当时直接吓尿了。

当即停止账户操作的所有业务，DBA全量回复0点的数据，再找到Binlog的update语句的执行点，重放Binlog。检查数据恢复正常，重启开始账户相关的业务。耗时五个小时。

这五小时在老板的狂风暴雨中，你知道我是怎么度过的吗？太艰难了！

第二次，所在的公司使用云服务，数据库使用RDS。某程序员把跟进记录表的用户留言字段全部更改了，导致主从延时报警，销售人员没办法看用户留言的真实数据。

事情发生后，停止该表的业务，DBA通过云服务的工具直接恢复到发生问题前1秒的数据，从发现问题到解决问题也就是5分钟。

以上两个案例与删库跑路类似，都是数据丢失或数据污染之后的解决办法。但是处理起来，耗时不同。关键点在备份上！

给个建议！自建机房的方式需要有完备的dba和运维团队，对技术要求高，中小厂商没能力自建机房的，云方案还是要用起来。另外要关注云提供厂商提供的全套解决方案，千万别只把云方案当服务器使用。

微盟这次事故，我估计就没有采用云数据库，而是把云方案当服务器在用。云方案真正的价值在于容灾、快速扩容、紧急救火。这些能力中小公司要建立起来，不是说不可能而是难度极大。业务高速跑起来，压根没时间没资源去弄！

如果微盟用的是云数据库，云数据库一般都会保留binlog日志，先全量恢复再重放增量。这个恢复速度非常快，不会需要36小时还没弄完，产生这么大损失！

当然微盟也是受害者，说实话中国互联网发展太快，往往即便很努力也没法在很多方面考虑周全。好的是，有了云方案让一些中小公司的确会更高速的发展。看看公告：云厂商也在积极的帮助微盟做数据恢复！

技术人一定是保护用户数据的最后防线。最近几年，由于技术人员无意或者有意造成的事故不计其数。如果代码对世界的影响不大，那么这也许就不成问题。

打个比方，如果你写了一个危害几个人的代码，影响是极为有限的。但是如果你在拥有几亿用户的平台上做同样的事情，结果一定是惨烈的！

技术人一定要遵守职业道德底线，同时关注IT安全，尤其是技术管理者。希望我们一起让技术世界更安全更精彩！