Erweiterbare Schlüsselverwaltung mit Azure Key Vault (SQL Server)

Die SQL Server-Connector für Microsoft Azure Key Vault ermöglicht SQL Server Verschlüsselung, um den Azure Key Vault-Dienst als EKM-Anbieter (Extensible Key Management) zum Schutz der Verschlüsselungsschlüssel zu nutzen.

In diesem Thema:

Verwendungsmöglichkeiten für erweiterbare Schlüsselverwaltung

Ein organization kann SQL Server Verschlüsselung verwenden, um vertrauliche Daten zu schützen. SQL Server Verschlüsselung umfasst Transparent Data Encryption (TDE),Column Level Encryption (CLE) und Sicherungsverschlüsselung. In all diesen Fällen werden die Daten mit einem symmetrischen Datenverschlüsselungsschlüssel verschlüsselt. Der symmetrische Datenverschlüsselungsschlüssel wird außerdem geschützt durch Verschlüsselung mit einer Hierarchie von Schlüsseln, die in SQL Servergespeichert sind. Alternativ ermöglicht die EKM-Anbieterarchitektur SQL Server, die Datenverschlüsselungsschlüssel mithilfe eines asymmetrischen Schlüssels zu schützen, der außerhalb von SQL Server in einem externen Kryptografieanbieter gespeichert ist. Die Verwendung der Architektur des Anbieters für erweiterbare Schlüsselverwaltung stellt eine zusätzliche Sicherheitsebene dar und ermöglicht Unternehmen die getrennte Verwaltung von Schlüsseln und Daten.

Mit dem SQL Server Connector für Azure Key Vault können SQL Server den skalierbaren, leistungsstarken und hochverfügbaren Schlüsseltresordienst als EKM-Anbieter für den Schutz von Verschlüsselungsschlüsseln nutzen. Der Schlüsseltresordienst kann mit SQL Server Installationen in Microsoft Azure Virtual Machines und für lokale Server verwendet werden. Der Schlüsseltresordienst bietet auch die Option, genau gesteuerte und stark überwachte Hardwaresicherheitsmodule (HSMs) für ein höheres Maß an Schutz für asymmetrische Schlüssel zu verwenden. Weitere Informationen zum Schlüsseltresor finden Sie unter Azure Key Vault.

Die folgende Grafik enthält eine Zusammenfassung des Prozessablaufs der erweiterbaren Schlüsselverwaltung mit Schlüsseltresor. Die Nummern der Prozessschritte in der Grafik stimmen nicht mit den Nummern der Einrichtungsschritte, die auf die Grafik folgen, überein.

SQL Server EKM mithilfe des Azure Key Vault

Schritt 1: Einrichten des Schlüsseltresors für die Verwendung durch SQL Server

Führen Sie die folgenden Schritte aus, um einen Schlüsseltresor für die Verwendung mit der SQL Server-Datenbank-Engine für den Schutz des Verschlüsselungsschlüssels einzurichten. Für die Organisation wird möglicherweise bereits ein Tresor verwendet. Wenn kein Tresor vorhanden ist, kann der Azure-Administrator in Ihrem organization, der für die Verwaltung von Verschlüsselungsschlüsseln bestimmt ist, einen Tresor erstellen, einen asymmetrischen Schlüssel im Tresor generieren und dann SQL Server für die Verwendung des Schlüssels autorisieren. Machen Sie sich unter Erste Schritte mit Azure Key Vaultund der Referenz zu PowerShell- Azure Key Vault-Cmdlets mit dem Schlüsseltresordienst vertraut.

Wichtig

