Teilen über

Konzepte- und Konfigurationsleitfaden für die Verschlüsselung ruhender Daten

  • Artikel

Wichtig

Das Microsoft SQL Server 2019-Big Data-Cluster-Add-On wird eingestellt. Der Support für SQL Server 2019-Big Data-Clusters endet am 28. Februar 2025. Alle vorhandenen Benutzer*innen von SQL Server 2019 mit Software Assurance werden auf der Plattform vollständig unterstützt, und die Software wird bis zu diesem Zeitpunkt weiterhin über kumulative SQL Server-Updates verwaltet. Weitere Informationen finden Sie im Ankündigungsblogbeitrag und unter Big Data-Optionen auf der Microsoft SQL Server-Plattform.

In Big Data-Clustern für Microsoft SQL Server 2019 ab CU8 ist das Feature für die Verschlüsselung ruhender Daten verfügbar, um Verschlüsselung auf Anwendungsebene für alle auf der Plattform gespeicherten Daten bereitzustellen. In diesem Leitfaden werden die Konzepte, die Architektur und die Konfiguration für den Funktionssatz für die Verschlüsselung ruhender Daten für Big Data-Cluster beschrieben.

In SQL Server Big Data-Clustern werden Daten an den folgenden Stellen gespeichert:

  • SQL Server-Masterinstanz.
  • HDFS. Wird von Speicherpool und Spark verwendet.

Um Daten in SQL Server Big Data-Clustern transparent verschlüsseln zu können, gibt es zwei Ansätze:

  • Volumeverschlüsselung. Die Kubernetes-Plattform unterstützt diesen Ansatz. Diese Methode hat sich für Big Data-Clusterbereitstellungen bewährt. In diesem Artikel wird die Volumeverschlüsselung nicht behandelt. Informationen zum ordnungsgemäßen Verschlüsseln von Volumes, die für SQL Server Big Data-Cluster verwendet werden sollen, finden Sie in der Dokumentation Ihrer Kubernetes-Plattform oder Appliance.
  • Verschlüsselung auf Anwendungsebene. Diese Architektur bezieht sich auf die Verschlüsselung von Daten durch die Anwendung, die die Daten verarbeitet, bevor sie auf den Datenträger geschrieben werden. Für den Fall, dass die Volumes verfügbar gemacht werden, wäre ein Angreifer nicht in der Lage, Datenartefakte an anderer Stelle wiederherzustellen, es sei denn, das wurde ebenfalls mit denselben Verschlüsselungsschlüsseln konfiguriert.

Die Features für die Verschlüsselung ruhender Daten von SQL Server Big Data-Clustern unterstützen das Kernszenario der Verschlüsselung auf Anwendungsebene für die SQL Server- und HDFS-Komponenten.

Das Feature ermöglicht die folgenden Funktionen:

  • Systemseitig verwaltete Verschlüsselung ruhender Daten. Diese Funktion ist ab CU8 verfügbar.
  • Vom Benutzer verwaltete Verschlüsselung ruhender Daten ist auch als BYOK (Bring Your Own Key) bekannt. Dienstverwaltete Integrationen wurden in SQL Server 2019 CU8 eingeführt. Integrationen externer Schlüsselanbieter wurden in SQL Server 2019 CU11+ eingeführt.

Weitere Informationen finden Sie unter Schlüsselversionen in Big Data-Cluster für SQL Server.

