閱讀267 返回首頁    go 阿裏雲 go 技術社區[雲棲]

如何避免數據庫“勒索事件”和“從刪庫到跑路”的尷尬

摘要：8月24日，阿裏雲數據庫技術峰會到來，本次技術峰會邀請到了阿裏集團和阿裏雲數據庫老司機們，為大家分享了一線數據庫實踐經驗和技術幹貨。在本次峰會上，阿裏雲數據庫技術專家張友東（林青）分享了如何從代碼層麵做好數據庫安全防護，以及如何避免頻發的數據庫“勒索事件”的發生，幫助大家了解了數據庫安全防護需要注意的事項。

以下內容根據演講嘉賓現場視頻以及PPT整理而成。

近年來，數據庫安全問題逐漸引起大家的關注和重視，本次分享的主題就是如何去應對數據庫安全所麵對的問題。本次的分享主要將圍繞以下三個方麵：
  1. 2017數據庫安全事件及反思
  2. 如何讓你的數據庫更加安全可靠？
  3. 阿裏雲數據庫為你的數據保駕護航

一、2017數據庫安全事件及反思
2017年1月，MongoDB贖金事件
在今年的1月份，MongoDB黑客勒索贖金事件在互聯網上鬧得沸沸揚揚。這個事件大致就是某一天你發現自己的數據庫無法訪問了，當登陸到數據庫上去看時發現數據庫中的數據全都沒有了，而隻有黑客留下的一些記錄，裏麵的內容大概就是“你的數據庫已經被我黑掉了，而且我已經對於你的數據庫進行了備份，如果你想拿回自己的數據，就需要向某個比特幣賬戶中轉一筆錢。”，其實這與現實生活中的綁架勒索的性質基本相同。
2d69864c4e11f477319d35037d81f8ec72ebf72c
在被勒索的數據庫現場，黑客除了將數據庫黑掉之外，還會順便對於數據庫的用戶鄙視了一番。正如下圖中紅框中的所顯示的，黑客留言告訴數據庫用戶“你的數據庫開放了公網訪問並且還沒有開啟鑒權，你是怎麼想的呢？根本就沒有把數據當事情”。如果大家在數據庫的使用過程中也存在類似的部署情況，那就一定要關注數據庫的安全。
30d7954492d18624c44287900e8e0d11fbf54c71
自從MongoDB黑客勒索贖金事件發生之後，從1月份到現在的8月份，對於數據庫用戶產生了什麼樣的影響呢？下圖所展現的是今年1月份的數據統計，這是整個互聯網上MongoDB數據庫開放公網訪問端口的數量統計。在這個數據排行中的前兩名分別是美國和中國，其他國家與中美相比而言存在很大差距，其實這也是目前互聯網發達程度的一個縮影。在1月份，美國的MongoDB數據庫開放公網訪問端口數量大概有一萬七千個，中國則差不多剛好一萬多個。
4110cbd37a32a47b2d3f7b81c2f0cf9249a9f6c1
而到了今年8月份，美國的MongoDB數據庫開放公網訪問端口數量降到了其1月份數量的50%，而在中國則隻降到了原本的80%，這充分說明了中國的技術同學在吸取技術經驗教訓方麵還是有所欠缺的，所以我們應該更加重視數據庫的安全問題。而且這個數據也隻是能夠統計到的，可能真實的數字會更多。
4ed8910450979233ea0a16c692770f33ddbf8752
針對於MongoDB黑客勒索贖金事件，我們能夠從中得到什麼樣的經驗教訓呢？
  1. 這些數據庫之所以會被黑客攻擊，一個原因是這些數據庫開放了公網訪問，使得任何一台連接到公網的機器都能夠訪問到。除此之外，這些數據庫也沒有開啟鑒權，所以導致黑客能夠輕鬆地訪問用戶的數據庫，造成了用戶的數據損失。
  2. 受到影響的用戶對於數據的備份不夠重視，因為如果用戶對於數據進行了備份，即使黑客將數據刪除了，用戶也可以通過備份數據來進行恢複。

