如何避免离职员工从删库到跑路的尴尬

2018-05-14 18:39 1778 0
2017年6月8日,荷兰的云端代管服务供应商Verelox传出遭到离职员工恶搞,删除了所有的客户资料与多数服务器上的数据。

Verelox专门提供KWM虚拟机器与VPS虚拟专属主机的代管服务,于荷兰、法国、加拿大及美国皆设有数据中心,在此次事故发生后,Verelox在官网上公布了该事件,临时冻结了所有的客户账号,并全力为客户恢复数据,继之旋即于官网上祭出声明,但是,无论如何已经不可能恢复全部数据。

根据Verelox的声明,一名已离职的系统管理员删除了所有客户资料并清除绝大多数的服务器,使得该公司不得不暂时将服务下线,网络与代管服务将在执行安全更新之后于当周复原,将针对仍愿意使用该公司服务的客户提出补偿方案。

删除云主机上的客户数据相当于暴力破坏公司核心资产,是一种犯罪行为,该工程师一定会受到法律的制裁,但是巨大的损失已经造成,无法挽回。

从删库到跑路

从删库到跑路

比离职员工删库跑路更频繁发生的是各种意外删除数据的事件

2017年1月31日23:00 左右,Gitlab一名系统管理员在极度疲劳的情况下,尝试删除一个空的目录,结果指令发往了另外一台服务器的命令窗口,等他回过神来的时候,27分钟过去, 终止删除操作为时已晚,大约 300 GB 左右的数据只剩下约4.5 GB。 GitLab.com丢失了 6 小时的数据库数据。

2017年4月5日,知名的 VPS 服务商 DigitalOcean 出现了一次删除生产数据库的事故。删库导致 DigitalOcean 的控制面板和 API 无法正常使用,时间长达 4 小时 56 分。此次事故的根本原因是工程师驱动的配置错误。有个用于自动化测试的程序,错误使用了生产证书。

无论是主观还是无意,数据库被删除,都是互联网公司难以承受之重,Fintech公司尤其无法接受跟钱相关的数据丢失,技术团队必须要防患于未然。

首先要防止的是,数据库被开发人员误删。

开发人员是否需要连接生产数据?有人说需要,有人说不需要。不同的情况下有不同的道理。这里我们分开来讨论。如果开发人员不需要直接连接数据库,是最好不过的了,就杜绝了数据被开发人员删除的危险,也没有数据被泄露的风险,也不会因为敲出了一个select * from xxx造成负载异常升高。

如果开发人员需要连接呢?通常需要做到以下两点:
1、如果开发人员需要能连接生产数据库,需要给到只读账号,且需要一个人一个账号
2、如果生产库有从库/备库,最好能让开发人员连接从库/备库。

其次,需要防止数据被管理员删除。
事实上,Verelox的数据就是被不开心的系统管理员恶意删除的。管理员不能使用root账号直接在操作系统层面操作数据文件,尽量使用客户端从远端连接到数据库进行维护。由于意外失误,像Gitlab管理员一样,在昏昏欲睡的时候,rm -rf清掉整个硬盘的事故也太多了,需要使用堡垒机等工具配合屏蔽这类高危命令。最后,尽量减少使用图形工具,因为太多的图形工具,会隐含的具有某些功能,如autocommit,设置字符集等。

第三,如何防止数据被程序删除呢?
通常,架构设计上需要注意,重要数据永远不要直接删除,标记为“删除”状态。不能给程序的用户all privilegesInsertdeleteupdate各类命令的权限单独赋予。

第四,防黑客。
应用的网络进行分层设计。接入层,应用层,数据层。数据层只对固定的应用服务器开放。数据库永远只放在内网,监听在内网IP上。

第五,周密的备份
即使管理员跑路也不怕。数据的物理备份和逻辑备份相互补充,文件不小心被删除的,用物理备份恢复;表被drop掉的,用逻辑备份恢复。备份也经常需要演练。因为一方面要保证我们的备份可用;另外一个方面我们也需要对多久可以恢复负责。对CTO及运维负责人而言,备份情况也需要每天检查。

当然了,为避免从删库到跑路事件的发生,最好的办法还是好好照顾自家运维人员,开心工作开心生活,有问题及时沟通解决,做好数据库安全管理,权限管控、审计、备份容灾。不要做出通过删库报复公司报复社会的行为。

运维不易,请多多关爱。


您需要登录后才可以回帖 登录 | 立即注册