案例分析：从误删除数据库血案看数据库系统的安全设计

日前，微博网友大佬坊间八卦爆料，顺丰科技数据中心一位高级工程师误删除生产数据库，导致某项业务无法使用并持续590分钟。顺丰根据公司相关规定，辞退工程师邓某，并在顺丰内网通报。

事情经过

邓某工程师是顺丰科技 IT 数据中心应用交付技术部互联网产品运维组的 IT 运维开发高级工程师。在接收到变更需求后，邓在操作过程中，错选了 RUSS 数据库，打算删除执行的 SQL。在选定删除时，因其操作不严谨，光标回跳到 RUSS 库的实例，在未看清所选内容的情况下，便通过 delete 执行删除，同时忽略了弹窗提醒，直接回车，导致 RUSS 生产数据库被删掉，这是非常严重的安全事件了。

因为工作人员的不严谨操作，导致数据丢失，OMCS 运营监控管控系统发生故障，使该系统上临时车险发车功能无法使用并持续了约590分钟，给顺丰业务带来严重影响。

事故原因分析

事故出来之后，网上对于这一事件有一些原因分析，总结起来有如下几点：

1)黑客攻击。黑客利用系统存在的漏洞，侵入系统，非法删除数据库。

2)硬件故障。如果系统中数据库服务只部署了单个节点，当这单个节点挂掉之后，整个数据库就无法提供服务了。也就是说数据库没有备份，这对于重要数据系统来说是严重的缺陷。

3)软件缺陷。数据库服务属于软件系统的一种类型，当软件存在Bug的时候，也往往会造成安全问题。

4)运维失误。数据库往往是由运维人员管理的，而运维人员由于多种原因可能会发生一些操作失误，比如长时间疲劳工作、责任心差、对公司不满存在蓄意破坏等等，这些都可能造成数据的丢失。

5)自然灾害。类似于机房断电以及其他可能的自然灾害导致机房数据无法恢复。

这些年删过的数据库

其实删除数据库这种神操作已经发生很多次了，最近几年发生的著名数据库删除事件有：

2017 年 2 月，GitLab 的一位系统管理员在给线上数据库做负载均衡工作时，遭受了 DDoS 攻击。在阻止了攻击之后，运维人员发现了数据库不同步的问题，便开始修复，在修复过程中，错误地在生产环境上执行了数据库目录删除命令，导致 300GB 数据被删成 4.5G，GitLab 被迫下线。

2017 年 6 月，一家荷兰海牙的云主机商 verelox.com，一名前任管理员删光了该公司所有客户的数据，并且擦除了大多数服务器上面的内容。最终导致 Verelox 暂时将网络下线。在发布的官方公告中，Verelox 表示一直努力恢复数据，但遗憾的是，已丢失的所有数据可能恢复不了。

2017 年 9 月，某 IT 大厂技术工程师帮助广西移动进行扩容割接（即增加系统容量）时，不小心将 HSS 设备里面的用户数据格式化删除，导致广西移动近 100多万用户数据丢失，使用户手机8个多小时失联，不能通话上网。

2015年5月，国内某知名旅行网数据库被物理删除，每小时损失就高达100多万美元。

在数据经济时代，数据库正变得越来越有价值，已经成为企业最核心的资产。无论是哪一种删除，都会给用户服务和企业的正常经营造成严重的负面影响，这一点是毋庸质疑的。

根本原因分析

尽管可能存在上面多种原因都会导致数据库被删除，但公号珺认为最根本的原因还是系统安全设计有缺陷。理由如下：

无论是运维人员误操作删除数据库，还是黑客入侵系统导致数据库被删除，都是因为系统赋予了某一特权用户拥有这样的超级权限。这种超级权限没有相应的约束机制，本身就是系统设计的错误。这里不禁要问：①对于生产数据库来说，运维人员的权限究竟应该是什么？ ②生产数据库的数据是由谁产生的？③谁有权对数据库记录进行维护，如添加、修改和删除？

数据库维护的流程是什么？对于重要数据库内容的修改、删除的流程应该是什么？特别是对于整个数据库的删除流程应该是什么样的？仅有弹窗提示够不够？系统是否有足够的验证或检测过程？

因为系统安全设计有缺陷，导致由于运维人员的误操作而错误地删除了整个数据库，而将全部责任推给运维人员，公号珺认为这也不甚合理。运维人员误操作固然有错，但是系统开发时安全需求和设计不足，导致系统先天存在这样的缺陷。今天如果没有运维人员的误操作，系统仍然存在被黑客或者恶意的其他内部人员删除整个数据库的风险。这是系统设计上的缺陷，不能完全让这个运维工程师背这个黑锅。

系统安全设计解决方案

这里从权限管理和系统结构安全的角度给出一个数据库系统安全设计解决方案：

1）最小授权：运维人员的操作权限应该仅用于完成他的运维工作。如果生产数据是由用户产生的，运维人员只负责系统维护，不应该有修改、删除数据库记录等操作的权限，特别是对整个数据库的删除权限。

2）职责分离：就像银行柜员一些重要业务需要主管的审批一样，对于重要的数据库系统运维操作来说，比如大量数据记录或者整个库的删除，必须要有数据库运维主管的审批、确认，才可以完成操作。这样就可以避免因为某一个人误操作、或者蓄意破坏而导致的重要记录/甚至整个数据库完全被删除。

3）结构安全：对于重要数据库系统来说，在系统结构设计上应考虑重要节点冗余，配置两台数据库服务器，随时保持数据库备份，这样就不会出现数据库误删除而导致全部业务数据丢失。

4）失效安全：为避免重要数据库系统的突然故障，比如临时断电等，应该设计数据库临时保留策略，如生成快照。

如果软件/系统在开发的时候充分考虑了这些问题，即使某一天运维人员糊涂了也不会出现数据库整体被删除的状况。

我们还能做些什么？

消除认识误区，提高对系统的性能和安全性概念的理解：

比如国内某大型IT企业的云平台系统可靠性号称已经达到了6个9的水平，即99.9999%，而其可用性也达到了99.95%的水平，可是前不久仍然发生了企业数据丢失的事件，双方还对赔偿金额问题至今没有达成一致意见。

请大家注意可靠性和安全性不是一个概念哦。可靠性是指产品在规定的时间内，在规定的条件下，完成预定功能的能力。通常理解就是实现预定业务功能的能力。而安全性是指在系统发生故障或者遭到它方攻击破坏时仍然能够提供所需功能的能力。安全性包括多个属性，比如保密性、完整性、可用性、真实性、权限管理可控性、可行性等等，企业强调的可用性只是其中的一个属性。安全是全方位的，仅有可用性一个指标也是远远不够的。所以企业强调它的系统可靠性有5个9还是6个9并不能保证安全性不出问题，大家要擦亮眼睛，不要误认为可靠性高，系统安全性就好。

好啦，今天的科普就到这里。

祝大家中秋/国庆双节快乐！！走之前别忘了给公号珺点个赞。