共用方式為

SQL Server 巨量數據叢集中的主要版本

適用於：SQL Server 2019 (15.x)

Important

MICROSOFT SQL Server 2019 巨量數據叢集已淘汰。 SQL Server 2019 巨量數據叢集的支援已於 2025 年 2 月 28 日結束。 如需詳細資訊，請參閱 Microsoft SQL Server 平臺上的公告部落格文章和巨量數據選項。

本文提供如何在 SQL Server 巨量數據叢集中使用金鑰版本的詳細數據，以用於 HDFS 和 SQL Server 金鑰的金鑰管理和金鑰輪替。 本文包含版本如何 納入客戶金鑰的詳細數據。

如需保護 SQL Server 巨量數據叢集的一般資訊，請參閱 SQL Server 巨量數據叢集的安全性概念。

如需設定和使用待用加密功能的詳細資訊，請參閱下列指南：

HDFS keys

若要在 HDFS 中使用静态加密，需要下列概念：

  • 加密區域 （EZ）：加密區域是 HDFS 中與金鑰相關聯的資料夾。 此資料夾中的所有檔案都會加密。 SQL Server 巨量數據叢集中的預設布建 EZ 稱為“securelake”。
  • 加密區金鑰（EZ 金鑰）：具名對稱金鑰。 在 SQL Server 大數據叢集中，默認配置的系統管理鍵是 "securelakekey"。 加密金鑰是使用在 SQL Server 巨量資料叢集名稱節點 Pod 內執行的 Hadoop KMS（金鑰管理伺服器）來管理。 EZ 金鑰會受到儲存在 controldb 中的主要加密金鑰進一步保護（如下節所述）。 EZ 金鑰會藉由擷取主要加密密鑰的公用部分來加密，並透過 Hadoop KMS 將解密要求傳送至控制平面。
  • 加密的數據加密金鑰：加密區域中的每一個檔案都會由針對檔案產生的數據加密密鑰 （DEK） 加密。 建立 DEK 之後，它會與數據一起保存。 若要保存 DEK，請先由加密區域金鑰加密，然後與資料一起保存。 DEK 會隨機產生每個檔案，而對稱 DEK 的強度與 EZ 金鑰的強度相同。

下圖說明如何保護 DEK 的檔案，以及 DEK 如何受到 EZ 密鑰 securelakekey 的保護。

顯示檔案如何被 DEK 保護，以及 DEK 如何被 EZ 金鑰 securelakekey 保護

SQL Server 金鑰

系統管理的主要加密密鑰和 HDFS EZ 金鑰會儲存在 controldb-<#> 中，例如 controldb-0。 如需詳細資訊，請參閱 使用巨量數據叢集部署的資源。

SQL Server 資料庫是由對稱金鑰加密，也稱為資料庫加密密鑰 （DEK）。 DEK 會以加密格式保存資料庫。 DEK 保護裝置可以是 憑證 或 非對稱密鑰。 若要變更 DEK 保護裝置，請使用 ALTER DATABASE ENCRYPTION KEY 語句。 SQL Server 中的非對稱金鑰具有元數據，其中包含控制平面內密鑰的 URL 連結。 因此，資料庫加密金鑰 （DEK） 的所有加密和解密作業都會在控制器內完成。 SQL Server 會儲存公鑰，但只能識別非對稱密鑰，且不會使用公鑰進行加密。

SQL Server 金鑰

SQL Server 巨量數據叢集的主要加密金鑰

在 SQL Server 巨量數據叢集控制平面中，若要保護加密區域密鑰，以及在 SQL Server 中佈建非對稱密鑰，有主要加密密鑰的概念。 主要加密密鑰有兩個，一個用於 SQL Server，一個用於 HDFS。 此概念可讓 SQL Server 巨量數據叢集控制平面允許主要加密金鑰位於叢集外部。 主要加密金鑰的屬性如下：

  1. 主要加密金鑰是非對稱 RSA 金鑰。
  2. 針對 SQL Server 主要實例和 HDFS 建立另一個主要加密密鑰。
  3. 對應至主要加密金鑰的公鑰一律會儲存在控制器資料庫或 controldb 中。 私鑰會儲存在系統管理的主要加密金鑰的控制器資料庫中。 對於來自硬體安全性模組（HSM）或任何其他外部提供者的加密金鑰，私鑰不會儲存在控制器資料庫內（除非外部密鑰的應用程式攜帶私鑰）。 不過，controldb 內不需要私鑰，而 SQL Server 巨量數據叢集不需要私鑰數據。
  4. 使用主要加密金鑰的公鑰進行加密作業可以在控制器本身內執行，或者控制器可以將公鑰散發至 Hadoop KMS，讓 Hadoop KMS 可以在本機執行加密。 解密作業應該由外部密鑰提供者處理，例如 HSM。 此設計可讓我們將非對稱密鑰的敏感性部分保留在叢集外，並在客戶的保護之下。 這可確保解密所有數據的根目錄永遠不會在 SQL Server 巨量數據叢集生態系統中針對客戶設定的密鑰使用。

