從微盟刪庫,談談身邊'刪庫跑路'的大神

今天互聯網圈子最火的一件事就是‘微盟被惡意刪庫’...

微盟公告

當然，該類事件在圈子內屢見不鮮， 只是36小時恢復期比較長了...

運維人員惡意刪除核心數據這種操作確實是有可能發生，但是在正常情況下又不應該發生。當然由於管理的不規範、權限的控制等問題依然可能造成某些人員惡意或非惡意的製造出‘ 刪庫跑路’事件。

下面盤點一下在我身邊發生過的‘刪庫跑路’事件：

核心研發 應用服務器 4小時恢復

工作以來第一次接觸的‘刪庫跑路’事件，當時公司的權限設置還是比較好的。除了部門leader其他任何人 無生產環境的直接操作權限。日誌只能通過一個日誌服務來進行查看。所以正常情況下開發人員是無法接觸到生產服務器的。
某一天生產環境出現異常，但是在測試環境還真的沒有復現，加班到深夜跟leader討論是不是可以進入生產服務器去看一下？然後leader就給開啓了權限並且在旁邊盯着。
排查了半個小時沒有什麼進度，leader就轉身去弄自己的東西了。
研發又研究了大概十幾分鍾，突然跟leader說:
‘X哥，你看這是咋啦？’
leader回頭看了一眼發現一切都已經空了...一臉黑線的問： 你幹啥了!!!
回答: rm -rf /*   可能也是羣裏的大佬教的

當天晚上兩個人都沒回家，當時還沒有客戶使用，並且還是晚上。所以影響不大，四個小時恢復。

核心研發 刪除數據庫 3小時恢復

後來又發生一次刪庫事件，確實是刪庫，不存在爭議！
研發收到leader的通知要刪庫某個數據庫，相關數據已經遷移至其他平臺存儲。所以數據庫要進行物理刪除。
刪除的數據庫名稱爲 X_DATA，但是該研發其實本身沒有該庫的權限。他的權限列表裏可見的只有XX_DATA。
收到命令後一直很糾結，很奇怪爲啥要刪了。但是還是忠實的執行了命令 刪除XX_DATA庫。

業務模塊直接癱瘓...
不過很厲害的是,由於該研發不知道爲啥要刪除這個數據庫。覺得可能有需要就把數據進行了本地備份 他的硬盤是夠大的
馬上從本地恢復數據，由於網絡原因，三小時回覆。

運維人員 禁用雲密鑰  4小時恢復

事情僅發生在幾天前。週末，在家悠哉悠哉的看電視，玩遊戲。
突然收到服務器告警，負載飈高。趕緊進入服務器進行查看。 這點小權限還是有的

發現有個服務的資源佔用非常高，而這個服務是往阿里雲數據通道寫入數據的。排查日誌發現數據一直寫入失敗重試，當時已經重試了幾千次，四個小時沒有數據寫入成功。 
之前由於其他原因直接把重試次數修改爲了無限次，並且已經穩定運行了半年多，沒有任何的修改與操作，所以當出現問題時馬上進入阿里雲。沒看到有變更的公告，去企業相關羣詢問了一下。
阿里雲的人還沒有回覆，運維私聊我了:訪問密鑰(AK/SK)我禁用了，核心就這麼一句話。
我當時就瘋了，當時就想過去抽他。但是還是先恢復業務再說。

別說爲啥禁用，先給我開啓了再說。
幾分鐘後，取消禁用，數據正常寫入！由於使用了MQ，所以數據無丟失。影響較小。無實時計算內容，指標無異常。
排查其他使用該訪問密鑰的服務均受到不同程度影響!

more...

---

整體上來說，無論是在什麼樣的企業都會存在惡意或非惡意的刪庫事件。都是由於我們對於權限的控制與規則的控制沒有做好。
之前經歷過較爲嚴格的生產環境控制，研發人員對於 生產環境無權操作。日誌只能通過採集到日誌系統中進行展現。修改數據？提交SQL，審覈，執行。工作到最後，我好像都不知道生產環境有沒有公網，因爲一切都是內網host..

大數據環境下還經歷過提交了Job之後,等Job執行完成後你才能拿到一份壓縮好的日誌。而執行時的數據都是通過文檔進行解釋，無法看到原始存儲。甚至存儲位置..每天執行一次，執行完成去ftp上下載執行日誌。痛苦！

其實在生產環境切換到root還是很擔心的，問一下自己:

• 你有root權限你怕嗎？
• 你的SQL條件準確嗎?
• 你的敏感命令可以執行嗎？
• rm -rf /* 瞭解一下...
  
  

  看到了？不錯，說的就是你...!

本文分享自微信公衆號 - 指尖數蟲（zhijianshuchong）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。