圖1:傳統(tǒng)數(shù)據(jù)庫多層級安全防御架構

雖然數(shù)據(jù)庫安全功能越做越強,但這些安全技術手段都是針對傳統(tǒng)數(shù)據(jù)庫所面臨的威脅構建的。作為面向開放市場的云數(shù)據(jù)庫服務,其所面臨的風險相較于傳統(tǒng)數(shù)據(jù)庫更加多樣化,更加復雜化,無論是應用程序漏洞、系統(tǒng)配置錯誤,還是惡意管理員都可能對數(shù)據(jù)安全與隱私保護造成巨大風險。云數(shù)據(jù)庫,其部署網(wǎng)絡由“私有環(huán)境”向“開放環(huán)境”轉變,系統(tǒng)運維管理角色被拆分為業(yè)務管理員和運維管理員。業(yè)務管理員擁有業(yè)務管理的權限,屬于企業(yè)業(yè)務方,而運維管理員屬于云服務提供商。數(shù)據(jù)庫運維管理員雖然被定義成系統(tǒng)運維管理,其實際依舊享有對數(shù)據(jù)的完全使用權限,通過運維管理權限或提權來訪問數(shù)據(jù)甚至篡改數(shù)據(jù);再者由于開放式的環(huán)境和網(wǎng)絡邊界的模糊化,用戶數(shù)據(jù)在整個業(yè)務流程中被更充分的暴露給攻擊者,無論是傳輸、存儲、運維還是運行態(tài),都有可能遭受來自攻擊者的攻擊。因此對于云數(shù)據(jù)庫場景,如何解決第三方可信問題,如何更加可靠的保護數(shù)據(jù)安全相比傳統(tǒng)數(shù)據(jù)庫面臨著更大挑戰(zhàn),其中數(shù)據(jù)安全、隱私不泄露是整個云數(shù)據(jù)庫面臨的首要安全挑戰(zhàn)。

當前云數(shù)據(jù)庫數(shù)據(jù)安全隱私保護是針對數(shù)據(jù)所處階段來制定保護措施的,如在數(shù)據(jù)傳輸階段使用安全傳輸協(xié)議SSL/TLS,在數(shù)據(jù)持久化存儲階段使用透明存儲加密,在返回結果階段使用RLS(Row Level Security)或者數(shù)據(jù)脫敏策略。這些傳統(tǒng)技術手段可以解決單點風險,但不成體系,且對處于運行或者運維狀態(tài)下的數(shù)據(jù)則缺少有效的保護。面對越來越復雜的云環(huán)境,我們需要一種能夠徹底解決數(shù)據(jù)全生命周期隱私保護的系統(tǒng)性解決方案。事實上,近年來學術界以及工業(yè)界陸續(xù)提出了許多創(chuàng)新思路:數(shù)據(jù)離開客戶端時,在用戶側對數(shù)據(jù)進行加密,且不影響服務端的檢索與計算,從而實現(xiàn)敏感數(shù)據(jù)保護,此時即便數(shù)據(jù)庫管理員也無法接觸到用戶側的密鑰,進而無法獲取明文數(shù)據(jù)。這一思路被稱為全密態(tài)數(shù)據(jù)庫解決方案,或全加密數(shù)據(jù)庫解決方案。

2、全密態(tài)數(shù)據(jù)庫與數(shù)據(jù)全生命周期保護

全密態(tài)數(shù)據(jù)庫,顧名思義與大家所理解的流數(shù)據(jù)庫、圖數(shù)據(jù)庫一樣,就是專門處理密文數(shù)據(jù)的數(shù)據(jù)庫系統(tǒng)。數(shù)據(jù)以加密形態(tài)存儲在數(shù)據(jù)庫服務器中,數(shù)據(jù)庫支持對密文數(shù)據(jù)的檢索與計算,而與查詢任務相關的詞法解析、語法解析、執(zhí)行計劃生成、事務ACID、數(shù)據(jù)存儲都繼承原有數(shù)據(jù)庫能力。

