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

本文涉及的产品
数据安全中心,免费版
云原生 API 网关,700元额度,多规格可选
简介: 这个事情发生在两年前,是某丰的工程师,根据网上披露的信息,大体情况是这样:首先工程师接到了需求变更的任务工单,需要进行数据库SQL执行操作,并事先准备好了SQL的脚本。接下来通过登陆跳板机就进入到了生产数据库的管理端,然后运行Navicat-MySQL的客户端管理工具。这时候问题出现了,他发现自己选择错了数据库,但是SQL脚本已经粘贴上准备执行了,所以他的目的是按delete键删除选定的执行SQL语句,可是万万没想到鼠标光标跳到了数据库实例上面,这时候的delete键就是删除数据库实例了,结果这位工程师还不看弹出框的提醒,直接按了回车键。最后的结果那就是运营监控管控平台挂了!故障持续了10小时

1.背景

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

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

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

  1. 关键数据库的部署必须是在独立的安全域内,任何外部的操作需要通过跳板机实现。他们做得很好,甚至达到了政府信息中心安全的要求。
  2. 数据中心管控要按照最小范围考虑,谁出的问题,能最快地追踪到。
  3. 数据库的操作需要走需求变更流程,而不是被工程师随心所欲地修改。

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

2.你的数据库在互联网开放端口吗?

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

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

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

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

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

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

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

领导:你把事情搞复杂了,要简单地来,
我:咋简单?
领导:大厂云的数据库端口开放给国企云,国企云就部署微服务访问大厂云数据库。
我:我说数据库暴露在互联网很危险,而且执行一次业务在公网来回传递,会拖慢平台整体性能。
领导:你说得也太玄乎了!

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

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

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

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

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

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

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

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

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

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

3.数据库安全问题的反思

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

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

642.jpg

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

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


作者:西安守护石信息科技CTO

相关文章
|
23天前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。
|
23天前
|
设计模式 缓存 关系型数据库
探索微服务架构中的数据库设计挑战
微服务架构因其模块化和高扩展性被广泛应用于现代软件开发。然而,这种架构模式也带来了数据库设计上的独特挑战。本文探讨了在微服务架构中实现数据库设计时面临的问题,如数据一致性、服务间的数据共享和分布式事务处理。通过分析实际案例和提出解决方案,旨在为开发人员提供有效的数据库设计策略,以应对微服务架构下的复杂性。
|
23天前
|
消息中间件 缓存 监控
优化微服务架构中的数据库访问:策略与最佳实践
在微服务架构中,数据库访问的效率直接影响到系统的性能和可扩展性。本文探讨了优化微服务架构中数据库访问的策略与最佳实践,包括数据分片、缓存策略、异步处理和服务间通信优化。通过具体的技术方案和实例分析,提供了一系列实用的建议,以帮助开发团队提升微服务系统的响应速度和稳定性。
|
24天前
|
设计模式 架构师 Java
Java开发工程师转架构师需要学习什么
Java开发工程师转型为架构师需掌握多项技能:精通Java及框架、数据库与分布式系统;熟悉设计模式与架构模式;积累项目经验;提升沟通与领导力;持续学习新技术;培养系统设计与抽象能力;了解中间件及开发工具;并注重个人特质与职业发展。具体路径应结合个人目标与实际情况制定。
45 18
|
23天前
|
消息中间件 缓存 监控
优化微服务架构中的数据库访问:策略与实践
随着微服务架构的普及,如何高效管理和优化数据库访问成为了关键挑战。本文探讨了在微服务环境中优化数据库访问的策略,包括数据库分片、缓存机制、异步处理等技术手段。通过深入分析实际案例和最佳实践,本文旨在为开发者提供实际可行的解决方案,以提升系统性能和可扩展性。
|
27天前
|
存储 负载均衡 数据库
探索后端技术:从服务器架构到数据库优化的实践之旅
在当今数字化时代,后端技术作为支撑网站和应用运行的核心,扮演着至关重要的角色。本文将带领读者深入后端技术的两大关键领域——服务器架构和数据库优化,通过实践案例揭示其背后的原理与技巧。无论是对于初学者还是经验丰富的开发者,这篇文章都将提供宝贵的见解和实用的知识,帮助读者在后端开发的道路上更进一步。
|
2月前
|
消息中间件 存储 运维
微服务架构下的数据库选择与挑战
【8月更文第29天】随着微服务架构的流行,如何为每个服务选择合适的数据库成为了一个重要的话题。微服务架构强调将大型应用程序分解为一组小型、独立的服务,这些服务通常各自拥有自己的数据库。这种架构模式带来了灵活性和可扩展性,但也带来了数据一致性、事务管理和跨服务数据访问等方面的挑战。
41 0
|
2月前
|
存储 缓存 关系型数据库
Django后端架构开发:缓存机制,接口缓存、文件缓存、数据库缓存与Memcached缓存
Django后端架构开发:缓存机制,接口缓存、文件缓存、数据库缓存与Memcached缓存
38 0
|
2月前
|
存储 前端开发 关系型数据库
Linux 技术架构:前端、后端与数据库的完美融合
【8月更文挑战第25天】本文深入剖析了Linux操作系统的技术架构,重点介绍了前端、后端及数据库三大核心组成部分。Linux前端技术不仅涵盖了图形用户界面(GUI),包括GNOME、KDE等桌面环境,还涉及HTML、CSS、JavaScript等Web前端技术及其相关框架。后端技术则聚焦于Python、Java等多种编程语言、Apache和Nginx等Web服务器以及MySQL、PostgreSQL等数据库管理系统。Linux数据库技术覆盖了关系型和非关系型数据库,如MySQL、MongoDB等,并提供了多种数据库管理工具。
69 0
|
2月前
|
存储 Serverless API
Serverless 架构实现弹幕场景问题之在initializer方法中初始化数据库实例如何解决
Serverless 架构实现弹幕场景问题之在initializer方法中初始化数据库实例如何解决
18 0