刪庫跑路技術白皮書

寫技術白皮書的目的是：

①培養大家從行業角度做宏觀綜述的能力；

②保證團隊技術的可傳承性，一份份白皮書仿若一本本九陽真經，至少有個覆盤的本本留下來。

好，下面就開始這份（防）刪庫跑路技術白皮書。

1 概述

刪庫跑路是一種歷史悠久、後果嚴重的公司資產損壞事故，一旦發生，輕則業務短時間不可用，重則公司倒閉關門，甚至有人爲此坐牢。

圖1 從刪庫到跑路
對於這種重大經營性風險，經歷過掛牌上市的公司都有方法機制預防和應對。生產環境安全保障的流程制度是否健全，也是審計機構重點核查的對象。與其審計機構進場的時候臨時抱佛腳，不如你仔細閱讀本文，未雨綢繆，把該做的工具做好，把該建的流程規範建好。

1.1 微盟刪庫後被刑拘

最近一次也是最爲人所知的是香港上市公司微盟集團刪庫。在這次運維工程師“含恨”出手連根擦除、應用服務中斷整整九天的事件裏，微盟被刪除的數據體量達到了數百TB。隨後這位賀姓員工被上海市寶山區公安局刑事拘留。

有詩爲證：一鍵驚神刪主備，SaaS憑空起風雷。身負重責莫自棄，我心光明道不移。 

恢復小隊通過審計日誌可以看出，2020年2月23日19時許，微盟的賀姓運維工程師刪除了微盟業務數據，甚至下了死手刪除了備份數據文件。微盟被刪的數據分爲兩部分，一部分是存放在自建數據庫裏的現網業務數據，部署在數據庫服務器上；一部分是存放在備份服務器上的備份數據。因爲是文件刪除操作，兩種服務器裏的文件都是碎片化記憶，且不可見。二者區別在於，數據庫服務器中的殘存文件數量多，類型繁雜；而備份服務器文件類型單一，數據集中。
經過相對常規的操作，2月17日及以前的所有數據都找回來了。2月28日，微盟拿到2月17日的備份數據後，恢復所有業務線上生產環節，老用戶可登錄後臺，微站產品所有數據重新上線。但這還不夠，騰訊雲技術團隊和數據恢復公司還需要通過打撈小文件拼接大文件的方式繼續恢復後續的數據。

圖2 前線工程師在做拷貝數據

每一次拼接，都要數據從頭到尾掃描一遍，匹配是否成功。爲了加快掃描和驗證，需要強大的計算力，騰訊雲臨時調用騰訊上海機房 100 臺服務器做支持。如果能順利推進，整個過程可無障礙執行，一旦出現問題，就要推翻重來，一次需要 12 小時。經歷了無數次“打撈、掃描、拼接、驗證”後，終於，最大的一個核心數據文件在2月28日晚上找回來了，它由 7 個碎片組成。
3月1日晚，微盟發佈公告說，由於此次數據量規模非常大，爲了保證數據一致性和線上體驗，3月2日凌晨2點進行系統上線演練，3月3日上午9點數據恢復正式上線。同時發佈了1.5 億元的商家賠付計劃。
這份公告對這次事件也進行了反思：“沒有嚴格按照公司的內控管理制度，對運維人員的權限進行分級和分區管理。”這次事件中的最大問題在於，權限管理過於簡化，沒有嚴格劃分業務場景並且梳理最低的操作權限需求，導致了超級管理員的出現，而恰巧超級管理員出現了不軌意圖，給企業造成了重大損失。
“你讓我評價這件事，我第一感受是不要再發生這種事情了，企業的IT治理一定要把安全放在第一位。”恢復數據作戰總指揮徐勇州說，“微盟是幸運的，能100%找回數據是奇蹟，但如果再發生一次，未必有這麼幸運了。” 

依據《刑法》第 286 條（對計算機信息系統功能進行刪除、修改、增加、干擾，造成計算機信息系統不能正常運行，後果嚴重的，構成“破壞計算機信息系統罪”）以及相關司法解釋，“刪庫跑路”如果造成 10 臺以上計算機系統不能正常運行就可以判刑，如果影響 50 臺以上則至少判 5 年。即“刪庫跑路”的量刑標準與影響到的計算機系統數量有關。毫無疑問，以微盟的體量，賀姓員工量刑至少五年起。