在全密態(tài)數(shù)據(jù)庫機制下,一個用戶體驗良好的業(yè)務數(shù)據(jù)流圖如下圖1所示。假定數(shù)據(jù)列c1已以密文形態(tài)存放在數(shù)據(jù)庫服務端,用戶發(fā)起查詢任務指令。用戶發(fā)起的查詢任務無需進行特殊化改造,對于查詢中涉及的與敏感數(shù)據(jù)c1相關聯(lián)的參數(shù),在客戶端按照與數(shù)據(jù)相同的加密策略(加密算法,加密密鑰等)完成加密,如圖1中關聯(lián)參數(shù)“123”被加密成“0xfe31da05”。參數(shù)加密完成后整個查詢任務被變更成一個加密的查詢任務并通過安全傳輸通道發(fā)到數(shù)據(jù)庫服務端,由數(shù)據(jù)庫服務端完成基于密文的查詢檢索。檢索得到的結果仍然為密文,并最終返回客戶端進行解密。

圖2:全密態(tài)數(shù)據(jù)庫核心業(yè)務數(shù)據(jù)流

根據(jù)該業(yè)務數(shù)據(jù)流可以看出,全密態(tài)數(shù)據(jù)庫的核心思想是:用戶自己持有數(shù)據(jù)加解密密鑰且數(shù)據(jù)加解密過程僅在客戶側完成,數(shù)據(jù)以密文形態(tài)存在于數(shù)據(jù)庫服務側的整個生命周期過程中,并在數(shù)據(jù)庫服務端完成查詢運算。

由于整個業(yè)務數(shù)據(jù)流在數(shù)據(jù)處理過程中都是以密文形態(tài)存在,通過全密態(tài)數(shù)據(jù)庫,可以實現(xiàn):(1)保護數(shù)據(jù)在云上全生命周期的隱私安全,無論數(shù)據(jù)處于何種狀態(tài),攻擊者都無法從數(shù)據(jù)庫服務端獲取有效信息;(2)幫助云服務提供商獲取第三方信任,無論是企業(yè)服務場景下的業(yè)務管理員、運維管理員,還是消費者云業(yè)務下的應用開發(fā)者,用戶通過將密鑰掌握在自己手上,使得高權限用戶無法獲取數(shù)據(jù)有效信息;(3)使能合作伙伴,通過全密態(tài)數(shù)據(jù)庫可以讓合作伙伴借助全密態(tài)能力更好的遵守個人隱私保護方面的法律法規(guī)。

3、全密態(tài)數(shù)據(jù)庫核心思路與挑戰(zhàn)

正如全密態(tài)數(shù)據(jù)庫定義所描述的那樣,全密態(tài)數(shù)據(jù)庫的核心任務是保護數(shù)據(jù)全生命周期安全并實現(xiàn)基于密文數(shù)據(jù)的檢索計算。在加密算法足夠安全的情況下,外部攻擊者及內部管理員均無法獲取有效的數(shù)據(jù)信息。

對于用戶來說,從已有數(shù)據(jù)庫服務切換成全密態(tài)數(shù)據(jù)庫或者直接將應用部署于全密態(tài)數(shù)據(jù)庫,需要解決三個主要的問題:(1)如何保障密態(tài)計算機制的安全性,全密態(tài)數(shù)據(jù)庫從原理上可以有效保障數(shù)據(jù)安全,但這要求密文數(shù)據(jù)檢索及運算的算法在機理和工程上要達到該原理要求;(2)如何進行業(yè)務的無縫遷移或者輕量化遷移,全密態(tài)數(shù)據(jù)庫最顯著的特征是數(shù)據(jù)存儲信息的變更,那與加密數(shù)據(jù)相關的各類參數(shù)都要同步進行變更,否則會因為計算數(shù)據(jù)形態(tài)的不對等導致查詢紊亂;(3)如何避免服務切換所帶來的性能損耗,本質上需要將加密算法實現(xiàn)和工程實現(xiàn)所產(chǎn)生的性能回退控制在一個合理的范圍內,避免因為不合理的數(shù)據(jù)加解密和數(shù)據(jù)存儲膨脹帶來性能急速下降。只有解決這三個關鍵問題,才能真正的推動全密態(tài)數(shù)據(jù)庫落地。

