[[408870]]

01 背景

這個(gè)事情發(fā)生在兩年前，是某豐的工程師，根據(jù)網(wǎng)上披露的信息，大體情況是這樣：首先工程師接到了需求變更的任務(wù)工單，需要進(jìn)行數(shù)據(jù)庫SQL執(zhí)行操作，并事先準(zhǔn)備好了SQL的腳本。接下來通過登陸跳板機(jī)就進(jìn)入到了生產(chǎn)數(shù)據(jù)庫的管理端，然后運(yùn)行Navicat-MySQL的客戶端管理工具。

這時(shí)候問題出現(xiàn)了，他發(fā)現(xiàn)自己選擇錯(cuò)了數(shù)據(jù)庫，但是SQL腳本已經(jīng)粘貼上準(zhǔn)備執(zhí)行了，所以他的目的是按delete鍵刪除選定的執(zhí)行SQL語句，可是萬萬沒想到鼠標(biāo)光標(biāo)跳到了數(shù)據(jù)庫實(shí)例上面，這時(shí)候的delete鍵就是刪除數(shù)據(jù)庫實(shí)例了，結(jié)果這位工程師還不看彈出框的提醒，直接按了回車鍵。最后的結(jié)果那就是運(yùn)營(yíng)監(jiān)控管控平臺(tái)掛了！故障持續(xù)了10小時(shí)，對(duì)企業(yè)造成了嚴(yán)重的負(fù)面影響，直接負(fù)責(zé)人也被解雇。

拿出來這個(gè)事情聊，其實(shí)并不是想再吐槽什么，只不過為我下來真正想吐槽的其他事情做一個(gè)鋪墊，我認(rèn)為某豐的安全管理做的有幾個(gè)亮點(diǎn)是可以拿出來說的。

1.  關(guān)鍵數(shù)據(jù)庫的部署必須是在獨(dú)立的安全域內(nèi)，任何外部的操作需要通過跳板機(jī)實(shí)現(xiàn)。他們做得很好，甚至達(dá)到了政府信息中心安全的要求。
2.  數(shù)據(jù)中心管控要按照最小范圍考慮，誰出的問題，能最快地追蹤到。
3.  數(shù)據(jù)庫的操作需要走需求變更流程，而不是被工程師隨心所欲地修改。

其實(shí)他們出現(xiàn)的問題是賦予MySQL數(shù)據(jù)庫登陸操作的權(quán)限太大了，可是直接干庫，也就是說越是關(guān)鍵性高的平臺(tái)系統(tǒng)，運(yùn)維過程中越要注重具體細(xì)節(jié)，你不能上來就給root。

02 你的數(shù)據(jù)庫在互聯(lián)網(wǎng)開放端口嗎？

前段時(shí)間，我在“有問題就有答案”的平臺(tái)回答了一個(gè)問題，內(nèi)容涉及到我曾經(jīng)遇到的一個(gè)架構(gòu)升級(jí)問題，被領(lǐng)導(dǎo)要求對(duì)互聯(lián)網(wǎng)開放端口，內(nèi)容大體是這樣子：

我以前做過一個(gè)云端業(yè)務(wù)服務(wù)產(chǎn)品，開始一直是用大廠云，不過隨著業(yè)務(wù)需求增加，部分服務(wù)又要在國(guó)企云部署。也就涉及到了雙云交互。

具體業(yè)務(wù)場(chǎng)景我也描述一下：各家云的數(shù)據(jù)庫數(shù)據(jù)所有權(quán)屬于不同的運(yùn)營(yíng)方，所以要分開，各個(gè)云存儲(chǔ)各自的，但客戶端業(yè)務(wù)是統(tǒng)一入口。舉個(gè)例子，可以這么去理解：App平臺(tái)業(yè)務(wù)需要入駐很多商家，但某一個(gè)區(qū)域的的所有商家數(shù)據(jù)需要?dú)w該區(qū)域自己選擇的云服務(wù)商托管，數(shù)據(jù)自然也歸該區(qū)域的商家聯(lián)盟所有，但是商家是服務(wù)全國(guó)的，自然APP是全國(guó)一個(gè)入口。

那為什么要用MQ呢？實(shí)際上的目標(biāo)設(shè)計(jì)：統(tǒng)一入口的API網(wǎng)關(guān)可以將全國(guó)任何一個(gè)客戶端的請(qǐng)求調(diào)度到國(guó)企云的子網(wǎng)關(guān)上去執(zhí)行該區(qū)域的微服務(wù)業(yè)務(wù)，并將數(shù)據(jù)存儲(chǔ)在國(guó)企云，但是中心數(shù)據(jù)庫還是在大廠云，仍然需要將國(guó)企云作為二級(jí)平臺(tái)數(shù)據(jù)庫的數(shù)據(jù)通過MQ的方式同步到數(shù)據(jù)中心，甚至以后還會(huì)有類似模式。

