從微盟被刪庫談企業安全管理

做者：易陽
治學教育信息科技 CTO&聯合創始人

早上爆出一條企業安全的大新聞，微盟被刪庫了.......你們先來看看新聞：

很震驚！很震撼！嚇得我趕忙召集全公司服務端小夥伴Review了咱們全部的安所有署！！！

完全檢查完以後，我放心了，咱們即使被刪庫也能夠快速恢復！

解決完隱憂以後，做爲一個在業內安全大廠360工做五年的僞安全人士，今天跟廣大作技術的小夥伴聊聊企業安全那點事：

---

01 事件覆盤

公告透露出兩個重大信息！咱們來看看：

第一，恢復時間長，公告是這麼說的：「和您同樣，咱們度過了漫長的36小時，咱們預計這次故障還會持續一段」。

那麼爲何須要這麼久的時間來恢復？

以個人經驗推測，必定是生產環境的主備數據庫都被刪庫了！而且大機率應該是作了rm -rf類型的極端操做。不用懷疑就是傳說中的刪庫跑路！固然影響是產生了，人確定跑不了！

你們可能要問了，那數據庫恢復下不就行了嗎？沒這麼簡單！

第二，更重要的信息！你們看看這句：「犯罪嫌疑人乃微盟研發中心運維部核心工做人員賀某」。原來是內部人員！

那爲何一個普通運維人員有如此大能量？

很簡單，很多互聯網的運維人員基本都會有root權限。基本就是公司業務上帝級別的存在。說實話，我作管理這麼多年，對運維崗位一直是當心翼翼。固然是大廠能夠作的更完善，權限分層分級，就很難出現這種狀況。

現實是不少中小公司，運維就那麼幾我的，甚至一我的。

---

02 防刪庫指南

除了微盟此次安全事故，關於刪庫跑路，一直是互聯網的黑傳說。

IT界有一個老梗，某論壇的數據庫管理員抱怨本身老闆一直虐待他，結果他一氣之下就刪庫跑路了……

再假設一種狀況，若是在服務器維護的時候不當心執行了 rm -rf 命令……如今整臺服務器被刪光了腫麼辦？？？

對於中小公司來講，想把權限作完善作複雜，基本沒有可能！想依賴運維人員自己素質和心理狀態，那就是靠天吃飯！

中小公司防刪庫真正的答案是：作好備份！作好最小程度權限管理！**

1. 數據庫備份很重要

先來看看一個標準的數據庫架構圖：

從上圖中你們能夠分析一下關鍵點：

主庫：對應線上實時的業務，若是出現故障，整個系統和網站的訪問將受到影響。從庫：通常用於查詢和主從切換之用。備份數據：備份方式經常使用全量備份和增量備份的方式。備份的策略包括跨機器、跨機房、跨區備份。數據是企業第一輩子產力，數據備份尤爲重要。

存在數據備份問題的公司也有2個層次。最低層次的，有些公司壓根就沒有作備份，那出問題必定很麻煩，只能從磁盤作恢復，這個過程很是漫長！

不作數據備份的公司，長點心吧！特別是CTO或者技術負責人，淘汰的就是您這種吶！

高點層次的，有備份但只有全量備份沒有增量備份。全量備份固然不能每天作，每一個公司有本身的策略，多是一個月一次也多是一週一次。若是是這種狀況，那這中間的一個月或者一週的備份數據還得從磁盤作恢復，同樣很慢！

微盟雖然不是大廠，也算有必定規模了，備份確定是作了。根據公告的信息，恢復須要這麼久，我推斷要麼是全量是好久前作的，增量數據丟失了，要麼是刪除者作了極端操做都給幹掉了！

2. 作好最小程度權限管理

BAT級別的權限管理，咱就不談了，其實咱也不懂。懂了也沒資源作。我談談中小廠怎麼作好最小程度權限管理。 

數據庫操做權限和備份權限分離

DBA負責平常主從庫的管理和維護。運維負責備份數據的保存。採用全量和增量備份的方式。若是DBA刪除主庫，主從同步，則重庫數據被刪除。業務系統受到影響，運維能立刻收到業務報警，運維同事接管數據庫，進行備份恢復。