Wenn Sie über mehrere Azure-Abonnements verfügen, müssen Sie das Abonnement verwenden, das SQL Server enthält.

  1. Erstellen Sie einen Tresor: Erstellen Sie einen Tresor nach der Anweisungen im Abschnitt Erstellen eines Schlüsseltresors in Erste Schritte mit Azure Key Vault. Notieren Sie den Namen des Tresors. In diesem Thema wird ContosoKeyVault als Schlüsseltresorname verwendet.

  2. Generieren Sie einen asymmetrischen Schlüssel im Tresor: Der asymmetrische Schlüssel im Schlüsseltresor wird verwendet, um SQL Server Verschlüsselungsschlüssel zu schützen. Nur der öffentliche Teil des asymmetrischen Schlüssels verlässt jemals den Tresor, der private Teil wird nie vom Tresor exportiert. Alle kryptografischen Vorgänge mit dem asymmetrischen Schlüssel werden an den Azure-Schlüsseltresor delegiert und durch die Schlüsseltresorsicherheit geschützt.

    Es gibt mehrere Möglichkeiten, wie Sie einen asymmetrischen Schlüssel generieren und im Tresor speichern können. Sie können einen Schlüssel extern generieren und den Schlüssel als PFX-Datei in den Tresor importieren. Oder Sie erstellen den Schlüssel mit den Schlüsseltresor-APIs direkt im Tresor.

    Der SQL Server Connector erfordert, dass die asymmetrischen Schlüssel 2048-Bit-RSA sein, und der Schlüsselname darf nur die Zeichen "a-z", "A-Z", "0-9" und "-" verwenden. In diesem Dokument wird als Name des asymmetrischen Schlüssels ContosoMasterKeyverwendet. Ersetzen Sie dies durch den eindeutigen Namen, den Sie für den Schlüssel verwenden.

    Wichtig

    Das Importieren des asymmetrischen Schlüssels wird für Produktionsszenarien dringend empfohlen, da der Administrator dann den Schlüssel in einem Schlüsselhinterlegungssystem hinterlegen kann. Wenn der asymmetrische Schlüssel im Tresor erstellt wird, kann er nicht hinterlegt werden, da der private Schlüssel nie den Tresor verlassen kann. Schlüssel zum Schützen wichtiger Daten sollten hinterlegt werden. Der Verlust eines asymmetrischen Schlüssels führt dazu, dass Daten dauerhaft nicht wiederhergestellt werden können.

    Wichtig

    Der Schlüsseltresor unterstützt mehrere Versionen desselben benannten Schlüssels. Schlüssel, die von SQL Server Connector verwendet werden sollen, sollten keine Versionsangabe oder ein Rollback aufweisen. Wenn der Administrator den Schlüssel, der für SQL Server Verschlüsselung verwendet wird, rollieren möchte, sollte im Tresor ein neuer Schlüssel mit einem anderen Namen erstellt und zum Verschlüsseln des DEK verwendet werden.

    Weitere Informationen zum Importieren eines Schlüssels in den Tresor oder zum Erstellen eines Schlüssels im Schlüsseltresor (nicht empfohlen für Produktionsumgebungen) finden Sie im Abschnitt Hinzufügen eines Schlüssels oder eines geheimen Schlüssels zum Schlüsseltresor in Erste Schritte mit Azure Key Vault.

  3. Rufen Sie Azure Active Directory-Dienstprinzipale für SQL Server ab: Wenn sich die Organisation für einen Microsoft Cloud-Dienst registriert, erhält sie ein Azure Active Directory. Erstellen Sie Dienstprinzipale in Azure Active Directory, damit SQL Server beim Zugriff auf den Schlüsseltresor verwenden können (um sich bei Azure Active Directory zu authentifizieren).

    • Ein Dienstprinzipal wird von einem SQL Server Administrator benötigt, um auf den Tresor zuzugreifen, während SQL Server für die Verwendung der Verschlüsselung konfiguriert wird.

    • Die SQL Server-Datenbank-Engine benötigt einen weiteren Dienstprinzipal für den Zugriff auf den Tresor zum Entpacken von Schlüsseln, die in SQL Server Verschlüsselung verwendet werden.

    Weitere Informationen zum Registrieren einer Anwendung und Generieren eines Dienstprinzipals finden Sie im Abschnitt Registrieren einer Anwendung in Azure Active Directory in Erste Schritte mit Azure Key Vault. Der Registrierungsprozess gibt eine Anwendungs-ID (auch bekannt als CLIENT-ID) und einen Authentifizierungsschlüssel (auch bekannt als geheimer Schlüssel) für jeden Azure Active Directory- Dienstprinzipalzurück. Bei Verwendung in der CREATE CREDENTIAL -Anweisung muss der Bindestrich aus der CLIENT-ID entfernt werden. Notieren Sie diese für die Verwendung in den unten stehenden Skripts:

    • Dienstprinzipal für eine sysadmin -Anmeldung: CLIENTID_sysadmin_login und SECRET_sysadmin_login

    • Dienstprinzipal für die SQL Server-Datenbank-Engine: CLIENTID_DBEngine und SECRET_DBEngine.

  4. Erteilen der Berechtigung für die Dienstprinzipale für den Zugriff auf die Key Vault: Sowohl die CLIENTID_sysadmin_login als auch CLIENTID_DBEngineService Prinzipale erfordern die Berechtigungen get, list, wrapKey und unwrapKey im Schlüsseltresor. Wenn Sie Schlüssel über SQL Server erstellen möchten, müssen Sie auch die Berechtigung zum Erstellen im Schlüsseltresor erteilen.

    Wichtig

    Benutzer müssen mindestens über die Vorgänge wrapKey und unwrapKey für den Schlüsseltresor verfügen.

    Weitere Informationen zum Erteilen von Berechtigungen für den Tresor finden Sie im Abschnitt Autorisieren der Anwendung zum Verwenden des Schlüssels oder des geheimen Schlüssels in Erste Schritte mit Azure Key Vault.

    Links zur Dokumentation für Azure Key Vault

