靜態加密概念與配置指南

Important

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

從Microsoft SQL Server 2019 CU8 巨量數據叢集開始，待用加密功能可用來提供應用層級加密給儲存在平臺中的所有數據。本指南說明巨量數據叢集待用加密功能集的概念、架構和組態。

SQL Server 巨量數據叢集會將資料儲存在下列位置：

SQL Server 主要實例。
HDFS. 被儲存池和Spark使用。

有兩種方法可以透明加密 SQL Server 巨量數據叢集中的數據：

Volume encryption. Kubernetes 平台支援此方法。這是巨量數據叢集部署的最佳做法。本文未涵蓋磁碟區加密。請參閱 Kubernetes 平臺或應用裝置檔，以瞭解如何正確加密用於 SQL Server 巨量數據叢集的磁碟區。
應用層級加密。此架構是指在將數據寫入磁碟之前，由處理數據的應用程式來加密數據。如果磁碟區暴露，攻擊者將無法在其他地方還原數據物件，除非目的地系統也已使用相同的加密密鑰進行設定。

SQL Server 大數據叢集的靜態加密功能集支援 SQL Server 和 HDFS 元件在應用層級進行加密的核心情境。

此功能提供下列功能：

由系統管理的靜態加密。這項功能可在 CU8+ 中使用。
使用者管理的靜態加密，又稱攜帶您自己的密鑰（BYOK）。 SQL Server 2019 CU8 中引進了服務管理的整合。 SQL Server 2019 CU11+ 引進外部密鑰提供者整合。

如需詳細資訊，請參閱 SQL Server 巨量數據叢集中的主要版本。

Key definitions

SQL Server 巨量資料叢集金鑰管理服務（KMS）

由控制器主持的服務負責管理 SQL Server 巨量數據叢集靜默加密功能的金鑰和憑證。此服務支援下列功能：
- 安全管理和儲存用於靜態加密的密鑰和憑證。
- Hadoop KMS 相容性。 KMS 可作為巨量數據叢集上 HDFS 元件的密鑰管理服務。
- SQL Server 透明數據加密（TDE）憑證管理。
System-managed keys

巨量數據叢集 KMS 服務會管理 SQL Server 和 HDFS 的所有金鑰和憑證
User-defined keys

由巨量數據叢集 KMS 管理的使用者定義金鑰，通常稱為自備密鑰。 SQL Server 巨量數據叢集支援自定義金鑰定義，以用於 SQL Server 和 HDFS 元件上的加密。巨量數據叢集 KMS 會管理這些金鑰。

Caution

SQL Server 主要實例會繼承 SQL Server TDE 功能。不過，手動將自定義密鑰從檔案載入 Pod、在 SQL Server 上註冊，並針對 TDE 使用自定義金鑰並不是支援的案例。巨量數據叢集 KMS 不會管理這些金鑰。這種情況可能會導致您的資料庫無法讀取。若要正確使用外部提供的密鑰，請使用本文中所述的「外部提供者」功能。
External providers

支援與大數據叢集 KMS 相容的外部密鑰解決方案，為加密操作委派提供支持。 SQL Server 2019 CU11+ 支援此功能。啟用此功能后，加密的根密鑰會裝載於巨量數據叢集控制器外部。

SQL Server 巨量數據叢集上的靜態資料加密

巨量數據叢集 KMS 控制器服務支持系統管理的金鑰和外部提供者控制密鑰，以在 SQL Server 和 HDFS 上實現待用數據加密。

這些金鑰和憑證由服務管理。本文提供如何與服務互動的操作指南。

此功能集引進巨量數據叢集 KMS 控制器服務，為 SQL Server 和 HDFS 上的待用數據加密提供系統管理的金鑰和憑證。這些金鑰和憑證由服務管理。本文提供如何與服務互動的操作指南。

SQL Server 實例會使用已建立的透明數據加密（TDE）功能。
HDFS 會在每個 Pod 內使用原生 Hadoop KMS 來與控制器上的巨量數據叢集 KMS 互動。此方法可讓 HDFS 加密區域在 HDFS 上提供安全路徑。

SQL Server 實例

系統產生的憑證會安裝在要與 TDE 命令搭配使用的 SQL Server Pod 上。系統管理的憑證命名標準是 TDECertificate + timestamp。例如： TDECertificate2020_09_15_22_46_27 。
主要實例巨量數據叢集布建的資料庫和用戶資料庫將不會自動加密。資料庫管理員可能會使用已安裝的憑證來加密任何資料庫。
計算集區和存放集區會使用系統產生的憑證自動加密。
雖然在技術上可以使用 T-SQL EXECUTE AT 命令進行數據集區加密，但目前不建議且不受支援。使用這項技術來加密數據集區資料庫可能無效，且加密可能未在想要的狀態進行。此方法也會針對下一個版本建立不相容的升級路徑。
SQL Server 金鑰輪替是使用標準 T-SQL 系統管理命令來達成。如需詳細資訊，請參閱 SQL Server 巨量數據叢集透明數據加密（TDE）待用使用指南。
加密監視會透過適用於 TDE 的現有標準 SQL Server DMV 進行。
支援備份和還原已啟用 TDE 的資料庫到叢集。
支援高可用性。如果 SQL Server 主要實例上的資料庫已加密，則資料庫的所有次要複本也會加密。

