Freigeben über

Einrichten der erweiterbaren Schlüsselverwaltung für SQL Server-TDE mit Azure Key Vault

  • Artikel

Gilt für: SQL Server

In diesem Artikel installieren und konfigurieren Sie den SQL Server-Connector für Azure Key Vault.

Hinweis

Microsoft Entra ID war zuvor als Azure Active Directory (Azure AD) bekannt.

Erweiterbare Schlüsselverwaltung mit Azure Key Vault (AKV) ist für SQL Server für Linux Umgebungen verfügbar, beginnend mit SQL Server 2022 (16.x) kumulatives Update 12. Führen Sie die gleichen Anweisungen aus, überspringen Sie jedoch die Schritte 3 und 4.

Voraussetzungen

Bevor Sie Azure Key Vault mit Ihrer SQL Server-Instanz verwenden, müssen Sie sicherstellen, dass die folgenden Voraussetzungen erfüllt sind:

Hinweis

In SQL Server 2022 (16.x) CU 14 und höheren Versionen unterstützt SQL Server für Linux die erweiterbare Schlüsselverwaltung für TDE mit Azure Key Vault. Die Schritte 3 und 4 in dieser Anleitung sind für SQL Server für Linux nicht erforderlich.

Schritt 1: Einrichten eines Microsoft Entra-Dienstprinzipals

Um Ihrer SQL Server-Instanz Zugriffsberechtigungen für Ihren Azure Key Vault zu erteilen, benötigen Sie ein Dienstprinzipalkonto in Microsoft Entra ID.

  1. Melden Sie sich beim Azure-Portal an, und führen Sie einen der folgenden Schritte aus:

    • Wählen Sie die Schaltfläche Microsoft Entra ID.

      Screenshot des Bereichs „Azure-Dienste“.

    • Wählen Sie Weitere Dienste aus und geben Sie dann im Bereich Alle Dienste Microsoft Entra ID ein.

  2. Registrieren Sie eine Anwendung nach der folgenden Vorgehensweise bei Microsoft Entra ID. Detaillierte Schritt-für-Schritt-Anweisungen finden Sie im Abschnitt Erhalten Sie eine Identität für die Anwendung im Azure Key Vault-Blogbeitrag, Azure Key Vault – Schritt für Schritt.

    1. Wählen Sie im Abschnitt Verwalten Ihrer Microsoft Entra ID-Ressource die Option App-Registrierungen.

      Screenshot der Microsoft Entra ID-Übersichtsseite im Azure-Portal.

    2. Wählen Sie im Menüband auf der Seite App-Registrierungen die Option Neue Registrierung aus.

      Screenshot der Seite „App-Registrierungen“ im Azure-Portal.

    3. Geben Sie im Bereich Anwendung registrieren den Benutzernamen für die App ein, und wählen Sie dann Registrieren aus.

      Screenshot des Bereichs „Anwendung registrieren“.

    4. Wählen Sie im linken Bereich Zertifikate und Geheimnisse > Geheime Client-Schlüssel > Neuer geheimer Clientschlüssel aus.

      Screenshot des Bereichs „Zertifikate und Geheimnisse“ für die App im Azure-Portal.

    5. Geben Sie unter Geheimen Clientschlüssel hinzufügen eine Beschreibung und eine entsprechende Ablaufzeit ein, und wählen Sie dann Hinzufügen aus. Sie können keinen Ablaufzeitraum von mehr als 24 Monaten auswählen. Weitere Informationen finden Sie unter Hinzufügen eines geheimen Clientschlüssels.

      Screenshot des Abschnitts „Clientgeheimnis für die App hinzufügen“ im Azure-Portal.

    6. Wählen Sie im Bereich Zertifikate und Geheimnisse unter Wert die Schaltfläche Kopieren neben dem Wert des geheimen Clientschlüssels aus, der zum Erstellen eines asymmetrischen Schlüssels in SQL Server verwendet werden soll.

      Screenshot des Geheimniswerts im Azure-Portal.

    7. Wählen Sie im linken Bereich Übersicht aus, und kopieren Sie dann im Feld Anwendungs-ID (Client) den Wert, der zum Erstellen eines asymmetrischen Schlüssels in SQL Server verwendet werden soll.

      Screenshot des Werts „Anwendungs-ID (Client)“ im Bereich „Übersicht“.

Schritt 2: Erstellen eines Schlüsseltresors

Wählen Sie die Methode aus, mit der Sie einen Schlüsseltresor erstellen möchten.

Erstellen eines Schlüsseltresors über das Azure-Portal