2017年1月，爐石傳說數據庫故障
接下來和大家繼續探討2017年1月份的另一起數據庫安全事件，也就是爐石傳說數據庫故障事件。這個事件並沒有公布技術細節，隻有爐石傳說的官方公告。爐石傳說在1月14號因為機房斷電導致的出現了數據庫故障，最終導致整個服務停了四五天，最終在1月18號將數據回滾到14號的某一個時間點。
340bcbf8c89f09daf63c8160af681b2052016656
這個問題雖然沒有提供技術細節，但是我們依舊能夠從中發現幾個問題：
  1. 爐石傳說並沒有做高可用的機房容災，因為整個機房掛了，於是服務就停了。
  2. 整個數據恢複使用了四五天的時間，所以在數據恢複方麵的工作還是存在一定欠缺的。

2017年2月，Gitlab數據庫誤刪
在2017年2月份還出現了一起數據庫安全事件，就是Gitlab的數據庫誤刪事件。這個事件的發生完全是因為運維同學鏖戰到深夜的時候，在已經非常疲勞的情況下把某一個數據庫誤刪掉了。這個事件當時也導致Gitlab的整個服務都停掉了，但是做的比較好的一點是Gitlab將他們對於整個事件的處理過程在互聯網上進行了直播，同時將改進的措施通過分成很多個issue來實現。
27914effeea4341c8a9ec9e443038bcd54d37e43
Gitlab的最大問題就是：對於一個數據庫而言，理論上是做了多重的備份，但是在最終進行數據恢複的時候發現很多的數據備份其實是使用不了的。因為數據庫的很多數據備份並沒有經過驗證，所以在需要使用的時候才發現備份數據是無法使用的。
f43ac76eb0c85d3d4c6a1ed2fa7bc1eee78edd19
通過上麵的幾個案例，大家可以發現在數據庫安全方麵其實存在著很多的威脅。DBA同學鏖戰到深夜部署好自己的數據庫，以為自己的數據庫很安全了，但是事實卻並不是這樣的。總結而言，數據庫安全方麵所需要麵對的威脅主要可以分為以下幾個維度：
  1. 黑客攻擊，黑客攻擊存在不同層麵，也有很多種攻擊方法。
  2. 硬件故障，如果數據庫服務隻部署了單個節點，當單個節點掛掉之後，整個數據庫就無法提供服務了。
  3. 軟件缺陷，數據庫服務畢竟是軟件係統，當軟件存在Bug的時候，也往往會造成安全問題。
  4. 運維失誤，類似於剛才提到的Gitlab事件，數據庫往往是由運維同學管理的，而運維同學可能會發生一些運維的失誤，這也可能造成數據的丟失。
  5. 自然災害，類似於之前的爐石傳說的機房斷電以及其他可能的自然災害導致機房數據無法恢複。

二、如何讓你的數據庫更加安全可靠？
三招搞定數據庫安全
麵對這麼多數據庫安全的威脅，我們應該如何去做數據的安全防護呢？其實總結而言，隻需要三招就能搞定數據庫安全。第一招：安全配置，從單個數據庫節點的數據來看，應該盡可能地進行安全方麵的配置來避免遭受黑客攻擊以及非法訪問等。第二招：高可用部署，盡可能地部署多節點來構成的高可用數據庫服務，這樣就能夠應對硬件故障的問題，當單個節點出現問題的時候，可以直接啟用備用節點來頂上；當軟件出現Bug導致數據庫崩潰的時候，也可以通過高可用將故障進行轉移。第三招：數據備份，做好數據備份就可以應對運維的失誤以及自然災害等問題。通過以上的三個步驟，就可以使得數據庫達到比較安全的狀態。
6e3d50df2d3f6ac87eaa7c967271645f06f624e3

第一招: 數據庫安全配置
接下來為大家更加詳細地介紹如何使得數據庫更加安全可靠。首先分享如何對數據庫進行安全配置。因為用戶的業務性質往往各不相同，所以對於數據庫安全的要求級別也會是不一樣的。這裏的數據庫配置將會分為三個維度進行介紹，分別是基礎安全防護工作、進階模式和更高層級的數據庫防護需要做的工作。
884d5cbe90e3bfd11b52146f28afc83d6b5bcd97
首先，對於基礎的數據庫安全防護工作而言，這裏所需要做的第一件事情就是一定要開啟鑒權。無論是通過公網訪問數據庫還是隻在內網中進行訪問，鑒權都是必不可少的。當鑒權開啟之後，所有的數據庫訪問都會需要有鑒權的動作，而鑒權的方式也會有很多種，最常規的就是通過用戶名和密碼的方式進行鑒權。而在鑒權的設計中也應該注意一些問題，比如盡可能不要使用安全性比較弱的口令，在互聯網上雖然可能有一些用戶開啟了鑒權，但是使用像“root-root”或者“root-123456”這樣的弱口令的大有人在。基礎的配置除了鑒權之外，還應該注意的就是整個數據庫服務應該最小化網絡的暴露，數據庫服務需要部署在物理機器上，機器上可能會有很多塊網卡，並且還有很多個IP可以綁定，在這樣的情況下，盡量隻去綁定需要訪問的IP，如果沒有必要給公網用戶進行訪問，那麼就沒有必要開啟公網訪問。除了綁定盡量少的IP之外，還需要注意的就是端口，因為有些類似於MongoDB這樣的數據庫服務，為了方便用戶執行一些管理動作還開起了HTTP的端口。但是如果在生產環境進行訪問，最好將這些HTTP端口禁用掉。

