9 月 19 日，微博网友“大佬坊间八卦”爆料，顺丰科技数据中心的一位高级工程师邓某因误删生产数据库，导致某项服务无法使用并持续 590 分钟。

随后，顺丰根据公司相关规定，辞退工程师邓某，并在顺丰内网通报。

错选 RUSS 数据库

据内部通报，邓某错选了 RUSS 数据库，打算删除执行的 SQL。

在选定删除时，因其操作不严谨，光标回跳到 RUSS 库的实例，在未看清所选内容的情况下，便通过 delete 执行删除，同时邓某忽略了弹窗提醒，直接回车，导致 RUSS 生产数据库被删掉。

因运维工作人员不严谨的操作，导致OMCS运营监控系统瞬间崩溃，该系统上临时车线上发车功能无法使用并持续约10个小时。

同比9月5日的929条临时车需求临时变更，此次删库对生产业务产生了严重的负面影响。

运维工程师发现误删数据库之后，估计心里想着完蛋了，36计走为上计，直接跑路要紧~

原因分析

对于这次事件，来自数据安全公司安华金和的研究人员进行了如下原因追溯：

1、不要指望运维人永远不犯错

运维工作属于高压工种，被网友调侃是拿着如同白菜价的工资却操着卖白粉的心，心理压力大不说，为了应对外部攻击和后端非工作时间运维事件，通宵达旦加班更是家常便饭。

面对身心双重消耗，工作中稍有不慎犯个错误也是情理之中的事情。如果单靠约束运维人员不犯错误，只能说是主管领导和企业的双重天真。因此，就必须要通过规范的制度流程和有效的技术手段来防患未然。

2、流程先行，技术手段托底

从上述爆料的内部邮件中可以看出，郑某在接到变更需求后，“按照操作流程要求”，登陆生产数据库跳转机，却在后续操作中违反了操作流程，导致删库事件发生，带来严重影响。

外行看热闹，内行看门道。追根溯源，删库事件之所以发生，正是因为操作流程的建立并没有技术手段来托底，此次事件正暴露出权限管理、审批机制的双重缺失。因此，单有流程，却没有有效的技术手段作为“防守底线”，流程就变成了一纸空文，仅供事后追责而已。

要避免删库带来的严重影响，简单粗暴的说，生产数据库操作前，除了备份，必须人工交叉审核。

解决思路

避免此类删库跑事件，安全专家给出了两个解决思路：

一是完善的权限管理，让运维人员删不了库；

二是有效的审批机制，就算非要删库，也必须先向上级申请审批。

为此，安全专家在研发中心环境下模拟了此次现场，使用本事件内部通报中提到的navicat-mysql 进行操作，然后配合上数据库安全运维产品DBCtrl的界面，为大家提供两个解决思路。

完善的权限管理

1）安全管理员在DBCtrl上创建数据库安全运维申请人（aq1_sq1执行操作的人）和审批人（aq1_sp11审核运维操作的人），并分配对应的数据库运维操作权限（aq1_db1数据库组）：

现有流程基础上增加防守机制，通过数据库安全运维产品DBCtrl配置对生产库高危操作的规则，并设定为“拦截”动作，在Navicat上即使误操作也会被DBCtrl拦截，防止误删数据时间发生。具体操作步骤如下：

2）DBCtrl添加防护规则，拦截对生产库的高危敏感操作：

3）在Navicat上同时打开生产库和备份库，本来对备份库进行操作，光标误选中了生产库，执行“DROP TABLE DBFWUSERS”敏感表，操作被拦截：

4）同时，具备审计记录时候追踪查询，可以追溯到访问源以及执行的详情：

有效的审批机制

通过数据库安全运维业务标准化审批流程，规范操作，对数据库高危操作通增加人工交叉审核机制，使得流程规范化。具体操作步骤如下：

1）安全管理员在DBCtrl上创建数据库安全运维申请人（aq1_sq1执行操作的人）和审批人（aq1_sp11审核运维操作的人），并分配对应的数据库运维操作权限（aq1_db1数据库组）：

2）申请人需要对数据库进行操作，需要用自己的账号登录DBCtrl，发起审批流程：

3、申请完的任务自动分配到有权限的审批人，审批人根据提交的操作详情，人工审核是否批准该操作执行：

4.如果审批人认为高危不合规操作，驳回操作申请，并告知驳回理由，申请人收到审批结果，该操作不会被执行：

以上，是运用数据库安全运维的技术手段进行了场景还原，并通过实际操作验证了两个思路的可行性。总结下来，只要针对数据库安全运维的威胁点，建立相应的操作流程管理制度，让技术手段参与操作流程，就可以避免删库跑路，让运维人员不再“背锅”，让管理者睡个好觉。

本文转自雷锋网，如需转载请至雷锋网官网申请授权。

作者：郭佳，原文链接