Sie können den Schlüsseltresor über das Azure-Portal erstellen und ihm anschließend einen Microsoft Entra-Prinzipal hinzufügen.

  1. Erstellen Sie eine Ressourcengruppe.

    Alle Azure-Ressourcen, die Sie über das Azure-Portal erstellen, müssen in einer Ressourcengruppe enthalten sein, die Sie für Ihren Schlüsseltresor anlegen. Der Ressourcenname in diesem Beispiel lautet DocsSampleRG. Wählen Sie Ihren eigenen Ressourcengruppen- und Schlüsseltresornamen, da alle Schlüsseltresornamen global eindeutig sein müssen.

    Geben Sie im Bereich Ressourcengruppe erstellen unter Projektdetails die Werte ein, und wählen Sie dann Überprüfen + erstellen aus.

    Screenshot des Bereichs „Ressourcengruppe erstellen“ im Azure-Portal.

  2. Suchen oder wählen Sie im Azure-Portal die Schlüsseltresordienste aus, um einen Schlüsseltresor zu erstellen. Klicken Sie auf Erstellen.

    Wählen Sie im Bereich Schlüsseltresor erstellen die Registerkarte Allgemeine Informationen aus. Geben Sie die entsprechenden Werte für die Registerkarte ein. Außerdem wird empfohlen, den Löschschutz zu aktivieren.

    Screenshot des Bereichs „Schlüsseltresor erstellen“ im Azure-Portal.

  3. Auf der Registerkarte Zugriffskonfiguration haben Sie die Möglichkeit, die Azure-rollenbasierte Zugriffssteuerung oder Tresor-Zugriffsrichtlinie auszuwählen. Wir gehen auf beide Optionen ein, die Azure-Option für die rollenbasierte Zugriffssteuerung wird jedoch empfohlen. Weitere Informationen finden Sie in der Übersicht über Zugriffsmodelle.

    Screenshot des Bereichs „Schlüsseltresor erstellen“ und der Registerkarte „Zugriffskonfiguration“ im Azure-Portal.

  4. Sie können die Registerkarte „Netzwerk“ als Standard festlegen oder die Netzwerkeinstellungen für den Schlüsseltresor konfigurieren. Wenn Sie eine Firewall mit dem Schlüsseltresor verwenden, muss die Option „Vertrauenswürdigen Microsoft-Diensten Umgehung der Firewall erlauben“ aktiviert sein, es sei denn, Sie verwenden private Endpunktverbindungen. Weitere Informationen finden Sie unter Konfigurieren von Azure Key Vault-Firewalls und virtuellen Netzwerken.

  5. Wählen Sie die Schaltfläche Bewerten + erstellen aus, und erstellen Sie den Schlüsseltresor.

Rollenbasierte Zugriffssteuerung (Azure)

Die empfohlene Methode besteht darin, die rollenbasierte Zugriffssteuerung (RBAC) von Azure zu verwenden, um dem Schlüsseltresor Berechtigungen zuzuweisen. Mit dieser Methode können Sie Benutzern, Gruppen und Anwendungen auf einer detaillierteren Ebene Berechtigungen zuweisen. Sie können dem Schlüsseltresor auf der Verwaltungsebene (Azure-Rollenzuweisungen) und auf der Datenebene (Zugriffsrichtlinien für den Schlüsseltresor) Berechtigungen zuweisen. Wenn Sie nur die Zugriffsrichtlinie verwenden können, können Sie diesen Abschnitt überspringen und mit dem Abschnitt über die Zugriffsrichtlinie für den Tresor fortfahren. Weitere Informationen zu Azure Key Vault RBAC-Berechtigungen finden Sie unter In Azure integrierte Rollen für Key Vault-Vorgänge auf Datenebene.

  1. Wechseln Sie zu der von Ihnen erstellten Schlüsseltresorressource und wählen Sie die Zugriffssteuerungseinstellung (IAM) aus.

  2. Wählen Sie Hinzufügen>Rollenzuweisung hinzufügen.

    Screenshot der Schaltfläche „Rollenzuweisung hinzufügen“ im Bereich „Access Control (IAM)“ im Azure-Portal.

  3. Die EKM-Anwendung benötigt die Rolle des Benutzers für Kryptografiedienstverschlüsselung für Schlüsseltresore, um Wrap- und Unwrap-Operationen durchzuführen. Suchen Sie nach der Option Kryptografiedienstverschlüsselung für Schlüsseltresore und wählen Sie die Rolle aus. Wählen Sie Weiter aus.

    Screenshot der Auswahl einer Rollenzuweisung im Azure-Portal.

  4. Wählen Sie auf der Registerkarte Mitglieder die Option Mitglieder auswählen und suchen Sie dann nach der Microsoft Entra-Anwendung, die Sie in Schritt 1 erstellt haben. Wählen Sie die Anwendung aus und wählen Sie dann die Schaltfläche Auswählen aus.

    Screenshot des Bereichs „Mitglieder auswählen“ zum Hinzufügen einer Rollenzuweisung im Azure-Portal.

  5. Wählen Sie zweimal Überprüfen und zuweisen, um die Rollenzuweisung abzuschließen.

  6. Der Benutzer, der den Schlüssel erstellt, benötigt die Schlüsseltresoradministratorrolle. Suchen Sie nach Schlüsseltresoradministrator und wählen Sie die Rolle aus. Wählen Sie Weiter aus.

  7. Fügen Sie wie bei den vorherigen Schritten das Mitglied hinzu, das den Schlüssel erstellt, und weisen Sie die Rolle zu.

Tresorzugriffsrichtlinie

Hinweis

