談談UCloud保障數據安全的七種「武器」

當前，數據安全受到多方面的威脅。有來自系統軟硬件的非人爲故障，有運維工程師的誤操做，甚至是黑客或內部人員的惡意刪除。2017年1月31日，全球最大的代碼託管服務平臺Gitlab因爲工程師的誤操做，刪除了5000個項目和700個用戶帳號的數據，雖然多方補救，但部分數據最終沒能恢復。近幾年黑客入侵用戶系統後加密磁盤，以此來勒索的事件也層出不窮。更有來自黑客或內部人員的惡意刪除，致使業務的極大損失。

如何完全杜絕此類風險，確保數據安全，須要全方位的技術保障措施：備份、反入侵、分權限管理、快速回檔等技術手段都不可或缺，並且必須覆蓋每一類存儲產品。

UCloud做爲業界領先的雲服務商，提供了全面的各種存儲產品，開發了完整和成熟的數據安全機制。而且在爲數萬家用戶提供可靠線上服務的過程當中，積累了豐富的經驗。下文提到的數個案例，其實就發生在UCloud平臺上。經過咱們的產品和專業及時的服務，這些用戶最終得以恢復數據，避免由此形成的損失。

通常地說，用戶搭建數據庫有以下三種方式：使用公有云提供的DB PaaS託管服務，如UCloud UDB，由雲服務商來負責DB的搭建及運維；用戶也可使用公有云的雲主機和雲盤來自行搭建數據庫；或者在私有云環境下搭建。在這三種狀況下，UCloud都提供了專業的數據安全機制，來切實有效的保證用戶的數據安全。

接下來將介紹UCloud針對數據庫數據安全的七種「武器」。具體而言，本文主要回答以下三個問題：

1. 數據庫的備份容災機制如何完善？

2. 數據被破壞丟失後如何快速恢復？

3. 數據庫運維人員的權限如何有效控制？

UDB PaaS託管服務

若是須要獲得最專業的數據庫安全服務，用戶的首選就是雲服務商提供的DB PaaS服務。譬如說，UDB是UCloud提供的雲數據庫服務，支持各類主流的數據庫產品。自2013年上線以來，運營了數以萬計的UDB實例。

UDB遠遠不僅是幫用戶搭建DB那麼簡單，事實上這部分功能只是UDB價值的冰山一角。UDB提供了完備的數據庫搭建、運維、性能調優、資源擴縮容等服務。其高可用、高性能、便捷易用等特性幫助用戶大量減輕了運維負擔。同時，數據庫團隊還自研了分佈式架構、讀寫分離、存儲計算分離等特性，進一步提升雲數據庫的性能和可用性。在數據的備份恢復機制上，UDB提供自動備份、秒級恢復、監控告警、問題診斷等服務。

武器一：UDB備份機制

面對不可預測的誤操做或者人爲惡意操做，數據庫自身的備份機制就顯得尤其重要。UDB的備份機制具體以下：

（1）UDB的備份模式

a、自動備份天天自動進行一次備份（默認備份時間爲00:00—06:00的某一整點），備份能夠保存7天。備份模式包括物理備份和邏輯備份兩種。

b、用戶能夠對某些關鍵時間點的重要數據進行手動備份，容許保留個數爲3個。

**
（2）UDB備份文件存儲**

a、備份文件存儲在UCloud獨立的備份資源池中，安全性有保障。

b、備份文件的副本始終保持多份異地冗餘。

（3）備份文件轉存 

針對用戶個性化的備份文件存儲需求，UDB支持備份文件下載：

a、Web控制檯或API支持下載備份文件（包括自動備份和手動備份）。

b、Web控制檯或API支持下載二進制日誌文件（MySQL的binlog） 用戶在下載備份文件後，可轉存到自有的存儲系統或者UCloud平臺上的存儲類產品（UDisk、UFS、UFile等），理論上採用公有云存儲產品更爲安全可靠。

（4）備份成功率保障機制

a、UDB的自動備份具有有效的告警機制，若是備份失敗，則會自動觸發告警

b、UDB後臺會按期進行備份成功率的巡檢，經過SPT反饋備份狀況給到用戶。 

武器二：數據恢復方案

針對誤操做或者人爲惡意形成的數據庫刪除，UDB提供了一系列數據恢復方案。

a、對UDB實例中的庫作刪除，好比drop/delete操做，能夠從源實例經過回檔功能恢復到操做的前一刻，回檔到一個全新的實例。

b、UDB實例被刪除後，它原先的備份將持續自動保留7天，7天內仍然可從備份恢復爲一個全新實例。

c、出現最極端的狀況，實例被刪、備份文件所有被刪，那該怎麼辦呢？UDB後端在必定有效期內仍然保留有操做當天的最新備份，應對該極端狀況。因爲這份備份是系統內部維護，用戶並不能直接訪問。因此即使發生運維人員惡意刪除，此份備份依然存在，仍然可使用該備份來數據恢復。

武器三：從本地備份到跨雲備份

