最近網(wǎng)上又出一起刪庫跑路事件，本不想過多寫此類事件文字，但從業(yè)13年，十年DBA工作經(jīng)驗，職業(yè)素養(yǎng)還是驅使自己寫點內(nèi)容，以期能夠幫助廣大企業(yè)客戶。

本文主要以數(shù)據(jù)庫產(chǎn)品從業(yè)者角度，介紹幫助企業(yè)減少意外或有意對數(shù)據(jù)庫刪數(shù)據(jù)的破壞行為，關于數(shù)據(jù)安全的其他內(nèi)容如加密等不做過多描述。為了闡述方便，會引入一些RDS功能介紹。

###子賬號體系

針對數(shù)據(jù)被刪除的場景，從“大”到“小”都需要防護，包含實例、數(shù)據(jù)庫、表、記錄行。尤其是最大的數(shù)據(jù)單位，數(shù)據(jù)庫實例，是需要特別保護的，否則刪除一個實例破壞性實在太大了，而且就目前所知這個破壞性是比較徹底的，假設沒有做任何額外備份保護，刪除實例后再恢復是完全沒有這種可能。

阿里云針對這種實例級保護，主要是通過主子賬號體系來實現(xiàn)的，主賬號創(chuàng)建數(shù)據(jù)庫實例，然后通過子賬號授權DBA等管理人員維護數(shù)據(jù)庫實例。針對按量實例，在刪除實例的時候會收到短信驗證碼，保障每次刪除都是正確的；針對包年包月實例，在實例到期前就會有短信通知續(xù)費，到期后會鎖定7天，期間可隨時恢復，7天后實例釋放但會將最新全備文件放入回收站保留8天，因此在實例到期后客戶依舊有15天時間來恢復數(shù)據(jù)。此外由于本次疫情，阿里云針對所有RDS包月實例到期時間都做了延期鎖定動作，保障在疫情期間因為延遲上班導致的延期交費實例不被鎖定。

前面提到我們刪除實例的破壞性是比較徹底的，因為目前大部分廠商的數(shù)據(jù)庫的備份都是跟著數(shù)據(jù)庫實例走的，即實例刪除后備份文件也隨之清空，此時就沒有任何恢復手段了。在2019年底，我們針對此場景，特別設計了刪除實例后保留備份文件的功能，已經(jīng)上線，這樣在實例刪除后，依舊默認保留備份文件，以便隨時恢復，并且暫時是0元優(yōu)惠的，大家可免費使用。

DBA賬號和研發(fā)賬號分開

數(shù)據(jù)庫實例能夠保證安全后，并不能夠保證數(shù)據(jù)庫就是安全的，比方說最近這個案例，可以通過刪除實例中的數(shù)據(jù)實現(xiàn)破壞。以MySQL為例，數(shù)據(jù)庫中的數(shù)據(jù)以表和數(shù)據(jù)庫形式組織起來，以記錄行承載具體的數(shù)據(jù)，對數(shù)據(jù)庫和表的保護尤其重要。

對數(shù)據(jù)保護的原則還是權限分離，最基本的權限分離還是要做到的，化繁為簡在RDS MySQL中我們設計了兩種權限類型用戶，分別是“讀寫”權限用戶和“只DML”權限用戶，讀寫權限用戶有DDL的權限，因此我建議給業(yè)務系統(tǒng)使用的數(shù)據(jù)庫用戶選擇“只DML”權限，而不應該給予“讀寫”權限，以此避免通過編寫一個惡意程序去刪除數(shù)據(jù)庫中的表或者整個數(shù)據(jù)庫了。

據(jù)我所知，有不少企業(yè)業(yè)務系統(tǒng)中，會給應用系統(tǒng)以DDL權限，即在業(yè)務運行過程中系統(tǒng)會去自動創(chuàng)建表和刪除表，比方說某些ERP系統(tǒng)是此類設計方案，這就無法避免要授予“讀寫”權限用戶給應用系統(tǒng)。另外在MySQL的權限體系中，有一個drop權限，其特性非常有意思，擁有這個權限就具備的刪除表和刪除數(shù)據(jù)庫的能力。因此這個場景，在一定程度上就加重了數(shù)據(jù)安全隱患。為了解決這種場景，我們專門在AliSQL內(nèi)核層設計了一個回收站，這樣縱然業(yè)務系統(tǒng)執(zhí)行了drop table等操作，DBA依舊可用在內(nèi)核回收站中快速的把數(shù)據(jù)找回。

如果要對表中數(shù)據(jù)行進行保護，就會相對比較復雜，除了通過binlog來反向更新找回數(shù)據(jù)外，我建議客戶可以開通SQL洞察功能，SQL 洞察除了用于審計，也可以用于找回數(shù)據(jù)。當然于此，DMS企業(yè)版也是我強烈推薦的一款產(chǎn)品，這款產(chǎn)品是過去阿里DBA團隊內(nèi)部研發(fā)流程管理的結晶，發(fā)布與回滾、表級權限的精細粒度控制、單行數(shù)據(jù)的masking等，都是專門的數(shù)據(jù)保護特性。

