1.背景
這個事情發生在兩年前，是某豐的工程師，根據網上披露的資訊，大體情況是這樣：首先工程師接到了需求變更的任務工單，需要進行資料庫SQL執行操作，并事先準備好了SQL的腳本。接下來通過登陸跳闆機就進入到了生産資料庫的管理端，然後運作Navicat-MySQL的用戶端管理工具。
這時候問題出現了，他發現自己選擇錯了資料庫，但是SQL腳本已經粘貼上準備執行了，是以他的目的是按delete鍵删除標明的執行SQL語句，可是萬萬沒想到滑鼠光标跳到了資料庫執行個體上面，這時候的delete鍵就是删除資料庫執行個體了，結果這位工程師還不看彈出框的提醒，直接按了Enter鍵。最後的結果那就是營運監控管控平台挂了！故障持續了10小時，對企業造成了嚴重的負面影響，直接負責人也被解雇。
拿出來這個事情聊，其實并不是想再吐槽什麼，隻不過為我下來真正想吐槽的其他事情做一個鋪墊，我認為某豐的安全管理做的有幾個亮點是可以拿出來說的。
- 關鍵資料庫的部署必須是在獨立的安全域内，任何外部的操作需要通過跳闆機實作。他們做得很好，甚至達到了政府資訊中心安全的要求。
- 資料中心管控要按照最小範圍考慮，誰出的問題，能最快地追蹤到。
- 資料庫的操作需要走需求變更流程，而不是被工程師随心所欲地修改。
其實他們出現的問題是賦予MySQL資料庫登陸操作的權限太大了，可是直接幹庫，也就是說越是關鍵性高的平台系統，運維過程中越要注重具體細節，你不能上來就給root。
2.你的資料庫在網際網路開放端口嗎？
前段時間，我在“有問題就有答案”的平台回答了一個問題，内容涉及到我曾經遇到的一個架構更新問題，被上司要求對網際網路開放端口，内容大體是這樣子：
我以前做過一個雲端業務服務産品，開始一直是用大廠雲，不過随着業務需求增加，部分服務又要在國企雲部署。也就涉及到了雙雲互動。
具體業務場景我也描述一下：各家雲的資料庫資料所有權屬于不同的營運方，是以要分開，各個雲存儲各自的，但用戶端業務是統一入口。舉個例子，可以這麼去了解：App平台業務需要入駐很多商家，但某一個區域的的所有商家資料需要歸該區域自己選擇的雲服務商托管，資料自然也歸該區域的商家聯盟所有，但是商家是服務全國的，自然APP是全國一個入口。
那為什麼要用MQ呢？實際上的目标設計：統一入口的API網關可以将全國任何一個用戶端的請求排程到國企雲的子網關上去執行該區域的微服務業務，并将資料存儲在國企雲，但是中心資料庫還是在大廠雲，仍然需要将國企雲作為二級平台資料庫的資料通過MQ的方式同步到資料中心，甚至以後還會有類似模式。
另外資料中心還要統一管理基礎平台資料，任何的記錄調整，都要通過MQ分發到二級雲平台的資料庫中，防止各自為政的情況。那麼這時候大廠雲就是資料中心了，而新的國企雲就是二級平台的資料庫。這樣以後不僅可以容納其它雲平台，包括以後獨立自建的私有雲機房也可以通過此模式連接配接起來。
是以要有個MQ，實作資料協作，當時我認為RabbitMQ更合适一些，總之要做關鍵業務的消息傳遞，作為架構師我給上司提出來架構需要調整，雙雲走MQ比較穩妥。
你們猜上司怎麼跟我溝通的？
上司：你把事情搞複雜了，要簡單地來，
我：咋簡單？
上司：大廠雲的資料庫端口開放給國企雲，國企雲就部署微服務通路大廠雲資料庫。
我：我說資料庫暴露在網際網路很危險，而且執行一次業務在公網來回傳遞，會拖慢平台整體性能。
上司：你說得也太玄乎了！
好吧，那我們就直接上架構圖看看按照上司的意見到底是個什麼效果。
先看看原來的架構圖，如下圖所示：我們可以看到紅色圈中的API網關->微服務->資料庫通訊互動，都是在一個内部高速、穩定且幾乎不存在路由的網絡中進行線上事務計算處理的請求響應過程中。
好，看看現在按照上司要求的最簡單辦法——資料庫暴漏公網，第二個雲是部署所屬服務範圍的部分微服務。
如下圖所示：紅色線頭代表的就是用戶端發起請求，大廠雲API網關就要通過公網反向代理到國企雲的微服務，然後國企雲的微服務做再通過公網同步通路大廠雲的資料庫做事務級處理。然後，再通過兩次公網傳輸，把業務處理的資料響應給用戶端。備注：這個過程中沒有展現雙雲微服務之間的RPC協作。
這個架構就不談什麼高并發、低延時、事務穩定、通路可靠，因為底子都這樣了，再談這些都是扯淡。更關鍵的是安全性更為緻命，在這種純粹拿公網賭命的架構下，這已經不是平衡成本和技術的問題了。
為什麼說這種架構安全性更為緻命呢？說到這裡，我也真的想先吐槽一下當時回答的評論中居然有不少搞技術的人覺得，網際網路上開放生産資料庫端口不是問題，可以用白名單、加密這些方法來控制。
咱們就再回頭看看某豐的事件，這還是在正規的流程下，都會出現如此巧合的删庫錯誤，更何況，把資料庫放置在公開環境，已經形成無法控制的網絡邊界局面，這種架構一旦定型，隻要以後随着業務的增加，隻要再加入個某雲，甚至是企業私有雲，或者是某個第三方系統對接，資料中心都要在公網給所有外部通路開資料庫白名單，那麼資料中心的管控範圍就會無限制地擴大。
隻要任意一台在公網上與資料中心連接配接的伺服器被攻擊，在任意跨域的白名單伺服器上走一個Navicat，甚至是終端指令，就能因為攻擊或者是操作失誤把資料庫中心搞垮，記好，是整個資料中心！中心資料庫就得完蛋，而且資料中心的管控人員還無法追蹤責任人。我就想問這些提出沒問題的技術人員不膽寒嗎？
盡管在公網上開放MQ端口也有安全風險，它總比開放資料庫風險小！删了MQ了，竊取了MQ資料，這都好恢複，損失也是最小。而且MQ隻是通道，通道裡的資料停留多少，都可以控制，還可以加密，例如：為了安全，我控制MQ通道資料就持久化一天，隔天就清理，難道我能把資料庫中心隔天的資料清理嗎？
是以安全不僅僅來自外部，往往問題出在内部，是以資料中心的安全一定要用最小範圍的思想來限定網絡邊界，就是為了可控！
3.資料庫安全問題的反思
有時候國内的架構師就得面對低成本，又怕麻煩的小企業主思維牽着鼻子走，盡量把問題簡單化這個說法沒錯，但是簡單化也要有個節制，否則就是無底線了，這會為企業信譽帶來極大的潛在威脅，一旦東窗事發，可能會對社會造成不可挽回的損失。當然我并沒有讓這個事情朝壞的方向發展，還是頂住壓力，堅持本心，這也是架構師的責任。
作為我們技術人員更應該懂得軟體架構之複雜，軟體架構之微妙和軟體架構之責任，在網際網路時代，很多資料都逐漸變得缺乏保護，作為架構師、工程師，我們多想一點，多出一份力，就一定能做得更好！
上圖是我給出真正想達到的雙雲架構目标，如下圖所示：無論在何地的使用者使用用戶端APP需要通路國企雲所屬區域的服務，都會通過一個API網關總入口重定向到國企雲所在的網關上，那麼之後的所有線上事務操作都是在雲内部完成，這樣就保證了各雲的業務通訊獨立性，不會像上面那個架構的通訊變成了拖着長長的尾巴。
國企雲的區域資料庫通過同步任務，将資料經過MQ上傳至資料中心，這就是分布式架構中保證了業務資料的最終一緻性。同理，資料中心下發基礎資料的修改，必要情況下，下發過程可以配合臨時停止國企雲的網關服務，保證同步完成後再啟用，實作分布式環境下，基礎配置資料在不同雲的強一緻性。
作者：西安守護石資訊科技CTO