爲了確保數據的絕對安全，必須作到數據的多份備份，能夠從本地磁盤的多份備份到跨區域備份，甚至實現跨雲平臺的多雲備份。

數據庫數據可靠性受底層有效的RAID保護，實例級的冗餘則包括主實例採用高可用架構，後端主備雙節點，保證數據雙份冗餘。控制檯一鍵建立從實例，主實例能夠一主帶N從，包括可用區級（主從在同可用區）和地域級（主從跨可用區），保證明例級冗餘。

UCloud還提供數據傳輸產品UDTS，在數據庫可靠性更高要求的場景，主實例能夠經過UDTS搭建異地或者兩地三中心的UDB集羣架構，進一步保障數據安全。此外，UDTS也適用於多雲部署的場景，其支持多種數據庫類型、雙向遷移的能力，能夠幫助使用者將數據平滑地作跨雲的遷移和備份。某電商即是藉此實現了UCloud和T雲之間的數據同步。

UDB數據恢復案例

---

場景一：數據庫誤變動

遊戲行業業務變動快、變動多，是比較容易形成數據庫誤操做或者不當變動的狀況，此時如何快速恢復到變動前狀態就成爲了棘手的問題。某遊戲用戶在版本發佈時形成數據庫的schema變動字段出錯，發現出錯時，已經對遊戲服形成了巨大影響。此時，管理人員對影響的UDB實例作了一個回檔操做，恢復至變動前一刻，精確到秒級，挽回了損失。再對源實例進行必要數據的導出，補償到回檔的新實例，避免數據丟失。

場景二：數據庫誤刪除

在運維權限管理混亂時，安全性就存在巨大的隱患，任何人都有可能對核心資源進行不正當操做。某互聯網App用戶的運維人員因爲看錯信息，形成核心UDB實例誤刪除。因UDB實例會天天自動備份，此時管理人員在控制檯找到UDB實例當天的最新備份，作了恢復操做，恢復爲一個全新UDB實例，減小了損失。

場景三：數據庫誤回收

在生產環境裏，最爲擔憂的是資源的回收未及時發現，例如（1）運維人員在資源整合時，刪除了某個數據庫實例；（2）過時資源未及時續費被自動回收，過後過了很長時間才反應過來，但爲時已晚。針對該場景，UDB實例後端在必定有效期內，仍然保留一份當天的最新備份，經過數據全量恢復的模式，幫助很多用戶找回數據。

使用雲主機自建DB

若是用戶出於各類緣由考慮，不肯意使用公有云的DB PaaS託管服務，而是但願使用公有云IaaS產品來自行搭建DB。UCloud一樣提供了專業的數據安全產品，那就是數據方舟。方舟是當前業界獨一無二的數據備份產品。經過在虛擬化層的I/O路徑改造，方舟能夠把用戶的原始塊設備存儲放在後端去存儲，而且能實現按秒的回滾。

武器四：數據方舟持續保護

對於數據備份產品，有兩個重要的能力評估指標——恢復點目標（RPO）和恢復時間目標（RTO），目前數據方舟的RPO已經達到秒級別，默認支持12小時內恢復任意一秒，24小時內任意整點恢復，3天內的任意零點恢復，用戶甚至能夠自由定製備份鏈秒級、小時級、天級的保護範圍，而且是恢復到一塊新的磁盤上；而數據方舟的RTO則可以達到最短5分鐘內恢復，即便是TB級別的數據量，也能夠作到半小時內恢復。

數據方舟是如何在技術上作到對用戶數據的持續保護呢？數據方舟後端使用了分層混合存儲設計，用戶的實時I/O會經過旁路以oplog的方式記錄到方舟的接入節點（FRONT）上，因爲方舟接入節點採用了高速磁盤設備，可以扛住用戶大量的I/O寫操做。

流式計算節點SHUFFLE會拉取接入節點的oplog進行批量處理，主要是進行數據分片（sharding），並將數據分片推送到最終存儲層（ARKER）進行存儲。隨着時間的流逝，ARKER也會不斷對數據進行合併，最終造成base/天級/小時/秒 四個級別的數據備份鏈。

用戶恢復時，會調動後端集羣全部節點的能力進行並行計算，加快恢復速度。值得一提的是，用戶恢復時當前的磁盤數據是保留的，數據會回滾到一塊新的磁盤上，這樣作的目的是若是用戶回滾後後悔，也可以回到恢復前的數據狀態。

數據方舟恢復數據案例

案例一：勒索病毒

2017年5月「永恆之藍」病毒爆發，全球大量Windows主機受到感染，企業重要文件被加密，只有支付高額贖金才能解密恢復文件。萬戶印刷公司的一臺雲服務器也遭受到了病毒攻擊，用戶的印刷文件被加密。

案例二：誤操做致使文件系統異常

2017年12月，某AI公司遭遇到了重大危機，其運維人員在對存放重要數據的雲硬盤進行擴容時，違規操做，致使硬盤出現了文件系統故障，數據沒法訪問。問題磁盤有着多個分區，該公司缺少對多分區磁盤進行文件系統修復的經驗，不敢貿然修復，擔心會所以致使數據進一步損壞。

