[[408870]]

01 背景

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

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

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

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

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

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

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

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

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

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

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

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

你們猜領導怎么跟我溝通的？ 

領導：你把事情搞復雜了，要簡單地來。

我：咋簡單？

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

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

領導：你說得也太玄乎了！

好吧，那我們就直接上架構圖看看按照領導的意見到底是個什么效果。

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

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

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

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

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

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

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

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

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

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

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

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

最后的附圖我才給出真正想達到的雙云架構目標，如下圖所示：無論在何地的用戶使用客戶端APP需要訪問國企云所屬區(qū)域的服務，都會通過一個API網(wǎng)關總入口重定向到國企云所在的網(wǎng)關上，那么之后的所有在線事務操作都是在云內部完成，這樣就保證了各云的業(yè)務通訊獨立性，不會像上面那個架構的通訊變成了拖著長長的尾巴。

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