最近網上又出一起刪庫跑路事件，本不想過多寫此類事件文字，但從業13年，十年DBA工作經驗，職業素養還是驅使自己寫點內容，以期能夠幫助廣大企業客戶。
本文主要以數據庫產品從業者角度，介紹幫助企業減少意外或有意對數據庫刪數據的破壞行為，關於數據安全的其他內容如加密等不做過多描述。為了闡述方便，會引入一些RDS功能介紹。
###子賬號體系
針對數據被刪除的場景，從“大”到“小”都需要防護，包含實例、數據庫、表、記錄行。尤其是最大的數據單位，數據庫實例，是需要特別保護的，否則刪除一個實例破壞性實在太大了，而且就目前所知這個破壞性是比較徹底的，假設沒有做任何額外備份保護，刪除實例後再恢復是完全沒有這種可能。
阿里雲針對這種實例級保護，主要是通過主子賬號體系來實現的，主賬號創建數據庫實例，然後通過子賬號授權DBA等管理人員維護數據庫實例。針對按量實例，在刪除實例的時候會收到短信驗證碼，保障每次刪除都是正確的；針對包年包月實例，在實例到期前就會有短信通知續費，到期後會鎖定7天，期間可隨時恢復，7天后實例釋放但會將最新全備文件放入回收站保留8天，因此在實例到期後客戶依舊有15天時間來恢復數據。此外由於本次疫情，阿里雲針對所有RDS包月實例到期時間都做了延期鎖定動作，保障在疫情期間因為延遲上班導致的延期交費實例不被鎖定。
前面提到我們刪除實例的破壞性是比較徹底的，因為目前大部分廠商的數據庫的備份都是跟著數據庫實例走的，即實例刪除後備份文件也隨之清空，此時就沒有任何恢復手段了。在2019年底，我們針對此場景，特別設計了刪除實例後保留備份文件的功能，已經上線，這樣在實例刪除後，依舊默認保留備份文件，以便隨時恢復，並且暫時是0元優惠的，大家可免費使用。
DBA賬號和研發賬號分開
數據庫實例能夠保證安全後，並不能夠保證數據庫就是安全的，比方說最近這個案例，可以通過刪除實例中的數據實現破壞。以MySQL為例，數據庫中的數據以表和數據庫形式組織起來，以記錄行承載具體的數據，對數據庫和表的保護尤其重要。
對數據保護的原則還是權限分離，最基本的權限分離還是要做到的，化繁為簡在RDS MySQL中我們設計了兩種權限類型用戶，分別是“讀寫”權限用戶和“只DML”權限用戶，讀寫權限用戶有DDL的權限，因此我建議給業務系統使用的數據庫用戶選擇“只DML”權限，而不應該給予“讀寫”權限，以此避免通過編寫一個惡意程序去刪除數據庫中的表或者整個數據庫了。
據我所知，有不少企業業務系統中，會給應用系統以DDL權限，即在業務運行過程中系統會去自動創建表和刪除表，比方說某些ERP系統是此類設計方案，這就無法避免要授予“讀寫”權限用戶給應用系統。另外在MySQL的權限體系中，有一個drop權限，其特性非常有意思，擁有這個權限就具備的刪除表和刪除數據庫的能力。因此這個場景，在一定程度上就加重了數據安全隱患。為了解決這種場景，我們專門在AliSQL內核層設計了一個回收站，這樣縱然業務系統執行了drop table等操作，DBA依舊可用在內核回收站中快速的把數據找回。
如果要對錶中數據行進行保護，就會相對比較複雜，除了通過binlog來反向更新找回數據外，我建議客戶可以開通SQL洞察功能，SQL 洞察除了用於審計，也可以用於找回數據。當然於此，DMS企業版也是我強烈推薦的一款產品，這款產品是過去阿里DBA團隊內部研發流程管理的結晶，發佈與回滾、表級權限的精細粒度控制、單行數據的masking等，都是專門的數據保護特性。
備份和恢復體系
數據保護的最後法寶永遠是備份，如果沒有備份，能夠保護數據的程度是很有限的，記得前兩年有個公司自建數據庫，認為雲盤有很高的數據可靠性保障就可以安全無憂，但是凡是代碼就有bug，最後的悲劇大家也比較清楚。無論是物理損壞、或人為損害，備份就是最後的救命稻草。
在阿里雲RDS中，會強制要求備份文件至少保留7天，每週至少做兩次全量備份，與AWS允許不備份的設計不同，我們這樣做真的是為了保護客戶，與國外環境不同，中國的DBA從業人員本來就少，有意識備份是少之又少，因此在這裡我們做的和AWS不一樣。同時為了降低成本，我們開發高壓縮比的備份技術，一般壓縮7到10倍，並且贈送50%實例存儲空間的免費備份空間。
另外有一個特別的建議，希望大家都能夠打開RDS的日誌備份，這樣在恢復的時候可以實現恢復到時間點，可以最大程度保護企業數據。若關閉日誌備份，那麼極端情況只能恢復到上次全量備份時間點，比方說一週兩次則有可能是三天前，因此我們建議僅對如開發測試環境數據庫關閉日誌備份，所有的生產數據庫都應該打開日誌備份。
災難發生時，數據庫恢復技術就顯得尤其重要，當然前提得有備份。我們過去只提供了克隆實例功能和覆蓋性恢復功能，在災難發生時，支持用戶把數據恢復到一個新實例，或者恢復到老實例（覆蓋恢復）。
在18年的時候，我們取消覆蓋恢復的功能，因為這個功能其實是非常危險的，如果覆蓋恢復過程出現異常，那麼數據錯亂將會更麻煩，這在當時是個痛苦的決定。數據庫恢復（克隆實例）是挽救數據的法寶，但是恢復效率也是非常重要的，否則意外發生時，也許需要幾天才能恢復（取決於數據庫大小），因此在19年我們全面上線了庫表級恢復能力，支持只恢復一個單表，這樣如果某種表數據丟失或者錯亂，可以快速的恢復，效率上是數量級的提升。另外針對一些更特殊場景，我們上線了RDS跨地域備份功能，其意義就不多說了。
關於備份恢復提最後一點，長期的定期的恢復演練是非常有必要的，否則你無法知道備份是否有效，相關版本是否匹配等，當然RDS已經在系統上實現這個機制，客戶可以放心使用。
給自建和同行朋友的建議
上面談到的幾點都以RDS舉例來說明的，對於在ECS自建或者IDC自建的朋友，我們也是希望能夠和我們一樣，加強對數據庫的保護，一些切實可行的動作包括：
· 重新Review下數據庫權限體系，最基本的權限分離還是要做到的，千萬不要有grant all on . 的用戶給到應用系統，因為凡是系統就會有bug，有些時候結果是超出想象的。
· 定期備份機制一定要做起來，雖然此舉涉及成本投入，但這是我們DBA行業的職業素養，不可得過且過。
· 定期演練也要做起來，意外發生時，你就是公司所有人的希望，甚至是你一年中唯一的閃光點，千萬不要手抖。
關於我們的同行，在這裡我也呼籲儘快完善產品功能，庫表級恢復、跨地域備份、備份獨立存儲（實例刪除後依舊保留）、內核回收站、秒級恢復，這些功能都是我們走訪調查大量客戶後的研究總結，全力完善起來對所有客戶都是有意義的。
給DBA和管理者的建議
雖然說RDS做了很多功能來保護客戶數據，但是個人認為一切的核心還是在於人。對於這次事件，我認為是個遺憾也是悲劇，也許有種種原因，但是這樣的操作是不理性的，不僅僅是對一家公司的破壞，也許甚者對背後多個家庭或者行業都有破壞性，另外也會加深外界對整個行業從業者的誤解。