工程师误删了公司生产数据库，如何看待数据安全架构的脆弱性？

Posted 2021-07-29 Hollis Chuang

01 背景

这个事情发生在两年前，是某丰的工程师，根据网上披露的信息，大体情况是这样：首先工程师接到了需求变更的任务工单，需要进行数据库SQL执行操作，并事先准备好了SQL的脚本。接下来通过登陆跳板机就进入到了生产数据库的管理端，然后运行Navicat-mysql的客户端管理工具。

这时候问题出现了，他发现自己选择错了数据库，但是SQL脚本已经粘贴上准备执行了，所以他的目的是按delete键删除选定的执行SQL语句，可是万万没想到鼠标光标跳到了数据库实例上面，这时候的delete键就是删除数据库实例了，结果这位工程师还不看弹出框的提醒，直接按了回车键。最后的结果那就是运营监控管控平台挂了！故障持续了10小时，对企业造成了严重的负面影响，直接负责人也被解雇。

拿出来这个事情聊，其实并不是想再吐槽什么，只不过为我下来真正想吐槽的其他事情做一个铺垫，我认为某丰的安全管理做的有几个亮点是可以拿出来说的。

1. 关键数据库的部署必须是在独立的安全域内，任何外部的操作需要通过跳板机实现。他们做得很好，甚至达到了政府信息中心安全的要求。

2. 数据中心管控要按照最小范围考虑，谁出的问题，能最快地追踪到。

3. 数据库的操作需要走需求变更流程，而不是被工程师随心所欲地修改。

其实他们出现的问题是赋予MySQL数据库登陆操作的权限太大了，可是直接干库，也就是说越是关键性高的平台系统，运维过程中越要注重具体细节，你不能上来就给root。

 

02 你的数据库在互联网开放端口吗？

前段时间，我在“有问题就有答案”的平台回答了一个问题，内容涉及到我曾经遇到的一个架构升级问题，被领导要求对互联网开放端口，内容大体是这样子：

我以前做过一个云端业务服务产品，开始一直是用大厂云，不过随着业务需求增加，部分服务又要在国企云部署。也就涉及到了双云交互。

具体业务场景我也描述一下：各家云的数据库数据所有权属于不同的运营方，所以要分开，各个云存储各自的，但客户端业务是统一入口。举个例子，可以这么去理解：App平台业务需要入驻很多商家，但某一个区域的的所有商家数据需要归该区域自己选择的云服务商托管，数据自然也归该区域的商家联盟所有，但是商家是服务全国的，自然APP是全国一个入口。

那为什么要用MQ呢？实际上的目标设计：统一入口的API网关可以将全国任何一个客户端的请求调度到国企云的子网关上去执行该区域的微服务业务，并将数据存储在国企云，但是中心数据库还是在大厂云，仍然需要将国企云作为二级平台数据库的数据通过MQ的方式同步到数据中心，甚至以后还会有类似模式。

另外数据中心还要统一管理基础平台数据，任何的记录调整，都要通过MQ分发到二级云平台的数据库中，防止各自为政的情况。那么这时候大厂云就是数据中心了，而新的国企云就是二级平台的数据库。这样以后不仅可以容纳其它云平台，包括以后独立自建的私有云机房也可以通过此模式连接起来。

因此要有个MQ，实现数据协作，当时我认为RabbitMQ更合适一些，总之要做关键业务的消息传递，作为架构师我给领导提出来架构需要调整，双云走MQ比较稳妥。

你们猜领导怎么跟我沟通的？ 

领导：你把事情搞复杂了，要简单地来，

我：咋简单？

领导：大厂云的数据库端口开放给国企云，国企云就部署微服务访问大厂云数据库。

我：我说数据库暴露在互联网很危险，而且执行一次业务在公网来回传递，会拖慢平台整体性能。

领导：你说得也太玄乎了！

好吧，那我们就直接上架构图看看按照领导的意见到底是个什么效果。