Wichtige Definitionen

  • Schlüsselverwaltungsdienst (KMS) von SQL Server Big Data-Clustern

    Ein von einem Controller gehosteter Dienst, der für die Verwaltung von Schlüsseln und Zertifikaten für die Funktionen zur Verschlüsselung ruhender Daten für SQL Server Big Data-Cluster zuständig ist. Der Dienst unterstützt die folgenden Features:

    • Sichere Verwaltung und Speicherung von Schlüsseln und Zertifikaten, die für die Verschlüsselung ruhender Daten verwendet werden.
    • Kompatibilität mit Hadoop KMS. KMS fungiert als Schlüsselverwaltungsdienst für die HDFS-Komponente in Big Data-Clustern.
    • SQL Server Transparent Data Encryption (TDE)-Zertifikatverwaltung.

  • Systemseitig verwaltete Schlüssel

    Der KMS-Dienst für Big Data-Cluster verwaltet alle Schlüssel und Zertifikate für SQL Server und HDFS.

  • Benutzerdefinierte Schlüssel

    Benutzerdefinierte Schlüssel, die vom KMS-Dienst für Big Data-Cluster verwaltet werden, werden auch als BYOK (Bring Your Own Key) bezeichnet. SQL Server Big Data-Cluster unterstützen die benutzerdefinierte Definition von Schlüsseln, die für die Verschlüsselung auf SQL Server- und HDFS-Komponenten verwendet werden. KMS für Big Data-Cluster verwaltet diese Schlüssel.

    Achtung

    Die SQL Server-Masterinstanz erbt das TDE-Feature von SQL Server. Das manuelle Laden benutzerdefinierter Schlüssel aus Dateien in Pods, deren Registrierung bei SQL Server und deren Verwendung für TDE wird jedoch nicht unterstützt. Diese Schlüssel werden nicht vom KMS für Big Data-Cluster verwaltet. Diese Situation kann dazu führen, dass die Datenbanken nicht mehr gelesen werden können. Wenn Sie extern bereitgestellte Schlüssel ordnungsgemäß verwenden möchten, verwenden Sie das Feature „Externe Anbieter“ wie in diesem Artikel beschrieben.

  • Externe Anbieter

    Für die Delegierung des Verschlüsselungsvorgangs werden Lösungen für externe Schlüssel unterstützt, die mit dem KMS-Dienst für Big Data-Cluster kompatibel sind. Dieses Feature wird ab SQL Server 2019 CU11 unterstützt. Wenn dieses Feature aktiviert ist, wird der Stammschlüssel der Verschlüsselung außerhalb des Big Data-Cluster-Controllers gehostet.

Verschlüsselung ruhender Daten auf SQL Server Big Data-Clustern

Der KMS-Controllerdienst für Big Data-Cluster unterstützt bei der Verschlüsselung ruhender Daten in SQL Server und HDFS systemseitig verwaltete Schlüssel und von externen Anbietern gesteuerte Schlüssel.

Diese Schlüssel und Zertifikate werden vom Dienst verwaltet. In diesem Artikel finden Sie betriebsbezogene Anleitungen für die Interaktion mit dem Dienst.

Die Features verfügen über den neuen KMS-Controllerdienst für Big Data-Cluster, um systemseitig verwaltete Schlüssel und Zertifikate für die Verschlüsselung ruhender Daten sowohl in SQL Server als auch in HDFS bereitzustellen. Diese Schlüssel und Zertifikate werden vom Dienst verwaltet. In diesem Artikel finden Sie betriebsbezogene Anleitungen für die Interaktion mit dem Dienst.

  • SQL Server-Instanzen nutzen die bestehende Transparent Data Encryption-Funktion (TDE).
  • HDFS verwendet den nativen Hadoop KMS in jedem Pod für die Interaktion mit dem KMS für Big Data-Cluster auf dem Controller. Dieser Ansatz ermöglicht HDFS-Verschlüsselungszonen, die sichere Pfade auf HDFS bereitstellen.

SQL Server-Instanzen

  • Für die Verwendung mit TDE-Befehlen wird ein systemseitig generiertes Zertifikat auf SQL Server-Pods installiert. Der Benennungsstandard für das systemseitig verwaltete Zertifikat lautet TDECertificate + timestamp. Beispiel: TDECertificate2020_09_15_22_46_27.
  • Auf der Masterinstanz des Big Data-Clusters bereitgestellte Datenbanken und Benutzerdatenbanken werden nicht automatisch verschlüsselt. Datenbankadministratoren können das installierte Zertifikat verwenden, um eine beliebige Datenbank zu verschlüsseln.
  • Der Computepool und der Speicherpool werden automatisch mithilfe des systemseitig generierten Zertifikats verschlüsselt.
  • Von der Verschlüsselung des Datenpools, wenn auch technisch möglich mithilfe von EXECUTE AT-T-SQL-Befehlen, wird abgeraten, außerdem wird sie auch zurzeit nicht unterstützt. Die Verwendung dieser Methode zur Verschlüsselung von Datenpool-Datenbanken ist möglicherweise nicht effektiv, und die Verschlüsselung erfolgt möglicherweise nicht im gewünschten Zustand. Bei dieser Vorgehensweise entsteht auch ein inkompatibler Upgradepfad zu den nächsten Releases.
  • Die SQL Server-Schlüsselrotation wird mithilfe von standardmäßigen T-SQL-Verwaltungsbefehlen erreicht. Weitere Informationen finden Sie im Leitfaden zur Verwendung von SQL Server Transparent Data Encryption (transparente Datenverschlüsselung, TDE) für Big Data-Cluster.
  • Die Überwachung der Verschlüsselung erfolgt über vorhandene SQL Server-Standard-DMVs für TDE.
  • Das Sichern und Wiederherstellen einer TDE-fähigen Datenbank im Cluster wird unterstützt.
  • Hochverfügbarkeit wird unterstützt. Wenn eine Datenbank in der primären Instanz von SQL Server verschlüsselt ist, werden alle sekundären Replikate der Datenbank ebenfalls verschlüsselt.