在基礎的安全配置完成之後，就可以更進一步地去實現進階的配置。進階的配置主要分為兩部分，第一部分是開啟鑒權之後，因為有很多個用戶需要去訪問數據庫，而這些用戶往往會擁有不同的角色，比如開發、運維、DBA以及測試等等，所以需要盡量地為不同的角色配置不同的操作權限，而不是一股腦地為所有的用戶都賦予Root權限，使得所有的用戶能執行一切操作。具體給什麼權限呢？其實這裏應該使用最小化權限原則，用戶需要什麼樣的權限，那就隻給用戶能夠滿足需求的最低權限。這樣就能夠盡量地避免一些誤操作，也能夠避免在出現數據誤刪事件之後，各個角色之間相互甩鍋，當為不同用戶分配了不同的權限之後，這樣的問題就可以避免了。同時還可以開啟審計日誌，審計日誌就是可以將所有數據庫的操作都記錄下來，具體是哪個用戶操作的、操作用了多長時間、整個操作的執行計劃等都可以詳細地記錄下來，這樣就能將所有的操作都實現有據可查，即使發現數據庫的誤刪動作以及非法訪問都可以立即查出是誰做的。而且通過開啟審計日誌，還可以方便地查看數據庫的運行狀態是否是健康的。

如果用戶想要獲得更高級別的數據庫安全配置其實可以做兩部分的工作，其中一部分工作就是實現SSL鏈路加密。通過SSL鏈路加密能夠避免數據被抓包的風險，並且在開啟SSL鏈路加密之後，客戶端和數據庫服務端存在一個相互認證的過程，這樣就可以避免遭受中間人攻擊。除了鏈路加密，為了達到更高的數據安全級別，還可以在數據存儲的時候進行數據加密，也就是TDE數據加密，這個通常是由數據庫存儲引擎在將數據存儲到磁盤上的時候來做的透明的數據加密。而這樣的整個加密過程對於用戶而言是完全透明的，用戶不需要去修改自己的訪問業務代碼。

第二招: 數據庫高可用部署
以上所提到的三個層次的數據安全配置方式是需要根據用戶自身業務的不同需求來進行配置的。單個節點的安全配置可能主要是為了防止數據庫被黑客入侵，但是如果發生了硬件故障或者軟件故障導致數據庫崩潰，想要實現數據庫的安全轉移，就需要實現數據庫的高可用部署。那麼如何實現整個數據庫集群的高可用部署呢？總結而言，數據庫的高可用部署主要可以分為三種模式，分別是外部支持、內建高可用以及通過計算和存儲分離將數據庫的數據存儲到共享存儲之上，讓共享存儲來負責數據庫的安全。這三種模式中，外部支持常見的有MySQL的MHA、Redis的Redis-sentinal，以及PGPool和Keepalived等都是實現的外部支持的高可用。在內建支持高可用方麵，像MySQL Group Replication、MongoDB Replica Set以及阿裏雲最新上線的MySQL金融版都提供了內置的高可用策略。而在共享存儲方麵，主要有一些比如將數據放到SAN存儲上，或者使用DRBD共享磁盤存儲，而且阿裏雲即將上線的PolarDB數據庫也實現了類似的共享存儲模式。
72f0e8cc7183ef816c96a5970ca78936ae8e6db1

