活動實錄|拒絕"刪庫到跑路"，探究餓了麼數據安全保障體系

數人云「告別人肉運維」上海Meetup的實錄第二彈來啦！本次分享的嘉賓是餓了麼DBA團隊負責人虢國飛。實錄將從用戶訪問、數據庫架構體系、數據備份、數據流轉和數據操做等幾個方面介紹餓了麼目前在數據安全方面的一些措施。

虢國飛 / 餓了麼DBA團隊負責人

從事數據庫領域10+年，主要關注於數據庫管理自動化建設和MySQL、Pg、MSSQL、NoSQL等領域的研究。

本次主題關於數據安全的保障。前面的引子是Gitlab數據庫出現問題，它有五重的數據保障，但都失效了。開始以前有幾個問題：

1. 在座不少是作運維或數據庫工做的，如今公司數據庫有備份嗎？

2. 若是數據庫有備份，多長時間作一次還原測試來驗證數據庫的備份是否是有效？

3. 有沒有一個月以內作一次整個備份檢驗的？在一個月以內作一次，好比一年作十次或者十二次還原檢驗？

帶着上面的疑問，我分享一下餓了麼在數據安全上所採起的一些措施，包括備份和還原的方式，與你們一塊兒探討。

本次活動主題是如何減小人肉運維，讓數據庫運維和業務運維實現自動化。爲何作到保持有備份，而且驗證備份有效的公司不是那麼多呢？關鍵在於資源，資源不光包括硬件資源，也包括人力資源。若是經過人肉方式時刻保證整套系統持續有效運做，成本至關高。

數據訪問

數據在入到數據庫以前，可能會面臨一些注入的攻擊甚至拖庫等風險。用戶訪問數據庫的時候，餓了麼有一箇中間層叫作DAL層，若是作一些分庫分表的應用不少時候都會運用這一中間層軟件，開源軟件有此類功能的也不少，像mycat、atlas等。

在這一層，餓了麼作了一些數據方面相關的保護。首先，由於有中間這一層，因此在底層數據架構方面對研發或者對外都是一個不透明的狀態，拿不到具體數據庫IP地址，咱們只把這些敏感的信息開放到有限的一些人的手裏；第二層面，在DAL層把一些敏感的信息所有加密掉，好比用戶名、密碼這種訪問數據庫的信息；第三，會對風險的SQL作一些限制，好比一次要拉一百萬數據的SQL，是不支持的，或者想drop一個表，這樣的風險動做都會屏蔽掉。

餓了麼對外開放的一些權限在帳號部分也作了限制：

首先，每一個業務都是專用的帳號，不會多業務共用一個帳號；

第二，帳號權限是最小的，通常就是增、刪、改、查，有的甚至是隻有增、改、查三個權限，刪除權限都沒有，因此帳號風險是最小化。還有一個是對內網的網段去作限制，在帳號賦權的時候限定它能訪問的網段；

第三，SQL限制講過，DAL層會作一些相應的限制，在數據庫一層也能夠去作，好比一些更新的SQL是不帶條件的，這時能夠限制掉，包括刪除的動做。若是沒有帶條件，這個風險是很高的，通常認爲都是有問題的，因此這部分風險會在數據層去屏蔽。

在數據訪問上，主要把信息進行一個屏蔽以及加密，以及對權限和操做的動做作了一層保障。DAL的架構在中間層，也是至關於對數據庫提早作了一個訪問控制和負載均衡層，固然它的功能不止這一點，還包括剛剛說的路由，一些緊急SQL的屏蔽等。

數據流轉

數據進來以後會面臨各方須要使用數據的問題：
首先，在DAL這層進到生產數據庫的時候，在入口這一端作限制；
第二，數據落到相應BU生產數據庫的時候，若是這些數據要給其它BU去訪問，數據應該如何提供？目前比較通用的方式是經過接口，某個BU去調用其餘BU一些相應的業務接口提去數據。若是接口提供不了的話，跨業務的訪問也走DAL層，DAL會把全部訪問的痕跡記錄下來。對於生產的數據，如今有不少研發會要求在他們的alpha和beta環境去作壓力測試，要同步生產的數據，還有須要查生產的數據，但這些數據可能包含敏感數據，怎麼辦？

餓了麼開發了一個DBQuery的軟件。對研發來講DBQuery能提供能查生產的數據，而後導出生產的數據，同時還可以把數據同步到其它的環境，可是這些操做都是受限的。首先它能操做的數據量是有限的，一些敏感的記錄會作脫敏的處理，全部研發人員在上面所作的操做都會被記錄下來，例如在上面作的導出動做、拉取數據、查詢等。若是是這個平臺自己不能支持的需求，那麼會聯合DBA和安全團隊去作把關，好比要對第三方提供一些大數據量的數據，這樣會有安全的保障。因此數據流的控制從入口，跨業務團隊的訪問，以及到不一樣的環境數據同步，包括研發想查看的這些記錄，都會記錄下來它的操做，以及對這些操做作相應的限制。

備份還原

DBA最重要的一個責任——數據庫的備份和還原。餓了麼的方案和你們所知道的或所瞭解的都差很少，可是如何把它作到或者更好的作到，各個公司都會不同。餓了麼有全量、增量、以及Binlog的備份，而後會拷貝到Ceph作保存，包括本地的備份和遠程的備份。關鍵的第三點，它可以完成自動的部署、運行和監控。一個業務上線的時候，由於有標準化，上去以後，備份就自動跑，若是沒有備份，就會收到告警。運行得正不正常，或者備份中失敗了，或者沒有運行備份，均可以經過監控的一個界面看到狀況，備份的時長以及什麼時間點去作的、在哪些機器上去作的，都是自動在後臺運行的。