目前,全密態(tài)數(shù)據(jù)庫在學術界和工業(yè)界均有研究和嘗試,主要聚焦于兩種解決方案:(1)密碼學解決方案,或稱為純軟解決方案,通過設計滿足密文查詢屬性的密碼學算法來保證查詢的正確性,如已知常見的OPE(Order Preserving Encryption)算法,數(shù)據(jù)加密后仍保留順序屬性;(2)硬件方案,通過可信執(zhí)行環(huán)境(TEE, Trusted Execution Environment)來處理REE(Rich Execution Environment,REE與TEE相對應)環(huán)境中的密文數(shù)據(jù)運算,圖3展示了ARM架構下的TEE與REE的對應關系。無論是密碼學解決方案還是現(xiàn)有的硬件方案都有他們各自的優(yōu)缺點。

圖3:REE與TEE邏輯關系圖

密碼學方案的核心思路是整個運算過程都是在密文狀態(tài),通過基于數(shù)學理論的算法來直接對密文數(shù)據(jù)進行檢索與計算。該方案需要解決在用戶不感知的條件下,實現(xiàn)密文數(shù)據(jù)的安全、高效檢索與計算,當前的主要挑戰(zhàn)在兩個方面:一方面學術界當前主要的密碼學算法,大部分都是基于功能實現(xiàn)及安全能力的考慮,對于內外存儲、網(wǎng)絡吞吐、計算消耗等性能指標都會有不同的劣化,甚至有些性能完全脫離了實際場景,因此如何能在數(shù)據(jù)密文狀態(tài)下實現(xiàn)檢索和計算,并且滿足性能要求,是密碼學方案的最大挑戰(zhàn);另一方面,通常一種數(shù)學算法只能解決部分業(yè)務場景,如何將多種密碼學算法融合,以實現(xiàn)數(shù)據(jù)庫查詢和計算的主要功能,也是密碼學方案的一大挑戰(zhàn)。

硬件方案的核心思路是將存放于REE側的加密數(shù)據(jù)傳遞給TEE側,并在TEE側完成數(shù)據(jù)解密和計算任務(見圖3),依賴TEE的“隔離性”或“對REE側應用的不可見性”實現(xiàn)數(shù)據(jù)計算過程的安全保護。一方面,受限于TEE空間的大小(如SGX v1僅提供128MB可用空間、基于ARM TrustZone方案一般也僅提供幾十MB空間),難以處理大量數(shù)據(jù)和復雜操作,這就要求TEE內僅關注關鍵敏感數(shù)據(jù)的查詢操作,降低攻擊面;另一方面由于REE與TEE運行切換和數(shù)據(jù)交互帶來額外的開銷,因此需要解決整個運算過程中的REE與TEE的計算資源分配與高效調度問題,也是硬件方案面臨的一大挑戰(zhàn)。

4、GaussDB(openGauss)全密態(tài)數(shù)據(jù)庫解決方案

4.1 開創(chuàng)性自適應架構打造首款支持軟模式密態(tài)計算

全密態(tài)數(shù)據(jù)庫中的軟件方案和硬件方案目前均已取得了很多進展,特別的,工業(yè)界已開始在逐步采用硬件方案。借助諸如Intel SGX等安全硬件的TEE空間,對數(shù)據(jù)計算空間進行物理或邏輯隔離,實現(xiàn)數(shù)據(jù)對REE的“不可見”。但硬件方案目前存在兩個較大的缺陷:首先由于數(shù)據(jù)在TEE內部均為明文存在,因此數(shù)據(jù)的安全性完全依賴于硬件本身的安全性。目前針對硬件的攻擊方式如側信道攻擊等越來越多,但是一般硬件設備更新迭代周期較長,一旦出現(xiàn)漏洞無法及時更新修補,將直接導致用戶數(shù)據(jù)長時間暴露在風險之下。其次用戶在使用該特性時,密鑰需要離開客戶端環(huán)境發(fā)送給TEE使用,而該傳輸過程的安全直接依賴于硬件設備廠商的證書簽名,惡意的硬件設備廠商人員完全有能力攻擊并竊取用戶的數(shù)據(jù)及密鑰,因此硬件方案,也需要用戶在使用過程中,持續(xù)信任硬件設備廠商。

