雲上資料庫安全新挑戰-行控

雲技術是IT產業界的一場技術變革。雲給市場帶來一種更加便宜、更加高效、更加靈活的IT解決方案。雲的解決方案已經被越來越多的使用者所認可和採納。我國政府明確提出雲技術是我國未來資訊化產業發展的重點領域。

在我國雲技術依舊處於成長期階段。據統計 2017年中國雲端計算機市場規模已經達到2602億美元，增長率為18.5%，預計到2020年公有云規模將達到4114億美元。隨著雲業務相關技術的成熟。安全成為雲下一階段主要面臨的挑戰。

現今成熟的雲平臺已經基本解決使用者身份、憑證、系統漏洞、拒絕服務等多類安全問題。但在資料洩露上還有很多不足。除去內鬼造成資料洩露外，最常見的是由於資料讀取許可權設定細粒度不足導致。RDS做為雲上資料主要儲存場景，如何做細粒度控制，將成為各個雲廠商面臨的重要挑戰。對於行存資料庫，行控是最關鍵的細粒度控制。加強RDS的行控能力，是杜絕資料洩露的有效手段。

行控-RDS安全缺失

RDS是雲上資料庫的簡稱。大部分中小企業使用者的核心資料會儲存在RDS中。RDS大部分是MySQL資料庫。我們走訪了大量雲廠商，簡化掉複雜的雲機制，大部分雲廠商租給中小企業的RDS其實是以資料庫例項為單位出租的。在一臺實體物理機上有多個虛擬機器，每臺虛擬機器上有多個程序。每個程序對應一個mysqld。每個mysqld都對應不同的埠和資料庫配置檔案。每一個啟動的Mysqld都對應一個例項。使用者租用的RDS就是一個數據庫例項。每個使用者通過雲平臺訪問到自己被分配的資料庫例項中。

這種以例項為單位切割RDS和使用者的方式，依賴資料庫自身的特點。有效規避了，因為使用者誤操作導致資料庫崩潰，而影響到另一使用者使用資料庫的問題。同時由於從例項層就分割，可以有效的保障不同使用者的資料儲存的邏輯位置是相互分離，避免了惡意讀取或修改他人資料的問題。

早先雲上業務模型較為簡單，隨著業務的複雜度上升。只依賴資料庫自身的許可權切割，難以滿足使用者對資料庫中資料的細粒度控制需求。很多現場需求中，客戶要求同一張表中區分出保密資料、敏感資料和公開資料。不同的使用者訪問表，只能訪問到當前使用者有許可權訪問的資料。例如下圖表中紅色框對應的是保密資料、藍色對應的是敏感資料、黑色對應的是公開資料。資料庫賬號分為三種:第一種是可以訪問保密資料、敏感資料和公開資料的tom賬號、第二種是隻能訪問敏感資料和公開資料的 cat賬號。第三種是隻能訪問公開資料的dog賬號。

RDS上資料庫賬號的許可權控制只能到表級，而現實中省級資料中心從各個地方採集到的資料不會因為安全級別不同，而彙總到不同的表中。所以RDS現在的權控體系和客戶的安全需求產生了一定的差距。如果能讓RDS從表變成行控，則會解決此類安全需求。

一.  RDS行控-檢視法

RDS資料庫最簡單實現行控的方法是採用檢視+觸發器的方法來，限制使用者訪問全部表。整體思路是假設有表A是用來記錄資料的。我們給表A重名成表B。在建立檢視A。利用資料庫語法不區分檢視和表的特性。使原來對錶A（改名成表B）的操作遷移到檢視A上進行。而檢視A，在讀取表B的時候，完成了對錶B內容的過濾。防止保密資料被使用者讀取。

上述雖然解決了讀的問題，但同是也引起了寫的問題。於是引入觸發器C當寫檢視A的時候，再通過觸發器C。把寫檢視A的操作變成寫表B。具體流程如下圖所示：

紅色部分是準備階段。準備階段首先會把表A重名成表B。接著會根據表B建立檢視A。最後會部署觸發器C解決針對檢視A的寫，轉移到表B上。

綠色部分是讀過程，當用戶讀取資料時，首先會訪問檢視A。檢視A中有過濾的物件，保證從B中讀取的資料已經剔除保密資料。最後返回給使用者使用。