外部支持示例：MHA for MySQL
ec163c3d25201e260b36cfe25e8c35e93996d295
本文中針對數據庫高可用部署的三種模式分別選取一個例子進行詳細介紹。首先分享外部支持的高可用應該如何去實現，這裏以MHA for MySQL為例。比如MySQL部署了一主兩備的三節點集群，這時會存在一個MHA的Manager不停地去探索三節點集群的運行狀態，當發現主節點故障的時候，MHA的Manager會自動將備節點切換為主節點。這樣的策略是非常直觀的，而且也是在目前在生產環境中使用最多的策略。那麼對於這樣的策略而言，又有什麼缺點呢？首先這個策略需要一個外部模塊進行仲裁，那麼就會出現一個問題：外部模塊的高可用又由誰來實現呢？除此之外，因為外部模塊和數據庫係統其實是兩個係統，它們之間通過網絡交互來實現可用性的探測，但是對於複雜的場景而言，這種方式是無法處理的。比如MHA與整個MySQL的三節點的網絡如果隔離了，那麼MHA就無法處理了。

內建高可用示例：MySQL Group Replication
f744afe2f17c7df11c5281f1074aa88467680f4e
而上述的問題可以通過數據庫內建高可用解決。接下來就為大家分享數據庫內建高可用的MySQL Group Replication的例子。這個例子中就解決了在之前提到的模式下需要外部模塊來仲裁的情況，現在就是將高可用做到集群中去，比如MySQL Group Replication其實會有N個節點，這裏以三個節點為例。那麼在Group Replication裏麵，可以采用每個節點都是主節點的模式，也可以采用一主兩備的模式。如果所有的節點都為主節點，那麼所有的節點都可以進行寫入操作，在這些節點中間通過Paxos協議進行選舉並且實現數據庫強一致性的同步。當其中的一個節點出現故障的時候，集群可以實現自動的故障轉移讓可用的節點來提供服務。目前的趨勢也是使用三節點，不光是Group Replication，包括阿裏雲數據庫金融版也默認使用三節點，在三個節點之間通過Raft協議來進行選舉以及數據一致性的同步。在有了這樣支持的前提之下，對於生產環境下的三節點服務而言，隻要大多數節點存活，那麼整體的數據庫服務就不會受到影響。

共享存儲案例：阿裏雲PolarDB
266ccb6d5ddb3cfed42c45f41c9e709c6ef79d04
使用共享存儲的策略並不是意味著不需要做高可用了，而是將計算和存儲進行分離，但是最終對於存儲還是需要實現高可用的。上圖中右側是阿裏雲PolarDB的例子，其上層是計算，下層是存儲。大家可以看到在PolarDB的存儲層是通過Raft實現了高可用的一致性數據同步，也就是說將整個數據同步下沉到存儲層，而之前往往都是在計算層實現的。那麼這樣做有什麼好處呢？因為存儲和計算的整個生命周期是不一樣的，比如數據庫是一個寫多讀少的場景，可能數據庫除了能夠提供線上服務還可以提供離線的數據分析服務，所以需要部署很多的數據節點。如果按照現在的架構，可能每個節點都存儲了一份數據，在實現共享存儲之後，可能隻存儲了三份數據，而計算節點可以根據訪問需求進行無限地擴展，達到了計算和存儲分開管理的目的。

第三招: 數據庫備份
以上的三個例子介紹了目前數據庫的高可用是怎樣實現的，接下來介紹如何實現數據庫的備份。很多人對於數據庫的備份存在著一個疑問：之前已經實現了數據庫三節點了，通過三節點已經將數據存儲了三份了，那麼為什麼還需要去做數據備份呢？其實一定是需要做備份的。這裏就需要談到做數據備份究竟有什麼樣的好處了，假設剛才實現了三節點數據庫的部署，這樣所能夠應對的場景就像三節點的其中一個節點的硬件出現故障了，這時候可以自動fail over，或者其中某一個節點因為軟件Bug導致整個數據庫崩潰了，但是還有多個節點可用，這樣整個數據庫服務仍舊是處於可用狀態。而備份所解決的問題卻是：對於剛才的場景，假如運維同學對於三節點數據庫做了誤操作，向主節點發送了“drop database”刪除數據庫的操作，這樣整個數據庫就會從主節點刪除掉了，同時這個刪除動作也會同步到備節點上去，也就是對於像誤刪這樣的場景，所有的節點上的數據都是會丟失的。還有就是類似於誤刪的黑客刪庫攻擊，也會將整個數據庫都刪除掉，而且這將會是無法恢複的。除此之外，如果發生了自然災害，或者整個機房出現了故障，數據也都會丟失，這時如果進行了數據庫的備份，以上的場景就都能夠覆蓋了。
86f1d751e50f2a7dc2de4c009f8807e60924c4e9
而在製定具體的備份策略的時候應該考慮兩點：第一點就是業務能夠容忍多長時間的數據丟失，如果能夠接受一天的數據丟失，那麼每天做一次全量的數據庫備份就可以了；如果對於數據丟失完全是零容忍的，那麼就需要去做任意時間點的數據備份，也就是說可以通過數據備份把數據恢複到任意一個時間點。除了數據能夠恢複到什麼程度，另外一點考量就是數據庫備份需要多長時間才能夠恢複，也就是所謂的RTO指標，這個指標決定了具體在做備份的時候是通過讀數據庫的文件做邏輯備份還是通過直接備份物理文件去實現物理備份。在做備份的時候有兩點比較重要的注意事項：首先，因為備份需要有一個對於數據庫的持續讀取過程，有時候可能會因為備份影響到數據庫的正常線上服務，也就是需要注意備份對於正常業務的影響；除此之外，備份的終極目標是當出現因為線上出現故障而需要使用備份數據的時候一定能夠恢複，所以在做了數據庫備份之後，一定要去做備份恢複的演練，來檢驗一下數據在備份之後到底能不能恢複。