另外數(shù)據(jù)中心還要統(tǒng)一管理基礎(chǔ)平臺(tái)數(shù)據(jù)，任何的記錄調(diào)整，都要通過MQ分發(fā)到二級(jí)云平臺(tái)的數(shù)據(jù)庫中，防止各自為政的情況。那么這時(shí)候大廠云就是數(shù)據(jù)中心了，而新的國(guó)企云就是二級(jí)平臺(tái)的數(shù)據(jù)庫。這樣以后不僅可以容納其它云平臺(tái)，包括以后獨(dú)立自建的私有云機(jī)房也可以通過此模式連接起來。

因此要有個(gè)MQ，實(shí)現(xiàn)數(shù)據(jù)協(xié)作，當(dāng)時(shí)我認(rèn)為RabbitMQ更合適一些，總之要做關(guān)鍵業(yè)務(wù)的消息傳遞，作為架構(gòu)師我給領(lǐng)導(dǎo)提出來架構(gòu)需要調(diào)整，雙云走M(jìn)Q比較穩(wěn)妥。

你們猜領(lǐng)導(dǎo)怎么跟我溝通的？ 

領(lǐng)導(dǎo)：你把事情搞復(fù)雜了，要簡(jiǎn)單地來。

我：咋簡(jiǎn)單？

領(lǐng)導(dǎo)：大廠云的數(shù)據(jù)庫端口開放給國(guó)企云，國(guó)企云就部署微服務(wù)訪問大廠云數(shù)據(jù)庫。

我：我說數(shù)據(jù)庫暴露在互聯(lián)網(wǎng)很危險(xiǎn)，而且執(zhí)行一次業(yè)務(wù)在公網(wǎng)來回傳遞，會(huì)拖慢平臺(tái)整體性能。

領(lǐng)導(dǎo)：你說得也太玄乎了！

好吧，那我們就直接上架構(gòu)圖看看按照領(lǐng)導(dǎo)的意見到底是個(gè)什么效果。

先看看原來的架構(gòu)圖，如下圖所示：我們可以看到紅色圈中的API網(wǎng)關(guān)->微服務(wù)->數(shù)據(jù)庫通訊交互，都是在一個(gè)內(nèi)部高速、穩(wěn)定且?guī)缀醪淮嬖诼酚傻木W(wǎng)絡(luò)中進(jìn)行在線事務(wù)計(jì)算處理的請(qǐng)求響應(yīng)過程中。

好，看看現(xiàn)在按照領(lǐng)導(dǎo)要求的最簡(jiǎn)單辦法——數(shù)據(jù)庫暴漏公網(wǎng)，第二個(gè)云是部署所屬服務(wù)范圍的部分微服務(wù)。

如下圖所示：紅色線頭代表的就是客戶端發(fā)起請(qǐng)求，大廠云API網(wǎng)關(guān)就要通過公網(wǎng)反向代理到國(guó)企云的微服務(wù)，然后國(guó)企云的微服務(wù)做再通過公網(wǎng)同步訪問大廠云的數(shù)據(jù)庫做事務(wù)級(jí)處理。然后，再通過兩次公網(wǎng)傳輸，把業(yè)務(wù)處理的數(shù)據(jù)響應(yīng)給客戶端。備注：這個(gè)過程中沒有體現(xiàn)雙云微服務(wù)之間的RPC協(xié)作。

這個(gè)架構(gòu)就不談什么高并發(fā)、低延時(shí)、事務(wù)穩(wěn)定、訪問可靠，因?yàn)榈鬃佣歼@樣了，再談這些都是扯淡。更關(guān)鍵的是安全性更為致命，在這種純粹拿公網(wǎng)賭命的架構(gòu)下，這已經(jīng)不是平衡成本和技術(shù)的問題了。

為什么說這種架構(gòu)安全性更為致命呢？說到這里，我也真的想先吐槽一下當(dāng)時(shí)回答的評(píng)論中居然有不少搞技術(shù)的人覺得，互聯(lián)網(wǎng)上開放生產(chǎn)數(shù)據(jù)庫端口不是問題，可以用白名單、加密這些方法來控制。