全密態(tài)數(shù)據(jù)庫的軟件方案目前在學術界發(fā)展較快,通過一系列數(shù)學算法在密文空間直接對密文進行查詢運算,保障數(shù)據(jù)隱私不泄露。軟件方案可以不依賴于硬件能力,也不需要在服務側獲取密鑰對數(shù)據(jù)進行解密,但當前也存在著在第三章節(jié)提到的巨大挑戰(zhàn)。

圖4:GaussDB全密態(tài)數(shù)據(jù)庫架構

在華為全連接大會上,華為正式發(fā)布基于GaussDB的全密態(tài)數(shù)據(jù)庫解決方案,該方案結合軟件模式與硬件模式各自的優(yōu)缺點,推出融合策略,實現(xiàn)硬件模式和軟件模式的自由切換,該方案支持全場景應用,包括公有云、混合云以及終端智慧業(yè)務,更為重要的是對終端用戶透明無感知。

在硬件模式下,GaussDB首先支持多硬件平臺能力,如Intel CPU的SGX能力,以及業(yè)內首創(chuàng)的華為自主研發(fā)鯤鵬ARM TrustZone能力。其次GaussDB實現(xiàn)了最小粒度的隔離級別,使得攻擊面最小化,并且通過一系列的密鑰安全保障機制,如多層密鑰管理體系、可信傳輸通道、會話級密鑰管理機制等,實現(xiàn)了硬件環(huán)境中的數(shù)據(jù)及密鑰安全,從而降低因硬件安全問題而導致的用戶數(shù)據(jù)及密鑰泄露風險。

由于硬件模式依賴于硬件及其生產(chǎn)廠商的安全和信譽,且用戶在實際使用過程中需要依賴特性硬件環(huán)境,GaussDB還開創(chuàng)性的支持了軟件模式的密態(tài)查詢能力,通過對多種密碼學算法的深度性能優(yōu)化,構建出不同的密態(tài)查詢引擎,以完成不同的檢索和計算功能,實現(xiàn)數(shù)據(jù)等值查詢、范圍查詢、保序查詢、表達式計算等特性。特別的,通過引入確定性加密機制,實現(xiàn)了數(shù)據(jù)的增刪改查、表字段關聯(lián)、等值檢索等基本操作;基于GS-OPE算法的密文索引技術,實現(xiàn)了數(shù)據(jù)密態(tài)保序查詢、表達式大小比較等常規(guī)操作;通過Range-Identify算法,實現(xiàn)數(shù)據(jù)密態(tài)范圍查詢。

GaussDB 全密態(tài)數(shù)據(jù)庫解決方案創(chuàng)新性的解決了多個技術難點,實現(xiàn)了對用戶無感知、數(shù)據(jù)加密無泄漏等核心競爭力。

4.2 全自動加密驅動實現(xiàn)用戶數(shù)據(jù)庫操作無感知

要實現(xiàn)在客戶端進行加解密,無疑需要在客戶端進行大量維護管理,包括數(shù)據(jù)密鑰管理,敏感數(shù)據(jù)加密,解析和修改SQL語句等。如果僅僅提供數(shù)據(jù)加密工具,由用戶來對數(shù)據(jù)進行顯式加密,一方面會增加用戶的開發(fā)成本,另一方面用戶也容易因數(shù)據(jù)加密不到位而造成數(shù)據(jù)泄露。