全量備份方法
9f5535e9674c0714b35cc5d6e34c8535208cb527
接下來介紹具體的備份策略，首先介紹上麵所提到的全量備份，通過每天做一次全量備份就可以實現將數據恢複到一天的某個時間點。那麼全量備份應該如何實現呢？從整個數據庫的多個層次來介紹，上圖中的最上層是數據庫的邏輯層，其下層是文件係統層，最下麵一層就是塊設備以及卷管理層，這三層中的每一層都可以去做數據備份。首先，在數據庫邏輯層麵做備份，其實就是將數據庫中的數據全部讀取並且存儲下來，這就是通常所說的邏輯備份，目前開源數據庫已經可以提供很多工具來幫助實現邏輯全量備份。在文件係統層麵，可以拷貝整個數據庫的數據目錄，把數據目錄中的數據存儲下來做物理備份。再往底層到卷管理和塊設備層，如果使用的是LVM可以直接使用其卷管理的snapshot功能，如果使用的是雲主機，各大雲廠商也提供相應的snapshot功能，比如阿裏雲的ECS就提供了snapshot功能，通過這樣功能實現定期的全量備份也是非常容易的。

邏輯備份 vs 物理備份
邏輯備份和物理備份的區別以及對於數據的影響存在多大的差異呢？我們又應該如何選擇數據庫備份策略的時候呢？下圖就為大家進行了簡單對比，從五個維度來對於邏輯備份和物理備份進行對比。
68e62e11603536d861d96d67bee11b33da01d0db
首先，從備份效率上來看，邏輯備份因為需要調用數據庫的接口來逐條地讀取數據庫中的數據使得整個效率比較低，而物理備份則是直接拷貝數據庫文件，所以其備份效率是相對比較高的。從恢複效率上進行對比，也就是對比進行數據恢複的時候所需要的時間，邏輯備份如果是將整個備份集存儲到雲端，那麼在恢複的時候就需要將備份集下載下來並且逐條地導入到數據庫中去，而如果使用的是物理備份方法則隻需要將數據目錄下載下來並且啟動整個進程就可以了，所以在恢複效率方麵也是物理備份比較高。從備份影響上來看，因為邏輯備份會需要直接與數據庫的訪問競爭資源，所以其整個影響是比較大的，而物理備份的影響是比較間接地，因為它是從在另外一個進程裏麵進行數據拷貝，所以其影響相對較小。對於備份集而言，其規模越大，保存這些備份數據所需要的成本也越高。從備份集的大小來看，邏輯備份通常會與整個數據庫的大小一致或者比數據庫更小，因為對於數據庫而言，不僅僅有數據還會有索引等其他內容，而對於索引這樣的內容，其實可以隻對於一些元數據進行備份，在進行數據恢複的時候可以根據這些元數據建立索引，而不是將所有的索引數據都進行備份，這樣可以使得整個備份集比原來的數據庫小一些，而物理備份的備份集大小卻一定是與原來數據庫大小一致的。最後，對於備份兼容性而言，邏輯備份的整體兼容性是比較好的，因為數據庫訪問接口是全向兼容的，所以使用邏輯備份即使跨數據庫版本也是可以恢複的，而使用物理備份時，因為數據庫隨著版本升級，可能數據庫存儲的布局發生了變化，這樣低版本的數據備份到了高版本數據庫中就可能無法恢複。根據以上五個方麵的對比，用戶可以根據自己的需求來選擇數據備份策略。

