1、云數據庫安全現狀及問題

伴隨著云基礎設施的快速增長和成熟,與之對應的云數據庫服務也層出不窮。一方面,受益于云服務的便捷性傳統企業加速業務上云,通過充分發揮云數據庫特有的輕松部署、高可靠、低成本等優勢降低企業運營成本,加速企業應用創新;另一方面,以蘋果iCloud服務為代表的存儲服務和云計算服務為移動消費者帶來應用便捷性,利用云側的數據庫服務存儲海量消費者的個人數據。

云數據庫儼然已成為數據庫業務未來重要的增長點,絕大多數的傳統數據庫服務廠商正在加速提供更優質的云數據庫服務。但無論是傳統的線下數據庫服務,還是日益增長的云數據庫服務,數據庫的核心任務都是幫助用戶存儲和管理數據,在復雜多樣的環境下,保證數據不丟失、隱私不泄露、數據不被篡改以及服務不中斷。這就要求數據庫具備多層次的安全防御機制,用來抵抗來自內部和外部的惡意攻擊行為。事實上,經過數據庫的長期發展,已經構建了體系化的安全能力,比如通過數據庫防火墻的入侵防御以及基于AI的攻擊識別及智能防御,做到“攻不破”;通過在數據庫服務端實現強認證機制,達到攻擊者“進不來”;通過完善的權限管理模型、對象訪問控制及校驗機制做到惡意用戶“拿不走”;通過數據加密存儲機制或數據靜態脫敏及動態脫敏機制實現對關鍵數據的保護,確保數據在被非法竊取后攻擊者“看不懂”;通過多副本備份,融合區塊鏈思想實現類賬本系統能力,做到“改不了”;通過系統內部細粒度審計機制,記錄用戶操作行為,達到攻擊行為“賴不掉”。除了傳統數據庫廠商本身在提升自己的能力外,許多專業化的評估測試機構也在幫助數據庫廠商挖掘產品缺陷,加速完善數據庫安全能力的構建,并出具專業化評估報告,作為第三方背書讓用戶“信得過”。這些成熟的安全技術手段,構建了數據庫縱深防御的安全體系,保障數據庫在應用中的安全。一個完整的防御架構如圖1所示。

 

 

圖1:傳統數據庫多層級安全防御架構

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

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

2、全密態數據庫與數據全生命周期保護

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

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

 

 

圖2:全密態數據庫核心業務數據流

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

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

3、全密態數據庫核心思路與挑戰

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

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

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

 

 

圖3:REE與TEE邏輯關系圖

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

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

4、GaussDB(openGauss)全密態數據庫解決方案

4.1 開創性自適應架構打造首款支持軟模式密態計算

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

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

 

 

圖4:GaussDB全密態數據庫架構

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

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

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

GaussDB 全密態數據庫解決方案創新性的解決了多個技術難點,實現了對用戶無感知、數據加密無泄漏等核心競爭力。

4.2 全自動加密驅動實現用戶數據庫操作無感知

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

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

 

 

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

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

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

 

 

圖6:主流硬件隔離方案

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

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

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

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

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

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

整個全密態數據庫解決方案中除數據本身具有敏感性質外,最為敏感的信息就是數據加解密密鑰,一旦密鑰泄露,將給用戶數據帶來嚴重風險。特別是在硬件模式下,密鑰需離開用戶側,傳輸到云側可信硬件環境中,其安全保護至關重要。GaussDB通過實現三層密鑰體系,讓各層密鑰各司其職,真正做到密鑰高強度的安全保護。

 

 

圖7:GaussDB高強度密鑰體系

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

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

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

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

5、全密態數據庫的未來

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

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