微盟如此慘痛的教訓，喚起了我們更多的記憶。

1.2 順豐刪庫後被辭退

2018年9月，順豐科技運維高級工程師鄧某在接到變更需求後，按照操作流程要求，登陸生產環境跳板機，在選定刪除時，光標回跳到 RUSS 庫的實例，在未看清所選內容的情況下，便通過 delete 執行刪除，同時鄧某忽略了彈窗提醒，直接回車，導致 RUSS 生產數據庫被刪掉。因爲運維工程師一個不嚴謹的操作，導致 OMCS運營監控系統瞬間崩潰，他的結局是被辭退。

圖3 順豐內部通報郵件

1.3 刪索引也會判刑

邱某2014年入職到杭州的一家科技公司，擔任技術總監。因老闆逼其離職，2018年6月23日就在自己家裏面遠程登上了公司在阿里雲的數據庫，當然爲了不過早暴露，他選擇刪除了數據庫上的一些關鍵索引和部分表格，但最終仍造成公司經濟損失。因邱某自願認罪並賠償了公司8萬元，杭州市餘杭區人民法院酌情予以從輕處罰，並對被告人邱某判處有期徒刑二年六個月，緩刑三年。

1.4 廣西移動用戶數據被誤格式化

2017年9月，某企業技術工程師幫助廣西移動進行擴容割接（即增加系統容量）時，不小心將 HSS 設備裏面的用戶數據格式化刪除，導致廣西移動近 80 萬用戶數據丟失。

1.5 Verelox被已離職員工刪庫

2017年6月10日，Verelox（一家提供VPS、服務器出租和託管的雲主機服務商）貼出公告：不幸的是，一名前任管理員刪光了所有的客戶數據，並且擦除了大多數服務器上面的內容。正因爲如此，我們已採取了必要的步驟或措施，暫時將我們的網絡下線。我們一直在努力恢復數據，但是這個方法可能恢復不了已丟失的所有數據。

1.6 Digital Ocean刪庫後人還在

2017年4月5日，位於紐約的雲服務商Digital Ocean 也遭遇了系統刪庫：由於配置錯誤，本應指向測試環境的任務被指向了生產環境，測試任務包含的環境初始化過程刪除了主生產數據庫，由此開啓了一次長達4小時56分鐘的停機事故。

1.7 gitlab刪庫後人還好

2017 年 2 月，gitlab 的一位荷蘭籍DBA 在深夜給線上數據庫做負載均衡工作時，遭受了 DDoS 攻擊。在阻止了攻擊之後，又發現了數據庫不同步的問題，於是開始修復。在修復的過程中，他發現 db2.staging都 hang 在那裏，無法同步，於是他想把db2.staging 的數據庫刪除了，這樣從新啓動一個新的複製，結果，刪除數據庫的命令錯誤地敲在了生產環境上（db1.cluster）：

sudo rm -rf

這是一個包含了 300 GB 實時生產數據的文件夾，等到他徹底清醒過來急忙按下 CTRL+C，只剩下 4.5GB 數據……由於沒有有效的備份，嘗試了所有5個恢復工具都沒有完成恢復，gitlab 被迫下線。

圖4 gitlab官方推特發通告

一樁樁一件件，觸目驚心，我們不能等到事件發生之後，再來悔恨，再四處求助恢復數據。

2 風險綜述

除了刪庫跑路之外，我們其實還會遇到其他高風險以至於雞飛蛋打。

2.1 機房故障災難

常見的是雲數據庫 RDS 實例故障，比如我們曾經在就餐午高峯遭遇突發的主數據庫 CPU 100%，誰也連不進去，整整 45 分鐘。我們還曾遇到過阿里雲單機房網絡不可用，完全連不進去，整整三個小時。這時候如果企業有多活機房，則可通過其他機房的數據進行恢復。如果只有單機房，只能根據異地備份文件來恢復。

2.2 底層存儲災難

底層存儲並不一定總能訪問到，如果你要恢復數據，最好有一份異地備份文件。2018年6月27日下午，阿里雲工程師團隊在上線一個自動化運維新功能中，執行了一項變更驗證操作，觸發了一個未知代碼bug，從而禁用了部分內部IP，導致全國大量客戶投訴雲存儲 OSS 產品無法訪問，也就是數據不可見了。

2.3 實例誤釋放災難

雲數據庫實例一旦被誤釋放，數據和備份會都被刪除，那將是塌天大禍。這時候如果有多活機房，則可通過其他機房的數據進行恢復。如果只有單機房，只能根據異地備份文件來恢復。

2.4 程序誤刪誤覆蓋災難

BUG 上線產生了大量髒數據，或刪錯了很多數據，可通過“數據備份”和“日誌備份”功能恢復到指定時間點。如果只是少量數據錯誤，可通過回滾 Binlog 日誌文件進行修復。很多年前，我們就曾經在頭一天晚上發佈了一個版本，到了第二天上午八九點收到了洪水一樣的投訴，這才發現大錯已經釀成，追悔莫及。當時還只有單機房，只有凌晨的常規數據庫備份，足足花了一天時間纔將數據悉數糾正。

2.5 訂正數據災難

同上，我們對訂正線上數據也非常謹慎，尤其是當一個新業務剛上線不久，管理後臺功能尚未完善之際，運營人員經常會找研發刷庫，而且通常會很急。急急忙忙編寫刷庫腳本的，與經過開發、聯調、測試、上線完整流程的，就是不一樣。不是不可以刷庫。但請記住，經常刷庫就一定要做成系統功能，常在河邊走，難免會溼鞋，出了事兒就是大事兒。 既然會遇到如此多災難，那麼我們應該如何防患於未然呢？

3 業界綜述

防範刪庫跑路，本質上還是一個數據庫安全的問題。對於這個問題，業界早有定論。蓋國強曾經撰寫過一本書：《數據安全警示錄》，提出了數據安全的五個緯度，可以基於這五個緯度來梳理企業的數據安全，並據此建立相應的安全防護措施。這五個緯度分別是：軟件安全、備份安全、訪問安全、防護安全、管理安全，它們可能會導致兩種性質的安全問題：一）內部威脅：由於內部管理不善而導致的數據安全問題；二）外部威脅：由於外部惡意攻擊入侵所帶來的安全問題。通常我們把安全問題狹義化爲後者，這實際上是片面的，在數據安全問題上，前者造成的數據損失、數據損毀，其發生概率和影響度都遠遠超過後者。

圖5 內外部兩種威脅

3.1 數據安全五大方面和十六條建議

下面對數據安全的五大方面做一個簡要分析：

一）軟件安全：指的是我們選擇的數據庫產品、版本是否穩定安全，廠商所能提供的補丁集和BUG修正是否及時，基礎硬件與操作系統是否經過認證。很多用戶在部署數據庫軟件時，僅僅選擇了最容易獲得的初始發佈版本，遺漏了可能已經存在的補丁修正，並且在運行維護中並不能夠及時跟蹤軟件更新，也無法獲得BUG信息、補丁修正和安全告警，這就使得軟件本身的很多風險隱患得不到修正。如果軟件安全無法保證，數據庫安全的基礎也就喪失了。 

 

二）備份安全：指用戶數據能否得到及時有效的備份保全，能否在故障災難之後獲得及時的恢復和挽救。在數據庫運行期，最爲重要的就是備份安全，如果沒有可靠的備份，將數據集中起來就只能是等待數據災難，所以我們將備份安全提升到核心地位，備份以及隨之衍生的容災安全等，都是企業整體數據架構應該考慮的因素。很多企業在數據災難之後因爲缺乏有效備份而一蹶不振。根據 Gartner 早年間一份調查報告顯示，在經歷了數據完全丟失而導致系統停運的企業中，有五分之二再也沒能恢復運營，餘下的企業也有三分之一在兩年內宣告破產。由此可見，由於備份安全問題導致的企業傷害可能遠遠大於黑客攻擊。 

 

三）訪問安全：指用戶數據庫的訪問來源和訪問方式是否安全可控。通常數據庫系統處於IT系統的核心，其安全架構涉及主機、系統、存儲、網絡等諸多方面，如果沒有明確的訪問控制，缺乏足夠的訪問分析與管理，那麼數據庫的安全將是混亂和無法控制的。在應用軟件使用和訪問數據庫時，要正確設置權限，控制可靠的訪問來源，保證數據庫的訪問安全，唯有保證訪問安全才能夠確保數據不被越權使用、不被誤操作所損害，通常最基本的訪問安全要實現程序控制、網絡隔離、來源約束等。 

 

