順豐高級工程師跑路被開除后,我們應如何避免誤刪生產數據庫

9 月 19 日,微博網友「大佬坊間八卦」爆料,順豐科技數據中心的一位高級工程師鄧某因誤刪生產數據庫,導致某項服務無法使用並持續 590 分鐘。

隨後,順豐根據公司相關規定,辭退工程師鄧某,並在順豐內網通報。(公眾號:雷鋒網)

錯選 RUSS 數據庫

據內部通報,鄧某錯選了 RUSS 數據庫,打算刪除執行的 SQL。

在選定刪除時,因其操作不嚴謹,光標回跳到 RUSS 庫的實例,在未看清所選內容的情況下,便通過 delete 執行刪除,同時鄧某忽略了彈窗提醒,直接回車,導致 RUSS 生產數據庫被刪掉。

因運維工作人員不嚴謹的操作,導致OMCS運營監控系統瞬間崩潰,該系統上臨時車線上發車功能無法使用並持續約10個小時。

同比9月5日的929條臨時車需求臨時變更,此次刪庫對生產業務產生了嚴重的負面影響。

運維工程師發現誤刪數據庫之後,估計心裡想着完蛋了,36計走為上計,直接跑路要緊~

原因分析

對於這次事件,來自數據安全公司安華金和的研究人員進行了如下原因追溯:

1、不要指望運維人永遠不犯錯

運維工作屬於高壓工種,被網友調侃是拿着如同白菜價的工資卻操着賣白粉的心,心理壓力大不說,為了應對外部攻擊和後端非工作時間運維事件,通宵達旦加班更是家常便飯。

面對身心雙重消耗,工作中稍有不慎犯個錯誤也是情理之中的事情。如果單靠約束運維人員不犯錯誤,只能說是主管領導和企業的雙重天真。因此,就必須要通過規範的制度流程和有效的技術手段來防患未然。

2、流程先行,技術手段托底

從上述爆料的內部郵件中可以看出,鄭某在接到變更需求后,「按照操作流程要求」,登陸生產數據庫跳轉機,卻在後續操作中違反了操作流程,導致刪庫事件發生,帶來嚴重影響。

外行看熱鬧,內行看門道。追根溯源,刪庫事件之所以發生,正是因為操作流程的建立並沒有技術手段來托底,此次事件正暴露出權限管理、審批機制的雙重缺失。因此,單有流程,卻沒有有效的技術手段作為「防守底線」,流程就變成了一紙空文,僅供事後追責而已。

要避免刪庫帶來的嚴重影響,簡單粗暴的說,生產數據庫操作前,除了備份,必須人工交叉審核。(公眾號:雷鋒網)

解決思路

避免此類刪庫跑事件,安全專家給出了兩個解決思路:

一是完善的權限管理,讓運維人員刪不了庫;

二是有效的審批機制,就算非要刪庫,也必須先向上級申請審批。

為此,安全專家在研發中心環境下模擬了此次現場,使用本事件內部通報中提到的navicat-mysql 進行操作,然後配合上數據庫安全運維產品DBCtrl的界面,為大家提供兩個解決思路。

完善的權限管理

1)安全管理員在DBCtrl上創建數據庫安全運維申請人(aq1_sq1執行操作的人)和審批人(aq1_sp11審核運維操作的人),並分配對應的數據庫運維操作權限(aq1_db1數據庫組):

現有流程基礎上增加防守機制,通過數據庫安全運維產品DBCtrl配置對生產庫高危操作的規則,並設定為「攔截」動作,在Navicat上即使誤操作也會被DBCtrl攔截,防止誤刪數據時間發生。具體操作步驟如下:

2)DBCtrl添加防護規則,攔截對生產庫的高危敏感操作:

3)在Navicat上同時打開生產庫和備份庫,本來對備份庫進行操作,光標誤選中了生產庫,執行「DROP TABLE DBFWUSERS」敏感表,操作被攔截:

4)同時,具備審計記錄時候追蹤查詢,可以追溯到訪問源以及執行的詳情:

有效的審批機制

通過數據庫安全運維業務標準化審批流程,規範操作,對數據庫高危操作通增加人工交叉審核機制,使得流程規範化。具體操作步驟如下:

1)安全管理員在DBCtrl上創建數據庫安全運維申請人(aq1_sq1執行操作的人)和審批人(aq1_sp11審核運維操作的人),並分配對應的數據庫運維操作權限(aq1_db1數據庫組):

2)申請人需要對數據庫進行操作,需要用自己的賬號登錄DBCtrl,發起審批流程:

3、申請完的任務自動分配到有權限的審批人,審批人根據提交的操作詳情,人工審核是否批准該操作執行:

4.如果審批人認為高危不合規操作,駁回操作申請,並告知駁回理由,申請人收到審批結果,該操作不會被執行:


以上,是運用數據庫安全運維的技術手段進行了場景還原,並通過實際操作驗證了兩個思路的可行性。總結下來,只要針對數據庫安全運維的威脅點,建立相應的操作流程管理制度,讓技術手段參與操作流程,就可以避免刪庫跑路,讓運維人員不再「背鍋」,讓管理者睡個好覺。

雷鋒網 VIA 安華金和


想在手機閱讀更多社交網絡資訊?下載【香港矽谷】Android應用
分享到Facebook
技術平台: Nasthon Systems