SQL Server 巨量資料叢集的主要版本
適用於:SQL Server 2019 (15.x)
重要
Microsoft SQL Server 2019 巨量資料叢集附加元件將會淘汰。 SQL Server 2019 巨量資料叢集的支援將於 2025 年 2 月 28 日結束。 平台上將完全支援含軟體保證 SQL Server 2019 的所有現有使用者,而且軟體將會持續透過 SQL Server 累積更新來維護,直到該時間為止。 如需詳細資訊,請參閱公告部落格文章 (英文) 與 Microsoft SQL Server 平台上的巨量資料選項 (部分機器翻譯)。
此文章提供如何針對 HDFS 與 SQL Server 金鑰的金鑰管理與金鑰輪替在 SQL Server 巨量資料叢集中使用金鑰版本的詳細資料。 該文章包含版本如何納入客戶金鑰 (部分機器翻譯) 的詳細資料。
如需保護 SQL Server 巨量資料叢集的一般資訊,請參閱 SQL Server 巨量資料叢集的安全性概念 (部分機器翻譯)。
如需設定及使用待用加密功能的相關資訊,請參閱下列指南:
HDFS 金鑰
在 HDFS 中使用待用加密涉及下列概念:
- 加密區域 (EZ):加密區域是 HDFS 中與金鑰相關聯的資料夾。 系統會加密此資料夾中的所有檔案。 SQL Server 巨量資料叢集中預設佈建的 EZ 稱為「安全湖」。
- 加密區域金鑰 (EZ 金鑰):具名對稱金鑰。 SQL Server 巨量資料叢集中佈建的預設系統管理為「安全湖金鑰」。 加密區域金鑰是使用 Hadoop KMS (金鑰管理伺服器) 來管理的,而 Hadoop KMS 在 SQL Server 巨量資料叢集加密的名稱節點 Pod 內執行。 EZ 金鑰進一步由儲存在 controldb (將在下列各節中討論) 中的主要加密金鑰所保護。 EZ 金鑰會在 Hadoop KMS 中加密,方法是擷取主要加密金鑰的公開部分,而解密要求會傳送至控制平面。
- 加密的資料加密金鑰:加密區域中的每個檔案都會由為檔案產生的資料加密金鑰 (DEK) 加密。 一旦建立 DEK,其就會隨著資料保存下來。 為保存 DEK,其會先由加密區域金鑰加密,然後隨著資料保存下來。 系統會為每個檔案隨機產生 DEK,而對稱 DEK 的強度會與 EZ 金鑰的強度相同。
下圖說明 DEK 如何保護檔案,以及 EZ 金鑰安全湖金鑰如何保護 DEK。
SQL Server 金鑰
系統管理的主要加密金鑰與 HDFS EZ 金鑰會儲存在 controldb 內,其會命名為 controldb-<#>,例如 controldb-0
。 如需詳細資訊,請參閱使用巨量資料叢集部署的資源 (部分機器翻譯)。
系統會以對稱金鑰 (亦稱為資料加密金鑰 (DEK)) 加密 SQL Server 資料庫。 DEK 會以加密格式隨著資料庫保存下來。 DEK 保護裝置可以是「憑證」或「非對稱金鑰」。 若要變更 DEK 保護裝置,請使用 ALTER DATABASE ENCRYPTION KEY 陳述式。 SQL Server 中的非對稱金鑰具有包含控制平面內金鑰 URL 連結的中繼資料。 因此,資料庫加密金鑰 (DEK) 的所有加密與解密作業都會在該控制器內完成。 SQL Server 會儲存公開金鑰,但只會針對識別非對稱金鑰的目的而儲存,而且不會使用公開金鑰來加密。
SQL Server 巨量資料叢集主要加密金鑰
在 SQL Server 巨量資料叢集控制平面中,為保護加密區域金鑰金鑰,以及在 SQL Server 中佈建非對稱金鑰,因此有主要加密金鑰的概念。 有兩個主要加密金鑰,一個用於 SQL Server,而另一個則用於 HDFS。 此概念可讓 SQL Server 巨量資料叢集控制平面允許主要加密金鑰存也在於叢集外部。 主要加密金鑰的屬性如下:
- 主要加密金鑰是非對稱 RSA 金鑰。
- 主要加密金鑰是針對 SQL Server 主要執行個體而建立,而另一個則是針對 HDFS 而建立。
- 對應至主要加密金鑰的公開金鑰一律會儲存在控制器資料庫或 controldb 中。 私密金鑰會儲存在系統管理的主要加密金鑰的控制器資料庫中。 針對來自硬體安全模組 (HSM) 或任何其他外部提供者的加密金鑰,私密金鑰不會儲存在控制器資料庫中 (除非外部金鑰的應用程式帶著私密金鑰)。 不過,controldb 內不需要私密金鑰,而且 SQL Server 巨量資料叢集不需要私密金鑰資料。
- 使用主要加密金鑰的公開金鑰進行加密作業可以在控制器本身內執行,或者控制器可以將公開金鑰散發至 Hadoop KMS,讓 Hadoop KMS 可以在本機執行加密。 解密作業預期應由外部金鑰提供者 (例如 HSM) 處理。 此設計可讓我們將非對稱金鑰的敏感部分保留在叢集外部並交由客戶保護。 這可確保客戶設定金鑰的 SQL Server 巨量資料叢集生態系統中一律不會提供用來解密所有資料的加密根目錄。
不同金鑰的儲存體保護
HDFS 檔案和 SQL Server 的 DEK 會隨著 DEK 所保護的資料一起儲存。 DEK 會分別由 HDFS EZ 金鑰或 SQL Server 中的非對稱金鑰保護。
SQL Server 中的非對稱金鑰具有包括控制平面中金鑰 URL 的中繼資料。 SQL Server 只會儲存非對稱金鑰的公開金鑰,以便與控制平面中的金鑰相互關聯。
controldb 中金鑰的儲存體會由 controldb 中的資料行加密金鑰保護。 controldb 會儲存與叢集相關的敏感性資訊,而且所有敏感性資訊都會由 controldb 中 SQL Server 的資料行加密金鑰保護,而資料行加密金鑰則進一步由儲存在 Kubernetes 祕密中的密碼保護。 如需詳細資訊,請參閱 Kubernetes 中的祕密文件 (英文)。
下圖摘要說明保護。 首先,HDFS EZ 金鑰的儲存體保護:
主要加密金鑰的儲存體保護:
金鑰輪替
HDFS 加密區域金鑰
使用 Active Directory 部署 SQL Server 巨量資料叢集時,系統會使用稱為「安全湖」(由「安全湖金鑰」所保護) 的預設加密區域來佈建 HDFS。 我們將在範例中使用預設值,不過可以使用 azdata
來佈建新的區域與金鑰。 「安全湖金鑰」由 HDFS 的主要加密金鑰保護,此主要加密金鑰儲存在控制平面中。 從 SQL 2019 CU9 開始,azdata
可用來輪替 HDFS 的 EZ 金鑰。 EZ 金鑰的輪替會導致產生新的金鑰資料,其名稱與「 安全湖金鑰」相同,但具有指向金鑰資料的新版本金鑰。 HDFS 中的任何新加密作業 (例如,檔案寫入),EZ 一律會使用與 EZ 相關聯的最新版金鑰。 針對 EZ 中由舊版金鑰保護的檔案,可以使用 azdata bdc hdfs encryption-zone reencrypt
命令,讓所有檔案都可以由最新版的 EZ 金鑰保護。
請考慮名為 file2 且放在 /securelake 中的檔案。 下面描述保護鏈結。
安全湖金鑰可以使用 azdata bdc hdfs key roll -n securelakekey
來輪替為新的版本。 輪替不會導致重新加密保護檔案的 DEK。 Hadoop 金鑰輪替會導致產生新的金鑰資料,並由最新版的主要加密金鑰保護。 下圖顯示安全湖金鑰輪替後的系統狀態。
為確保加密區域中的檔案受到輪替後安全湖金鑰的保護,請執行 azdata bdc hdfs encryption-zone -a start -p /securelake
。
下圖描述將加密區域重新加密後的系統狀態。
SQL Server
保護 SQL Database 的金鑰是可重新產生的 DEK。 重新產生的流程會導致系統重新加密整個資料庫。
主要加密金鑰輪替
注意
在 SQL Server 2019 CU10 之前,無法輪替主要加密金鑰。 從 SQL Server 2019 CU10 開始,我們公開了允許輪替主要加密金鑰的 azdata
命令。
主要加密金鑰是 RSA 2048 位元金鑰。 主要加密金鑰的輪替會根據金鑰的來源執行下列其中一個動作:
- 如果發出將主要金鑰輪替為系統管理金鑰的要求,則建立新的金鑰。 系統管理的金鑰是非對稱金鑰,這是在控制器內產生並儲存。
- 建立外部提供金鑰的參考,其中非對稱金鑰的私密金鑰將由客戶應用程式管理。 客戶應用程式不需要私密金鑰,但應該要知道如何根據所提供的應用程式設定來擷取私密金鑰。
主要金鑰的輪替不會重新加密任何項目。 接著必須輪替 SQL Server 與 HDFS 金鑰:
- 輪替主要金鑰之後,SQL Server 資料庫 DEK 保護裝置將必須輪替為所建立主要金鑰的新版本。
- 類似的概念也適用於 HDFS。 輪替 HDFS 金鑰時,新資料會由主要金鑰的最新版本加密。 較舊的 EZ 金鑰版本會維持不變。 在輪替 HDFS EZ 金鑰之後,必須重新加密與 EZ 金鑰相關聯的加密區域,以便由最新的 EZ 金鑰版本將其重新加密。
HDFS 的主要金鑰輪替
下圖說明針對 HDFS 輪替主要加密金鑰的流程。 首先,HDFS 的初始狀態:
主要加密金鑰將會使用 azdata bdc kms set –key-provider SystemManaged
來輪替。 (請注意,此命令會導致同時針對 SQL 與 HDFS 輪替主要加密金鑰,即使它們是控制平面內的不同金鑰亦然。) 使用 azdata bdc kms
命令之後:
若要使用新版本的 HDFS 主要加密金鑰,可以使用 azdata bdc hdfs key roll
命令,此命令接著會讓系統進入下列狀態。 輪替安全湖金鑰之後:
輪替安全湖金鑰會導致建立新版本的安全湖金鑰,並受到主要加密金鑰的保護。 若要確定安全湖中的檔案已由 securelakekey@2 加密,必須重新加密安全湖加密區域。 將加密區域重新加密之後:
SQL Server 的主要金鑰輪替
SQL Server 主要加密金鑰安裝在 SQL Server 主要執行個體的 master 資料庫中。
下圖說明針對 SQL Server 輪替主要加密金鑰的流程。
在全新安裝的 SQL Server 巨量資料叢集上,SQL Server 中不會佈建非對稱金鑰。 在 SQL Server 的初始狀態中,資料庫可能會使用憑證進行加密,不過 SQL Server 主要執行個體管理員會控制這個層面。
主要加密金鑰將會使用 azdata bdc kms set –key-provider SystemManaged
來輪替。 (請注意,此命令會導致同時針對 SQL 與 HDFS 輪替主要加密金鑰 (若沒有主要加密金鑰存在則會加以建立),即使它們是控制平面內的不同金鑰亦然。)
您可以使用下列 T-SQL 查詢並搭配 sys.asymmetric_keys
系統目錄檢視來查看非對稱金鑰。
USE master;
select * from sys.asymmetric_keys;
非對稱金鑰將會以命名慣例「tde_asymmetric_key_<version>」顯示。 SQL Server 管理員接著可以使用 ALTER DATABASE ENCRYPTION KEY,將 DEK 的保護裝置變更為非對稱金鑰。 例如,使用下列 T-SQL 命令:
USE db1;
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY tde_asymmetric_key_0;
現在,DEK 保護裝置已變更為使用非對稱金鑰:
如果重新執行 azdata bdc kms set
命令,則 SQL Server 中的非對稱金鑰會以「tde_asymmetric_key_sys.asymmetric_keys
version<」格式顯示 > 中的另一個項目。 azdata
命令可用來再次變更 SQL Server 資料庫的 DEK 保護裝置。
客戶提供的金鑰
使用將外部金鑰帶入 SQL Server 巨量資料叢集的功能,主要加密金鑰會使用客戶部署的應用程式來擷取公開金鑰。 輪替並使用 HDFS 金鑰時,系統會使用客戶所提供的金鑰識別碼,將解密 HDFS 金鑰的呼叫傳送至控制平面,然後重新導向至應用程式。 針對 SQL Server,系統會傳送加密的要求,而加密的要求會由控制平面完成,因為其具有公開金鑰。 從 SQL 解密 DEK 的要求也會傳送至控制平面,然後重新導向至 KMS 應用程式。
下圖說明在控制平面中設定外部金鑰時的互動:
安裝金鑰之後,不同承載的加密與解密會由主要加密金鑰保護。 此保護類似於系統管理的金鑰,不同之處在於解密呼叫會路由傳送至控制平面,然後路由傳送至 KMS 外掛程式應用程式。 KMS 外掛程式應用程式會將要求路由傳送至適當的位置,例如 HSM 或其他產品。