紫色部分是寫過程，當用戶寫入資料時，首先會向檢視A寫。檢視A會利用觸發器C把寫操作轉移給表B。最終表B被寫入資料。

利用檢視+觸發器可以解決一部分RDS行控的需求。實際上這種方案，雖然可以做到應用透明，但只適合保密資料特徵明顯、分類清晰。資料安全層級不復雜的場景。資料安全層級複雜會導致整個設計思路過度複雜，效能等問題也會暴露，在某些場景下這種方案完全不能使用。

二.  RDS行控-改SQL法

除了上述這種完全依賴資料庫自身機制實現RDS行控的方案外。還有些使用了改SQL的方式。在向資料庫發包的過程中，通過一個過濾元件，對SQL語句進行改寫。也可以達到過濾保密資料的目的。

如上圖所示當用戶訪問表A時，經過一個客戶配過策略的過濾器。過濾器會把SQL語句改寫。保證財務部（保密資料）不會被非授權使用者查詢到。從而達到RDS行控的目的。

這種方法本質是在資料之外，新增額外的控制產品達到增強資料庫權控的目的。這種方法比檢視法更加靈活、複雜度低、不會造成資料異常。部署起來也更加簡單。但根據策略修改SQL的效能和準確性，在某些複雜場景下可能會存在一些問題。

三.  RDS行控-過濾法

過濾法和上面的改SQL法正好相對應。改SQL法，改的是輸入的SQL，而過濾法改的是返回的結果集。返回的結果集，經過結果集過濾器。通過規則進行結果集的過濾。

這種針對結果集的過濾方案是現在雲上最常用的方法。使用者在訪問資料庫目標表後，通過一個結果集過濾器，按照使用者的需求對保密資料進行刪除，最終顯示公開資料。

這種方案好處是，在應用側部署對資料庫影響小。可以做成支援多種資料庫的通用方案。但問題是這種方案是把資料庫的行控制轉移到應用去做，這個過程中就可能已經出現數據洩露。而且由於過濾的方法基本是關鍵字算hash的方法。這種方法天生存在被hash碰撞的安全風險。把資料庫的行控能力遷移到應用中做是一種工程的手段，並不會加強RDS的安全性，甚至還給資料洩露留下伏筆。並且效率也是需要著重考慮的問題。

四.  RDS行控-安全標籤法

安全標籤法主要是在RDS上做的一種安全增強功能。這種方案是通過在目標表中新增偽列實現的。給表中的每一行新增偽列，偽列標明這一行的安全等級。給資料庫賬號新增可以訪問的安全等級的標籤。只有賬號擁有足夠安全等級的標籤才可以訪問到相關的資料。

表會在使用者設完策略後新加偽列這一列，如上圖的第三列，偽列專門標記出每一行的安全等級。安全標籤法可以讓使用者靈活的自定義安全等級。做出更適合實際應用場景的安全級別。安全標籤策略應該處在資料庫語法解析中。首先判斷資料庫賬號和表以及操作之間的許可權關係。如果通過許可權檢查，就應該通過安全標籤部分，識別真正能讀取的資料範圍。然後生成執行計劃。最後執行sql，拿到結果，完成整個查詢過程。查詢的內容符合查詢使用者所支援的安全等級。

上述四種方法：檢視法、改SQL法、過濾法和安全標籤法都在一定程度上可以實現RDS的行控需求。這四種方法使用的場景各不相同。但總體來說檢視法設定較為複雜、靈活性低是四種方法中適用面最窄的實現RDS行控的方案。其次改SQL法雖然靈活性比檢視法強，但容易被儲存過程等其他SQL執行方式繞過，也難以成為適應性高的RDS行控解決方案。過濾法是現在使用最廣泛的RDS行控解決方案。這種方式雖然在一定程度上解決了檢視法和改SQL法存在的問題。但由於權控被前移到應用側，資料庫還是會返回敏感資料。依舊存在較大的安全風險。但這種方案只能認為是RDS行控的工程解決方案。並不是一種徹底的解決方案。相比前三種方案安全標籤法是最佳的RDS行控增強方案。這個方案有廣闊的適用空間，同時真正把權控做在資料庫中。避免了資料庫到應用傳遞過程中出現的資料洩露問題。