HDFS-Verschlüsselungszonen

  • Active Directory-Integration ist erforderlich, um Verschlüsselungszonen für HDFS zu aktivieren.
  • Ein systemseitig generierter Schlüssel wird in Hadoop KMS bereitgestellt. Der Schlüsselname lautet securelakekey. In CU8 hat der Standardschlüssel 256 Bit, und wir unterstützen die Verschlüsselung mit 256-Bit-AES.
  • Eine Standardverschlüsselungszone wird unter Verwendung des obigen systemseitig generierten Schlüssels in einem Pfad namens /securelake bereitgestellt.
  • Benutzer können mithilfe in diesem Leitfaden bereitgestellter spezifischer Anweisungen andere Schlüssel und Verschlüsselungszonen erstellen. Benutzer können während der Schlüsselerstellung zwischen den Schlüsselgrößen 128, 192 oder 256 auswählen.
  • Bei HDFS-Verschlüsselungszonen wird die Schlüsselrotation mithilfe von azdata erreicht. Weitere Informationen hierzu finden Sie unter Leitfaden zur Verwendung von SQL Server HDFS-Verschlüsselungszonen für Big Data-Cluster.
  • Das Einbinden von HDFS-Tiering über einer Verschlüsselungszone wird nicht unterstützt.

Verwaltung der Verschlüsselung ruhender Daten

Im Folgenden sind die Verwaltungsfunktionen für die Verschlüsselung ruhender Daten aufgeführt:

  • SQL Server TDE wird mit standardmäßigen T-SQL-Befehlen verwaltet.
  • HDFS-Verschlüsselungszonen und HDFS-Schlüssel werden mithilfe von azdata-Befehlen verwaltet.
  • Die folgenden Verwaltungsfeatures werden mithilfe von ausgeführten Notebooks ausgeführt:
    • Sicherung und Wiederherstellung von HDFS-Schlüsseln
    • Löschen von HDFS-Schlüsseln

Konfigurationsleitfaden

Während neuer Bereitstellungen von SQL Server Big Data-Clustern (ab CU8) wird die Verschlüsselung ruhender Daten standardmäßig aktiviert und konfiguriert. Dies bedeutet:

  • Die KMS-Komponente für Big Data-Cluster wird im Controller bereitgestellt und generiert einen Standardsatz von Schlüsseln und Zertifikaten.
  • SQL Server wird mit aktivierter TDE bereitgestellt, und Zertifikate werden vom Controller installiert.
  • Hadoop KMS für HDFS wird für die Interaktion mit dem KMS für Big Data-Cluster für Verschlüsselungsvorgänge konfiguriert. HDFS-Verschlüsselungszonen sind konfiguriert und einsatzbereit.

Die im vorherigen Abschnitt beschriebenen Anforderungen und Standardverhalten sind gültig.

Bei einer neuen Bereitstellung von SQL Server Big Data-Clustern ab CU8 oder beim direkten Upgrade auf CU9 müssen keine weiteren Schritte durchgeführt werden.

Upgradeszenarien

