Categories
程式開發

因運維惡意操作,微盟宕機36小時,企業如何加強風險防範能力?


2月25日,微盟發佈公告表示SAAS 業務數據遭到人為破壞。經調查後獲悉公司的 SaaS 業務生產環境和數據遭到集團研發中心運維部一位核心運維員工破壞,導致公司當前暫時無法向客戶提供 SaaS 產品(“SaaS 生產環境和數據破壞”)。

公司已於 2020 年 2 月 24 日向中國上海市寶山區公安局(“寶山區公安局”)報案,目前該員工已經被寶山區公安局進行刑事拘留。本文,InfoQ邀請了騰訊雲最具價值專家、dbaplus 社群聯合發起人楊建榮,給企業提供一些防範風險的建議,希望對從業者有所幫助。

因運維惡意操作,微盟宕機36小時,企業如何加強風險防範能力? 1

以下為楊建榮的回复:

每每看到行業內的數據事故,我們在感慨之餘,更需要的就是自省,因為這可以敲響我們的警鐘。微盟技術團隊從一個創業團隊一路走來,逐步建立了較為成熟的安全管理規範,對服務器和數據訪問權限有著明確的分層和分級的授權管理制度,這次雖然有疏忽,實際上也是受害者。

根據事件跟踪得知,騰訊雲本次從一開始就大力支持微盟,派了很多技術專家,不計成本來幫助微盟和微盟的客戶,使得恢復得以順利開展。但問題是要補救和修復,需要一套流程、制度和技術相輔相成,而且是一個持久改進的過程。米蘭.昆德拉曾經說過:永遠不要以為可以逃避,因為每一步都決定著最後的結局。

從個人理解來看,因為涉及的環境複雜、涉及團隊較多,所以恢復效率和驗證方面需要一些時間。在數據恢復方面,有一條不成文的規定,那就是數據在一定程度上可以丟,但是不能亂。丟的數據,可以通過其他方式進行補救,但是數據一亂就失去了修復基準。因為這次是人為惡意操作,所以恢復的難度會更大。

接下來,我通過流程、技術和製度三方面來分別進行闡述,如何在此類事故中將損失降到最低,希望對企業有所幫助。

1、流程

1.完善故障演練流程,作為一項共同目標來協作完成,做到忙而不亂

很多公司都會對故障演練存在一些疑慮,因為這會帶來一些潛在的隱患,越是不能動,不敢動,在出問題的時候,修復效率越低下,每個人和團隊更加關注自己這一部分的工作,顯然會忽略一些相關環節,所以能夠組織故障演練的流程和規範,把這些梳理和固化下來,在處理問題時才能夠做到忙而不亂。

2.完善故障響應流程,不同等級的問題系統由具體的負責人介入

為什麼很多問題的修復進展不可控?一方面是需要團隊協作;另一方面是臨時去協調和熟悉問題,排查問題的效率是比較低的,可以考慮引入故障的等級分類,及時通知相關團隊,把一些問題的處理作為預先處理的環節提前接入。

3.運維操作需要報備

運維不做無準備的操作,不做加塞操作(比如臨時補充一些未經測試的腳本),重要操作,重大操作都需要報備,及時通告,把被動變為主動。

4.引入審計流程,實現獨立的服務審計機制

審計環節是一個相對重要的獨立環節,可以引入服務審計機制,可以通過獨立的審計服務發現潛在的隱患,及時督正問題。

5…業務異常預警,需要同步相關鏈路層

對於業務層的異常,業務預警尤其關鍵。及時預警並同步到相關鏈路,可以避免系統雪崩的情況。

2、技術

1.完善備份恢復體系,使得恢復能夠可控,高效。比如,基礎備份(全備和增量備份)和熱數據恢復(基於binlog的閃回技術)

備份恢復體系的建設是數據庫建設的基礎,也是衡量服務可用性的最後一根稻草,充分結合全量備份和增量備份,提高恢復效率。

舉例來說,下面是一個全量備份和增量備份方案,實現一次全備,永遠增量的實現策略,然後在這個基礎上實現基於binlog的閃回。

因運維惡意操作,微盟宕機36小時,企業如何加強風險防範能力? 2

2.集群環境的恢復是系統薄弱環節

系統服務之間互相依賴,這是之前很少有人關注的,所以毫無疑問,這是一塊硬骨頭,我們需要重點關注。

3.使用回收站技術,杜絕人為惡意/誤刪除

備份能夠解決一些異常情況下的數據恢復,但是效率相對不高,從規範角度來說,如何避免危險操作,轉而使用更加優雅可控的處理方式是我們需要思考的問題。

Drop操作是默認提交的,而且是不可逆的,在數據庫操作中都是跑路的代名詞,MySQL層面目前沒有相應的Drop操作恢復功能,除非通過備份來恢復,但是我們可以考慮將Drop操作轉換為一種可逆的DDL操作。

MySQL中默認每個表有一個對應的ibd文件,其實可以把Drop操作轉換為一個rename操作,即把文件從testdb遷移到testdb_arch下面;從權限上來說,testdb_arch是業務不可見的,rename操作可以平滑的實現這個刪除功能,如果在一定時間後確認可以清理,則數據清理對於已有的業務流程是不可見的,如下圖所示。

因運維惡意操作,微盟宕機36小時,企業如何加強風險防範能力? 3

此外,還有兩個額外建議,一個是對於大表變更,盡可能考慮低峰時段的在線變更,比如使用pt-osc工具或者是維護時段的變更,這裡就不再贅述了。

4.服務權限設置,需指定客戶端權限

分業務管理主庫和備份庫是互聯網行業的普遍慣例,很多公司普遍都會授予運維較大的權限,這也是導致很多故障發生的潛在隱患。

在這方面我們可以參考如下的一張設計圖(來自張文宇老師),可以在多個環節發力,改進權限問題。

因運維惡意操作,微盟宕機36小時,企業如何加強風險防範能力? 4

3、制度

制度相對來說是比較嚴格、冷面的,我們可以在技術和流程規範之中尋找一些平衡點來輔助作為製度的基石。比如,密碼的安全等級設置,權限管理引入審批制度等,在此就不贅述了。

結束語

最後,希望所有技術從業人員可以遵守職業道德,希望所有企業可以具備風險防範意識,在這類事件中有效降低損失。

作者介紹:

楊建榮,騰訊雲最具價值專家、dbaplus 社群聯合發起人,Oracle ACE,競技世界資深DBA