Schritt 2: Installieren des SQL Server-Connectors

Der SQL Server Connector wird vom Administrator des SQL Server Computers heruntergeladen und installiert. Der SQL Server Connector steht als Download im Microsoft Download Center zur Verfügung. Suchen Sie nach SQL Server-Connector für Microsoft Azure Key Vault. Überprüfen Sie die Details, Systemanforderungen und Installationsanweisungen, wählen Sie den Download des Connectors, und starten Sie die Installation mit Ausführen. Lesen Sie die Lizenzbedingungen, stimmen Sie ihnen zu, und setzen Sie den Vorgang fort.

Standardmäßig wird der Connector unter C:\Programme\SQL Server-Connector für Microsoft Azure Key Vault installiert. Dieser Speicherort kann während des Setups geändert werden. (Wenn Sie ihn ändern, passen Sie die unten angegebenen Skripts entsprechend an.)

Nach Abschluss der Installation ist Folgendes auf dem Computer installiert:

  • Microsoft.AzureKeyVaultService.EKM.dll: Dies ist die kryptografische EKM-Anbieter-DLL, die mit der CREATE CRYPTOGRAPHIC PROVIDER-Anweisung bei SQL Server registriert werden muss.

  • Azure Key Vault SQL Server-Connector: Dies ist ein Windows-Dienst, der dem kryptografischen Anbieter für erweiterbare Schlüsselverwaltung die Kommunikation mit dem Schlüsseltresor ermöglicht.

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

Schritt 3: Konfigurieren von SQL Server zur Verwendung eines Anbieters für erweiterbare Schlüsselverwaltung für den Schlüsseltresor

Berechtigungen

Das gesamte Verfahren erfordert die CONTROL SERVER-Berechtigung oder die Mitgliedschaft in der festen Serverrolle sysadmin . Bestimmte Aktionen erfordern die folgenden Berechtigungen:

  • Zum Erstellen eines Kryptografieanbieters ist die CONTROL SERVER-Berechtigung oder die Mitgliedschaft in der festen Serverrolle sysadmin erforderlich.

  • Zum Ändern einer Konfigurationsoption und Ausführen der RECONFIGURE-Anweisung muss Ihnen die ALTER SETTINGS-Berechtigung auf Serverebene erteilt worden sein. Die ALTER SETTINGS-Berechtigung ist in den festen Serverrollen sysadmin und serveradmin eingeschlossen.

  • Zum Erstellen von Anmeldeinformationen ist die ALTER ANY CREDENTIAL-Berechtigung erforderlich.

  • Zum Hinzufügen von Anmeldeinformationen zu einem Anmeldenamen ist die ALTER ANY LOGIN-Berechtigung erforderlich.

  • Zum Erstellen eines asymmetrischen Schlüssels ist die CREATE ASYMMETRIC KEY-Berechtigung erforderlich.

