0
9 月 19 日，微博網友“大佬坊間八卦”爆料，順豐科技數據中心的一位高級工程師鄧某因誤刪生產數據庫，導致某項服務無法使用并持續(xù) 590 分鐘。
隨后，順豐根據公司相關規(guī)定，辭退工程師鄧某，并在順豐內網通報。（公眾號：雷鋒網）
據內部通報，鄧某錯選了 RUSS 數據庫，打算刪除執(zhí)行的 SQL。
在選定刪除時，因其操作不嚴謹，光標回跳到 RUSS 庫的實例，在未看清所選內容的情況下，便通過 delete 執(zhí)行刪除，同時鄧某忽略了彈窗提醒，直接回車，導致 RUSS 生產數據庫被刪掉。
因運維工作人員不嚴謹的操作，導致OMCS運營監(jiān)控系統(tǒng)瞬間崩潰，該系統(tǒng)上臨時車線上發(fā)車功能無法使用并持續(xù)約10個小時。
同比9月5日的929條臨時車需求臨時變更，此次刪庫對生產業(yè)務產生了嚴重的負面影響。
運維工程師發(fā)現誤刪數據庫之后，估計心里想著完蛋了，36計走為上計，直接跑路要緊~
對于這次事件，來自數據安全公司安華金和的研究人員進行了如下原因追溯：
1、不要指望運維人永遠不犯錯
運維工作屬于高壓工種，被網友調侃是拿著如同白菜價的工資卻操著賣白粉的心，心理壓力大不說，為了應對外部攻擊和后端非工作時間運維事件，通宵達旦加班更是家常便飯。
面對身心雙重消耗，工作中稍有不慎犯個錯誤也是情理之中的事情。如果單靠約束運維人員不犯錯誤，只能說是主管領導和企業(yè)的雙重天真。因此，就必須要通過規(guī)范的制度流程和有效的技術手段來防患未然。
2、流程先行，技術手段托底
從上述爆料的內部郵件中可以看出，鄭某在接到變更需求后，“按照操作流程要求”，登陸生產數據庫跳轉機，卻在后續(xù)操作中違反了操作流程，導致刪庫事件發(fā)生，帶來嚴重影響。
外行看熱鬧，內行看門道。追根溯源，刪庫事件之所以發(fā)生，正是因為操作流程的建立并沒有技術手段來托底，此次事件正暴露出權限管理、審批機制的雙重缺失。因此，單有流程，卻沒有有效的技術手段作為“防守底線”，流程就變成了一紙空文，僅供事后追責而已。
要避免刪庫帶來的嚴重影響，簡單粗暴的說，生產數據庫操作前，除了備份，必須人工交叉審核。（公眾號：雷鋒網）
避免此類刪庫跑事件，安全專家給出了兩個解決思路：
一是完善的權限管理，讓運維人員刪不了庫；
二是有效的審批機制，就算非要刪庫，也必須先向上級申請審批。
為此，安全專家在研發(fā)中心環(huán)境下模擬了此次現場，使用本事件內部通報中提到的navicat-mysql 進行操作，然后配合上數據庫安全運維產品DBCtrl的界面，為大家提供兩個解決思路。
1）安全管理員在DBCtrl上創(chuàng)建數據庫安全運維申請人（aq1_sq1執(zhí)行操作的人）和審批人（aq1_sp11審核運維操作的人），并分配對應的數據庫運維操作權限（aq1_db1數據庫組）：
現有流程基礎上增加防守機制，通過數據庫安全運維產品DBCtrl配置對生產庫高危操作的規(guī)則，并設定為“攔截”動作，在Navicat上即使誤操作也會被DBCtrl攔截，防止誤刪數據時間發(fā)生。具體操作步驟如下：
2）DBCtrl添加防護規(guī)則，攔截對生產庫的高危敏感操作：
3）在Navicat上同時打開生產庫和備份庫，本來對備份庫進行操作，光標誤選中了生產庫，執(zhí)行“DROP TABLE DBFWUSERS”敏感表，操作被攔截：
4）同時，具備審計記錄時候追蹤查詢，可以追溯到訪問源以及執(zhí)行的詳情：
通過數據庫安全運維業(yè)務標準化審批流程，規(guī)范操作，對數據庫高危操作通增加人工交叉審核機制，使得流程規(guī)范化。具體操作步驟如下：
1）安全管理員在DBCtrl上創(chuàng)建數據庫安全運維申請人（aq1_sq1執(zhí)行操作的人）和審批人（aq1_sp11審核運維操作的人），并分配對應的數據庫運維操作權限（aq1_db1數據庫組）：
2）申請人需要對數據庫進行操作，需要用自己的賬號登錄DBCtrl，發(fā)起審批流程：
3、申請完的任務自動分配到有權限的審批人，審批人根據提交的操作詳情，人工審核是否批準該操作執(zhí)行：
4.如果審批人認為高危不合規(guī)操作，駁回操作申請，并告知駁回理由，申請人收到審批結果，該操作不會被執(zhí)行：
以上，是運用數據庫安全運維的技術手段進行了場景還原，并通過實際操作驗證了兩個思路的可行性?？偨Y下來，只要針對數據庫安全運維的威脅點，建立相應的操作流程管理制度，讓技術手段參與操作流程，就可以避免刪庫跑路，讓運維人員不再“背鍋”，讓管理者睡個好覺。
雷鋒網 VIA 安華金和
雷峰網原創(chuàng)文章，未經授權禁止轉載。詳情見轉載須知。