Wenn Sie die Azure-Option für die rollenbasierte Zugriffssteuerung verwenden, können Sie diesen Abschnitt überspringen. Wenn Sie das Berechtigungsmodell ändern, können Sie dies über das Menü Zugriffskonfiguration des Schlüsseltresors tun. Vergewissern Sie sich, dass Sie über die richtigen Berechtigungen zur Verwaltung des Schlüsseltresors verfügen. Weitere Informationen finden Sie unter Aktivieren von Azure RBAC-Berechtigungen für den Schlüsseltresor.

  1. Wählen Sie auf der Registerkarte Zugriffskonfiguration Zugriffsrichtlinie für den Tresor aus. Wenn Sie einen bestehenden Schlüsseltresor verwenden, können Sie in der Ressource Schlüsseltresor das Menü Zugriffsrichtlinien auswählen und dann Erstellen wählen.

  2. Wählen Sie im Bereich Erstellen einer Zugriffsrichtlinie die Option Berechtigungen abrufen und auflisten aus den Optionen Schlüsselverwaltungsvorgänge. Wählen Sie unter den Optionen für kryptografische Operationen die Berechtigungen Schlüssel aufheben und Schlüssel umwandeln aus. Wählen Sie Weiter aus.

    Screenshot des Links „Zugriffsrichtlinie hinzufügen“ im Bereich „Zugriffsrichtlinien“.

  3. Wählen Sie auf der Registerkarte Prinzipal die in Schritt 1 erstellte Anwendung aus.

    Screenshot des Anwendungssuchfelds im Bereich „Prinzipal“.

  4. Wählen Sie Weiter und dann Erstellen aus.

Erstellen eines Schlüssels

  1. Wählen Sie im Bereich Schlüsseltresor die Option Schlüssel und dann die Option Erstellen/Importieren. Dadurch wird der Bereich Schlüssel erstellen geöffnet. Geben Sie den Namen eines Schlüsseltresors ein. Wählen Sie Option Generieren aus und geben Sie einen Namen für den Schlüssel ein. Für den SQL Server-Connector ist es erforderlich, dass im Schlüsselnamen nur die Zeichen „a-z“, „A-Z“, „0-9“ und „-“ bei einem Zeichenlimit von 26 Zeichen verwendet werden.

  2. Verwenden Sie den Schlüsseltyp RSA und die RSA-Schlüsselgröße von 2048. EKM unterstützt derzeit nur einen RSA-Schlüssel. Legen Sie die Werte für Aktivierungs- und Ablaufdatum entsprechend fest, und legen Sie Aktiviert auf Ja fest.

    Screenshot des Bereichs „Schlüssel erstellen“.

Bewährte Methoden

Es werden die folgenden bewährten Methoden empfohlen, um die schnelle Wiederherstellung von Schlüsseln sicherzustellen und den Zugriff auf Ihre Daten außerhalb von Azure zu ermöglichen:

  • Erstellen Sie Ihren Verschlüsselungsschlüssel lokal auf einem lokalen HSM-Gerät (Hardware Security Module). Stellen Sie sicher, dass Sie einen asymmetrischen RSA-Schlüssel mit 2048 oder 3072 Bit verwenden, damit er von SQL Server unterstützt wird.

  • Importieren Sie den Verschlüsselungsschlüssel in Ihren Azure Key Vault. Dieser Prozess wird in den folgenden Abschnitten beschrieben.

  • Bevor Sie den Schlüssel zum ersten Mal in Ihrem Azure Key Vault verwenden, erstellen Sie eine Schlüsselsicherung Ihres Azure Key Vaults mit dem PowerShell-Cmdlet Backup-AzureKeyVaultKey.

  • Stellen Sie sicher, dass Sie jedes Mal eine neue Schlüsselsicherung Ihres Azure Key Vaults erstellen, wenn Sie Änderungen am Schlüssel vornehmen (z. B. wenn Sie ACLs, Tags oder Schlüsselattribute hinzufügen).

    Hinweis

    Die Sicherung eines Schlüssels ist ein Azure Key Vault-Schlüsselvorgang, der eine Datei zurückgibt, die an einer beliebigen Stelle gespeichert werden kann.

    Der Einsatz des SQL Server-Connectors für Azure Key Vault hinter einer Firewall oder einem Proxyserver kann sich auf die Leistung auswirken, wenn der Datenverkehr verzögert oder blockiert wird. Machen Sie sich mit Zugreifen auf Azure Key Vault hinter einer Firewall vertraut und stellen Sie sicher, dass die richtigen Regeln gelten.

Optional – Ein von Azure Key Vault verwaltetes HSM (Hardwaresicherheitsmodul) konfigurieren

Ein von Azure Key Vault verwaltetes HSM (Hardwaresicherheitsmodul) wird für SQL Server und SQL Server auf Azure Virtual Machines (VMs) unterstützt, wenn die aktuelle Version des SQL Server-Connectors sowie von Azure SQL verwendet werden. Das verwaltete HSM ist ein vollständig verwalteter, hochverfügbarer Einzelmandant-HSM-Dienst. Das verwaltete HSM bietet eine sichere Grundlage für kryptografische Operationen und Schlüsselspeicher. Das verwaltete HSM ist darauf ausgelegt, die strengsten Sicherheits- und Complianceanforderungen zu erfüllen.

