从删库到跑路，论运维的自我修养

不小心删库了怎么办

跑路？

近日，据微博网友@大佬坊间八卦爆料，顺丰的一个工程师手误把线上系统一个库删除了，然后跑路了。

　　从爆料截图获悉，该工作人员是顺丰公司的IT运维开发高级工程师，因手误删了生产数据库，导致某项服务无法使用并持续 590 分钟，对公司业务造成了严重的负面影响。顺丰在公司内网对其进行了通报，并已辞退。

　　现在这事已经在圈内炸开了锅，看热闹不嫌事大也纷纷调侃到：

“不删几次库都不算运维了”

“没删过库的工程师就都不是好程序猿”

“《MySql入门：从删库到跑路》”

▲表情包已就位

　　说白了，这是一起因运维操作失误而引发的数据库安全事件。盘点近两年发生的数据库安全事件，类似删库的也不是一两起了，仅2017年就曾发过Gitlab数据库误删、云主机商verelox.com管理员删库，当然也少不了炉石传说数据库损坏回档、Instapaper服务中断等，前不久华住酒店数据泄露也与数据库管理漏洞有着莫大的关系。

　　其实呢，就删库这一类服务器安全事件而言，也没有什么了不起（删了就跑贼刺激），谁还没个倒霉的时候。但一次次删库事件的发生，我们得从中吸取教训，这样才能亡羊补牢，以绝后患，你说对吧。

　　总结此前发生的多起惨绝人寰的删库事件，有以下三大原因：

软硬件故障。这个好理解，硬件故障如单个节点挂掉，软件故障如系统bug，出现这种情况服务器就容易挂掉。当然，大家都熟知的黑客攻击就不说了。

自然因素。自然灾害，如意外断电而引发的炉石传说数据库损坏就是此类事故了。

人为因素。人为因素多半是运维失误，常见的有错误操作或恶意删除，这两者是引发删库等服务器安全事件最为常见的原因。典型例子就数2015年携程瘫痪事件了。

　　那对于企业来说，该采取何种措施来避免此类事件的发生呢？

　　从管理的角度来讲，做好数据库的安全配置是可以解决数据库安全问题，这一方面需要加固数据库安全配置，避免其遭受黑客攻击、自然危害；另外一方面，做好人为因素（如运维人员无意、有意删库）的安全管理，这才是解决问题的重点所在。毕竟，80%的安全威胁来自企业内部，包括企业内部人员恶意操作、无意违规行为等等，这些行为是导致数据损坏和数据库系统破坏的常见原因。

　　考虑到现有数据库及运维操作所面临的的安全威胁难题，引入数据库及运维审计系统就显得十分有必要了。基于事中检测预警和事后追踪溯源的设计理念，运维审计系统的引入可以确定每个用户的操作权限，当用户进行关键操作时，系统会根据预先设置进行相应的告警并对违规操作进行阻断，从而避免用户误操作、越权操作以及恶意操作等情况危及到数据库安全。

　　在此情况下，基于这一理念而设计的任子行云运维安全审计系统就应运而生了。该系统在原有运维审计系统的基础上，针对云平台的运维审计、内控管理而设计，通过引入银行内控管理机制、运维全程审计的功能特点，可有效解决政企私有云/公有云、运营商云化改造等云运维安全难题。

云运维安全审计功能

权限粒度细分

　　云运维安全审计系统可以对运维人员进行细粒度的权限控制，系统集认证、单点登陆授权于一体，可根据人员、时间、系统账户、操作指令等内容设定访问权限，实时拦截敏感操作，指令复核确认：

● 限制用户能够访问的服务器范围；

● 限制用户能够登录的时间；

● 设定用户操作指令黑、白名单，阻止违规操作行为；

操作行为记录

　　云运维安全审计系统对所有经过审计系统的操作行为，如操作时间、IP地址、用户账号、服务器账号、操作指令、操作结果等信息实行操作过程全程记录。对于所有的操作记录，云运维安全审计系统可以长时间进行保留，为日后安全审计提供客观依据。

异常行为告警

　　云运维安全审计系统内置安全事件规则库，并可实时对用户的操作过程进行检测，一旦发现违规操作行为，可实时发送告警信息或自动中止操作会话。系统与云平台无缝集成，全面支持虚拟机镜像、虚拟机实例安全管理，支持云平台虚拟机生命周期管理。

　　在部署云运维安全审计系统后，该系统所具有的集账号管理、权限管理、认证管理、指令复核和操作审计于一体的功能设计，可为政企单位提供统一的安全保护框架，整合企业服务器、网络设备、主机系统，确保合法用户安全、方便使用特定资源。在保障合法用户权益的同时，可有效地保障支撑系统安全可靠地运行，确保业务数据信息安全。

▼

　　可以说，在该系统投入使用后，企业所担心的删库、内控权限以及运维安全等服务器运维管理问题将得以解决。拒绝重蹈顺丰删库覆辙，运维操作实时告警，历史记录回放，做中国好运维，从安全可溯源的云运维安全审计做起。

　　最后，还是得提醒下，在做好自家运维防护工作同时，照顾好自家的运维管理人员，减少人肉运维，让低级错误不再重现，这才是正确的运维之道。

↓↓↓ 点击"阅读原文" 【查看更多信息】