增量備份方法
bcc14c98c4be746a260b52a1d9fa8f7e17517828
接下來分享增量備份方法。增量備份其實就可以幫助我們將自己的數據恢複到某一個時間點，如果業務能夠接受一天或者幾個小時的數據恢複，其實采用全量備份就足夠了。如果想要達到任意時間點的恢複，就還需要做增量備份，將增量備份和全量備份配合起來就可以實現任意時間點的備份。增量備份方法的原理也比較簡單，首先每天做一次數據庫的全量備份，之後把對於數據庫的每條更改的binlog都備份下來，接下來如果需要進行恢複的話，就可以使用最近的一次全量備份數據並且重放binlog一直到所需要恢複到的時間點就可以實現任意時間點的恢複。這部分的數據備份也存在很多工具，所以有需求的同學可以更加深入地研究。

三、阿裏雲數據庫為你的數據保駕護航
接下來介紹阿裏雲的數據庫是如何實現數據安全防護的，其實阿裏雲數據庫安全防護也是基於上述的安全配置、高可用部署以及數據備份這三個策略。阿裏雲數據庫——ApsaraDB目前的數據庫產品已經支持了整個DB Engine排名前十的絕大部分數據庫，比如關係型數據庫的MySQL、SQL Server、PG以及NoSQL數據庫中的MongoDB、Redis以及HBase等。
3ff8071332e01f634cf63731007662cb74c06665

ApsaraDB 安全體係總覽
下圖是ApsaraDB安全體係的總覽，主要分為了三個維度：最內側的框表示的是ApsaraDB在單節點上所做的安全工作，比如鏈路加密、訪問鑒權以及防止SQL注入等；這一層往上就是在單節點實現了安全配置之後的高可用部署，最外麵一層就是在高可用基礎之上做的數據備份以及機房容災工作。
9da4def709f256fb38ab553115a1052a6366f686

ApsaraDB 數據安全特性
326656b4fe5c26690f15754884b9541902ecd967
首先，對於單個節點的數據庫安全配置而言，目前ApsaraDB支持如下的特性：
  1. 在數據庫接收請求開始就支持SSL鏈路加密，也就是說可以配置數據庫使得所有請求的網絡數據都是加密的，這樣可以免除數據被抓包的風險，還能避免中間人攻擊。
  2. 當加密的數據到達數據庫，開始處理用戶請求之後，還提供了鑒權以及白名單策略。首先鑒權是默認開啟的，如果用戶希望使更多的服務器能夠訪問數據庫就需要去開啟白名單，通過鑒權+白名單這兩個策略來盡量地避免非法訪問。
  3. 在通過了鑒權和白名單之後還會進行SQL檢測，因為SQL訪問可能包含像SQL注入這樣的攻擊，所以需要對於用戶的SQL進行防止注入的檢測。
  4. 同時，如果配置了審計日誌就會把所有的訪問都記錄到審計日誌裏麵，有了審計日誌之後，所有的請求以及所有數據庫的操作都是有據可查的並且是可以回溯的。
  5. 在最底層數據存儲到磁盤的時候還可以配置TDE存儲加密，這樣使得最終的數據以密文的形式存儲到磁盤中，這樣即使對方拿到數據文件也無法讀取其中的數據。
  6. 最後，阿裏雲還會提供數據保險服務，用戶可以為自己的數據庫購買保險，當出現黑客攻擊、數據庫被破壞的情況發生時，可以獲得一定的賠付。

總結而言，對於整體安全策略而言，在故障發生之前，通過SSL、鑒權等策略盡量避免非法請求進入數據庫。當訪問進來之後，通過SQL檢測，在事中對於安全策略進行加固，盡量地避免攻擊。在事後，通過審計日誌將訪問請求都記錄下來，更好地發現攻擊以及誤刪等問題。最後，通過第三方數據保險使得用戶在數據丟失時獲得一定的經濟補償，來彌補所受到的損失。以上這些就是阿裏雲ApsaraDB單節點上的數據庫安全特性。