In Schritt 2 haben Sie erfahren, wie Sie einen Schlüsseltresor und einen Schlüssel im Azure Key Vault erstellen. Optional können Sie ein von Azure Key Vault verwaltetes HSM verwenden, um einen Schlüssel zu speichern oder zu erstellen, der mit dem SQL Server Connector verwendet werden soll. Gehen Sie wie folgt vor:

  1. Erstellen Sie ein von Azure Key Vault verwaltetes HSM. Dazu können Sie das Azure-Portal verwenden, indem Sie nach dem von Azure Key Vault verwalteten HSM-Dienst suchen und die neue Ressource erstellen oder indem Sie Azure CLI, PowerShell oder eine ARM-Vorlage verwenden.

  2. Aktivieren Sie das verwaltete HSM. Nur die designierten Fachkräfte in der IT-Verwaltung, die während der Erstellung des verwalteten HSMs zugewiesen wurden, können das HSM aktivieren. Dazu wählen Sie die verwaltete HSM-Ressource im Azure-Portal aus, indem Sie im Menü Übersicht der Ressource die Option Sicherheitsdomäne herunterladen auswählen. Folgen Sie dann einem der Schnellstarts, um Ihr verwaltetes HSM zu aktivieren.

  3. Erteilen Sie dem Microsoft Entra-Dienstprinzipal Berechtigungen für den Zugriff auf das verwaltete HSM. Die Rolle Administrator*in für verwaltete HSMs erteilt keine Berechtigungen zum Erstellen eines Schlüssels. Ähnlich wie in Schritt 2 benötigt die EKM-Anwendung die Rolle Kryptografiebenutzer*in für verwaltete HSMs oder Benutzer*in der Kryptografiedienstverschlüsselung für verwaltete HSMs, um Verpackungs- und Entpackungsoperationen auszuführen. Wählen Sie den Typ der Unternehmensanwendung aus, wenn Sie den Prinzipal für die Rollenzuweisung hinzufügen. Weitere Informationen finden Sie unter Integrierte Rollen der lokalen RBAC für verwaltetes HSM.

  4. Wählen Sie im Menü des von Azure Key Vault verwalteten HSM-Diensts unter Einstellung die Option Schlüssel aus. Wählen Sie im Fenster Schlüssel die Option Generieren/Importieren/Sicherung wiederherstellen aus, um einen Schlüssel zu erstellen oder einen vorhandenen Schlüssel zu importieren.

    Hinweis

    Beim Erstellen von Anmeldedaten für den Zugriff auf das verwaltete HSM lautet die Identität <name of Managed HSM>.managedhsm.azure.net. Sie ist in der Übersicht des von Azure Key Vault verwalteten HSMs als HSM-URI im Azure-Portal zu finden.

    Automatische Schlüsselrotation wird im von Azure Key Vault verwalteten HSM unterstützt. Weitere Informationen finden Sie unter Konfigurieren der automatischen Schlüsselrotation in verwaltetem HSM in Azure.

    SQL Server-Connector Version 15.0.2000.440 oder höher, ist erforderlich, um das von Azure Key Vault verwaltete HSM zu unterstützen.

    Verwaltetes HSM unterstützt Verbindungen mit privaten Endpunkten. Weitere Informationen finden Sie unter Integrieren des verwalteten HSM in Azure Private Link. In dieser Konfiguration muss die Microsoft Trusted Service Bypass-Option für die Azure Key Vault Managed HSM Networking-Einstellung aktiviert sein.

Schritt 3: Installieren des SQL Server-Connectors

Laden Sie den SQL Server-Connector aus dem Microsoft Download Centerherunter. Der Download sollte vom Administrator des SQL Server-Computers ausgeführt werden.

Hinweis

  • Die SQL Server Connector-Versionen 1.0.0.440 und früher wurden ersetzt und werden in Produktionsumgebungen nicht mehr unterstützt. Lesen Sie die Anweisungen auf der Seite SQL Server Connector – Wartung und Problembehandlung unter Upgrade des SQL Server-Connectors.
  • Von Version 1.0.3.0 an meldet der SQL Server-Connector relevante Fehlermeldungen zur Problembehandlung an die Windows-Ereignisprotokolle.
  • Von Version 1.0.4.0 an werden private Azure-Clouds unterstützt, darunter Azure betrieben von 21Vianet, Azure Deutschland und Azure Government.
  • In Version 1.0.5.0 gibt es einen Breaking Change, die den Fingerabdruckalgorithmus betrifft. Nach dem Upgrade auf Version 1.0.5.0 treten möglicherweise Fehler bei der Datenbankwiederherstellung auf. Weitere Informationen finden Sie im KB-Artikel 447099.
  • Ab Version 1.0.5.0 (Zeitstempel: September 2020) unterstützt der SQL Server-Connector das Filtern von Nachrichten sowie Wiederholungslogik für Netzwerkanforderungen.
  • Ab der aktualisierten Version 1.0.5.0 (Zeitstempel: November 2020) unterstützt der SQL Server-Connector die Schlüssel RSA 2048, RSA 3072, RSA-HSM 2048 und RSA-HSM 3072.
  • Ab der aktualisierten Version 1.0.5.0 (Zeitstempel: November 2020) können Sie auf eine bestimmte Schlüsselversion im Azure Key Vault verweisen.

Screenshot des Installationsassistenten für den SQL Server-Connector.

Standardmäßig wird der Connector unter C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault installiert. Dieser Speicherort kann während des Setups geändert werden. Wenn Sie ihn ändern, müssen Sie die Skripts im nächsten Abschnitt anpassen.

