數據安全無小事：揭祕華爲雲GaussDB(openGauss)全密態數據庫

摘要：全密態數據庫，專門處理密文數據的數據庫系統，數據以加密形態存儲在數據庫服務器中，數據庫支持對密文數據的檢索與計算。

一、雲數據庫安全現狀及問題

伴隨着雲基礎設施的快速增加和成熟，與之對應的雲數據庫服務也層出不窮。一方面，受益於雲服務的便捷性傳統企業加速業務上雲，經過充分發揮雲數據庫特有的輕鬆部署、高可靠、低成本等優點下降企業運營成本，加速企業應用創新；另外一方面，以蘋果iCloud服務爲表明的存儲服務和雲計算服務爲移動消費者帶來應用便捷性，利用雲側的數據庫服務存儲海量消費者的我的數據。

雲數據庫儼然已成爲數據庫業務將來重要的增加點，絕大多數的傳統數據庫服務廠商正在加速提供更優質的雲數據庫服務。但不管是傳統的線下數據庫服務，仍是日益增加的雲數據庫服務，數據庫的核心任務都是幫助用戶存儲和管理數據，在複雜多樣的環境下，保證數據不丟失、隱私不泄露、數據不被篡改以及服務不中斷。這就要求數據庫具有多層次的安全防護機制，用來抵抗來自內部和外部的惡意攻擊行爲。

事實上，通過數據庫的長期發展，已經構建了體系化的安全能力，好比經過數據庫防火牆的入侵防護以及基於AI的攻擊識別及智能防護，作到「攻不破」；經過在數據庫服務端實現強認證機制，達到攻擊者「進不來」；經過完善的權限管理模型、對象訪問控制及校驗機制作到惡意用戶「拿不走」；經過數據加密存儲機制或數據靜態脫敏及動態脫敏機制實現對關鍵數據的保護，確保數據在被非法竊取後攻擊者「看不懂」；經過多副本備份，融合區塊鏈思想實現類帳本系統能力，作到「改不了」；經過系統內部細粒度審計機制，記錄用戶操做行爲，達到攻擊行爲「賴不掉」。

除了傳統數據庫廠商自己在提高本身的能力外，許多專業化的評估測試機構也在幫助數據庫廠商挖掘產品缺陷，加速完善數據庫安全能力的構建，並出具專業化評估報告，做爲第三方背書讓用戶「信得過」。這些成熟的安全技術手段，構建了數據庫縱深防護的安全體系，保障數據庫在應用中的安全。一個完整的防護架構如圖1所示。

圖1：傳統數據庫多層級安全防護架構

雖然數據庫安全功能越作越強，但這些安全技術手段都是針對傳統數據庫所面臨的威脅構建的。做爲面向開放市場的雲數據庫服務，其所面臨的風險相較於傳統數據庫更加多樣化，更加複雜化，不管是應用程序漏洞、系統配置錯誤，仍是惡意管理員均可能對數據安全與隱私保護形成巨大風險。

雲數據庫，其部署網絡由「私有環境」向「開放環境」轉變，系統運維管理角色被拆分爲業務管理員和運維管理員。業務管理員擁有業務管理的權限，屬於企業業務方，而運維管理員屬於雲服務提供商。數據庫運維管理員雖然被定義成系統運維管理，其實際依舊享有對數據的徹底使用權限，經過運維管理權限或提權來訪問數據甚至篡改數據；再者因爲開放式的環境和網絡邊界的模糊化，用戶數據在整個業務流程中被更充分的暴露給攻擊者，不管是傳輸、存儲、運維仍是運行態，都有可能遭受來自攻擊者的攻擊。所以對於雲數據庫場景，如何解決第三方可信問題，如何更加可靠的保護數據安全相比傳統數據庫面臨着更大挑戰，其中數據安全、隱私不泄露是整個雲數據庫面臨的首要安全挑戰。

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

二、全密態數據庫與數據全生命週期保護

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

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

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

根據該業務數據流能夠看出，全密態數據庫的核心思想是：用戶本身持有數據加解密密鑰且數據加解密過程僅在客戶側完成，數據以密文形態存在於數據庫服務側的整個生命週期過程當中，並在數據庫服務端完成查詢運算。

因爲整個業務數據流在數據處理過程當中都是以密文形態存在，經過全密態數據庫，能夠實現：(1)保護數據在雲上全生命週期的隱私安全，不管數據處於何種狀態，攻擊者都沒法從數據庫服務端獲取有效信息；(2)幫助雲服務提供商獲取第三方信任，不管是企業服務場景下的業務管理員、運維管理員，仍是消費者雲業務下的應用開發者，用戶經過將密鑰掌握在本身手上，使得高權限用戶沒法獲取數據有效信息；(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的計算資源分配與高效調度問題，也是硬件方案面臨的一大挑戰。

四、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環境，只在會話期間存在，結束馬上釋放，最小化數據密鑰生命週期，防止因代碼漏洞或異常狀況引發的密鑰泄露。

五、全密態數據庫的將來

全密態數據庫技術理念拋開了傳統的多點技術單點解決數據風險的問題，經過系統化思惟創建了一套可以覆蓋數據全生命週期的安全保護機制。這套機制使得用戶在無感知的狀況下就解決了數據的安全隱私保護，對於攻擊者和管理者來講都沒法獲取有效信息。全密態數據庫是數據庫安全隱私保護的高級防護手段，但全密態數據庫在當前仍存在必定的侷限性，仍須要突破算法安全性和性能損耗等相關問題。

全密態數據庫在實際應用中建議僅針對敏感數據進行使用，經過藉助於數據庫自己提供的多方位數據保護機制，爲不一樣等級的數據提供不一樣層級的安全機制，從而構建全方位的數據安全保護機制。將來GaussDB會將該能力逐步開源到openGauss，與社區共同推動和完善全密態數據庫解決方案，一塊兒打造數據庫安全生態。

點擊關注，第一時間瞭解華爲雲新鮮技術~