[[408870]]

01 背景

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我：咋簡單？

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

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

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

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

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

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

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

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

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

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

只要任意一臺在公網(wǎng)上與數(shù)據(jù)中心連接的服務(wù)器被攻擊，在任意跨域的白名單服務(wù)器上走一個Navicat，甚至是終端命令，就能因為攻擊或者是操作失誤把數(shù)據(jù)庫中心搞垮，記好，是整個數(shù)據(jù)中心！中心數(shù)據(jù)庫就得完蛋，而且數(shù)據(jù)中心的管控人員還無法追蹤責(zé)任人。我就想問這些提出沒問題的技術(shù)人員不膽寒嗎？

盡管在公網(wǎng)上開放MQ端口也有安全風(fēng)險，它總比開放數(shù)據(jù)庫風(fēng)險小！刪了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ù)庫安全問題的反思

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

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

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

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