Für den Connector existiert keine Schnittstelle. Wenn er jedoch erfolgreich installiert wurde, wird Microsoft.AzureKeyVaultService.EKM.dll auf dem Computer installiert. Diese Assembly ist die DLL des EKM-Kryptografieanbieters, die mithilfe der CREATE CRYPTOGRAPHIC PROVIDER-Anweisung bei SQL Server registriert werden muss.

Die SQL Server-Connectorinstallation ermöglicht außerdem den Download von Beispieldateien für die SQL Server-Verschlüsselung.

Fehlercodeerläuterungen, Konfigurationseinstellungen oder Wartungsaufgaben für SQL Server-Connector finden Sie unter:

Schritt 4: Hinzufügen eines Registrierungsschlüssels zur Unterstützung des EKM-Anbieters

Warnung

Das Ändern der Registrierung sollte von Benutzern vorgenommen werden, die genau wissen, was sie tun. Wird die Registrierung falsch angepasst, können schwerwiegende Probleme auftreten. Für weiteren Schutz sichern Sie die Registrierung, bevor Sie sie ändern. Sie können die Registrierung wiederherstellen, wenn ein Problem auftritt.

  1. Stellen Sie sicher, dass SQL Server installiert ist und ausgeführt wird.

  2. Führen Sie regedit aus, um den Registrierungs-Editor zu öffnen.

  3. Erstellen Sie einen SQL Server Cryptographic Provider-Registrierungsschlüssel auf HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft. Der vollständige Pfad lautet HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider.

  4. Klicken Sie mit der rechten Maustaste auf den SQL Server Cryptographic Provider-Registrierungsschlüssel und wählen Sie Berechtigungen aus.

  5. Erteilen Sie dem SQL Server Cryptographic Provider-Registrierungsschlüssel die Berechtigung Vollzugriff für das Benutzerkonto, das den SQL Server-Dienst ausführt.

    Screenshot des EKM-Registrierungsschlüssels im Registrierungs-Editor.

  6. Wählen Sie Übernehmen und anschließend OK aus.

  7. Schließen Sie den Registrierungs-Editor und starten Sie den SQL Server-Dienst neu.

    Hinweis

    Wenn Sie TDE mit EKM oder Azure Key Vault für eine Failoverclusterinstanz verwenden, müssen Sie einen zusätzlichen Schritt durchführen, um HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider zu Ihrer Prüfpunktroutine zur Clusterregistrierung hinzuzufügen, damit die Registrierung zwischen den Knoten synchronisiert werden kann. Die Synchronisierung erleichtert die Datenbankwiederherstellung nach einem Failover und einer Schlüsselrotation.

    Führen Sie in PowerShell den folgenden Befehl aus, um den Registrierungsschlüssel der Prüfpunktroutine für die Clusterregistrierung hinzuzufügen:

    Add-ClusterCheckpoint -RegistryCheckpoint "SOFTWARE\Microsoft\SQL Server Cryptographic Provider" -Resourcename "SQL Server"

Schritt 5: Konfigurieren von SQL Server

Einen Hinweis zu den minimal erforderlichen Berechtigungsstufen für jede Aktion in diesem Abschnitt finden Sie unter B. Häufig gestellte Fragen.

Konfigurieren der master-Datenbank

  1. Führen Sie sqlcmd aus oder öffnen Sie SQL Server Management Studio.

  2. Konfigurieren Sie SQL Server für die EKM-Verwendung durch Ausführen des folgenden Transact-SQL-Skripts:

    -- Enable advanced options.
USE master;
GO

EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO

-- Enable EKM provider
EXEC sp_configure 'EKM provider enabled', 1;
GO
RECONFIGURE;

  3. Registrieren Sie den SQL Server-Connector bei SQL Server als EKM-Anbieter.

    Erstellen Sie einen Kryptografieanbieter mithilfe des SQL Server-Connectors, der einen EKM-Anbieter für Azure Key Vault darstellt. In diesem Beispiel lautet der Name des Anbieters AzureKeyVault_EKM.

    CREATE CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM
FROM FILE = 'C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault\Microsoft.AzureKeyVaultService.EKM.dll';
GO

    Hinweis

    Der Dateipfad darf höchstens 256 Zeichen umfassen.

  4. Richten Sie SQL Server-Anmeldeinformationen für eine SQL Server-Anmeldung zur Verwendung des Schlüsseltresors ein.

    Für jede Anmeldung, die eine Verschlüsselung mithilfe eines Schlüssels aus dem Schlüsseltresor ausführen soll, müssen Anmeldeinformationen hinzugefügt werden. Dazu können beispielsweise gehören:

    • Eine SQL Server-Administratoranmeldung, die den Schlüsseltresor verwendet, um SQL Server-Verschlüsselungsszenarios einzurichten und zu verwalten.

    • Andere SQL Server-Anmeldungen, die TDE oder andere SQL Server-Verschlüsselungsfeatures aktivieren können.

    Es besteht eine Eins-zu-Eins-Zuordnung zwischen Anmeldeinformationen und Anmeldungen. Da heißt, für jede Anmeldung müssen eindeutige Anmeldeinformationen vorhanden sein.

    Ändern Sie dieses Transact-SQL-Skript in der folgenden Weise:

    • Bearbeiten Sie das IDENTITY -Argument (DocsSampleEKMKeyVault), damit es auf Ihren Azure Key Vault verweist.

    • Ersetzen Sie den ersten Teil des SECRET-Arguments durch die Microsoft Entra-Client-ID aus Schritt 1: Einrichten eines Microsoft Entra-Dienstprinzipals. In diesem Beispiel lautet die Client-ID d956f6b9xxxxxxx.

      Wichtig

      Achten Sie darauf, die Bindestriche aus der App-ID (Client) zu entfernen.

    • Schließen Sie den zweiten Teil des SECRET-Arguments ab mit dem geheimen Clientschlüssel aus Schritt 1: Einrichten eines Microsoft Entra-Dienstprinzipals. In diesem Beispiel lautet der geheime Clientschlüssel yrA8X~PldtMCvUZPxxxxxxxx. Die letzte Zeichenkette für das SECRET-Argument ist eine lange Abfolge von Buchstaben und Zahlen ohne Bindestriche (mit Ausnahme des Abschnitts Geheimer Clientschlüssel, falls der geheime Clientschlüssel Bindestriche enthält).

      USE master;