不同金鑰的記憶體保護

HDFS 檔案和 SQL Server 的 DEK 會與 DEK 保護的數據一起儲存。 DEK 會分別受到 SQL Server 中的 HDFS EZ 金鑰或非對稱金鑰的保護。

SQL Server 中的非對稱金鑰具有元數據，包括控制平面中的密鑰 URL。 SQL Server 只會儲存非對稱金鑰的公鑰，以便與控制平面中的密鑰相互關聯。

controldb 中密鑰的儲存會受到 controldb 中的數據行加密金鑰保護。 controldb 會儲存叢集的敏感性資訊，而且所有敏感性信息都會受到 controldb 中 SQL Server 的數據行加密密鑰保護，該密鑰會進一步受到儲存在 Kubernetes 秘密中的密碼保護。 如需詳細資訊，請參閱 Kubernetes 檔中的秘密。

下圖摘要說明保護措施。 首先，HDFS EZ 金鑰的記憶體保護：

HDFS EZ 金鑰的記憶體保護

主要加密金鑰的記憶體保護：

主要加密金鑰的記憶體保護

Key rotation

HDFS 加密區域金鑰

使用 Active Directory 部署 SQL Server 巨量數據叢集時，HDFS 會以名為 securelake 的預設加密區域布建，並由 securelakekey 保護。 我們將依例使用預設值，但是可以使用azdata來佈署新的區域和密鑰。 securelakekey 受到 HDFS 的主要加密金鑰保護，該密鑰會儲存在控制平面中。 從 SQL 2019 CU9 開始， azdata 可用來輪替 HDFS 的 EZ 金鑰。 EZ 金鑰的輪替會導致產生新的密鑰材料，其名稱與“securelakekey”相同，但新的密鑰版本指向此密鑰材料。 HDFS 中的任何新加密作業（例如檔案寫入），EZ 一律會使用與 EZ 相關聯的最新版密鑰。 對於受舊版密鑰保護的 EZ 檔案， azdata bdc hdfs encryption-zone reencrypt 可以使用 命令，讓所有檔案都可以受到最新版 EZ 金鑰的保護。

請考慮將名為 file2 的檔案放在 /securelake 中。 下列描述保護鏈結。

Protection chain

securelakekey 可以使用 azdata bdc hdfs key roll -n securelakekey 更新至新版本。 輪替不會對保護檔案的 DEK 進行重新加密。 Hadoop 金鑰輪替會導致產生新的金鑰數據，並受到最新版 main-encryption-key 的保護。 下圖顯示 securelakekey 旋轉之後系統的狀態。

輪替後的保護鏈結

若要確保加密區域中的檔案受到輪替的 securelakekey 保護， azdata bdc hdfs encryption-zone -a start -p /securelake。

下圖描述加密區域重新加密之後的系統狀態。

重新加密之後的保護鏈結

SQL Server

保護 SQL Database 的金鑰是可重新產生的 DEK。 再生過程會導致整個資料庫重新加密。

主要加密金鑰輪替

Note

在 SQL Server 2019 CU10 之前，無法輪替主要加密密鑰。 從 SQL Server 2019 CU10 開始， azdata 命令會公開以允許輪替主要加密密鑰。

主要加密金鑰是 RSA 2048 位金鑰。 主要加密金鑰的輪替會根據金鑰的來源執行下列其中一項動作：

  1. 如果請求是將主要密鑰轉換至系統管理的密鑰，建立新的密鑰。 系統管理的金鑰是非對稱金鑰，產生並儲存在控制器內。
  2. 建立外部提供的金鑰參考，其中非對稱金鑰的私鑰將由客戶應用程式管理。 客戶應用程式不需要私鑰，但應該知道如何根據所提供的應用程式組態來擷取私鑰。