備份和恢復體系

數(shù)據(jù)保護的最后法寶永遠是備份，如果沒有備份，能夠保護數(shù)據(jù)的程度是很有限的，記得前兩年有個公司自建數(shù)據(jù)庫，認為云盤有很高的數(shù)據(jù)可靠性保障就可以安全無憂，但是凡是代碼就有bug，最后的悲劇大家也比較清楚。無論是物理損壞、或人為損害，備份就是最后的救命稻草。

在阿里云RDS中，會強制要求備份文件至少保留7天，每周至少做兩次全量備份，與AWS允許不備份的設計不同，我們這樣做真的是為了保護客戶，與國外環(huán)境不同，中國的DBA從業(yè)人員本來就少，有意識備份是少之又少，因此在這里我們做的和AWS不一樣。同時為了降低成本，我們開發(fā)高壓縮比的備份技術，一般壓縮7到10倍，并且贈送50%實例存儲空間的免費備份空間。

另外有一個特別的建議，希望大家都能夠打開RDS的日志備份，這樣在恢復的時候可以實現(xiàn)恢復到時間點，可以最大程度保護企業(yè)數(shù)據(jù)。若關閉日志備份，那么極端情況只能恢復到上次全量備份時間點，比方說一周兩次則有可能是三天前，因此我們建議僅對如開發(fā)測試環(huán)境數(shù)據(jù)庫關閉日志備份，所有的生產(chǎn)數(shù)據(jù)庫都應該打開日志備份。

災難發(fā)生時，數(shù)據(jù)庫恢復技術就顯得尤其重要，當然前提得有備份。我們過去只提供了克隆實例功能和覆蓋性恢復功能，在災難發(fā)生時，支持用戶把數(shù)據(jù)恢復到一個新實例，或者恢復到老實例（覆蓋恢復）。

在18年的時候，我們?nèi)∠采w恢復的功能，因為這個功能其實是非常危險的，如果覆蓋恢復過程出現(xiàn)異常，那么數(shù)據(jù)錯亂將會更麻煩，這在當時是個痛苦的決定。數(shù)據(jù)庫恢復（克隆實例）是挽救數(shù)據(jù)的法寶，但是恢復效率也是非常重要的，否則意外發(fā)生時，也許需要幾天才能恢復（取決于數(shù)據(jù)庫大小），因此在19年我們?nèi)嫔暇€了庫表級恢復能力，支持只恢復一個單表，這樣如果某種表數(shù)據(jù)丟失或者錯亂，可以快速的恢復，效率上是數(shù)量級的提升。另外針對一些更特殊場景，我們上線了RDS跨地域備份功能，其意義就不多說了。

關于備份恢復提最后一點，長期的定期的恢復演練是非常有必要的，否則你無法知道備份是否有效，相關版本是否匹配等，當然RDS已經(jīng)在系統(tǒng)上實現(xiàn)這個機制，客戶可以放心使用。

給自建和同行朋友的建議

上面談到的幾點都以RDS舉例來說明的，對于在ECS自建或者IDC自建的朋友，我們也是希望能夠和我們一樣，加強對數(shù)據(jù)庫的保護，一些切實可行的動作包括：

· 重新Review下數(shù)據(jù)庫權限體系，最基本的權限分離還是要做到的，千萬不要有grant all on?.?的用戶給到應用系統(tǒng)，因為凡是系統(tǒng)就會有bug，有些時候結果是超出想象的。

· 定期備份機制一定要做起來，雖然此舉涉及成本投入，但這是我們DBA行業(yè)的職業(yè)素養(yǎng)，不可得過且過。

· 定期演練也要做起來，意外發(fā)生時，你就是公司所有人的希望，甚至是你一年中唯一的閃光點，千萬不要手抖。

關于我們的同行，在這里我也呼吁盡快完善產(chǎn)品功能，庫表級恢復、跨地域備份、備份獨立存儲（實例刪除后依舊保留）、內(nèi)核回收站、秒級恢復，這些功能都是我們走訪調查大量客戶后的研究總結，全力完善起來對所有客戶都是有意義的。

給DBA和管理者的建議

雖然說RDS做了很多功能來保護客戶數(shù)據(jù)，但是個人認為一切的核心還是在于人。對于這次事件，我認為是個遺憾也是悲劇，也許有種種原因，但是這樣的操作是不理性的，不僅僅是對一家公司的破壞，也許甚者對背后多個家庭或者行業(yè)都有破壞性，另外也會加深外界對整個行業(yè)從業(yè)者的誤解。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉載。

總結

以上是生活随笔為你收集整理的阿里十年DBA经验产品经理：真的不要再有一起删库跑路事件了的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。