CREATE CREDENTIAL sysadmin_ekm_cred
    WITH IDENTITY = 'DocsSampleEKMKeyVault',                            -- for public Azure
    -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.usgovcloudapi.net', -- for Azure Government
    -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.azure.cn',          -- for Microsoft Azure operated by 21Vianet
    -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.microsoftazure.de', -- for Azure Germany
    -- WITH IDENTITY = '<name of Managed HSM>.managedhsm.azure.net',    -- for Managed HSM (HSM URI in the Azure portal resource)
           --<----Application (Client) ID ---><--Microsoft Entra app (Client) ID secret-->
    SECRET = 'd956f6b9xxxxxxxyrA8X~PldtMCvUZPxxxxxxxx'
FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM;

-- Add the credential to the SQL Server administrator's domain login
ALTER LOGIN [<domain>\<login>]
ADD CREDENTIAL sysadmin_ekm_cred;

    Ein Beispiel für die Verwendung von Variablen für das Argument CREATE CREDENTIAL und die programmgesteuerte Entfernung der Bindestriche aus der Client-ID finden Sie unter ANMELDEDATEN ERSTELLEN.

  5. Öffnen Sie Ihren Azure Key Vault-Schlüssel in Ihrer SQL Server-Instanz.

    Unabhängig davon, ob Sie einen neuen Schlüssel erstellt oder nach der Beschreibung in Schritt 2: Erstellen eines Schlüsseltresors einen asymmetrischen Schlüssel importiert haben, müssen Sie den Schlüssel öffnen. Öffnen Sie den Schlüssel, indem Sie im folgenden Transact-SQL-Skript Ihren Schlüsselnamen angeben.

    Wichtig

    Stellen Sie sicher, dass zuerst die Registrierungsvoraussetzungen für diesen Schritt erfüllt sind.

    • Ersetzen Sie EKMSampleASYKey durch den Namen, den der Schlüssel in SQL Server erhalten soll.
    • Ersetzen Sie ContosoRSAKey0 durch den Namen Ihres Schlüssels in Ihrem Azure Key Vault oder verwalteten HSM. Nachfolgend finden Sie ein Beispiel für einen versionslosen Schlüssel.
    CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0',
CREATION_DISPOSITION = OPEN_EXISTING;

    Ab der aktualisierten Version 1.0.5.0 des SQL Server-Connectors können Sie auf eine bestimmte Schlüsselversion im Azure Key Vault verweisen:

    CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379',
CREATION_DISPOSITION = OPEN_EXISTING;

    Im vorherigen Beispielskript stellt 1a4d3b9b393c4678831ccc60def75379 die spezifische Version des Schlüssels dar, der verwendet wird. Wenn Sie dieses Skript verwenden, spielt es keine Rolle, ob Sie den Schlüssel mit einer neuen Version aktualisieren. Die Schlüsselversion (Beispiel) 1a4d3b9b393c4678831ccc60def75379 wird immer für Datenbankvorgänge verwendet.

  6. Erstellen Sie mit dem asymmetrischen Schlüssel in SQL Server, den Sie im vorherigen Schritt erstellt haben, eine neue Anmeldung.

    --Create a Login that will associate the asymmetric key to this login
CREATE LOGIN TDE_Login
FROM ASYMMETRIC KEY EKMSampleASYKey;

  7. Erstellen Sie mithilfe des asymmetrischen Schlüssels in SQL Server eine neue Anmeldung. Löschen Sie die Zuordnung der Anmeldeinformationen aus Schritt 5: Konfigurieren von SQL Server so, dass die Anmeldeinformationen der neuen Anmeldung zugeordnet werden können.

    --Now drop the credential mapping from the original association
ALTER LOGIN [<domain>\<login>]
DROP CREDENTIAL sysadmin_ekm_cred;

  8. Ändern Sie die neue Anmeldung, und ordnen Sie die EKM-Anmeldeinformationen der neuen Anmeldung zu.

    --Now add the credential mapping to the new Login
ALTER LOGIN TDE_Login
ADD CREDENTIAL sysadmin_ekm_cred;