權限申請、權限審批和操做執行分離

開發人員作數據庫表的刪除或修改操做須要申請。技術主管或負責人審批，生成審批密碼。開發人員根據密碼登陸特定服務器，進行相關的操做。

增長隔離層

關掉DBA操做數據庫終端權限，經過yearning等審計平臺執行數據庫命令，高風險命令直接拒絕執行，併發出報警。技術總監或CTO確認沒問題以後，才能執行。

以上三點，用最小資源去作，徹底可行。若是還作不到，那就採用雲解決方案，基本上用好雲的方案，問題不大。

技術管理這件事，不能徹底依賴人。看公告怎麼說的：「因我的工做、生活等緣由」。具體什麼緣由咱也不知道，反正人是不可控的！技術管理要有抓手！合理結合公司資源作一些限制是頗有必要的！

---

03 關於雲方案

先說下一點我的經歷：

雖然沒經歷過刪庫跑路的狀況，可是身邊的程序員update語句不加where條件的狀況發生過2次。

第一次，所在的公司是自建機房，由DBA團隊管理數據庫集羣。某程序員把全部帳戶的積分字段改了，當時直接嚇尿了。

立即中止帳戶操做的全部業務，DBA全量回復0點的數據，再找到binlog的update語句的執行點，重放binlog。檢查數據恢復正常，重啓開始帳戶相關的業務。耗時三個小時。

第二次，所在的公司使用雲服務，數據庫使用RDS。某程序員把跟進記錄表的用戶留言字段所有更改了，致使主從延時報警，銷售人員沒辦法看用戶留言的真實數據。

事情發生後，中止該表的業務，DBA經過雲服務的工具直接恢復到發生問題前1秒的數據，從發現問題到解決問題也就是5分鐘。

以上兩個案例與刪庫跑路相似，都是數據丟失或數據污染以後的解決辦法。可是處理起來，耗時不一樣。關鍵點在備份上！

給個建議！自建機房的方式須要有完備的dba和運維團隊，對技術要求高，中小廠商沒能力自建機房的，雲方案仍是要用起來。另外要關注雲提供廠商提供的全套解決方案，千萬別隻把雲方案當服務器使用。

微盟此次事故，我估計就沒有采用雲數據庫，而是把雲方案當服務器在用。雲方案真正的價值在於容災、快速擴容、緊急救火。這些能力中小公司要創建起來，不是說不可能而是難度極大。業務高速跑起來，壓根沒時間沒資源去弄！

若是微盟用的是雲數據庫，雲數據庫通常都會保留binlog日誌，先全量恢復再重放增量。這個恢復速度很是快，不會須要36小時還沒弄完，產生這麼大損失！

固然微盟也是受害者，說實話中國互聯網發展太快，每每即使很努力也無法在不少方面考慮周全。好的是，有了雲方案讓一些中小公司的確會更高速的發展。看看公告：雲廠商也在積極的幫助微盟作數據恢復！

---

寫在最後的話：

技術人必定是保護用戶數據的最後防線。最近幾年，因爲技術人員無心或者有意形成的事故不可勝數。若是代碼對世界的影響不大，那麼這也許就不成問題。

打個比方，若是你寫了一個危害幾我的的代碼，影響是極爲有限的。可是若是你在擁有幾億用戶的平臺上作一樣的事情，結果必定是慘烈的！

技術人必定要遵照職業道德底線，同時關注IT安全，尤爲是技術管理者。但願咱們一塊兒讓技術世界更安全更精彩！

---

做者簡介：

易洋，治學教育信息科技 CTO&聯合創始人。

前騰訊 QQGAME 高級工程師，前人人網遊戲大廳技術經理，前 360 技術總監，前噠噠技術 VP，現擔任土豆教育 CTO & 聯創。在遊戲領域、直播領域、安全領域都有深厚的積累。帶領過超過 100 人的團隊，有較強的團隊管理能力。同時對產品和運營有必定的操盤能力。