Schlüsselversionen in Big Data-Cluster für SQL Server
Gilt für: 
SQL Server 2019 (15.x)
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.
Dieser Artikel enthält Details zur Verwendung von Schlüsselversionen in Big Data-Cluster für SQL Server für die Schlüsselverwaltung und die Schlüsselrotation für HDFS und SQL Server-Schlüssel. Der Artikel enthält Informationen dazu, wie die Schlüssel von Kunden in die Versionen integriert werden können.
Allgemeine Informationen zum Sichern von Big Data-Cluster für SQL Server finden Sie unter Sicherheitskonzepte für Big Data-Cluster für SQL Server.
Informationen zum Konfigurieren und Verwenden der Funktion zur Verschlüsselung ruhender Daten finden Sie in den folgenden Leitfäden:
- Konzepte- und Konfigurationsleitfaden für die Verschlüsselung ruhender Daten
- Leitfaden zur Verwendung von SQL Server HDFS-Verschlüsselungszonen für Big Data-Cluster
- Leitfaden zur Verwendung von SQL Server Transparent Data Encryption(transparente Datenverschlüsselung, TDE) für Big Data-Cluster
HDFS-Schlüssel
Für die Verwendung der Verschlüsselung ruhender Daten in HDFS sind die folgenden Konzepte von Bedeutung:
- Verschlüsselungszonen (Encryption Zones, EZ): Bei einer Verschlüsselungszone handelt es sich um einen Ordner in HDFS, der einem Schlüssel zugeordnet ist. Alle Dateien in diesem Ordner sind verschlüsselt. Die standardmäßig bereitgestellte EZ in Big Data-Cluster für SQL Server wird als „securelake“ bezeichnet.
- Verschlüsselungszonenschlüssel (EZ-Schlüssel): Ein benannter symmetrischer Schlüssel. Der standardmäßig vom System verwaltete und bereitgestellte Schlüssel in Big Data-Cluster für SQL Server ist der „securelakekey“. Die Verschlüsselungszonenschlüssel werden mithilfe von Hadoop KMS (Key Management Server, Schlüsselverwaltungsserver) verwaltet, der in den Namensknotenpods von Big Data-Cluster für SQL Server ausgeführt wird. Die EZ-Schlüssel werden weiter durch einen in „controldb“ gespeicherten Hauptverschlüsselungsschlüssel geschützt. (Eine Erläuterung dazu finden Sie in den folgenden Abschnitten.) Die EZ-Schlüssel werden in Hadoop KMS durch Abrufen des öffentlichen Teils des Hauptverschlüsselungsschlüssels verschlüsselt, während die Entschlüsselungsanforderungen an die Steuerungsebene gesendet werden.
- Verschlüsselter Datenverschlüsselungsschlüssel: Jede Datei in der Verschlüsselungszone wird mit einem für die Datei generierten Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) verschlüsselt. Der DEK wird nach dem Erstellen mit den Daten permanent gespeichert. Damit der DEK dauerhaft erhalten bleibt, wird er zuerst mit dem Verschlüsselungszonenschlüssel verschlüsselt und dann mit den Daten permanent gespeichert. Der DEK wird nach dem Zufallsprinzip pro Datei generiert, und die Stärke des symmetrischen DEK entspricht der Stärke des EZ-Schlüssels.
In der folgenden Grafik wird erläutert, wie Dateien durch den DEK geschützt werden und wie der DEK durch den EZ-Schlüssel „securelakekey“ geschützt wird.
SQL Server-Schlüssel
Der vom System verwaltete Hauptverschlüsselungsschlüssel und die HDFS-EZ-Schlüssel werden in der „controldb“ gespeichert, die den Namen „controldb-<#>“ hat, z. B. controldb-0. Weitere Informationen finden Sie unter Mit dem Big Data-Cluster bereitgestellte Ressourcen.
SQL Server-Datenbanken werden mit einem symmetrischen Schlüssel verschlüsselt, der auch als Datenbankverschlüsselungsschlüssel (Database Encryption Key, DEK) bezeichnet wird. Der DEK wird in der Datenbank in einem verschlüsselten Format permanent gespeichert. Bei der DEK-Schutzvorrichtung kann es sich um ein Zertifikat oder um einen asymmetrischen Schlüssel handeln. Wenn Sie eine andere DEK-Schutzvorrichtung verwenden möchten, verwenden Sie die Anweisung ALTER DATABASE ENCRYPTION KEY. Der asymmetrische Schlüssel in SQL Server enthält Metadaten, die einen URL-Link zum Schlüssel in der Steuerungsebene enthalten. Daher werden alle Ver- und Entschlüsselungsvorgänge des Datenbankverschlüsselungsschlüssels (Database Encryption Key, DEK) im Controller durchgeführt. SQL Server speichert den öffentlichen Schlüssel, jedoch nur, um den asymmetrischen Schlüssel zu identifizieren. Zum Verschlüsseln wird der öffentliche Schlüssel nicht verwendet.
Big Data-Cluster für SQL Server – Hauptverschlüsselungsschlüssel
In der Steuerungsebene von Big Data-Cluster für SQL Server gibt es zum Schutz der Verschlüsselungszonenschlüssel und zur Bereitstellung von asymmetrischen Schlüsseln in SQL Server ein Konzept des Hauptverschlüsselungsschlüssels. Es gibt zwei Hauptverschlüsselungsschlüssel: einen für SQL Server und einen für HDFS. Bei diesem Konzept ist es möglich, dass die Steuerungsebene von Big Data-Cluster für SQL Server zulässt, dass sich der Hauptverschlüsselungsschlüssel auch außerhalb des Clusters befindet. Der Hauptverschlüsselungsschlüssel weist folgende Eigenschaften auf:
- Die Hauptverschlüsselungsschlüssel sind asymmetrische RSA-Schlüssel.
- Es wird ein Hauptverschlüsselungsschlüssel für die SQL Server-Masterinstanz und ein anderer für HDFS erstellt.
- Der öffentliche Schlüssel zum Hauptverschlüsselungsschlüssel wird immer in der Controllerdatenbank oder „controldb“ gespeichert. Der private Schlüssel wird in der Controllerdatenbank für den vom System verwalteten Hauptverschlüsselungsschlüssel gespeichert. Bei Verschlüsselungsschlüsseln von einem Hardwaresicherheitsmodul (HSM) oder einem anderen externen Anbieter werden die privaten Schlüssel nicht in der Controllerdatenbank gespeichert (es sei denn, die Anwendung für externe Schlüssel stellt den privaten Schlüssel bereit). Der private Schlüssel wird jedoch nicht in der „controldb“ benötigt, und das Material für den privaten Schlüssel wird von Big Data-Cluster für SQL Server nicht benötigt.
- Verschlüsselungsvorgänge, bei denen der öffentliche Schlüssel des Hauptverschlüsselungsschlüssels verwendet wird, können im Controller selbst ausgeführt werden, oder der Controller kann den öffentlichen Schlüssel an Hadoop KMS verteilen, damit die Verschlüsselung von Hadoop KMS lokal ausgeführt werden kann. Es wird erwartet, dass die Entschlüsselungsvorgänge vom externen Schlüsselanbieter wie HSM durchgeführt werden. Durch dieses Design können wird den vertraulichen Teil des asymmetrischen Schlüssels außerhalb des Clusters und unter dem Schutz des Kunden halten. Dadurch wird sichergestellt, dass der Verschlüsselungsstamm zum Entschlüsseln aller Daten niemals im Big Data-Cluster für SQL Server-Ökosystem für vom Kunden konfigurierte Schlüssel verfügbar ist.
Speicherschutz für verschiedene Schlüssel
Die DEK für HDFS-Dateien und SQL Server werden zusammen mit den Daten gespeichert, die vom DEK geschützt werden. Der DEK wird durch den HDFS-EZ-Schlüssel oder den asymmetrischen Schlüssel in SQL Server geschützt.
Asymmetrische Schlüssel in SQL Server enthalten Metadaten wie etwa die URL des Schlüssels in der Steuerungsebene. SQL Server speichert nur den öffentlichen Schlüssel des asymmetrischen Schlüssels für die Zuordnung zum Schlüssel in der Steuerungsebene.
Der Schlüsselspeicher in „controldb“ wird durch den Spaltenverschlüsselungsschlüssel in „controldb“ geschützt. In der „controldb“ werden vertrauliche Informationen zum Cluster gespeichert. Alle vertraulichen Informationen werden durch einen Spaltenverschlüsselungsschlüssel von SQL Server in „controldb“ geschützt. Diese wiederum wird durch ein in Kubernetes-Geheimnissen gespeichertes Kennwort geschützt. Weitere Informationen finden Sie unter Secrets in Kubernetes Documentation (Dokumentation zu Geheimnissen in Kubernetes).
Der Schutz ist in den folgenden Abbildungen zusammenfassend dargestellt. Zuerst der Speicherschutz von HDFS-EZ-Schlüsseln:
Speicherschutz des Hauptverschlüsselungsschlüssels:
Schlüsselrotation
HDFS-Verschlüsselungszonenschlüssel
Wenn Big Data-Cluster für SQL Server mit Active Directory bereitgestellt wird, wird HDFS mit der Standardverschlüsselungszone „securelake“ bereitgestellt, die durch den Schlüssel securelakekey geschützt ist. In den Beispielen hier werden die Standardeinstellungen verwendet. Mit azdata können jedoch neue Zonen und Schlüssel bereitgestellt werden. Der Schlüssel securelakekey wird durch einen Hauptverschlüsselungsschlüssel für HDFS geschützt, der in der Steuerungsebene gespeichert ist. Ab SQL 2019 CU9 kann azdata für die Rotation der EZ-Schlüssel für HDFS verwendet werden. Die Rotation von EZ-Schlüsseln bewirkt, dass neues Schlüsselmaterial mit dem Namen „securelakekey“ generiert wird, jedoch mit einer neuen Version des Schlüssels, die auf das Schlüsselmaterial verweist. Bei jedem neuen Verschlüsselungsvorgang in HDFS (etwa bei Dateischreibvorgängen) wird in der EZ immer die neueste Version des Schlüssels verwendet, der der EZ zugeordnet ist. Für Dateien in einer EZ, die durch eine ältere Version von Schlüsseln geschützt wird, kann der Befehl azdata bdc hdfs encryption-zone reencrypt verwendet werden, sodass alle Dateien mit der neuesten Version des EZ-Schlüssels geschützt werden können.
Stellen Sie sich eine Datei mit dem Namen „file2“ vor, die in „/securelake“ gespeichert ist. Im Folgenden ist die entsprechende Schutzkette dargestellt.
Für den Schlüssel „securelakekey“ kann mithilfe von azdata bdc hdfs key roll -n securelakekey eine Rotation zu einer neuen Version durchgeführt werden. Durch die Rotation werden die DEK, die die Datei schützen, nicht erneut verschlüsselt. Die Hadoop-Schlüsselrotation bewirkt, dass neues Schlüsselmaterial generiert und durch die neueste Version des Hauptverschlüsselungsschlüssels geschützt wird. In der folgenden Abbildung ist der Zustand des Systems nach der Rotation des Schlüssels „securelakekey“ dargestellt.
Verwenden Sie azdata bdc hdfs encryption-zone -a start -p /securelake, um sicherzustellen, dass die Dateien in den Verschlüsselungszonen durch den rotierten Schlüssel „securelakekey“ geschützt sind.
In der folgenden Abbildung ist der Zustand des Systems nach der erneuten Verschlüsselung der Verschlüsselungszone dargestellt.
SQL Server
Die SQL-Datenbank wird durch den DEK geschützt, der erneut generiert werden kann. Beim erneuten Generieren wird die gesamte Datenbank erneut verschlüsselt.
Rotation des Hauptverschlüsselungsschlüssels
Hinweis
Vor SQL Server 2019 CU10 gab es keine Möglichkeit zur Rotation des Hauptverschlüsselungsschlüssels. Ab SQL Server 2019 CU10 ist die Rotation des Hauptverschlüsselungsschlüssels mithilfe des Befehls azdata möglich.
Beim Hauptverschlüsselungsschlüssel handelt es sich um einen 2048-Bit-RSA-Schlüssel. Je nach Quelle des Schlüssels bewirkt die Rotation des Hauptverschlüsselungsschlüssels eine der folgenden Aktionen:
- Erstellen eines neuen Schlüssels bei einer Anforderung zum Rotieren des Hauptschlüssels zu einem vom System verwalteten Schlüssel. Ein vom System verwalteter Schlüssel ist ein asymmetrischer Schlüssel, der im Controller generiert und gespeichert wird.
- Erstellen eines Verweises auf einen extern bereitgestellten Schlüssel, wobei der private Schlüssel des asymmetrischen Schlüssels durch die Kundenanwendung verwaltet wird. Die Kundenanwendung muss nicht über den privaten Schlüssel verfügen. Sie muss jedoch so konfiguriert sein, dass der private Schlüssel abgerufen werden kann.
Durch die Rotation des Hauptschlüssels wird nichts erneut verschlüsselt. SQL Server- und HDFS-Schlüssel müssen im Anschluss daran rotiert werden:
- Nach der Rotation des Hauptschlüssels muss die DEK-Schutzvorrichtung der SQL Server-Datenbank zur neuen Version des erstellten Hauptschlüssels rotiert werden.
- Ähnliche Konzepte gelten für HDFS. Bei der Rotation des HDFS-Schlüssels wird neues Material mit der neuesten Version des Hauptschlüssels verschlüsselt. Ältere Versionen der EZ-Schlüssel bleiben unverändert. Nach der Rotation des HDFS-EZ-Schlüssels müssen die dem EZ-Schlüssel zugeordneten Verschlüsselungszonen erneut verschlüsselt werden, sodass sie danach mit der neuesten Version des EZ-Schlüssels verschlüsselt sind.
Rotation des Hauptschlüssels für HDFS
In der folgenden Abbildung ist die Rotation des Hauptverschlüsselungsschlüssels für HDFS dargestellt. Zunächst der Anfangszustand von HDFS:
Der Hauptverschlüsselungsschlüssel wird mit azdata bdc kms set –key-provider SystemManaged rotiert. (Durch den Befehl wird die Rotation des Hauptverschlüsselungsschlüssels für SQL und HDFS bewirkt, obwohl es sich dabei in der Steuerungsebene um verschiedene Schlüssel handelt.) Nach der Verwendung des Befehls azdata bdc kms:
Zur Verwendung der neuen Version des HDFS-Hauptverschlüsselungsschlüssels kann der Befehl azdata bdc hdfs key roll verwendet werden, durch den das System in den folgenden Zustand übergeht. Nach der Rotation des Schlüssels „securelakekey“:
Bei der Rotation des Schlüssels „securelakekey“ wird eine neue Version des Schlüssels „securelakekey“ erstellt und durch den Hauptverschlüsselungsschlüssel geschützt. Wenn sichergestellt werden soll, dass die Dateien in „securelake“ durch securelakekey@2 verschlüsselt werden, muss die Verschlüsselungszone „securelake“ erneut verschlüsselt werden. Nach der erneuten Verschlüsselung der Verschlüsselungszone:
Rotation des Hauptschlüssels für SQL Server
Der SQL Server-Hauptverschlüsselungsschlüssel wird in der Masterdatenbank der SQL Server-Masterinstanz installiert.
In der folgenden Abbildung ist die Rotation des Hauptverschlüsselungsschlüssels für SQL Server dargestellt.
Bei einer Neuinstallation von Big Data-Cluster für SQL Server wird in SQL Server kein asymmetrischer Schlüssel bereitgestellt. Im Anfangszustand von SQL Server können die Datenbanken mithilfe von Zertifikaten verschlüsselt werden. Dieser Aspekt wird jedoch vom Administrator der SQL Server-Masterinstanz bestimmt.
Der Hauptverschlüsselungsschlüssel wird mit azdata bdc kms set –key-provider SystemManaged rotiert. (Durch den Befehl wird die Rotation des Hauptverschlüsselungsschlüssels für SQL und HDFS [oder die Erstellung des Schlüssels] bewirkt, obwohl es sich dabei in der Steuerungsebene um verschiedene Schlüssel handelt.)
Der asymmetrische Schlüssel kann mithilfe der folgenden T-SQL-Abfrage mit der Systemkatalogsicht sys.asymmetric_keys angezeigt werden.
USE master;
select * from sys.asymmetric_keys;
Der asymmetrische Schlüssel wird gemäß der Namenskonvention als „tde_asymmetric_key_<Version>“ angezeigt. Der SQL Server Administrator kann dann die Schutzvorrichtung des DEK mithilfe von ALTER DATABASE ENCRYPTION KEY so ändern, dass der asymmetrische Schlüssel verwendet wird. Verwenden Sie beispielsweise den folgenden T-SQL-Befehl:
USE db1;
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY tde_asymmetric_key_0;
Die DEK-Schutzvorrichtung wurde so geändert, dass nun der asymmetrische Schlüssel verwendet wird:
Wenn der Befehl azdata bdc kms set erneut ausgeführt wird, wird für den asymmetrischen Schlüssel in sys.asymmetric_keys ein weiterer Eintrag im Format „tde_asymmetric_key_<Version>“ angezeigt. Der Befehl azdata kann verwendet werden, um die DEK-Schutzvorrichtung einer SQL Server-Datenbank noch mal zu ändern.
Vom Kunden bereitgestellter Schlüssel
Mit der Funktion zum Einbinden externer Schlüssel in Big Data-Cluster für SQL Server wird vom Hauptverschlüsselungsschlüssel der öffentliche Schlüssel mithilfe der vom Kunden bereitgestellten Anwendung abgerufen. Wenn HDFS-Schlüssel rotiert und verwendet werden, werden die Aufrufe zum Entschlüsseln der HDFS-Schlüssel mithilfe des vom Kunden bereitgestellten Schlüsselbezeichners an die Steuerungsebene gesendet und an die Anwendung umgeleitet. Bei SQL Server werden die Verschlüsselungsanforderungen durch die Steuerungsebene gesendet und bearbeitet, da sich hier der öffentliche Schlüssel befindet. Die Anforderungen zum Entschlüsseln des DEK aus SQL werden ebenfalls an die Steuerungsebene gesendet, dann jedoch an die KMS-Anwendung umgeleitet.
In der folgenden Abbildung sind die Interaktionen beim Konfigurieren von externen Schlüsseln in der Steuerungsebene dargestellt:
Nach der Installation des Schlüssels werden die Verschlüsselung und die Entschlüsselung verschiedener Nutzdaten durch den Hauptverschlüsselungsschlüssel geschützt. Dieser Schutz gleicht dem Schutz durch vom System verwaltete Schlüssel, jedoch mit dem Unterschied, dass die Entschlüsselungsaufrufe an die Steuerungsebene und anschließend an die KMS-Plug-In-App geleitet werden. Die Anforderung wird von der KMS-Plug-In-App an eine geeignete Stelle wie etwa HSM oder ein anderes Produkt geleitet.