GaussDB將這一系列的復雜操作,全部封裝在客戶端加密驅動中,實現(xiàn)了完全自動化的敏感信息加密替換,同時在數(shù)據(jù)庫中存儲了所有加密相關的元信息,使得數(shù)據(jù)庫可以很好的識別和處理對應的加密數(shù)據(jù)。如圖5所示,由于SQL語句中與敏感信息相關的參數(shù)也被加密處理,使得發(fā)送至數(shù)據(jù)庫服務側的查詢任務(圖中ciphertext query)也不會泄露用戶查詢意圖,減少客戶端的復雜安全管理及操作難度,實現(xiàn)用戶應用開發(fā)無感知。另外,GaussDB提供一系列的配置接口,滿足用戶對加密字段、加密算法、密鑰安全存儲等不同場景的需要。GaussDB全密態(tài)數(shù)據(jù)庫的透明性使得用戶在任務遷移時將獲得極大的便捷性。

圖5:全自動客戶端加密驅動

4.3 利用算子級隔離顯著降低安全風險

當密文查詢進入數(shù)據(jù)庫內核之后,就需要依賴現(xiàn)有的查詢處理模塊來完成數(shù)據(jù)運算。對數(shù)據(jù)庫這種高度復雜的系統(tǒng),在硬件模式下,如何將敏感數(shù)據(jù)的檢索、計算等核心功能解耦隔離,放在安全環(huán)境中獨立運行,從而最小化敏感數(shù)據(jù)計算面臨的安全風險,一直是GaussDB的一個重大難題。

圖6:主流硬件隔離方案

當前業(yè)界主要有三種TEE隔離計算方案:數(shù)據(jù)庫級隔離、模塊級隔離、算子級隔離。這三種方案從攻擊面和工程實現(xiàn)維度來看,有顯著的差異。

數(shù)據(jù)庫級隔離,是在TEE中完整的建立一個特殊的數(shù)據(jù)庫引擎,將敏感數(shù)據(jù)的查詢請求直接發(fā)送給該數(shù)據(jù)庫進行全部的解析和執(zhí)行處理。該方案的架構比較清晰,實現(xiàn)簡單,安全性和可靠性直接依賴于TEE中數(shù)據(jù)庫的能力。然而,由于TEE中數(shù)據(jù)庫引擎的代碼規(guī)模較大,因此數(shù)據(jù)庫實例需要消耗更多的TEE側資源,且一旦由于潛在代碼缺陷導致在執(zhí)行過程出現(xiàn)嚴重錯誤,將導致出現(xiàn)TEE環(huán)境崩潰等嚴重后果。

模塊級隔離,是將SQL執(zhí)行器放到TEE中,實現(xiàn)對語句的執(zhí)行過程進行保護。執(zhí)行器是數(shù)據(jù)庫查詢語句的查詢任務執(zhí)行模塊,與數(shù)據(jù)庫級隔離相比,這種方式減小了TEE中的代碼規(guī)模,其安全性主要依賴于執(zhí)行模塊的安全能力。但該方式下仍有大量與敏感數(shù)據(jù)計算無關的操作將在TEE中運行,而這些操作都可能接觸到明文數(shù)據(jù),故而容易引入錯誤或者無意泄露敏感數(shù)據(jù),留下安全攻擊隱患。

算子級隔離。算子是機密數(shù)據(jù)計算的最小、最核心功能單元,如數(shù)據(jù)排序算子、表達式計算等。通過將密文算子放在TEE中執(zhí)行,可以針對性的對敏感數(shù)據(jù)進行重點保護,排除非敏感數(shù)據(jù)操作帶來的潛在風險,具有最小規(guī)模的代碼實現(xiàn)。但是其難度和挑戰(zhàn)并存:首先,數(shù)據(jù)庫的復雜性決定了將敏感數(shù)據(jù)的單一算子執(zhí)行過程進行解耦存在較大的挑戰(zhàn)性,傳統(tǒng)的pipeline執(zhí)行流程意味著單個算子執(zhí)行過程的連續(xù)性,針對算子執(zhí)行過程中的核心計算流程進行解耦就需要進行定向梳理;其次單個查詢語句通常涉及多個算子運算,整個查詢運算流程需要根據(jù)算子運算需求多次切換到TEE側環(huán)境,對性能造成影響。