咱們就再回頭看看某豐的事件，這還是在正規(guī)的流程下，都會(huì)出現(xiàn)如此巧合的刪庫錯(cuò)誤，更何況，把數(shù)據(jù)庫放置在公開環(huán)境，已經(jīng)形成無法控制的網(wǎng)絡(luò)邊界局面，這種架構(gòu)一旦定型，只要以后隨著業(yè)務(wù)的增加，只要再加入個(gè)某云，甚至是企業(yè)私有云，或者是某個(gè)第三方系統(tǒng)對(duì)接，數(shù)據(jù)中心都要在公網(wǎng)給所有外部訪問開數(shù)據(jù)庫白名單，那么數(shù)據(jù)中心的管控范圍就會(huì)無限制地?cái)U(kuò)大。

只要任意一臺(tái)在公網(wǎng)上與數(shù)據(jù)中心連接的服務(wù)器被攻擊，在任意跨域的白名單服務(wù)器上走一個(gè)Navicat，甚至是終端命令，就能因?yàn)楣艋蛘呤遣僮魇д`把數(shù)據(jù)庫中心搞垮，記好，是整個(gè)數(shù)據(jù)中心！中心數(shù)據(jù)庫就得完蛋，而且數(shù)據(jù)中心的管控人員還無法追蹤責(zé)任人。我就想問這些提出沒問題的技術(shù)人員不膽寒嗎？

盡管在公網(wǎng)上開放MQ端口也有安全風(fēng)險(xiǎn)，它總比開放數(shù)據(jù)庫風(fēng)險(xiǎn)小！刪了MQ了，竊取了MQ數(shù)據(jù)，這都好恢復(fù)，損失也是最小。而且MQ只是通道，通道里的數(shù)據(jù)停留多少，都可以控制，還可以加密，例如：為了安全，我控制MQ通道數(shù)據(jù)就持久化一天，隔天就清理，難道我能把數(shù)據(jù)庫中心隔天的數(shù)據(jù)清理嗎？

因此安全不僅僅來自外部，往往問題出在內(nèi)部，所以數(shù)據(jù)中心的安全一定要用最小范圍的思想來限定網(wǎng)絡(luò)邊界，就是為了可控！

 03 數(shù)據(jù)庫安全問題的反思

有時(shí)候國(guó)內(nèi)的架構(gòu)師就得面對(duì)低成本，又怕麻煩的小企業(yè)主思維牽著鼻子走，盡量把問題簡(jiǎn)單化這個(gè)說法沒錯(cuò)，但是簡(jiǎn)單化也要有個(gè)節(jié)制，否則就是無底線了，這會(huì)為企業(yè)信譽(yù)帶來極大的潛在威脅，一旦東窗事發(fā)，可能會(huì)對(duì)社會(huì)造成不可挽回的損失。當(dāng)然我并沒有讓這個(gè)事情朝壞的方向發(fā)展，還是頂住壓力，堅(jiān)持本心，這也是架構(gòu)師的責(zé)任。

作為我們技術(shù)人員更應(yīng)該懂得軟件架構(gòu)之復(fù)雜，軟件架構(gòu)之微妙和軟件架構(gòu)之責(zé)任，在互聯(lián)網(wǎng)時(shí)代，很多數(shù)據(jù)都逐漸變得缺乏保護(hù)，作為架構(gòu)師、工程師，我們多想一點(diǎn)，多出一份力，就一定能做得更好！

最后的附圖我才給出真正想達(dá)到的雙云架構(gòu)目標(biāo)，如下圖所示：無論在何地的用戶使用客戶端APP需要訪問國(guó)企云所屬區(qū)域的服務(wù)，都會(huì)通過一個(gè)API網(wǎng)關(guān)總?cè)肟谥囟ㄏ虻絿?guó)企云所在的網(wǎng)關(guān)上，那么之后的所有在線事務(wù)操作都是在云內(nèi)部完成，這樣就保證了各云的業(yè)務(wù)通訊獨(dú)立性，不會(huì)像上面那個(gè)架構(gòu)的通訊變成了拖著長(zhǎng)長(zhǎng)的尾巴。

國(guó)企云的區(qū)域數(shù)據(jù)庫通過同步任務(wù)，將數(shù)據(jù)經(jīng)過MQ上傳至數(shù)據(jù)中心，這就是分布式架構(gòu)中保證了業(yè)務(wù)數(shù)據(jù)的最終一致性。同理，數(shù)據(jù)中心下發(fā)基礎(chǔ)數(shù)據(jù)的修改，必要情況下，下發(fā)過程可以配合臨時(shí)停止國(guó)企云的網(wǎng)關(guān)服務(wù)，保證同步完成后再啟用，實(shí)現(xiàn)分布式環(huán)境下，基礎(chǔ)配置數(shù)據(jù)在不同云的強(qiáng)一致性。