數據還原也是如此，有一個循環的週期。餓了麼重要數據驗證週期是15天。由於有好幾百套DB，15天到一個月，重要的是15天會驗證一次，一個月週期的是不過重要的一些業務，都會在循環的週期去作驗證。驗證除了檢驗備份的可靠性之外，還有一個目的，即拿到數據還原的時長。研發或者領導會問若是如今某個數據庫出現了問題，多久可以找回來或者還原回來數據？這些都是須要數據支持的。它還能夠去抽樣，除了它本身循環去檢測的，能夠隨時拉一個庫出來，還原到哪一個時間甚至哪一個點位都是能夠的。餓了麼經過平臺去實現，不須要找機器、再找被分在哪裏，只要告之要還原的是哪一個庫，想還原到什麼樣子，維護成本很小。

上圖右側截圖裏有一些應用的時間以及它的狀態是成功仍是失敗。

DBA操做

除了在防範數據入口的時候對業務的數據進行一些控制，還要在底層作一些備份還原保障，另外DBA的一些操做對數據安全也至關重要，這部分出問題的狀況也很多。在如何保證DBA操做的安全方面，不少公司都會有各類各樣的軍規。

相似的軍規餓了麼也有，但如今慢慢淡化，由於軍規是與人相關的因素，特別不可控，餓了麼以前作軍規的時候把那些操做的風險都分了不一樣的類，一個要求是能保證操做的時候可以快速的回滾，舉個例子，好比清空一個表的數據應該如何作，由於有時風險很大。咱們的處理方式是先把這個表去rename一個待刪除的表，放一週以後會有自動的任務再去清理這個表。若是操做的時候出現問題，那能夠立刻讓它rename恢復過來。還有一個限制是風險操做在操做的時間上作限制，不能在業務高峯時間去作這些動做，是有一個維護的窗口期，在業務的低峯期纔去作。這樣可以保證一旦出問題損失最小化，雖然咱們可以快速恢復，可是若是在高峯時間操做其影響仍然很大，若是選擇有維護窗口期的話，損失是最小的。

之因此講淡化軍規是由於如今餓了麼想作工具化，這個工具裏最重要的是把高風險操做的流程步驟固化到工具裏面，讓工具去操做，人就不用太在乎操做的流程是否是OK的。有些作不到的流程，它也會提示出來有什麼風險，操做的時候會給DBA一個相應的警告。工具化以後，不少操做就能夠在後臺自動運行了

以上實際在生產上面跑的一些需求，紅色的部分大部分是自動執行的，由於平臺上線的時間才幾個月，以前這部分全是DBA在操做的，如今有不少任務DBA不須要本身操做，由後臺的系統任務去調度起來，基本上沒有風險，因此須要關注的點就變得愈來愈少了，人力也能夠解放出來把這個平臺作得更好。餓了麼今年正在作一個開發的自助平臺，設計的目標是研發可以在上面完成數據庫的一些操做，包括數據歸檔，加表等動做，符合平臺驗證規則的話DBA不須要干預。

架構保障

上圖是餓了麼如今架構的狀況。首先有兩個機房，A機房和你們主流的部署架構差很少，即主從的一個架構。有一臺特殊的機器DS（DelaySlave），它會保持與生產數據的數據同步有一個時差，好比它會延後一天或者是半天的時間、12小時，若是生產操做出現了問題，就能夠快速的經過它回放到操做前的一個點把這些數據找出來。這樣的恢復速度是最快的，追回的時間僅要幾分鐘。它不光提供半天以內數據快速恢復，並且餓了麼的備份也都在上面作，這樣備份的時候不會影響到生產運行。哪怕這臺機器上跑不少的備份任務都不會影響，由於它主要是作數據的備份，並且監控就是在標準化部署這一臺以後，全部的備份任務和監控程序都會自動與它作匹配，因此只要完成這一架構的搭建，接下來的事情繫統自動去作，也不須要人肉乾預。若是它沒有備份成功或者備份失敗或者跳過了備份，在監控備份和還原監控裏面都會獲得體現。

下面這是作還原的一部分機器，咱們是循環週期去作還原的，因此它在一個週期內一定會完成這些庫的校驗，驗證它的備份是否有效。在另外一個機房，中間有一個組件叫DRC，這個軟件最初淘寶作得比較多，即跨機房的一些數據的同步。它提供了數據同步和訂閱的功能，監聽數據庫狀態的變動，並且在多機房之間同步的時候能夠作不少動做，比方如數據的壓縮、過濾，還有剛剛提到的數據訂閱，出了問題它能夠上報。此外，有一個特殊的機器叫QS，DBQuery服務的功能就部署在它上面，在上面會完成研發對數據的查詢以及數據從它到各個環境的導入、過濾和脫敏。

從整個架構體系對數據的保障來看，一是有多機房，二是主從的HA，以及DelaySlave和一些備份機制。從數據入進來到DAL層、到數據庫裏面針對一些帳號權限的限制以及架構的保障和備份、還原體系的完善以及DelaySlave的延遲備份來保障餓了麼整個數據的安全，這樣的架構體系爲數據安全提供了多層保障。

總結