全部產品
Search
文件中心

PolarDB:概述

更新時間:Jul 06, 2024

本文主要介紹了PolarDB資料庫代理(Proxy)提供的全密態PolarMySQL功能。

前提條件

PolarDB資料庫代理版本需為2.8.36或以上。如何查看和升級當前資料庫代理版本,請參見小版本升級

背景資訊

隨著國家對資料安全和個人敏感資訊的加強監管,原子化的資料安全能力無法滿足監管要求,國家標準和行業標準逐漸提出資料全生命週期的安全保障的需求,傳統的三方安全強化和用戶端加密都在客戶成本、架構改造、資料庫效能等帶來了不同層面的弊端,因此全密態資料庫得到了快速發展和行業認可。  

從應用視角看,全密態資料庫可以解決不同應用情境下的資料安全問題,幾種典型情境如下:

  • 平台安全營運:該情境主要針對在不可信環境(如第三方平台)下提供的資料庫服務的安全防護,保證使用者資料在營運過程中的安全。例如,業務將應用程式資料庫遷移到雲上,需要應對雲平台以及營運人員越權訪問資料的潛在威脅;再如,資料應用需要將資料庫整體線下部署到客戶線下環境,需要防止資料被客戶營運非授權擷取。  

  • 敏感性資料合規:該情境主要針對在不可信環境(如第三方平台)下提供的應用服務的安全防護,保證終端使用者敏感性資料的安全。例如,企業使用第三方服務管理其商業資料時,需要應對商業秘密被服務商擷取的潛在威脅;再如,個人識別資料(PII)、基因等隱私資料在被第三方管理過程中,要滿足全程加密的合規要求。  

  • 多來源資料融合:該情境主要針對多來源資料的聯合分析,保證在多方資料融合計算時,資料不會被其他參與方擷取。例如,在聯合風控、跨國服務等情境下,有嚴格的資料合規要求,組織間無法進行明文資料的合規化擷取;再如,在合作營銷等情境下,存在組織間的既合作又競爭的複雜關係,難以進行明文資料共用。

功能介紹

  • 支援所有已有的SQL運算元,且應用透明無感知,升級“0”成本。僅需幾行配置即可切換到全密態用戶端驅動EncJDBC,已有業務代碼無需任何修改即可接入。具體配置過程請參見整合EncJDBC

  • 全密態MySQL也提供了EncDB SDK,應用可以基於商務邏輯,靈活調用SDK提供的安全介面。EncDB SDK的使用說明請參見整合EncDB SDK

  • 查詢結果加密返回,無懼資料庫帳號泄露、研發營運竊取資料。使用者可以基於業務需要,配置加密規則,指定需要被加密保護的敏感性資料;全密態資料庫在查詢返回標記的敏感性資料時,使用使用者密鑰,自動對敏感性資料進行加密,加密後內容僅持有密鑰的使用者可以解密獲得對應的明文內容。因此,即使資料庫帳號泄露,也無法看到查詢結果中的敏感性資料內容,甚至資料庫研發營運人員也只能看到密文查詢內容。

  • 支援使用者指定密鑰。使用者可以任意選擇信任的已有或者第三方Key Management Service,擷取期望密鑰後,動態傳遞給全密態用戶端。密鑰僅由使用者持有,運行時通過安全分發機制參與資料庫查詢,服務結束時自動銷毀,無需擔心密鑰被外部或者內部使用者竊取。

  • 效能貼近現有非密態資料庫效能。查詢效能與使用者指定的敏感欄位數量成反比,即查詢涉及敏感性資料越多,效能損耗響應增加。TPCC下測試分別對20%、50%、100%欄位加密的資料庫時,其效能分別為明文資料庫的93%、86%、79%。更多效能資料請參見全密態MySQL資料庫效能測試報告

應用情境

全密態雲資料庫的長期目標是設計和研發以資料機密性和完整性為原生能力的新型資料庫結構描述及系統產品。通過相應的設計最佳化和架構調整,在引入安全能力的同時,仍然保障資料庫系統的高效能、高穩定和低成本。

針對不同業務情境所面臨的不同資料安全問題,以下列舉了一些全密態雲資料庫適用的典型情境:

  • 應用服務面向資料庫服務的資料加密

    在一般的應用情境中,資料的擁有者即為應用服務方。他們希望防止資料庫服務及其營運人員接觸到任何應用資料,同時保證資料庫的正常運作。

  • 終端客戶面嚮應用服務的資料加密

    在面向終端使用者的應用情境中,部分資料(如健康資料、財務資料等)的擁有者為客戶本人。他們希望應用服務只提供資料管理和分析的能力,不能接觸私人明文資料。

  • 安全可靠的加密資料共用

    由於加密資料的密鑰只由資料擁有者持有,任何其他角色都無法接觸明文資料。在需要將部分資料與第三方分享時,使用者希望在不泄漏自身密鑰的前提下完成加密資料的分享,同時滿足合規要求。

image.png

注意事項

  • 加密規則在主地址上不生效,您需要使用叢集地址或自訂叢集地址。

  • 當前只支援普通的COM_QUERY,不支援COM_STMT_PREPARE等其它命令。EncJDBC只支援text protocol,並不支援binary protocol。在所有情況下,用戶端的prepared statament操作都通過text protocol來完成。

  • 當前加密功能與動態脫敏功能互斥,兩者不能同時開啟。

  • 如果之前已經開通過動態脫敏功能,則需要先把所有的脫敏規則先刪除掉,然後重建立立規則並選中規則類型為加密

  • 使用者指定密鑰後,目前暫不支援更新密鑰。整個資料庫叢集共用同一個使用者密鑰。

  • 請勿繞過資料庫代理Proxy(SecureGW)直接連接訪問原生MySQL Kernel,否則您的資料庫叢集將喪失Sensitive Data Discovery and Protection能力。此外,為防止惡意訪問,建議您開啟日誌審計等功能,通過日誌等管理手段進行事後審計追責。

使用方法

詳情請參見管理加密規則