Konfigurieren der zu verschlüsselnden Benutzerdatenbank

  1. Erstellen Sie eine Testdatenbank, die mit dem Schlüssel des Azure Key Vaults verschlüsselt wird.

    --Create a test database that will be encrypted with the Azure Key Vault key
CREATE DATABASE TestTDE;

  2. Erstellen Sie einen Schlüssel für die Datenbank über ASYMMETRIC KEY (EKMSampleASYKey).

    USE <DB Name>;
--Create an ENCRYPTION KEY using the ASYMMETRIC KEY (EKMSampleASYKey)
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER ASYMMETRIC KEY EKMSampleASYKey;

  3. Verschlüsseln Sie die Testdatenbank. Aktivieren Sie TDE durch Festlegen von ENCRYPTION ON.

    --Enable TDE by setting ENCRYPTION ON
ALTER DATABASE TestTDE
SET ENCRYPTION ON;

Registrierungsdetails

  1. Führen Sie die folgende Transact-SQL-Abfrage in der master-Datenbank aus, damit der verwendete asymmetrischen Schlüssel angezeigt wird.

    SELECT name, algorithm_desc, thumbprint FROM sys.asymmetric_keys;

    Die Anweisung gibt Folgendes zurück:

    name            algorithm_desc    thumbprint
EKMSampleASYKey RSA_2048          <key thumbprint>

  2. Führen Sie in der Benutzerdatenbank (TestTDE) die folgende Transact-SQL-Abfrage aus, damit der verwendeten Schlüssel angezeigt wird.

    SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint
FROM sys.dm_database_encryption_keys
WHERE database_id = DB_ID('TestTDE');

    Die Anweisung gibt Folgendes zurück:

    encryptor_type encryption_state_desc encryptor_thumbprint
ASYMMETRIC KEY ENCRYPTED             <key thumbprint>

Bereinigung

  1. Bereinigen Sie die Testobjekte. Löschen Sie alle Objekte, die in diesem Testskript erstellt wurden.

    -- CLEAN UP
USE master;
GO
ALTER DATABASE [TestTDE] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [TestTDE];
GO

ALTER LOGIN [TDE_Login] DROP CREDENTIAL [sysadmin_ekm_cred];
DROP LOGIN [TDE_Login];
GO

DROP CREDENTIAL [sysadmin_ekm_cred];
GO

USE master;
GO
DROP ASYMMETRIC KEY [EKMSampleASYKey];
DROP CRYPTOGRAPHIC PROVIDER [AzureKeyVault_EKM];
GO

    Beispielskripts finden Sie im Blog zum Thema SQL Server Transparent Data Encryption und erweiterbare Schlüsselverwaltung mit Azure Key Vault.

  2. Der SQL Server Cryptographic Provider-Registrierungsschlüssel wird nach dem Löschen eines Schlüssels oder aller EKM-Schlüssel nicht automatisch bereinigt. Sie muss manuell bereinigt werden. Das Bereinigen des Registrierungsschlüssels sollte mit äußerster Vorsicht erfolgen, da bei vorzeitiger Bereinigung der Registrierung die EKM-Funktionalität unterbrochen werden kann. Löschen Sie zum Bereinigen des Registrierungsschlüssels den SQL Server Cryptographic Provider-Registrierungsschlüssel auf HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.

Problembehandlung

Wenn der Registrierungsschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider nicht erstellt ist oder die erforderlichen Berechtigungen nicht erteilt sind, schlägt die folgende DDL-Anweisung fehl:

CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0',
CREATION_DISPOSITION = OPEN_EXISTING;

Msg 33049, Level 16, State 2, Line 65
Key with name 'ContosoRSAKey0' does not exist in the provider or access is denied. Provider error code: 2058.  (Provider Error - No explanation is available, consult EKM Provider for details)

Bald ablaufende geheime Clientschlüssel

Wenn die Anmeldeinformationen einen geheimen Clientschlüssel aufweisen, der demnächst abläuft, kann den Anmeldeinformationen ein neues Geheimnis zugewiesen werden.

  1. Aktualisieren Sie das ursprünglich erstellte Geheimnis aus Schritt 1: Einrichten eines Azure AD-Dienstprinzipals.

  2. Ändern Sie die Anmeldeinformationen mit der selben Identität und dem neuen Geheimnis mithilfe des folgenden Codes. Ersetzen Sie <New Secret> durch Ihr neues Geheimnis:

    ALTER CREDENTIAL sysadmin_ekm_cred
WITH IDENTITY = 'DocsSampleEKMKeyVault',
SECRET = '<New Secret>';

  3. Starten Sie den SQL Server-Dienst neu.

Hinweis

Wenn Sie EKM in einer Verfügbarkeitsgruppe (AG) einsetzen, müssen Sie die Anmeldedaten ändern und den SQL Server-Dienst auf allen Knoten der AG neu starten.

Nehmen Sie eine Rotation des asymmetrischen Schlüssels mit einem neuen AKV-Schlüssel oder einer neuen AKV-Schlüsselversion vor.

