[[408870]]

01 背景

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

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

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

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

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

02 你的數據庫在互聯網開放端口嗎？

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

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

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

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

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

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

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

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

我：咋簡單？

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

我：我說數據庫暴露在互聯網很危險，而且執行一次業務在公網來回傳遞，會拖慢平臺整體性能。

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

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

先看看原來的架構圖，如下圖所示：我們可以看到紅色圈中的API網關->微服務->數據庫通訊交互，都是在一個內部高速、穩定且幾乎不存在路由的網絡中進行在線事務計算處理的請求響應過程中。

好，看看現在按照領導要求的最簡單辦法——數據庫暴漏公網，第二個云是部署所屬服務范圍的部分微服務。

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

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

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

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

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

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

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

 03 數據庫安全問題的反思

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

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

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

國企云的區域數據庫通過同步任務，將數據經過MQ上傳至數據中心，這就是分布式架構中保證了業務數據的最終一致性。同理，數據中心下發基礎數據的修改，必要情況下，下發過程可以配合臨時停止國企云的網關服務，保證同步完成后再啟用，實現分布式環境下，基礎配置數據在不同云的強一致性。