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

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

###子賬號(hào)體系

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

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

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

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

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

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

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

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

備份和恢復(fù)體系

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

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

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

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

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

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

給自建和同行朋友的建議

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

· 重新Review下數(shù)據(jù)庫權(quán)限體系，最基本的權(quán)限分離還是要做到的，千萬不要有g(shù)rant all on?.?的用戶給到應(yīng)用系統(tǒng)，因?yàn)榉彩窍到y(tǒng)就會(huì)有bug，有些時(shí)候結(jié)果是超出想象的。

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

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

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

給DBA和管理者的建議

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

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

總結(jié)

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

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