So konfigurieren Sie SQL Server für die Verwendung eines Kryptografieanbieters

  1. Konfigurieren Sie die Datenbank-Engine für die Verwendung von EKM, und registrieren (erstellen) Sie den Kryptografieanbieter bei SQL Server.

    -- Enable advanced options.
    USE master;
    GO
    
    sp_configure 'show advanced options', 1 ;
    GO
    RECONFIGURE ;
    GO
    -- Enable EKM provider
    sp_configure 'EKM provider enabled', 1 ;
    GO
    RECONFIGURE ;
    GO
    
    -- Create a cryptographic provider, using the SQL Server Connector
    -- which is an EKM provider for the Azure Key Vault. This example uses 
    -- the name AzureKeyVault_EKM_Prov.
    
    CREATE CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov 
    FROM FILE = 'C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault\Microsoft.AzureKeyVaultService.EKM.dll';
    GO
    
  2. Richten Sie eine SQL Server Anmeldeinformationen für eine SQL Server Administratoranmeldung ein, um den Schlüsseltresor zu verwenden, um SQL Server Verschlüsselungsszenarien einzurichten und zu verwalten.

    Wichtig

    Das IDENTITY-Argument von erfordert den Namen des Schlüsseltresors CREATE CREDENTIAL . Das SECRET-Argument von CREATE CREDENTIAL erfordert, dass die <Client-ID> (ohne Bindestriche) und <Secret> ohne Leerzeichen zwischen ihnen übergeben werden.

    Im folgenden Beispiel wird die Client-ID (EF5C8E09-4D2A-4A76-9998-D93440D8115D) von den Bindestrichen entfernt und als Zeichenfolge EF5C8E094D2A4A769998D93440D8115D eingegeben, und das Geheimnis wird durch die Zeichenfolge SECRET_sysadmin_login dargestellt.

    USE master;
    CREATE CREDENTIAL sysadmin_ekm_cred 
        WITH IDENTITY = 'ContosoKeyVault', 
        SECRET = 'EF5C8E094D2A4A769998D93440D8115DSECRET_sysadmin_login' 
    FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov ;
    
    -- Add the credential to the SQL Server administrators domain login 
    ALTER LOGIN [<domain>/<login>]
    ADD CREDENTIAL sysadmin_ekm_cred;
    

    Ein Beispiel für die Verwendung von Variablen für die CREATE CREDENTIAL Argumente und das programmgesteuerte Entfernen der Bindestriche aus der Client-ID finden Sie unter CREATE CREDENTIAL (Transact-SQL).

  3. Wenn Sie einen asymmetrischen Schlüssel importiert haben, wie zuvor in Schritt 1, Abschnitt 3, beschrieben, öffnen Sie den Schlüssel, indem Sie im folgenden Beispiel Ihren Schlüsselnamen angeben.

    CREATE ASYMMETRIC KEY CONTOSO_KEY 
    FROM PROVIDER [AzureKeyVault_EKM_Prov]
    WITH PROVIDER_KEY_NAME = 'ContosoMasterKey',
    CREATION_DISPOSITION = OPEN_EXISTING;
    

    Obwohl für die Produktion nicht empfohlen (da der Schlüssel nicht exportiert werden kann), ist es möglich, einen asymmetrischen Schlüssel direkt im Tresor aus SQL Server zu erstellen. Wenn Sie zuvor keinen Schlüssel importiert haben, erstellen Sie mit dem folgenden Skript zu Testzwecken einen asymmetrischen Schlüssel im Schlüsseltresor. Führen Sie das Skript mithilfe einer mit den Anmeldeinformationen sysadmin_ekm_cred bereitgestellten Anmeldung aus.

    CREATE ASYMMETRIC KEY CONTOSO_KEY 
    FROM PROVIDER [AzureKeyVault_EKM_Prov]
    WITH ALGORITHM = RSA_2048,
    PROVIDER_KEY_NAME = 'ContosoMasterKey';
    

Tipp

Benutzer, die den Fehler Erhalten, kann öffentlicher Schlüssel vom Anbieter nicht exportiert werden. Anbieterfehlercode: 2053. sollte ihre Berechtigungen get, list, wrapKey und unwrapKey im Schlüsseltresor überprüfen.