Bei vorhandenen Clustern wird vom Upgradeprozess keine neue Verschlüsselung oder Neuverschlüsselung von noch nicht verschlüsselten Benutzerdaten erzwungen. Dieses Verhalten ist entwurfsbedingt, und für die einzelnen Komponenten müssen folgende Aspekte berücksichtigt werden:

  • SQL Server

    • SQL Server-Masterinstanz. Der Upgradeprozess wirkt sich nicht auf Masterinstanzdatenbanken und installierte TDE-Zertifikate aus. Es wird empfohlen, Datenbanken und manuell installierte TDE-Zertifikate vor dem Upgradeprozess zu sichern. Außerdem wird empfohlen, diese Artefakte außerhalb des Big Data-Clusters zu speichern.
    • Compute- und Speicherpool. Diese Datenbanken werden systemseitig verwaltet, sind flüchtig und werden beim Clusterupgrade neu erstellt und automatisch verschlüsselt.
    • Datenpool. Das Upgrade hat keine Auswirkungen auf Datenbanken im SQL Server-Instanzenteil des Datenpools.

  • HDFS

    Beim Upgradeprozess werden keine HDFS-Dateien und -Ordner außerhalb von Verschlüsselungszonen angefasst.

Upgrade von einer Version bis CU8 auf CU9

Es sind keine weiteren Schritte erforderlich.

Upgrade von einer Version bis CU6 auf CU8

Achtung

Führen Sie vor einem Upgrade auf SQL Server Big Data-Cluster CU8 eine vollständige Sicherung Ihrer Daten aus.

Verschlüsselungszonen werden nicht konfiguriert. Die Hadoop KMS-Komponente wird nicht für die Verwendung von KMS für Big Data-Cluster konfiguriert. Befolgen Sie die Anleitungen im nächsten Abschnitt, um HDFS-Verschlüsselungszonen nach dem Upgrade zu konfigurieren und zu aktivieren.

Aktivieren von HDFS-Verschlüsselungszonen nach einem Upgrade auf CU8

Wenn Sie ein Upgrade Ihres Cluster auf CU8 durchgeführt haben (azdata upgrade) und HDFS-Verschlüsselungszonen aktivieren möchten, gibt es zwei Möglichkeiten:

  • Ausführung des ausgeführten Notebooks in Azure Data Studio mit dem Namen SOP0128: Aktivieren von HDFS-Verschlüsselungszonen in Big Data-Clustern zum Durchführen der Konfiguration.
  • Führen Sie die Skripts wie unten beschrieben aus.

Anforderungen:

  • Integrierter Active Directory-Cluster.
  • Im AD-Modus in den Cluster konfigurierte und protokollierte Azure Data CLI (azdata).

Führen Sie die folgenden Schritte aus, um den Cluster mit Unterstützung für Verschlüsselungszonen neu zu konfigurieren.

  1. Nachdem Sie das Upgrade mit azdata ausgeführt haben, speichern Sie die folgenden Skripts.

    Anforderungen für die Ausführung der Skripts:

    • Beide Skripts sollten sich im selben Verzeichnis befinden.
    • kubectl in der PATH-Konfigurationsdatei für Kubernetes im Ordner $HOME/.kube.

    Dieses Skript sollte run-key-provider-patch.sh benannt werden:

    #!/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'

    Dieses Skript sollte updatekeyprovider.py benannt werden:

    #!/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))

    Führen Sie run-key-provider-patch.sh mit den entsprechenden Parametern aus.

Konfiguration externer Anbieter

Wie in den vorherigen Abschnitten bereits erwähnt, wird die Funktion zur Verschlüsselung ruhender Daten in einer Bereitstellung eines Big Data-Clusters für SQL Server 2019 ab CU8 standardmäßig mit systemseitig verwalteten Schlüsseln aktiviert. Informationen zum Aktivieren eines externen Schlüsselanbieters zum Schutz der Stammschlüssel bei der Verschlüsselung von SQL Server und HDFS finden Sie unter Externe Schlüsselanbieter in Big Data-Cluster für SQL Server.

Nächste Schritte

Weitere Informationen zur Verwendung von Schlüsselversionen in SQL Server-Big Data-Clustern finden Sie im Artikel zu Schlüsselversionen in SQL Server-Big Data-Clustern.

Weitere Informationen zur sinnvollen Verwendung der Verschlüsselung ruhender Daten von Big Data-Cluster für SQL Server finden Sie in folgenden Artikeln:

Weitere Informationen zu Big Data-Cluster für SQL Server finden Sie in der folgenden Übersicht: