“刪庫跑路”重現江湖，技術和制度如何保障資料安全？

近日，一則來自微盟官網的訊息在業內引起軒然大波，“刪庫跑路”重現江湖……由此，關於如何從技術和制度兩方面進行資料安全防範的關注和討論廣泛展開。

事件的具體細節想必大家都知道了，我們僅在這裡回顧一下時間節點：

• 2月23日18:56，運維員工（犯罪嫌疑人）透過 VPN 登入公司伺服器並實施破壞。
• 2月23日19時，系統監控報告故障，生產環境及資料遭受嚴重破壞，隨即微盟啟動緊急響應機制。
• 2月24日，微盟向警方報案，犯罪嫌疑人現已被抓獲。
• 2月25日7時，生產環境和資料修復有序進行，並預計到25日晚上24點前可完成生產環境修復，恢復對新使用者的服務。
• 2月27日下午，微盟創始人孫濤勇回應刪庫事件：涉事員工深陷網路貸。
• 預計2月28日晚上24點才能完成老使用者的資料修復。

“微盟刪庫”事件發生後的一天內，微盟集團蒸發的市值超過 10億港元！基於微盟的 300萬家商戶生意基本停擺！長達 53-125小時崩潰時間，已屬非常嚴重事故！

一個個數字的背後，是中小商家的叫苦連天，是微盟公司的追悔莫及，是當事人賀某即將面臨的嚴厲刑罰，更是其他企業和相關從業人員的警鐘長鳴……

資料安全無小事

針對這次“微盟刪庫”事件，有業界專家表示，企業在進行資料管理的時候應該做到兩點：一是實行備份機制；二是管理許可權要分開。備份的工作必須從業務條線獨立出來，把權責分開；同時，做到“最小化授權”，只有需要的許可權才給。另外，企業還需要加強演練，做好應急預案，提升對生產環境的定位，並對員工做好安全教育和人文關懷。

這似乎是老生常談了，而事實上，在災難來臨之前，多數人都會覺得自己是幸運者。資料安全，是時刻懸在企業和IT從業人員頭頂的一把利劍，大意不得。

回看歷史，類似這次事件而導致的業務停擺事故其實屢見不鮮，不論是人為破壞，還是技術Bug、裝置故障，歸根結底都是“人禍”，我們能做的必須是防患於未然，從技術和制度兩方面齊抓，才能將“災難”的發生機率降到最低（還不可能絕對避免）。

雲和恩墨創始人蓋國強先生曾在2017年和2018年分別就業內的兩起資料安全事故分享過自己的觀點，現在重新翻看，依然有很高的參考價值：

關於爐石傳說的Oracle資料庫故障不要以為你也可以倖免
靜默錯誤：為什麼看了那麼多災難，還是過不好備份這一關？

“對於運維來說，最重要的是提高自身的免疫力，獲得高抗風險能力，從而在災難中倖存下來。事關企業資料安危的情況，無論如何都不能疏忽大意。”那麼如何避免陷入資料安危的困境？首先，要有完善、有效的備份和容災機制；其次，要有完善的故障處理策略和流程；再次，要有端到端融會貫通的應急機制；最後，要有能夠快速協同的團隊資源。

這裡，備份被放在了首位，因為它是最基本也是最重要的。蓋老師曾總結的DBA四大守則，第一條便是“備份重於一切”。正所謂：硬體一壞，誰也沒招；線路再穩，藍翔報銷；功夫再高，也怕菜刀。只有有效的備份才能讓企業高枕無憂。但這就夠了嗎？當然不夠。在蓋老師曾總結的提升資料安全的“16條軍規”中，嚴管許可權、明確職責、網路隔離、防範內患、安全審計等都有提及，這都需要技術和制度相互協同來得以落實。

為此，筆者就技術和制度兩個層面在保障資料安全的舉措上做了一些歸納，希望能給讀者帶來些許提示。

技術層面：

最原始的方式便是傳統備份與恢復。現在很多中小企業受限於技術能力和成本，還是透過邏輯或物理的方式進行備份，在必要的時候進行恢復。但這存在的很多問題，比如：資料量越大，RTO越長；備份時間點與問題發生點之間的時間間隔越大，RTO也很長。注意，備份的恢復速度是必須要充分考慮的，因為這直接影響著業務的連續性。低效備份在關鍵時刻會害死人，這不是危言聳聽。此外，邏輯備份容易造成資料丟失，而備份介質損壞更是致命，這就是前面提到的“硬體一壞，誰也沒招”。

提到備份，就不得不提容災，就是採用邏輯或物理同步方式搭建容災環境，透過資料同步到備庫的方式進行資料的同步複製。這裡存在一個問題是一旦主庫資料進行刪除，備庫也會做相應的刪除操作，沒有真正起到保護資料安全的作用，是有漏洞的。那麼，採用儲存映象的方式進行容災呢？會存在映象時間點和故障點之間的資料差異，導致一致性問題。

為了簡化備份，持續性資料保護（Continuous Data Protection）出現了。CDP是對傳統資料保護技術的一個重大突破。系統管理者無須關注資料的備份過程，而是僅僅當災難發生後，簡單地選擇需要恢復到的資料備份時間點即可實現資料的快速恢復。連續性的問題不存在了，然而資料的不一致問題依舊沒有得到有效解決。由於CDP開發者並不關心一個或多個I/O記錄對應的事務行為，以及是否包含有效資料，所以邏輯一致性的檢測往往被忽視了，其結果會導致資料庫無法啟動，或者啟動後出現其他問題，例如：資料物件損壞、無法插入資料等。

為了解決一致性的問題，複製資料管理（Copy Data Management）技術可以說是CDP的進階，重點在於對已經複製出來的資料的管理，結合日誌處理技術，提高資料的實時性並解決了資料一致性的問題。CDP解決保護的持續性問題，CDM解決保護出來資料的管理問題；CDM的資料獲取基於CDP方式來採集資料，也算是“資料管理”和“資料保護”的有機結合，既解決了資料持續保護的問題，也解決了容災、開發測試快速使用資料的需求。資料保護+資料管理，既滿足了使用者保護資料的需求，也滿足了使用者對資料管理和敏捷使用的訴求。

雲和恩墨的ZDBM產品就是採用CDM技術的資料庫備份、容災、複製資料管理平臺。對於一致性還是連續性，相信每一個運維團隊都會根據業務特性形成預先的準則，不同的業務系統在不同的階段就會有不同的取捨。ZDBM做到了兩者的平衡，滿足了組織在資料安全保護和高效利用備份資料方面的迫切需求。

此外，另一款MyData產品，其備份恢復功能提供了基於XtraBackup的物理全量、增量備份，binlog日誌備份以及使用mydumper邏輯備份的三種備份方式，可以根據不同的備份恢復需求進行靈活的搭配，提供了更多選擇。

制度層面：

首先從預防的角度看，建立敏感資料操作的雙人複核機制，關鍵應用業務的刪庫監控機制，以及基於許可權稽核的許可權控制機制都是行之有效的舉措。

從這次的“微盟刪庫”事件來說，本質上更多的就是制度問題。從防範難度級別以及安全透視級別來分析，運維外包人員（乙方），受監管範圍最大，一般透過網路隔離就可以避免“人禍”的發生；接下來是開發人員，主要風險在於系統上線更新及其資料庫操作許可權管理上，這就需要前面提到的“最小化授權”。那麼對於運維人員（甲方）呢？區別於外包人員的運維許可權，甲方運維人員所掌握的許可權範圍更大，操作更加頻繁，因此是人為因素導致事故的高發區。微盟的那位研發中心運維部核心運維人員賀某正是這個角色。最後，許可權最高，防範難度最大的就是組織內的IT部門主管了。所以說，組織除了要在內部機制上加強管控，包括資料安全、研發技術安全等以外，為了避免百密一疏，還必須在文化上讓員工對自身的道德底線有所認知，恪守信條，不可觸碰法律紅線。

其次便是應急策略。組織需要制定極端情況下的應急防範措施，並定期進行備份恢復演練。儘管沒有誰敢真的線上上全盤執行"rm -fr /*"這樣的操作，但依舊可以模擬各種可能的情況，以及不同情況的組合，再針對這些情況制定不同的預案，並在開發、測試環境試著進行演練。

總之，制度是“文”、技術是“武”，文武雙全方能高枕無憂。從大部分企業的情況看，現在資料安全最薄弱的環節就是在管理安全上，這部分是高許可權、高風險的所在，必須以技術+管理的方式相輔相成，依靠技術手段來杜絕管理制度的人為逾越，並透過技術來保障資料的可防守、可恢復。

防範攻擊 加強管控

在蓋老師的《資料安全警示錄》一書中，提出了資料安全的五個緯度，可以基於這五個緯度來梳理企業的資料安全，並據此建立相應的安全防護措施。

在資料安全的範疇內，我們將安全劃分為五大方面，分別是： 軟體安全、備份安全、訪問安全、防護安全、管理安全。在企業資料安全中，這五大方面是相輔相成、互有交叉、共同存在的，下面是關於資料庫安全的一張思維導圖：

在這五大安全方向中，可能出現兩種性質的安全問題。第一，由於內部管理不善而導致的資料安全問題；第二，由於外部惡意攻擊入侵所帶來的安全問題。通常我們把安全問題狹義化為後者，這實際上是片面的，在資料安全問題上，前者造成的資料損失、資料損毀，其發生機率和影響度都遠遠超過後者。

下面我們對資料安全的五大方面做一下簡要的分析和探討：

1.軟體安全是指我們選擇的資料庫產品、版本是否穩定安全；廠商所能提供的補丁集和BUG修正是否及時、基礎硬體與作業系統是否經過認證。很多使用者在部署資料庫軟體時，僅僅選擇了最容易獲得的初始釋出版本，遺漏了可能已經存在的補丁修正，並且在執行維護中並不能夠及時跟蹤軟體更新，也無法獲得BUG資訊、補丁修正和安全告警，這就使得軟體本身的很多風險隱患得不到修正。如果軟體安全無法保證，資料庫安全的基礎也就喪失了。

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

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

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

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

針對這次“微盟刪庫”事件而引出的技術和制度如何保障資料安全的話題，筆者在此摘錄了蓋老師三年前的一篇文章中總結的提升資料庫安全的“16條軍規”供大家參考。也許事後回看，微盟乃至所有的資料災難的避免，都可以從以下16條建議中找到答案：

1.備份重於一切：我曾經在總結的DBA四大守則的第一條就指出，『備份重於一切』，有了有效的備份，即使遭遇災難，也可以從容應對，對於重要的生產環境，適當建立備庫進行資料保護，查詢分擔，也會減少生產庫的風險；唯一會讓DBA們從夢中驚醒的就是：沒有備份！所以對於資料庫運維來說，第一重要的是做好備份！有備方能無患！

2.嚴格管控許可權：過度授權即是為資料庫埋下安全隱患，在進行使用者授權時一定要遵循最小許可權授予原則，避免因為過度授權而帶來的安全風險。本次安全風險，如果使用者只具備最低許可權，如不具備DDL許可權，那麼也不會遭到風險。

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.適時的軟體升級：這裡的軟體指資料庫軟體，尤其是當Oracle已經發布了安全補丁，已知的安全漏洞被駭客利用，則更可能對資料庫產生致命的傷害。

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

15.樹立安全意識：安全問題最大的敵人是僥倖，很多企業認為安全問題機率極低，不會落到自己的環境中，所以對於安全不做必要的投入，造成了安全疏忽。所以安全問題最大的敵人是我們自己，安全需要一點一滴的加強，逐步完善，雲和恩墨一直幫助核心客戶進行全面的安全評估，制定安全方案，守護資料安全。

16.開始安全審計：以Oracle資料庫為例，資料庫已經提供了很多安全防範的手段和方法，我們建議使用者適當展開安全防範措施，開啟部分任務審計，定期分析資料庫風險，由此逐步完善資料庫安全。

寫在最後

在當今資料安全問題日益凸現的時代，對於安全的防範和防護已成為企業IT建設中的重要環節。雲和恩墨資料安全解決方案從漏洞掃描、入侵檢測、訪問控制、查詢審計等多方面保障組織的核心資料資產安全。自研軟體ZDBM和MyData都能對資料庫進行高效備份，與緊急救援、資料庫恢復等服務相結合，可實現全方位的資料保護。重視資料安全，讓“刪庫跑路”的悲劇不再上演。

最後的最後，祝所有運維兄弟們保持身心健康，也請各企業在當下的非常時期對自己的將士們給予更多關懷！願類似事件不再發生，讓技術和制度有效規避風險，保障企業健康、良性發展！

（部分圖片來自網路）