四）安全防範：指通過主動的安全手段對數據庫通訊、傳輸等進行增強、監控、防護、屏蔽或阻斷，諸如數據加密、審計、數據防火牆等技術都在這一範疇之內。我們必須認識到，在IT技術高度發展的今天，風險是無處不在、層出不窮的，可能我們從未思考過的安全問題，每天都在不斷湧現，所以在數據庫環境中採取主動式防護，可以幫助我們監控分析和屏蔽很多未知風險。 

 

五）管理安全：指在企業數據的日常管理維護範疇內，能否充分保證數據安全以及服務的高可用連續提供。諸如DBA的維護、文件的管理、參數或數據結構的變更等等都可能引入數據風險，管理安全要求我們通過規範、制度以及技術手段去確保維護管理安全。另外，基於硬件、電力等基礎平臺的故障都可能影響數據庫服務的高可用性，在管理中要通過監控手段及時預警，通過集羣、備庫等切換與服務分擔保障服務的連續性。 

 

基於以上分析，蓋國強進一步提出了 16 條建議：

 

<1>備份重於一切：DBA四大守則的第一條就指出，『備份重於一切』。有了有效的備份，即使遭遇災難，也可以從容應對。唯一會讓DBA們從夢中驚醒的就是：沒有備份！所以對於數據庫運維來說，第一重要的是做好備份！有備方能無患！ 

 

<2>嚴格管控權限：過度授權爲數據庫埋下安全隱患，所以在向用戶授權時一定要遵循最小權限授予原則，避免因爲過度授權而帶來的安全風險。微盟這次安全風險，如果用戶只具備最低權限，那麼也不會遭遇如此災難。 

 

<3>明確用戶職責：應當明確不同的數據庫用戶的工作範圍，應當使用普通用戶身份的，就絕對不應該使用DBA的用戶身份。只有職權相稱，才能夠避免錯誤，降低風險。即便是擁有管理員職責的用戶，也應當遵循以不同身份執行不同任務的習慣，比如SYS和SYSTEM用戶的使用就應當進行區分和界定。 

 

<4>密碼策略強化：毫無疑問，數據庫用戶應當使用強化的密碼規則，確保弱口令帶來的安全風險，很多數據泄露問題來自弱口令攻擊和提權。 

 

<5>限制登錄工具：明確限制不同工具的使用場景，明確規定工具的準確來源，或者通過堡壘機等來限制數據庫訪問。對於工具也可以做出明確規則和限制，如限制僅能通過SQL Developer訪問生產，PL/SQL Developer工具僅能訪問測試環境，以減少安全風險甚至誤操作風險。 

 

<6>禁止遠程DDL：可以限制DDL操作僅能在數據庫服務器本地進行，禁止遠程連接執行DDL操作，這一手段在很多（未上公有云的）公司被嚴格執行。 

 

<7>使用綁定變量：在開發過程中，嚴格使用綁定變量，綁定變量可以防範SQL注入攻擊，減少數據庫安全風險。這次安全事故，很多用戶開始猜測是SQL注入，走了很多分析上的彎路。 

 

<8>監控監聽日誌：監聽日誌記錄了數據庫訪問的來源、程序等信息，包括惡意掃描，密碼嘗試等，一定要重視監聽日誌的作用，並對其進行分析和監控，以清楚地繪製數據庫訪問圖譜。 

 

<9>數據網絡隔離：數據庫的網絡環境應該一直隱藏在最後端，避免將數據庫置於直接的訪問連接之下，由此可以減少數據庫的訪問風險。 

 

<10>測試和生產環境隔離：環境互通就意味着同時可以訪問，也就可能帶來很多意想不到的安全風險。企業應當將測試環境和生產環境部署於不可互通，或者不可同時訪問的網絡環境中，避免因爲錯誤連接而發生的數據庫災難。分離部署一方面可以降低誤操作的可能性，也可以屏蔽一些無關的訪問可能，從而從網絡鏈路上保證數據安全。 

 