Weitere Informationen finden Sie unter

Beispiele

Beispiel A: Transparente Datenverschlüsselung mit einem asymmetrischen Schlüssel aus dem Schlüsseltresor

Erstellen Sie nach Abschluss der obigen Schritte Anmeldeinformationen und eine Anmeldung, und erstellen Sie einen Datenbank-Verschlüsselungsschlüssel, der durch den asymmetrischen Schlüssel im Schlüsseltresor geschützt wird. Verwenden Sie den Datenbank-Verschlüsselungsschlüssel zum Verschlüsseln einer Datenbank mit transparenter Datenverschlüsselung.

Zum Verschlüsseln einer Datenbank ist die CONTROL-Berechtigung für die Datenbank erforderlich.

So aktivieren Sie die transparente Datenverschlüsselung mit erweiterbarer Schlüsselverwaltung und dem Schlüsseltresor
  1. Erstellen Sie SQL Server-Anmeldeinformationen für die Datenbank-Engine, die beim Laden der Datenbank für den Zugriff auf die erweiterbare Schlüsselverwaltung mit dem Schlüsseltresor verwendet werden.

    Wichtig

    Das IDENTITY-Argument von CREATE CREDENTIAL erfordert den Namen des Schlüsseltresors. Das SECRET-Argument von CREATE CREDENTIAL erfordert, dass die <Client-ID> (ohne Bindestriche) und <Secret> ohne Leerzeichen zwischen ihnen übergeben werden.

    Im folgenden Beispiel wird die Client-ID (EF5C8E09-4D2A-4A76-9998-D93440D8115D) von den Bindestrichen bereinigt und als Zeichenfolge EF5C8E094D2A4A769998D93440D8115D eingegeben. Der geheime Schlüssel wird durch die Zeichenfolge SECRET_DBEnginedargestellt.

    USE master;
    CREATE CREDENTIAL Azure_EKM_TDE_cred 
        WITH IDENTITY = 'ContosoKeyVault', 
        SECRET = 'EF5C8E094D2A4A769998D93440D8115DSECRET_DBEngine' 
        FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov ;
    
  2. Erstellen Sie einen SQL Server-Anmeldenamen, der von Datenbank-Engine für TDE verwendet werden soll, und fügen Sie ihr die Anmeldeinformationen hinzu. In diesem Beispiel wird der asymmetrische Schlüssel CONTOSO_KEY aus dem Schlüsseltresor verwendet, der importiert oder zuvor für die Masterdatenbank erstellt wurde, wie oben in Schritt 3, Abschnitt 3 beschrieben.

    USE master;
    -- Create a SQL Server login associated with the asymmetric key 
    -- for the Database engine to use when it loads a database 
    -- encrypted by TDE.
    CREATE LOGIN TDE_Login 
    FROM ASYMMETRIC KEY CONTOSO_KEY;
    GO 
    
    -- Alter the TDE Login to add the credential for use by the 
    -- Database Engine to access the key vault
    ALTER LOGIN TDE_Login 
    ADD CREDENTIAL Azure_EKM_TDE_cred ;
    GO
    
  3. Erstellen Sie den Datenbank-Verschlüsselungsschlüssel (Database Encryption Key, DEK), der für die transparente Datenverschlüsselung verwendet wird. Der DEK kann mit jedem von SQL Server unterstützten Algorithmus und jeder unterstützten Schlüssellänge erstellt werden. Der DEK wird durch den asymmetrischen Schlüssel im Schlüsseltresor geschützt.

    In diesem Beispiel wird der asymmetrische Schlüssel CONTOSO_KEY aus dem Schlüsseltresor verwendet, der importiert oder zuvor erstellt wurde, wie oben in Schritt 3, Abschnitt 3 beschrieben.

    USE ContosoDatabase;
    GO
    
    CREATE DATABASE ENCRYPTION KEY 
    WITH ALGORITHM = AES_128 
    ENCRYPTION BY SERVER ASYMMETRIC KEY CONTOSO_KEY;
    GO
    
    -- Alter the database to enable transparent data encryption.
    ALTER DATABASE ContosoDatabase 
    SET ENCRYPTION ON ;
    GO
    

    Weitere Informationen finden Sie unter