主要金鑰的旋轉不會重新加密任何事物。 然後必須輪替 SQL Server 和 HDFS 金鑰：

  • 輪替主要密鑰之後，必須將 SQL Server 資料庫的 DEK 保護器更新為新的主要密鑰版本。
  • 類似的概念適用於 HDFS。 輪替 HDFS 金鑰時，新數據會由最新版的主要密鑰加密。 舊版的 EZ 金鑰會維持不變。 輪替 HDFS EZ 金鑰之後，必須重新加密與 EZ 金鑰相關聯的加密區域，才能由最新的 EZ 金鑰版本重新加密。

HDFS 的主要金鑰輪替

下圖說明輪替 HDFS 的主要加密金鑰的程式。 首先，HDFS 的初始狀態：

HDFS 的初始狀態

主要加密金鑰將使用 azdata bdc kms set –key-provider SystemManaged 輪替。 （請注意，此命令會導致 SQL 和 HDFS 的主要加密密鑰輪替，即使它們是控制平面內的不同密鑰也一樣。使用 azdata bdc kms 命令之後：

使用 azdata bdc kms 命令之後

若要使用新版本的 HDFS 主要加密金鑰， azdata bdc hdfs key roll 可以使用 命令，然後讓系統進入下列狀態。 旋轉 securelakekey 之後：

旋轉

替換 securelakekey 會導致創建新版本的 securelakekey，並用主要加密密鑰進行保護。 若要確定 securelake 中的檔案已由securelakekey@2加密，必須重新加密 securelake 加密區域。 重新加密加密區域之後：

重新加密加密區域之後

SQL Server 的主要密鑰輪替

SQL Server 主要加密金鑰會安裝在 SQL Server 主要實例的主資料庫中。

下圖說明輪替 SQL Server 的主要加密金鑰的程式。

在全新安裝 SQL Server 巨量數據叢集時，SQL Server 中不會佈建非對稱密鑰。 在 SQL Server 的初始狀態中，資料庫可能會使用憑證來加密，不過 SQL Server 主要實例管理員會控制這個層面。

SQL Server 的初始狀態

主要加密金鑰將使用 azdata bdc kms set –key-provider SystemManaged 輪替。 請注意，即使 SQL 和 HDFS 在控制平面中是不同的密鑰，此命令仍會導致兩者的主要加密金鑰輪替（或在不存在的情況下創建）。

SQL Server 主要加密金鑰會安裝在 SQL Server 主要實例的主要資料庫中

您可以使用下列 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 保護裝置已變更為使用非對稱密鑰：

在 DEK 保護裝置變更為使用非對稱金鑰之後

如果azdata bdc kms set重新執行命令，則 SQL Server 中的非對稱密鑰會以 「tde_asymmetric_key_sys.asymmetric_keysversion<」 格式顯示另一個條目>。 此命令 azdata 可用來再次變更 SQL Server 資料庫的 DEK 保護裝置。

客戶提供的金鑰

透過在 SQL Server 巨量資料叢集中引進外部金鑰的功能，主要加密密鑰會使用客戶部署的應用程式來擷取公鑰。 輪替和使用 HDFS 金鑰時，系統會將解密 HDFS 金鑰的呼叫傳送至控制平面，然後使用客戶提供的密鑰標識元重新導向至應用程式。 針對 SQL Server，加密的要求會由控制平面傳送並滿足，因為它具有公鑰。 從 SQL 解密 DEK 的要求也會傳送至控制平面，然後重新導向至 KMS 應用程式。

安裝客戶金鑰之後

下圖說明在控制平面中設定外部按鍵時的互動：

在控制平面中設定外部按鍵時的互動

安裝金鑰之後，不同承載的加密和解密會受到主要加密金鑰的保護。 此保護類似於系統管理的密鑰，不同之處在於解密呼叫路由傳送至控制平面，然後會路由傳送至 KMS 外掛程式應用程式。 KMS 外掛程式應用程式會將請求路由到適當的地方，例如 HSM 或其他產品。

See also

  • Last updated on