先看看原来的架构图，如下图所示：我们可以看到红色圈中的API网关->微服务->数据库通讯交互，都是在一个内部高速、稳定且几乎不存在路由的网络中进行在线事务计算处理的请求响应过程中。

好，看看现在按照领导要求的最简单办法——数据库暴漏公网，第二个云是部署所属服务范围的部分微服务。

如下图所示：红色线头代表的就是客户端发起请求，大厂云API网关就要通过公网反向代理到国企云的微服务，然后国企云的微服务做再通过公网同步访问大厂云的数据库做事务级处理。然后，再通过两次公网传输，把业务处理的数据响应给客户端。备注：这个过程中没有体现双云微服务之间的RPC协作。

这个架构就不谈什么高并发、低延时、事务稳定、访问可靠，因为底子都这样了，再谈这些都是扯淡。更关键的是安全性更为致命，在这种纯粹拿公网赌命的架构下，这已经不是平衡成本和技术的问题了。

为什么说这种架构安全性更为致命呢？说到这里，我也真的想先吐槽一下当时回答的评论中居然有不少搞技术的人觉得，互联网上开放生产数据库端口不是问题，可以用白名单、加密这些方法来控制。

咱们就再回头看看某丰的事件，这还是在正规的流程下，都会出现如此巧合的删库错误，更何况，把数据库放置在公开环境，已经形成无法控制的网络边界局面，这种架构一旦定型，只要以后随着业务的增加，只要再加入个某云，甚至是企业私有云，或者是某个第三方系统对接，数据中心都要在公网给所有外部访问开数据库白名单，那么数据中心的管控范围就会无限制地扩大。

只要任意一台在公网上与数据中心连接的服务器被攻击，在任意跨域的白名单服务器上走一个Navicat，甚至是终端命令，就能因为攻击或者是操作失误把数据库中心搞垮，记好，是整个数据中心！中心数据库就得完蛋，而且数据中心的管控人员还无法追踪责任人。我就想问这些提出没问题的技术人员不胆寒吗？

尽管在公网上开放MQ端口也有安全风险，它总比开放数据库风险小！删了MQ了，窃取了MQ数据，这都好恢复，损失也是最小。而且MQ只是通道，通道里的数据停留多少，都可以控制，还可以加密，例如：为了安全，我控制MQ通道数据就持久化一天，隔天就清理，难道我能把数据库中心隔天的数据清理吗？

因此安全不仅仅来自外部，往往问题出在内部，所以数据中心的安全一定要用最小范围的思想来限定网络边界，就是为了可控！

 

03 数据库安全问题的反思

有时候国内的架构师就得面对低成本，又怕麻烦的小企业主思维牵着鼻子走，尽量把问题简单化这个说法没错，但是简单化也要有个节制，否则就是无底线了，这会为企业信誉带来极大的潜在威胁，一旦东窗事发，可能会对社会造成不可挽回的损失。当然我并没有让这个事情朝坏的方向发展，还是顶住压力，坚持本心，这也是架构师的责任。

作为我们技术人员更应该懂得软件架构之复杂，软件架构之微妙和软件架构之责任，在互联网时代，很多数据都逐渐变得缺乏保护，作为架构师、工程师，我们多想一点，多出一份力，就一定能做得更好！

最后的附图我才给出真正想达到的双云架构目标，如下图所示：无论在何地的用户使用客户端APP需要访问国企云所属区域的服务，都会通过一个API网关总入口重定向到国企云所在的网关上，那么之后的所有在线事务操作都是在云内部完成，这样就保证了各云的业务通讯独立性，不会像上面那个架构的通讯变成了拖着长长的尾巴。

国企云的区域数据库通过同步任务，将数据经过MQ上传至数据中心，这就是分布式架构中保证了业务数据的最终一致性。同理，数据中心下发基础数据的修改，必要情况下，下发过程可以配合临时停止国企云的网关服务，保证同步完成后再启用，实现分布式环境下，基础配置数据在不同云的强一致性。

有道无术，术可成；有术无道，止于术

欢迎大家关注Java之道公众号

好文章，我在看❤️