Beispiel B: Verschlüsseln von Sicherungen mit einem asymmetrischen Schlüssel aus dem Schlüsseltresor

Verschlüsselte Sicherungen werden ab SQL Server 2014 unterstützt. Im folgenden Beispiel wird eine Sicherung erstellt und wiederhergestellt, die mit einem Verschlüsselungsschlüssel verschlüsselt wurde, der durch den asymmetrischen Schlüssel im Schlüsseltresor geschützt wird.

USE master;
BACKUP DATABASE [DATABASE_TO_BACKUP]
TO DISK = N'[PATH TO BACKUP FILE]' 
WITH FORMAT, INIT, SKIP, NOREWIND, NOUNLOAD, 
ENCRYPTION(ALGORITHM = AES_256, SERVER ASYMMETRIC KEY = [CONTOSO_KEY]);
GO

Beispiel für Wiederherstellungscode.

RESTORE DATABASE [DATABASE_TO_BACKUP]
FROM DISK = N'[PATH TO BACKUP FILE]' WITH FILE = 1, NOUNLOAD, REPLACE;
GO

Weitere Informationen zu Sicherungsoptionen finden Sie unter BACKUP (Transact-SQL).

Beispiel C: Verschlüsselung auf Spaltenebene mit einem asymmetrischen Schlüssel aus dem Schlüsseltresor

Das folgende Beispiel erstellt einen symmetrischen Schlüssel, der durch den asymmetrischen Schlüssel im Schlüsseltresor geschützt wird. Anschließend wird der symmetrische Schlüssel zum Verschlüsseln von Daten in der Datenbank verwendet.

In diesem Beispiel wird der asymmetrische Schlüssel CONTOSO_KEY aus dem Schlüsseltresor verwendet, der importiert oder zuvor erstellt wurde, wie oben in Schritt 3, Abschnitt 3 beschrieben. Um diesen asymmetrischen Schlüssel in der ContosoDatabase -Datenbank zu verwenden, müssen Sie die CREATE ASYMMETRIC KEY-Anweisung erneut ausführen, um der ContosoDatabase -Datenbank einen Verweis auf den Schlüssel zur Verfügung zu stellen.

USE [ContosoDatabase];
GO

-- Create a reference to the key in the key vault
CREATE ASYMMETRIC KEY CONTOSO_KEY 
FROM PROVIDER [AzureKeyVault_EKM_Prov]
WITH PROVIDER_KEY_NAME = 'ContosoMasterKey',
CREATION_DISPOSITION = OPEN_EXISTING;

-- Create the data encryption key.
-- The data encryption key can be created using any SQL Server 
-- supported algorithm or key length.
-- The DEK will be protected by the asymmetric key in the key vault

CREATE SYMMETRIC KEY DATA_ENCRYPTION_KEY
    WITH ALGORITHM=AES_256
    ENCRYPTION BY ASYMMETRIC KEY CONTOSO_KEY;

DECLARE @DATA VARBINARY(MAX);

--Open the symmetric key for use in this session
OPEN SYMMETRIC KEY DATA_ENCRYPTION_KEY 
DECRYPTION BY ASYMMETRIC KEY CONTOSO_KEY;

--Encrypt syntax
SELECT @DATA = ENCRYPTBYKEY(KEY_GUID('DATA_ENCRYPTION_KEY'), CONVERT(VARBINARY,'Plain text data to encrypt'));

-- Decrypt syntax
SELECT CONVERT(VARCHAR, DECRYPTBYKEY(@DATA));

--Close the symmetric key
CLOSE SYMMETRIC KEY DATA_ENCRYPTION_KEY;

Weitere Informationen

CREATE CRYPTOGRAPHIC PROVIDER (Transact-SQL)CREATE CREDENTIAL (Transact-SQL)CREATE ASYMMETRIC KEY (Transact-SQL)CREATE SYMMETRIC KEY (Transact-SQL)Extensible Key Management (EKM)Enable TDE Using EKMBackup EncryptionCreate an Encrypted Backup Create an Encrypted Backup