HDFS 加密區域

需要 Active Directory 整合，才能啟用 HDFS 的加密區域。
系統產生的金鑰會在 Hadoop KMS 中佈建。機碼名稱為 securelakekey。在 CU8 上，預設金鑰為 256 位，且支援 256 位 AES 加密。
在名為 /securelake 的路徑上使用上述系統產生的密鑰來布建預設加密區域。
用戶可以使用本指南中提供的特定指示來建立其他密鑰和加密區域。用戶能夠在金鑰建立期間選擇 128、192 或 256 的金鑰大小。
HDFS 加密區域金鑰輪替是使用 azdata來達成。如需詳細資訊，請參閱 SQL Server 巨量數據叢集 HDFS 加密區域使用指南。
不支援在加密區域之上掛接 HDFS 階層處理。

靜態加密管理

下列列表包含靜態加密的管理能力：

SQL Server TDE 管理是使用標準 T-SQL 命令來執行。
HDFS 加密區域和 HDFS 金鑰管理是使用 azdata 命令來執行。
下列管理功能是使用操作筆記本來執行：
- HDFS 金鑰備份和復原
- HDFS 金鑰刪除

Configuration guide

在 SQL Server 巨量數據叢集的新部署期間，從 CU8 開始，預設會啟用並配置 靜態加密。 That means:

巨量數據叢集 KMS 元件會部署在控制器中，併產生一組預設的金鑰和憑證。
SQL Server 已開啟 TDE 部署，且由控制器安裝憑證。
HdFS 的 Hadoop KMS 已設定為與巨量資料叢集 KMS 互動以進行加密作業。 HDFS 加密區域已設定且可供使用。

上一節所述的需求和預設行為適用。

如果執行新的 SQL Server 巨量數據叢集 CU8 部署，或直接升級至 CU9，則不需要其他步驟。

Upgrade scenarios

在現有的叢集上，升級程式不會對尚未加密的用戶數據強制執行新的加密或重新加密。此行為是設計方式，且每個元件必須考慮下列問題：

SQL Server
- SQL Server 主要實例。升級程式不會影響任何主要實例資料庫和已安裝的 TDE 憑證。建議您在升級程式之前備份資料庫和手動安裝的 TDE 憑證。我們也建議您將這些工件儲存在巨量數據叢集之外。
- 計算和儲存池。這些資料庫是系統管理的、揮發性的，而且會在叢集升級時重新建立並自動加密。
- Data pool. 升級不會影響數據集區中 SQL Server 實例中的資料庫。
HDFS

升級程式不會觸及加密區域以外的 HDFS 檔案和資料夾。

從 CU8 或更早版本升級至 CU9

不需要其他任何步驟。

從 CU6 或更早版本升級至 CU8

Caution

升級至 SQL Server 巨量數據叢集 CU8 之前，請先執行數據的完整備份。

不會設定加密區域。 Hadoop KMS 元件不會設定為使用巨量數據叢集 KMS。若要在升級後設定及啟用 HDFS 加密區域，請遵循下一節中的指示。

升級至 CU8 之後啟用 HDFS 加密區域

如果您將叢集升級為 CU8 （azdata upgrade）並想要啟用 HDFS 加密區域，則有兩個選項：

執行名為 SOP0128 的 Azure Data Studio 作業筆記本- 啟用巨量數據叢集中的 HDFS 加密區域 來執行設定。
執行腳本，如下所示。

Requirements:

Active Directory 整合式叢集。
Azure 資料 CLI （azdata）以 AD 模式設定並登入叢集。

請遵循此程式，以重新設定支援加密區域的叢集。

完成升級azdata後，儲存下列腳本。

文稿執行需求：

這兩個腳本都應該位於相同的目錄中。
kubectl 在 $HOME/.kube 資料夾中 Kubernetes 的PATH組態檔上。

此指令本應命名 為 run-key-provider-patch.sh：

#!/bin/bash

if [[ -z "${BDC_DOMAIN}" ]]; then
  echo "BDC_DOMAIN environment variable with the domain name of the cluster is not defined."
  exit 1
fi

if [[ -z "${BDC_CLUSTER_NS}" ]]; then
  echo "BDC_CLUSTER_NS environment variable with the cluster namespace is not defined."
  exit 1