<11>密碼差異設置：有些測試環境或者非產品環境是利用產品環境恢復得到的，DBA在建立了測試環境後，就沒有修改數據庫用戶的登錄密碼；經常性的，DBA也習慣在所有環境中設置通用的密碼；這些習慣爲系統帶來了很多風險和不確定性。特別建議用戶在不同環境中採用不同的密碼設置，這是因爲一方面產品環境和測試環境面對的訪問用戶不同，密碼設置相同則意味着產品環境的安全性完全得不到保障；另一方面，DBA登錄到不同的數據庫需要使用不同的密碼，這進一步減低了DBA在錯誤的環境下執行命令的可能性。 

 

<12>重要數據加密：很多重要的數據，需要加密存儲，最典型的就是用戶和密碼信息，大量的泄密事件本質上是因爲缺乏最基本的加密防範，對重要數據實施一定的安全防護加密，是應當予以適時考慮的安全方面之一。 

 

<13>適時的軟件升級：這裏的軟件指數據庫軟件。 

 

<14>防範內部風險：不可否認，絕大部分安全問題都來自於企業內部，來自最緊密、最輕易的接觸和訪問。企業的人員變動，崗位變更，都可能導致數據安全問題的出現，單純依靠對管理員的信任不足以保障數據安全，必須通過規章、制度與規範的約束才能夠規避安全風險。很多企業爲了便利而捨棄規範、規章或者安全限制是得不償失的做法。安全防範應當從內部做起，從限制約束自我做起，當最緊密相關的訪問都遵從守則，那麼系統的安全性就能夠獲得大幅度的提升。

 

<15>樹立安全意識：安全問題最大的敵人是僥倖，很多企業認爲安全問題概率極低，不會落到自己的環境中，所以對於安全不做必要的投入，造成了安全疏忽。所以安全問題最大的敵人是我們自己，安全需要一點一滴的加強，逐步完善。 

 

<16>開始安全審計：雲數據庫可能已經提供了一些安全防範的手段和方法。特別建議企業適當展開安全防範措施，開啓部分任務審計，定期分析數據庫風險，由此逐步完善數據庫安全。

 

3.2 防患於未然的六大法寶

而經歷了此次劫難完整過程的騰訊雲團隊，則給出了六條建議，相比較於事後搶救性恢復，如何避免這樣的災難再次發生，是更爲重要的，只要把握住如下六大法寶，就可以防患於未然。

一）建設數據庫災備系統：數據庫災備系統是基於數據庫層的技術和架構來實現對數據的保護，確保在諸如機房故障、地震、火災等不可抗因素下數據的安全。兩地三中心、三地四中心這類叫法其實就是指數據庫異地多中心的災備系統。建立災備系統的好處顯而易見，在業務環境發生安全故障（自然災備、機房故障、人爲誤刪）的時候，我們可以第一時間切換到異地的災備數據庫恢復數據和業務訪問。一套健全的災備系統可以使最佳復原時間目標（RTO）降低到秒級。目前主流雲廠商數據庫產品都有配套的災備產品解決方案，如下圖所示。

圖7 公有云提供的異地數據庫災備方案 

 

二）有效的備份：微盟這個時候如果沒有數據庫備份，或者備份沒有驗證過導致備份文件不可用，就失去了最後一根救命稻草，只能選擇走操作系統級別的磁盤文件恢復。即使僥倖能恢復，耗時也會非常之久，導致相當長的業務停機時間。需要注意的是，備份不是簡單的工具應用，而是系統化的備份策略。全量備份、增量備份、日誌備份的策略搭配、備份異地存儲、備份有效性驗證都必須考慮到位，把備份當做一個系統工程去建設，而不只是簡單的備份工具運營。 

 

三）訪問控制策略：對於絕大多數中小型公司來說，一個運維或DBA就能管整個系統，並且擁有整個系統所有主機的最大權限，比如 root。這種集權式的管理就存在“刪庫跑路”的風險。在運維體系的建議中，我們需要規避這種不受到權限制約的超級用戶。建議方案是建立多權分立的權限體系。以三權分立的體系爲例，將傳統數據庫系統 DBA的角色分解爲三個相互獨立的角色，分別是安全管理員，審計管理員，數據管理員。基於此基礎提出的安全策略，主要細分爲三個部分，分別爲數據加密、數據脫敏訪問、強制訪問控制，三者組合提供多個層級的數據安全保障能力。安全管理員、審計管理員、數據管理員這三個角色之間相互制約，消除出系統中的超級權限，從系統角色設計上解決了數據安全問題。

圖8 三權分立權限分解圖 

 

