01背景这件事发生在两年前。是某风的工程师??。根据网上披露的信息，大致情况是这样的：首先，工程师接到一个需求变更的任务单，需要进行数据库SQL操作。SQL脚本已准备就绪。接下来登录跳板机进入生产数据库的管理端，然后运行Navicat-MySQL客户端管理工具。这时候，问题就出现了。他发现自己选错了数据库，但是SQL脚本已经粘贴好可以执行了，于是他的目的是按delete键删除选中的执行SQL语句，没想到鼠标光标跳了起来到数据库。在上面的实例上，此时的delete键是删除数据库实例。结果工程师没有看弹框里的提示，直接按了回车键。最后的结果就是运营监控平台宕机！故障持续了10个小时，给公司造成了严重的负面影响，负责人被解雇。提起这件事来谈，其实也不是为了抱怨什么，而是为了等我下来的时候真正想抱怨的其他事情做铺垫。我觉得牟峰的安全管理有几个亮点可以提一下。关键数据库的部署必须在独立的安全域内，任何外部操作都需要通过跳板实现。他们做得很好，甚至达到了政府信息中心的安全要求。数据中心管控要考虑到最小的范围，谁出了问题，谁就能够尽快被追查到。数据库的运行需要经过需求变更流程，而不是工程师随意修改。其实他们存在的问题是给MySQL数据库登录操作的权限太大了，但是他们可以直接干数据库。也就是说，越是关键的平台系统，运维过程中需要关注的具体细节就越多。02你的数据库是在互联网上开放的吗？前段时间在“有问必答”的平台上回答了一个问题。某云业务服务产品一开始一直在用大公司的云，但随着业务需求的增加，部分服务不得不部署在国企的云上。还涉及到双云交互。我再说说具体的业务场景：各个云的数据库数据归属属于不同的运营商，所以需要分开。每个云存储都是独立的，但是客户端业务有一个统一的入口。比如可以这样理解：App平台业务需要入驻的商户很多，但是某个地区的所有商户数据都需要由该地区选择的云服务商托管，数据自然归属于区域的商家联盟，但商家服务全国，APP自然是面向全国的入口。那么为什么要使用MQ呢？实际目标设计：统一入口的API网关可以将全国任意客户端的请求调度到国企云的子网关执行区域内的微服务业务，并将数据存储在国企云，但是中心数据库还在大厂云还是需要通过MQ把国企云作为二级平台数据库的数据同步到数据中心，甚至会有一个未来类似的模式。此外，数据中心还需要对基础平台数据进行统一管理。任何记录调整都必须通过MQ分发到二级云平台的数据库，防止碎片化。那么这个时候大厂云就是数据中心，新国企云就是二级平台的数据库。这样以后不仅可以容纳其他云平台，独立自建的私有云机房也可以通过这种方式接入。所以，必须要有一个MQ来实现数据协同。当时觉得RabbitMQ更合适。一句话，传递关键业务信息，作为架构师，我向领导提出架构需要调整。双云使用MQ更安全。猜猜领导是怎么和我交流的？领导：你把事情复杂化了，保持简单。我：有多简单？负责人：大厂云的数据库端口开放给国企云，国企云部署微服务访问大厂云数据库。我：我说数据库暴露在互联网上是危险的，业务在公网上来回传输会拖慢平台的整体性能。领导：你说的太玄乎了！好吧，那我们直接上架构图看看按照领导的意见是什么效果。先看原架构图，如下图所示：我们可以看到红圈中的API网关->微服务->数据库通信交互是在一个几乎没有路由的内部高速稳定网络中进行的在在线事务计算处理的请求-响应过程中。好吧，我们来看看最简单的按照领导的要求——数据库泄露到公网，二云是在服务范围内部署一些微服务。如下图所示：红线代表客户端发起的请求。大厂云API网关通过公网反向代理国企云微服务，国企云微服务通过公网同步访问大厂。云数据库进行事务级处理。然后通过两次公网传输，将业务处理数据响应给客户端。备注：此过程不体现两个云微服务之间的RPC协作。这个架构不谈高并发、低延迟、稳定事务、可靠访问，因为基础就是这样，谈这些都是废话。更关键的是，安全更是要命。在这种纯粹夺取公众生命的结构下，这已经不是平衡成本和技术的问题了。为什么这种架构更致命？说到这里，我真的很想吐槽一下，当时评论里回答的很多技术人员都认为在网上开放生产数据库端口是没有问题的，可以通过白名单和加密来控制。让我们回顾一下Xfeng的事件。这个还在正规流程下，会出现这么巧合的删库错误。更有什者，将数据库置于开放环境中，形成了不可控的网络边界局面。这个架构一旦敲定，以后只要业务增加，只要接入某个云，甚至是企业私有云，或者第三方系统，数据中心就必须开放一个数据库白名单，对上所有的外部访问。公共网络，那么数据中心的控制范围将无限扩大。只要任何连接到公网数据中心的服务器受到攻击，就可以在任何跨域白名单服务器上运行Navicat甚至终端命令，就可以因攻击或操作失误而破坏数据库中心。记住，是整个数据中心！中央数据库注定要崩溃，数据中心的控制者将无法追查到责任人。我只想问问这些没有问题的技术人员，他们不胆小吗？虽然在公网开放MQ端口也有安全隐患，但总比开放数据库风险小！MQ被删除，MQ数据被盗。这样很容易恢复，损失也很小。而且，MQ只是一个渠道。可以控制和加密多少数据留在通道中。比如为了安全，我控制MQ通道数据持久化一天，第二天清理。数据库中心可以保存第二天的数据吗？清理？所以，安全不仅仅来自于外部，往往问题是来自于内部，所以数据中心的安全必须用最小范围的思维来限制网络边界，做到可控即可！03对数据库安全问题的反思国内的架构师有时不得不面对被牵着鼻子走的低成本又麻烦的小企业主。想把问题简单化固然没错，但在简化的过程中一定要有所节制，否则就没有底线，会给企业的声誉带来很大的潜在威胁。事件一旦曝光，可能给社会造成难以弥补的损失。当然，我没有让这件事往不好的方向发展。我依然顶住压力，坚守本心。这也是架构师的责任。作为我们的技术人员，我们应该了解软件架构的复杂性，了解软件架构的精妙之处，了解软件架构的责任。在互联网时代，很多数据逐渐变得不受保护。作为架构师和工程师，我们应该多思考，多一份文案，努力，一定能做得更好！我在最终的图中只给出了我真正想要实现的双云架构的目标，如下图所示：无论用户在哪里使用客户端APP，都需要访问所在区域的服务国企云所属，会通过一个API网关通用入口重定向到国企云所在的网关，后续所有在线交易操作都在云端完成，保证了企业业务通信的独立性每一朵云，都不会像上面的结构那样，变成一场旷日持久的交流。尾巴。国企云的区域数据库通过同步任务通过MQ将数据上传到数据中心，分布式架构保证了业务数据的最终一致性。同理，数据中心分发对基础数据的修改。必要时，分发过程可以配合国企云网关服务的临时停止，保证同步完成后再启用，这样在分布式环境下，不同的基础配置数据可以共享。云。一致性。