fi

kubectl get configmaps -n test

diff <(kubectl get configmaps mssql-hadoop-storage-0-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py) <(kubectl get configmaps mssql-hadoop-storage-0-configmap -n $BDC_CLUSTER_NS -o json | python -m json.tool)

diff <(kubectl get configmaps mssql-hadoop-sparkhead-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py) <(kubectl get configmaps mssql-hadoop-sparkhead-configmap -n $BDC_CLUSTER_NS -o json | python -m json.tool)

# Replace the config maps.
#
kubectl replace -n $BDC_CLUSTER_NS -o json -f <(kubectl get configmaps mssql-hadoop-storage-0-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py)

kubectl replace -n $BDC_CLUSTER_NS -o json -f <(kubectl get configmaps mssql-hadoop-sparkhead-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py)

# Restart the pods which need to have the necessary changes with the core-site.xml
kubectl delete pods -n $BDC_CLUSTER_NS nmnode-0-0
kubectl delete pods -n $BDC_CLUSTER_NS storage-0-0
kubectl delete pods -n $BDC_CLUSTER_NS storage-0-1

# Wait for sometime for pods to restart
#
sleep 300

# Check for the KMS process status.
#
kubectl exec -n $BDC_CLUSTER_NS -c hadoop nmnode-0-0 -- bash -c 'ps aux | grep kms'
kubectl exec -n $BDC_CLUSTER_NS -c hadoop storage-0-0 -- bash -c 'ps aux | grep kms'
kubectl exec -n $BDC_CLUSTER_NS -c hadoop storage-0-1 -- bash -c 'ps aux | grep kms'

此指令本應命名 為 updatekeyprovider.py：

#!/usr/bin/env python3

import json
import re
import sys
import xml.etree.ElementTree as ET
import os

class CommentedTreeBuilder(ET.TreeBuilder):
    def comment(self, data):
        self.start(ET.Comment, {})
        self.data(data)
        self.end(ET.Comment)

domain_name = os.environ['BDC_DOMAIN']

parser = ET.XMLParser(target=CommentedTreeBuilder())

core_site = 'core-site.xml'
j = json.load(sys.stdin)
cs = j['data'][core_site]
csxml = ET.fromstring(cs, parser=parser)
props = [prop.find('value').text for prop in csxml.findall(
    "./property/name/..[name='hadoop.security.key.provider.path']")]

kms_provider_path=''

for x in range(5):
    if len(kms_provider_path) != 0:
        kms_provider_path = kms_provider_path + ';'
    kms_provider_path = kms_provider_path + 'nmnode-0-0.' + domain_name

if len(props) == 0:
    prop = ET.SubElement(csxml, 'property')
    name = ET.SubElement(prop, 'name')
    name.text = 'hadoop.security.key.provider.path'
    value = ET.SubElement(prop, 'value')
    value.text = 'kms://https@' + kms_provider_path + ':9600/kms'
    cs = ET.tostring(csxml, encoding='utf-8').decode('utf-8')

j['data'][core_site] = cs

kms_site = 'kms-site.xml.tmpl'
ks = j['data'][kms_site]

kp_uri_regex = re.compile('(<name>hadoop.kms.key.provider.uri</name>\s*<value>\s*)(.*)(\s*</value>)', re.MULTILINE)

def replace_uri(match_obj):
    key_provider_uri = 'bdc://https@hdfsvault-svc.' + domain_name
    if match_obj.group(2) == 'jceks://file@/var/run/secrets/keystores/kms/kms.jceks' or match_obj.group(2) == key_provider_uri:
        return match_obj.group(1) + key_provider_uri + match_obj.group(3)
    return match_obj.group(0)

ks = kp_uri_regex.sub(replace_uri, ks)

j['data'][kms_site] = ks
print(json.dumps(j, indent=4, sort_keys=True))

使用適當的參數執行 run-key-provider-patch.sh 。

設定外部提供者

如前幾節所述，SQL Server 2019 CU8+ 巨量數據叢集部署預設會使用系統管理的密鑰啟用待用加密功能。若要讓外部金鑰提供者保護 SQL Server 和 HDFS 加密的根密鑰，請參閱 SQL Server 巨量資料叢集中的外部金鑰提供者。

Next steps

若要深入瞭解如何在 SQL Server 巨量數據叢集上使用密鑰版本，請參閱 SQL Server 巨量數據叢集中的主要版本。

若要深入瞭解如何在 SQL Server 巨量數據叢集中有效使用靜態加密，請參閱下列文章：

若要深入瞭解 SQL Server 巨量數據叢集，請參閱下列概觀：

SQL Server 2019 巨量數據叢集簡介

Last updated on 2021-10-05

共用方式為