案例三：遊戲回檔

2019年3月，某知名端遊公司出現了嚴重的運營事故，一個道具的複製漏洞致使了遊戲的平衡性失調，嚴重影響玩家體驗，所以須要快速完成回檔，保證對玩家的影響下降到最小。

這些案例中，用戶最終都經過UCloud旗下的數據方舟產品進行恢復，迅速找回了所須要的數據。

私有云DB的數據安全備份

若是用戶的DB搭建在私有云環境下，不要緊， UCloud的對象存儲產品UFile是一個海量的通用存儲產品。經過和第三方產品結合，即使是私有云的DB一樣能夠利用公有云海量及可靠的存儲服務，實現數據的高可靠性。

武器五：UFile對象存儲幫助數據庫備份

塊存儲上數據的保護不只能夠經過數據方舟解決，用戶還可使用基於 UFile 作數據持久化的 JuiceFS 存儲數據庫備份，JuiceFS 是爲雲端設計的 POSIX 共享文件系統，具備以下特色：

• 雲端：採用雲服務中的對象存儲做爲後端，綜合性價比極高。
• POSIX：兼容標準 POSIX 接口，能夠像本地文件系統同樣使用。
• 共享：上千臺機器同時掛載，高性能併發讀寫，共享數據。

UFile是UCloud自研的對象存儲系統，兼容s3協議，具有高可用、高可靠和低成本的數據存儲服務，提供多副本、跨地域等數據冗餘機制，支持三地及以上的跨地域災備功能。使用UFile用戶能夠實現高可靠、低成本的雲上和跨雲的數據備份，包括數據庫備份、日誌、大數據文件等。

基於UFile+JuiceFS搭建MySQL備份

UCloud用戶下廚房是國內最大的專一於家庭美食領域的社區，目前擁有超過四千萬註冊用戶，海量的業務也讓下廚房對數據庫的冗餘和備份格外的重視，而且總結出一套很是高效和可靠數據庫災備經驗。

除創建了跨可用區的主從節點外，下廚房會進行定時的整庫備份和實時的binlog備份。下廚房的數據庫備份藉助了UFile、JuiceFS和Percona Xtrbackup。使用JuiceFS用戶能夠無需修改代碼就能夠替換以前的本地備份。而且可利用JuiceFS後端的對象存儲來解決無限存儲空間、跨區域複製以及低成本等問題。下廚房的策略是保留 7 天內的 Percona XtraBackup 整庫備份、3 年內的 binlog 以及 1 年內的周級 mysqldump。

除此以外下廚房還想到了一個很是具有腦洞的備份驗證方案。有了備份還沒法作到高枕無憂，由於有時備份文件會出錯，等到須要恢復時才發現備份出錯就已經晚了。可是備份的驗證是個很是耗時的工做，須要拷貝備份到本地進行恢復。下廚房利用JuiceFS的快照功能，克隆一份備份文件，在不影響原備份文件的狀況下快速作驗證，省下大量拷貝的時間。

詳細實踐可參考連接：https://juicefs.com/blog/cn/p...

帳號和權限控制

在具有必定的備份和恢復機制下，數據庫運維管理人員的權限控制問題仍然不可忽視，例如將數據庫操做權限和備份權限進行分離、權限審批和操做執行分離、增長數據庫命令隔離層等。

武器六：子帳號

在權限管理控制方面，UCloud支持用戶爲本身的帳戶開設子帳號，並定義爲相應的角色。角色是一組產品權限的集合。若某成員的角色被修改，則其相應的權限也隨之變動。子帳號的存在有助於貫徹「最小權限管理」原則，只賦予工做職責所需的權限。大部分紅員或許只需雲資源的只讀權限，少許操做者可擁有修改的權限，而刪除權限必須經過管理員的審覈。

多級帳號權限控制，能夠有效的控制多級人員的操做權限，最大程度的下降來自內部人員惡意操做的可能。

武器七：安全鎖

安全鎖是雲資源高危操做的二次驗證服務。開啓該服務後，每次進行刪除資源等危險操做時，須要經過手機短信校驗身份纔可。

受安全鎖保護的高危操做例若有：

產品

操做

主機

開機、關機、刪除實例

物理機

關機、刪除實例

雲數據庫 UDB

刪除實例、關閉

雲內存存儲 UMem

釋放內存

對象存儲 UFile

刪除bucket、刪除ufile geo bucket

雲硬盤 UDisk

刪除實例

寫在最後

黑格爾曾說：「人類從歷史中學到的惟一教訓，就是人類沒法從歷史中學到任何教訓。」雲服務發展到今天，已經實現了多種完備的數據安全方案。如本文提到的UCloud七種武器，不管用戶使用哪種方式部署數據庫，必有一款適合你。企業在從此發生數據庫機器故障、誤操做、惡意刪除等情形時，可否充分利用雲服務商提供的數據備份、恢復機制以及帳號權限控制等能力，是解決數據丟失問題的關鍵。