MySQL从删库到跑路:顺丰高级工程师跑路被开除之后
9 月 19 日,微博网友“大佬坊间八卦”爆料,顺丰科技数据中心的一位高级工程师邓某因误删生产数据库,导致某项服务无法使用并持续 590 分钟。
![Mysql从删库到跑路:顺丰高级工程师跑路被开除后](https://s1.51cto.com/oss/201809/21/fb0636a74db9eb6785cbc7270b7a14f4.jpeg)
随后,顺丰根据公司相关规定,辞退工程师邓某,并在顺丰内网通报。(公众号:雷锋网)
![Mysql从删库到跑路:顺丰高级工程师跑路被开除后](https://s3.51cto.com/oss/201809/21/1688a7a8102a0991e4baa8d6864d68b3.jpeg)
错选 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拦截,防止误删数据时间发生。具体操作步骤如下:
![Mysql从删库到跑路:顺丰高级工程师跑路被开除后](https://s2.51cto.com/oss/201809/21/793c946703e1fc970e1b2982cd87ff5f.jpeg)
2)DBCtrl添加防护规则,拦截对生产库的高危敏感操作:
![Mysql从删库到跑路:顺丰高级工程师跑路被开除后](https://s3.51cto.com/oss/201809/21/ec8c3941fc287ef2c7b02d9498b4ef4b.jpeg)
3)在Navicat上同时打开生产库和备份库,本来对备份库进行操作,光标误选中了生产库,执行“DROP TABLE DBFWUSERS”敏感表,操作被拦截:
![](https://s1.51cto.com/oss/201809/21/c7e124387abb614c6b090599d4d536a1.jpeg)
4)同时,具备审计记录时候追踪查询,可以追溯到访问源以及执行的详情:
![Mysql从删库到跑路:顺丰高级工程师跑路被开除后](https://s1.51cto.com/oss/201809/21/27716552d02730a381822a87d2267bbf.jpeg)
![](https://s3.51cto.com/oss/201809/21/93ad64df8fa587edb92756146aab7487.jpeg)
有效的审批机制
1)通过数据库安全运维业务标准化审批流程,规范操作,对数据库高危操作通增加人工交叉审核机制,使得流程规范化。具体操作步骤如下:
![](https://s3.51cto.com/oss/201809/21/8236cd42959872b471cd22914a0a108d.jpeg)
2)申请人需要对数据库进行操作,需要用自己的账号登录DBCtrl,发起审批流程:
![](https://s4.51cto.com/oss/201809/21/750672e7ce9455e8dbaf595b9ee7171f.jpeg)
3、申请完的任务自动分配到有权限的审批人,审批人根据提交的操作详情,人工审核是否批准该操作执行:
![](https://s1.51cto.com/oss/201809/21/a5024133fdb3ae5755c6df22fb2a8975.jpeg)
4.如果审批人认为高危不合规操作,驳回操作申请,并告知驳回理由,申请人收到审批结果,该操作不会被执行:
![](https://s4.51cto.com/oss/201809/21/ca6fbb29abd7aa06fa1df3ff6c93e7b5.jpeg)
![](https://s5.51cto.com/oss/201809/21/4abbf3b9904742a7fdfc855d0574e576.jpeg)
以上,是运用数据库安全运维的技术手段进行了场景还原,并通过实际操作验证了两个思路的可行性。总结下来,只要针对数据库安全运维的威胁点,建立相应的操作流程管理制度,让技术手段参与操作流程,就可以避免删库跑路,让运维人员不再“背锅”,让管理者睡个好觉。
相关文章
- 数据孤岛是业务效率的无声杀手
- 2023展望:新的一年将给大数据分析领域带来什么?
- 阿里云ADB基于Hudi构建Lakehouse的实践
- 大数据在医疗保健领域的使用案例
- 微软增加说明:KB5021751 更新扫描已经 / 即将过时 Office 过程中不会触碰用户隐私
- 2022 Gartner全球云数据库管理系统魔力象限发布 腾讯云数据库入选
- 场景化、重实操,分享一个实时数仓实践案例
- Arctic的湖仓一体践行之路
- 分布式计算MapReduce究竟是怎么一回事?
- 淘系数据模型治理优秀实践
- 大数据分析对医疗保健的影响
- 当我们说大数据Hadoop,究竟在说什么?
- 2022年及以后大数据的五个发展趋势
- 网易严选离线数仓治理实践
- 2023 年数据治理趋势
- 一份“靠谱”的年度经营计划,你学会了吗?
- 漫谈对大数据的思考
- 测试一下,读懂数据的能力,你有吗?
- 用艺术的眼光探索数据之美
- 聊聊数据分析成果如何落地