ApsaraDB 高可用
8853c02728ecb435620f045276d50a12e47739fc
接下來介紹在單節點安全配置完成之後ApsaraDB如何實現高可用。ApsaraDB的產品形態是非常豐富的，有建議在測試環境使用的單節點、主備高可用的雙節點產品、針對金融場景的三節點產品以及即將上線的共享存儲產品，那麼針對如此之多的產品形態，實現高可用的策略也將會是不一樣的。這裏會有一個統一的HA Manager來做所有數據庫產品的高可用，而HA Manager本身也是一個高可用的係統，它會根據不同的產品形態進行可用性探測，比如對於主備雙節點數據庫產品而言，當發現主節點故障的時候把備節點切換成為主節點，而如果是三節點數據庫集群，則可以自己通過Raft達到高可用，並且通過自身實現fail over。對於這樣的情況，HA Manager則不需要做太多的工作，隻需要把整個集群狀態做一個同步就可以了，共享存儲也會有對應的策略。通過全局的HA Manager來達到ApsaraDB的高可用，最終的目的就是實現當節點出現故障的時候，能夠在秒級實現故障轉移。在實現高可用的同時，無論是單節點還是主備節點，都會默認配置數據備份動作。

ApsaraDB 任意時間點備份恢複
5738612e7673bbd764abc857a7c8e9ef35438cfa
上圖所展現的就是ApsaraDB在任意時間點進行數據備份恢複的係統架構。ApsaraDB會默認對於用戶的數據庫實例進行全量備份，同時還會持續地采集用戶數據庫的每一條變更的Binlog以及操作日誌，這樣就可以實現任意時間點的恢複。在備份的時候，為了盡量減少數據備份對於線上服務的影響，所有的備份都默認地從備節點執行的。之前提到的Gitlab的案例，其數據做了備份，但是從來沒有演練過，最終導致備份數據不能使用，而在阿裏雲上存在專門的數據庫備份恢複演練係統，它會持續地針對線上的實例來定期地做數據備份演練，這樣就不至於出現當數據庫出現故障時無法通過備份恢複的尷尬情況。

ApsaraDB 容災
f0b39207a644e810b6b42d9f0630faf934f71004
除了實現數據備份，ApsaraDB還提供了容災策略。這裏提供了兩種策略，第一種是ApsaraDB支持跨可用區的實例，也就是一個一主多備的數據庫實例可以跨多個可用區進行部署。這樣即使單個可用區的機房出現故障的時候，其他可用區的機房也不會受到影響，可以把整個服務轉移到另外的可用區。而一主多備的策略可以保證在某一個時刻至少有一個節點是活躍的。除了這個策略，ApsaraDB最近還推出了異地多活的容災模式，用戶可以在多個Region裏購買數據庫實例，阿裏雲在後台將通過數據庫同步服務自動地保持Region之間數據庫實例的數據處於同步狀態。同步的狀態就是可以配置一個為主節點一個為備節點，也可以配置兩個都為主節點並使他們之間數據相互同步，這樣就能夠達到兩個機房的主數據雙活的狀態，即便一個機房出現故障的時候，整個業務也可以切換到另外的機房來實現實時的容災，從而可以避免像之前提到的爐石傳說因為機房故障所造成的服務停止。

ApsaraDB 源碼能力 + 專家服務
739c17cdc18cb3edc84915b880a79a13fdf22988
麵對軟件故障，其實可以通過高可用來實現故障轉移。而數據庫也是軟件，有時也會遇到一些導致數據丟失的Bug，而很多用戶卻沒有那麼強大的技術能力來修複數據庫源碼級別的Bug，而阿裏雲數據庫團隊具有強大的源碼能力，能夠進行數據庫源碼的開發，這裏包括了開源數據庫的源碼開發以及像基於MySQL的AliSQL這樣的自研數據庫的源碼開發。除此之外，阿裏雲數據庫團隊還能夠提供專家服務，當用戶在使用阿裏雲數據庫時出現了問題可以聯係專家服務團隊的同學幫助解決。總而言之，阿裏雲數據庫擁有一套完備的數據安全防護體係，當你遇到自己無法解決的問題時，阿裏雲數據庫背後的強大技術團隊可以為你提供技術支撐。

最後更新：2017-09-02 01:33:42

  上一篇：go  映客直播技術實戰：直播平台的數據庫架構演變
  下一篇：go  Greenplum數據庫，分布式數據庫，大數據