為了追求極致的安全,GaussDB選擇了算子級隔離策略。為了解決算子級隔離的兩大問題,GaussDB全密態(tài)數(shù)據(jù)庫通過精心設計,成功實現(xiàn)了最小粒度的敏感數(shù)據(jù)檢索和計算模塊。同時,從多個層面對REE與TEE之間的world switch的性能和數(shù)據(jù)傳輸方式進行深度優(yōu)化,將性能影響降到最低。從而在顯著減小安全風險的同時,也有力地保障了數(shù)據(jù)庫系統(tǒng)的高效運行。

4.4 高強度密鑰體系保障密鑰安全

整個全密態(tài)數(shù)據(jù)庫解決方案中除數(shù)據(jù)本身具有敏感性質外,最為敏感的信息就是數(shù)據(jù)加解密密鑰,一旦密鑰泄露,將給用戶數(shù)據(jù)帶來嚴重風險。特別是在硬件模式下,密鑰需離開用戶側,傳輸?shù)皆苽瓤尚庞布h(huán)境中,其安全保護至關重要。GaussDB通過實現(xiàn)三層密鑰體系,讓各層密鑰各司其職,真正做到密鑰高強度的安全保護。

圖7:GaussDB高強度密鑰體系

第一層為數(shù)據(jù)密鑰,做到了字段級別,即針對不同的字段將采用不同的密鑰,同時對相同字段不同數(shù)據(jù)采用不同的鹽值,以實現(xiàn)不同字段之間的加密隔離,即使某一列數(shù)據(jù)的加密密鑰被泄露,也不會影響到其他數(shù)據(jù)安全,提升整體數(shù)據(jù)的安全性。

第二層為用戶密鑰,對不同用戶將使用不同的密鑰,以實現(xiàn)用戶之間的加密隔離,而且用戶密鑰永遠不會離開用戶可信環(huán)境;使得包括管理員在內的其他用戶,即便竊取了數(shù)據(jù)的訪問權限,也無法解密最終數(shù)據(jù)。

第三層為設備密鑰,即對不同的密鑰存儲設備或工具,使用不同的密鑰進行保護,實現(xiàn)設備間的加密隔離,大大增加了攻擊用戶密鑰存儲設備或工具破解密鑰的難度。

不僅如此,由于在硬件模式下,需要將字段級密鑰傳輸給硬件TEE環(huán)境使用。GaussDB在該場景下進行了更高強度的保護措施:首先,通過ECCDH協(xié)議安全協(xié)商和TEE內置證書簽名校驗,構建用戶側與TEE環(huán)境之間的可信通道,保證密鑰安全可信的加密傳輸,防止中間人攻擊;其次,密鑰不會以任何形式離開TEE環(huán)境,只在會話期間存在,結束立刻釋放,最小化數(shù)據(jù)密鑰生命周期,防止因代碼漏洞或異常情況引起的密鑰泄露。

5、全密態(tài)數(shù)據(jù)庫的未來

全密態(tài)數(shù)據(jù)庫技術理念拋開了傳統(tǒng)的多點技術單點解決數(shù)據(jù)風險的問題,通過系統(tǒng)化思維建立了一套能夠覆蓋數(shù)據(jù)全生命周期的安全保護機制。這套機制使得用戶在無感知的情況下就解決了數(shù)據(jù)的安全隱私保護,對于攻擊者和管理者來說都無法獲取有效信息。全密態(tài)數(shù)據(jù)庫是數(shù)據(jù)庫安全隱私保護的高級防御手段,但全密態(tài)數(shù)據(jù)庫在當前仍存在一定的局限性,仍需要突破算法安全性和性能損耗等相關問題。

全密態(tài)數(shù)據(jù)庫在實際應用中建議僅針對敏感數(shù)據(jù)進行使用,通過借助于數(shù)據(jù)庫本身提供的多方位數(shù)據(jù)保護機制,為不同等級的數(shù)據(jù)提供不同層級的安全機制,從而構建全方位的數(shù)據(jù)安全保護機制。未來GaussDB會將該能力逐步開源到openGauss,與社區(qū)共同推進和完善全密態(tài)數(shù)據(jù)庫解決方案,一起打造數(shù)據(jù)庫安全生態(tài)。

songjy