Hinweis

  • Wenn Sie einen AKV-Schlüssel manuell drehen, unterstützt SQL Server sowohl AKV-Schlüssel ohne Version oder versionsgesteuerten Schlüssel und es ist nicht erforderlich, einen anderen AKV-Schlüssel zu verwenden.
  • Der ursprüngliche AKV-Schlüssel kann gedreht werden, um eine neue Version zu erstellen, die den vorherigen schlüssel ersetzen kann, der in SQL Server erstellt wurde.
  • Bei manueller Schlüsseldrehung muss ein neuer asymmetrischer SQL Server-Schlüssel erstellt werden, der auf den versionslosen Schlüssel oder den versionierten Schlüssel verweist, der in AKV gedreht wurde. Für den neuen asymmetrischen SQL Server-Schlüssel wird der AKV-Schlüssel ohne Version automatisch mit der höchsten Schlüsselversion in AKV ausgewählt. Für den versionsierten Schlüssel müssen Sie die höchste Version in AKV mit der Syntax WITH PROVIDER_KEY_NAME = <key_name>/<version> angeben. Sie können den Verschlüsselungsschlüssel der Datenbank ändern, um ihn mit dem neuen asymmetrischen Schlüssel neu zu verschlüsseln. Derselbe Schlüsselname (mit oder ohne Version) kann mit der AKV-Rotationsrichtlinie verwendet werden. Bei versionierten Schlüsseln muss die aktuelle Version hinzugefügt werden. Für versionslose Schlüssel wird derselbe Schlüsselname verwendet.

SQL Server verfügt nicht über einen Mechanismus zur automatischen Rotation des für TDE verwendeten asymmetrischen Schlüssels. Für die manuelle Rotation eines asymmetrischen Schlüssels gelten die folgenden Schritte.

  1. Der in unserer Ersteinrichtung verwendete Berechtigungsnachweis (sysadmin_ekm_cred) kann auch für die Schlüsselrotation wiederverwendet werden. Optional können Sie eine neue Berechtigung für den neuen asymmetrischen Schlüssel erstellen.

    CREATE CREDENTIAL <new_credential_name>
    WITH IDENTITY = <key vault>,
    SECRET = 'existing/new secret'
    FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM;

  2. Fügen Sie die Anmeldedaten dem Prinzipal hinzu:

    ALTER LOGIN [domain\userName];
ADD CREDENTIAL <new_credential_name>;

  3. Erstellen Sie den neuen asymmetrischen Schlüssel auf der Grundlage des neuen Schlüssels (nach dem Drehen des Schlüssels). Der neue Schlüssel könnte ein versionsloser Schlüssel (ContosoRSAKey0 in unserem Beispiel) oder ein Schlüssel mit Version sein (ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379 wobei 1a4d3b9b393c4678831ccc60def75379 die Version des aktualisierten Schlüssels in AKV ist):

    CREATE ASYMMETRIC KEY <new_ekm_key_name>
 FROM PROVIDER [AzureKeyVault_EKM]
 WITH PROVIDER_KEY_NAME = <new_key_from_key_vault>,
 CREATION_DISPOSITION = OPEN_EXISTING;

  4. Erstellen Sie mithilfe des asymmetrischen Schlüssels eine neue Anmeldung:

    CREATE LOGIN <new_login_name>
FROM ASYMMETRIC KEY <new_ekm_key_name>;

  5. Legen Sie die Anmeldeinformationen des Prinzipals ab:

    ALTER LOGIN [domain\username]
DROP CREDENTIAL <new_credential_name>;

  6. Ordnen Sie die AKV-Anmeldedaten der neuen Anmeldung zu:

    ALTER LOGIN <new_login_name>;
ADD CREDENTIAL <new_credential_name>;

  7. Ändern Sie den Datenbankschlüssel (DEK) so, dass er mit dem neuen asymmetrischen Schlüssel neu verschlüsselt wird:

    USE [databaseName];
GO
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY <new_ekm_key_name>;

  8. Sie können den neuen asymmetrischen Schlüssel und den in der Datenbank verwendeten Verschlüsselungsschlüssel überprüfen:

    SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint
FROM sys.dm_database_encryption_keys
WHERE database_id = DB_ID('databaseName');

    Dieser Fingerabdruck sollte mit dem Registrierungsschlüssel unter dem Pfad HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider\Azure Key Vault\<key_vault_url>\<thumbprint> übereinstimmen und Ihnen das KeyUri für Ihren gedrehten Schlüssel liefern.

Wichtig

Die Rotation der logischen TDE-Schutzvorrichtung für einen Server bewirkt einen Wechsel zu einem neuen asymmetrischen Schlüssel oder zu einem Zertifikat, das den Datenbankschlüssel (DEK) schützt. Die Schlüsselrotation ist ein Onlinevorgang, der in wenigen Sekunden abgeschlossen sein sollte, da nur der DEK entschlüsselt und wieder verschlüsselt wird und nicht die gesamte Datenbank.

Löschen Sie nach der Rotation keine vorherigen Versionen des Schlüssels. Bei einem Rotation von Schlüsseln sind einige Daten noch immer mit den vorherigen Schlüsseln verschlüsselt, z. B. ältere Datenbanksicherungen, gesicherte Protokolldateien, virtuelle Protokolldateien (VLF) und Transaktionsprotokolldateien. Frühere Schlüssel können auch für eine Datenbank-Recovery oder eine Datenbankwiederherstellung erforderlich sein.

Zugehöriger Inhalt