四）數據存儲加密：數據加密是將數據庫中的數據通過身份認證、密鑰+密碼、密鑰管理等進行數據保護的技術，是防止數據庫的數據信息篡改和泄露的有效手段，通過數據信息加密能夠確保數據用戶信息的安全，即使數據被非法導出、備份文件被竊取，也無法恢復和訪問丟失的數據。 對於一些重要的機密數據，如一些金融數據、賬號密碼、商業祕密等，都必須存儲在數據庫中，需要防止對它們的未授權訪問，哪怕是整個系統都被破壞了，加密仍可以保護數據的安全。對數據庫安全性的威脅有時來自於網絡內部，一些內部用戶可能非法獲取用戶名和密碼，或利用其他方法越權使用數據庫，甚至可以直接打開數據庫文件來竊取或篡改信息。 數據加密方式有兩種：1）業務敏感數據加密：調用加密函數，將加密後的結果寫入數據庫，正常讀取的也是加密後的數據，在應用裏面執行解密。當然，敏感數據加解密涉及到一定的應用程序改造成本，需要決策層權衡下。2）數據庫內置加密功能：比如MySQL5.7版本推出的數據庫內置的TDE 透明數據加密，可對數據庫的表空間文件進行加密。現在主流雲廠商的數據庫產品都有自己的加密功能，可以做到更加細粒度的加密。 

 

五）數據庫審計能力：數據庫審計能夠實時記錄數據庫活動，對數據庫操作進行細粒度審計的合規性管理，對數據庫遭受到的風險行爲進行告警，如黑客對數據庫 SQL 注入攻擊、異常操作等。因此，提高數據庫的安全級別，還需要數據庫審計技術支撐。審計主要有如下幾種：1）語句審計2）（數據庫）對象審計3）（數據庫）用戶審計4）細粒度審計，FGA（Fine-Grained Audit） 另外，數據庫審計技術還用於監視並記錄對數據庫服務器的各類操作行爲，通過對網絡數據的分析，實時、智能地解析對數據庫服務器的各種操作，並記入審計數據庫中以便日後進行查詢、分析、過濾，實現對目標數據庫系統用戶操作的監控和審計。數據庫審計技術可以監控和審計用戶對數據庫中的數據庫表、視圖、序列、包、存儲過程、函數、庫、索引、同義詞、快照、觸發器等的創建、修改和刪除等，分析的內容可以精確到SQL操作語句一級。還可以根據設置的規則，智能判斷出違規操作數據庫的行爲，並對違規行爲進行記錄和報警。 

 

六）強調安全規範：這一點其實並不是數據庫功能系統層面的安全，而是管控制度層面的安全建設。

1）嚴格管控權限，明確用戶職責。遵循最小權限授予原則，避免因爲過度授權而帶來的安全風險。明確不同的數據庫用戶能夠用於的工作範圍，防範和隔離風險。比如：數據庫應用賬號只賦予SELECT、UPDATE、INSERT權限，取消DELETE權限。把需要DELETE權限的邏輯改成用UPDATE實現，避免被物理刪除。 

2）密碼策略強化。防範弱口令帶來的安全風險，定期更換密碼，同時生產和測試環境嚴格使用不同的密碼策略。 

3）移除匿名賬戶和廢棄的賬戶，比如經典的：mysql> use mysql;mysql> DELETE FROM userWHERE user="";mysql> flush privileges; 

4）制訂規範並貫徹執行，良好的規範是減少故障的基礎，全面的規範提升開發和運維人員的標準化。 

5）防範內部風險，絕大部分安全問題都來自於企業內部，通過規章、制度與技術手段規避安全風險。比如建立三權分立權限體系。 

6）樹立安全意識，安全問題最大的敵人是僥倖，制定安全方案，定期分析數據庫風險，逐步完善數據庫安全。 

7）及時打好安全補丁，務必保持數據庫爲最新版本。因爲攻擊者可以利用上一個版本的已知漏洞來訪問企業的數據庫。 

 

騰訊雲數據庫團隊語重心長地告誡我們，微盟刪庫事故的發生對其他企業的數據安全保護敲響了警鐘，僅僅依靠單點防護難以達到真正的安全防護效果，而構建基於全生命週期的安全防護成爲必然選擇。 

4 我們的做法

前文講述了很多風險來源和安全規範，那麼接下來分享一下我們保障數據庫安全的常規操作。

4.1 訪問安全類型的預防機制

首先，我們通過自研平臺 IDCenter、SimpleWay 配搭 LDAP 服務完成了帳號管理。這樣工程師在離職的時候，相關VPN帳號、堡壘機帳號、阿里雲帳號均會被刪除，再也無法登錄生產環境。登錄線上堡壘機也都有IP 白名單的限制，只允許公司 IP 訪問。

其次，我們依託 JumpServer 來阻斷危險操作。JumpServer 是一款由 Python + Django 開發的開源跳板機系統，能夠爲企業提供認證、授權、審計、自動化運維等基本功能。工程師登錄 JumpServer 後，我們在內部屏蔽了一些高危命令，只要有人執行，系統就會強制阻斷，而且系統對任何操作都會有審計和歷史記錄。

最後，開發工程師對線上的服務只有讀的權限，沒有操作權限。 

4.2 安全防範類型的預防機制

首先，與支付交易相關的商業應用需要做到數據脫敏存取。即有可能被開放訪問的用戶和客戶的敏感信息，如手機號，身份證號，銀行卡號，密鑰，在數據庫存儲和讀取的時候會採用 AES-128 對稱加解密，降低萬一被拖庫後的商業風險。 

4.3 備份安全類型的預防機制

我們採用了混合雲部署方式，橫跨 8 個機房，既有公有云提供的雲數據庫，也有自行搭建的數據庫集羣，它們都有相應的備份機制。更進一步的是，我們通常採用異地雙活機制，同時還會將數據同步到數據湖裏，所以相當於數據做了三地實時備份。如下圖所示，環境中有四個機房：主機房，從機房，數據機房，應急機房。

圖9 交易系統網絡拓撲圖 

如上圖所示，餐飲門店的客戶通過智能設備發起點餐或收單請求，第一次請求將默認訪問基礎域名，而基礎域名指向主機房，所以請求將進入主機房。主機房會判定客戶真正的業務歸屬機房以及對應的分片，將對應的動態域名下發給智能設備。智能設備以後的請求都將訪問動態域名，請求會直接進入對應的機房以及分片。客戶的業務歸屬機房和分片，可以通過控制檯動態調整。調整後，可以快速通知到智能設備，從而做到秒級切換客戶流量。主機房與從機房的多活數據（包括數據庫數據和緩存數據）保持實時雙向同步。主機房和從機房的業務數據變化都會分發到數據機房（即數據湖），所有大數據計算都在數據機房完成。就這樣，我們天然地做到了數據多地實時備份。 

4.4 管理安全類型的預防機制

我們有工具和流程雙重保障。這其中的工具，指的是數據庫自動化運維平臺（內部代號iDB），這也是一些大型互聯網公司所重點關注的IT基礎設施之一。它可以做到兩點：第一，確保生產環境的變更操作，有審覈記錄，有操作記錄，能回滾，第二，用戶崗位職責與系統用戶權限相符合，責權利對稱。

圖10 iDB（數據庫自動化運維平臺）在IDCenter上的入口 

數據存儲安全保障，首先是工具的預防機制。

• 帳號權限控制：業務工程操作數據庫的帳號在iDB裏申請和分配。寫帳號只有insert、delete、update和select權限，無alter、drop和truncate等DDL權限。讀帳號只有select權限。
• 帳號密碼控制：研發人員只是在 iDB 裏爲應用訪問某個環境裏的數據源申請工程帳號而已，部署和上線發佈對他來說是透明的，工程的配置文件裏密文密碼是我們自研的另一個研發協作平臺（內部代號CloudEngine）在構建鏡像的時候自動完成填充的，他不需要接觸到數據庫密碼。研發人員不知道數據庫明文密碼，也就沒有機會犯錯。
• 數據查詢權限：研發人員只允許通過iDB查詢線上數據，並保留登錄和查詢記錄。
• 數據訂正權限：研發人員只允許通過iDB提交DML語句，驗證語法正確性、是否使用索引、分表操作是否包含路由字段和單條影響行數等規則，在DBA審覈後生成備份並執行，誤操作可回滾。
• 表結構修改權限：研發人員只允許通過iDB提交DDL語句，驗證語法後經DBA審覈後執行。這種DDL操作也支持回滾。

其次，是公有云數據庫的安全預防機制。

• 雲數據庫的管理權限：數據庫管理人員（即DBA）可以管理雲數據庫，但是數據庫的實例釋放操作則需要運維經理角色確認。
• 數據庫訪問白名單：只允許指定IP和業務工程所在網段訪問相應的數據庫。

 最後，數據庫的備份及可恢復性測試，非常關鍵。備份永遠是數據庫管理員的第一要務。我們設定通過腳本自動備份，將備份相關信息記錄到iDB系統中，每週會做備份的可恢復性自動檢查。
位於IDC機房的自建數據庫集羣的備份機制是，通過腳本自動備份，將備份相關信息記錄到iDB系統中，每週會做備份的可恢復性自動檢查。
阿里雲的數據備份，則使用阿里雲自帶的“備份恢復”功能，介紹如下：

1）數據備份

RDS提供如下兩種備份功能：數據備份：設置的是週一至週日每天凌晨在備庫實例進行全量物理備份（後臺使用Percona XtraBackup備份），備份保留7天。日誌備份：已開啓日誌備份（Binlog日誌文件），日誌備份保留7天。 

2）數據恢復

恢復到阿里雲RDS實例，可以這麼做：按備份集：根據“數據備份”，將備份文件數據克隆出一個獨立的實例，驗證後，再將數據手動或通過DTS遷回原實例。按時間點：根據“數據備份”和“日誌備份”，將最近的一次全備和全備後的日誌備份恢復到一個新實例，經過驗證後，再將數據遷回原實例。恢復到自建機房數據庫，可以這麼做：根據“數據備份”和“日誌備份”，使用恢復工具PerconaXtraBackup將備份恢復到指定時間點。 雖然有這樣那樣的措施，但云數據庫仍存在一定管理風險，下面依次闡述。

4.4.1 阿里雲實例釋放時的風險

手動釋放阿里雲RDS實例的時候，大家務必小心謹慎，請多人交叉覈對實例ID是否正確。其原因如下所示。首先，阿里雲上“按量付費”的讀寫實例，子帳號都可以直接釋放實例，無需主帳號確認。 其次，阿里雲上“包年包月”的寫實例，子帳號看不到“釋放實例”的按鈕，只能提工單釋放。

但是在提工單的時候，需要手動填寫阿里雲的RDS“實例ID”，而無需提供額外信息，主帳號在工單中確認後，即可釋放並退款。爲了避免子帳號填寫錯誤而誤釋放實例，需要在處理阿里雲工單時引入線下審覈機制，主帳號負責人務必與DBA二次確認後，再由主帳號確認退款。

 

4.4.2.阿里雲RDS管理權限的風險

有RDS管理權限的話，即可在管理界面上刪庫和帳號，無需登錄數據庫。但阿里雲管理平臺上無法簡單快捷地檢查哪些子賬戶擁有RDS管理權限，所以除了DBA之外誰有權刪庫，無法一目瞭然。所以我們必須在賦權上小心謹慎，保證不同角色權限隔離。如擁有管理權限AliyunRDSFullAccess，就可以直接刪除庫，小心哦。

 

4.4.3.阿里雲RDS的備份可恢復性測試

我們確實有在做自動化可恢復性測試，但僅限於我們自己的IDC機房的數據庫備份可恢復性測試。阿里雲的雲數據庫本身並沒有備份可恢復性測試。 

4.4.4.實例恢復時間過長

實例級故障恢復時間較長，對於高頻交易類型業務來說也是一個重大風險，比如100G數據的實例恢復需要40分鐘。 

4.4.5.誤操作沒有快速恢復工具

目前阿里雲沒有提供快速恢復工具，需要開發工具，能快速從Binlog日誌文件中恢復最近的誤操作。

4.5 小結

刪庫跑路再現江湖，微盟市值蒸發10億元，還要對商戶賠付1.5億元，其中公司承擔1億，管理層承擔5000萬，所以說小洞不補，大洞喫苦，一出了事兒就是大事兒。備份，備份，備份，永遠是 DBA 的第一重責。備份高於一切。除了備份之外，還要未雨綢繆建設工具、流程和制度。我司的研發哲學第五條是“永遠要給自己留一個後備方案”。異地備份，多地備份，權限隔離，操作審計，交叉確認，……善待員工，給公司留條後路。
-完-