Freigeben über

Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) mit kundenseitig verwalteten Schlüsseln auf Datenbankebene

  • Artikel

Gilt für: Azure SQL-Datenbank

In diesem Artikel wird die transparente Datenverschlüsselung (TDE) mit kundenseitig verwalteten Schlüsseln auf Datenbankebene für Azure SQL-Datenbank beschrieben.

Hinweis

TDE CMK auf Datenbankebene ist für Azure SQL-Datenbank (alle SQL-Datenbank-Editionen) verfügbar. Sie ist nicht für Azure SQL Managed Instance, lokale SQL Server-Instanzen, Azure-VMs und Azure Synapse Analytics (dedizierte SQL-Pools, früher SQL DW) verfügbar.

Hinweis

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

Übersicht

Azure SQL bietet Kunden Verschlüsselungsfunktionen im Ruhezustand durch transparente Datenverschlüsselung (Transparent Data Encryption, TDE). Durch das Erweitern von TDE mit kundenseitig verwalteten Schlüsseln (Customer-Managed Keys, CMK) wird der Schutz ruhender Daten in einer Azure Key Vault-Instanz gespeichert, die Datenbankverschlüsselungsschlüssel verschlüsselt. Derzeit ist TDE mit CMK auf Serverebene festgelegt und wird von allen verschlüsselten Datenbanken geerbt, die diesem Server zugeordnet sind. Mit diesem neuen Feature können Sie TDE-Schutz als kundenseitig verwalteten Schlüssel für jede Datenbank innerhalb des Servers festlegen. Jede Microsoft.Sql/servers/databases-Ressource mit einer gültigen, nicht leeren encryptionProtector-Eigenschaft wird mit kundenseitig verwalteten Schlüsseln auf Datenbankebene konfiguriert.

In diesem Szenario kann ein asymmetrischer Schlüssel, der in einer kundeneigenen und vom Kunden verwalteten Azure Key Vault-Instanz (AKV) gespeichert ist, einzeln für jede Datenbank innerhalb eines Servers verwendet werden, um den Datenbankverschlüsselungsschlüssel (Database Encryption Key, DEK) zu verschlüsseln, der als TDE-Schutz bezeichnet wird. Es gibt eine Option zum Hinzufügen von Schlüsseln, Entfernen von Schlüsseln und Ändern der vom Benutzer zugewiesenen verwalteten Identität (UMI) für jede Datenbank. Weitere Informationen zu Identitäten finden Sie unter Verwaltete Identitätstypen in Azure.

Die folgenden Funktionen sind verfügbar:

  • Benutzerseitig zugewiesene verwaltete Identität: Sie können der Datenbank eine einzelne benutzerseitig zugewiesene verwaltete Identität zuweisen. Diese Identität kann verwendet werden, um auf die Azure Key Vault-Instanz zuzugreifen und Verschlüsselungsschlüssel zu verwalten.
  • Verschlüsselungsschlüsselverwaltung: Sie können das Hinzufügen mindestens eines Verschlüsselungsschlüssels auf Datenbankebene aktivieren und einen der hinzugefügten Schlüssel als TDE-Schutz festlegen. Die hinzugefügten Verschlüsselungsschlüssel verwenden die benutzerseitig zugewiesene verwaltete Identität, die der Datenbank bereits zugewiesen ist, um auf Azure Key Vault zuzugreifen.
  • Verbundclientidentität: Sie können auch einen kundenseitig verwalteten Schlüssel (CMK) aus Azure Key Vault in einem anderen Microsoft Entra-Mandanten aktivieren, um ihn als TDE-Schutz auf Datenbankebene festzulegen, indem Sie die Verbundclientidentität verwenden, die für die Azure SQL-Datenbank festgelegt ist. Dadurch können Sie TDE mit Schlüsseln verwalten, die in der Azure Key Vault-Instanz eines anderen Mandanten gespeichert sind.

Hinweis

Die systemseitig zugewiesene verwaltete Identität wird auf Datenbankebene nicht unterstützt.

Vorteile kundenseitig verwalteter TDE auf Datenbankebene

Da immer mehr Dienstanbieter, die auch als unabhängige Softwareanbieter (Independent Software Vendors, ISVs) bezeichnet werden, Azure SQL-Datenbank verwenden, um ihre Dienste zu erstellen, werden häufig Pools für elastische Datenbanken genutzt, um Computeressourcen effizient auf mehrere Datenbanken zu verteilen. Wenn die Datenbanken ihrer Kunden in einem freigegebenen Pool für elastische Datenbanken vorhanden sind, können ISVs die Möglichkeiten des Pools ausschöpfen, um die Ressourcennutzung zu optimieren und gleichzeitig sicherzustellen, dass jede Datenbank über angemessene Ressourcen verfügt.

Es gibt jedoch eine erhebliche Einschränkung für diesen Ansatz. Wenn mehrere Datenbanken auf demselben logischen Azure SQL-Server gehostet werden, verwenden sie TDE-Schutz auf Serverebene. ISVs können ihren Kunden keine Funktionen für echte kundenseitig verwaltete Schlüssel (CMK) anbieten. Ohne die Möglichkeit, ihre eigenen Verschlüsselungsschlüssel zu verwalten, zögern Kunden möglicherweise, sensible Daten dem Dienst des ISV anzuvertrauen, insbesondere wenn sie aufgrund von Compliancevorschriften vollständige Kontrolle über ihre Verschlüsselungsschlüssel bewahren müssen.

Mit TDE CMK auf Datenbankebene können ISVs ihren Kunden CMK-Funktionen bieten und Sicherheitsisolierung erreichen, weil der TDE-Schutz jeder Datenbank potenziell dem jeweiligen ISV-Kunden in einem Schlüsseltresor gehören kann, dessen Besitzer er ist. Die für die Kunden des ISV erzielte Sicherheitsisolierung bezieht sich sowohl auf den Schlüssel als auch auf die Identität, die für den Zugriff auf den Schlüssel verwendet wird.

Die folgende Abbildung fasst die oben genannten neuen Funktionen zusammen. Sie zeigt zwei separate Microsoft Entra-Mandanten. Der Best Services-Mandant, der den logischen Azure SQL-Server mit zwei Datenbanken (DB 1 und DB 2) enthält, und Azure Key Vault 1 mit Key 1 für den Zugriff auf die DB 1-Datenbank mithilfe von UMI 1. Sowohl UMI 1 als auch Key 1 stellen die Einstellung auf Serverebene dar. Standardmäßig erben alle Datenbanken, die ursprünglich auf diesem Server erstellt wurden, diese Einstellung für TDE mit CMK. Der Contoso-Mandant stellt einen Clientmandanten dar, der Azure Key Vault 2 mit Key 2 enthält, der die DB 2-Datenbank mandantenübergreifend als Teil der datenbankübergreifenden CMK-Unterstützung mit Key 2 und UMI 2 für diese Datenbank bewertet.

Einrichtung und Funktionsweise der kundenseitig verwalteten TDE auf Datenbankebene

Weitere Informationen zur mandantenübergreifenden Identitätskonfiguration finden Sie im folgenden Dokument auf Serverebene: Mandantenübergreifende kundenseitig verwaltete Schlüssel mit transparenter Datenverschlüsselung.

Unterstützte Szenarien für Schlüsselverwaltung

Im folgenden Abschnitt wird davon ausgegangen, dass ein Server vorhanden ist, der aus drei Datenbanken besteht (z. B. Database1, Database2 und Database3).

Vorhandenes Szenario

Key1 wird als kundenseitig verwalteter Schlüssel auf der Ebene des logischen Servers konfiguriert. Alle Datenbanken auf diesem Server erben denselben Schlüssel.

  • Server – Key1 als CMK festgelegt
  • Database1 – Key1 wird als CMK verwendet
  • Database2 – Key1 wird als CMK verwendet
  • Database3 – Key1 wird als CMK verwendet

Neues unterstütztes Szenario: Logischer Server, der mit kundenseitig verwaltetem Schlüssel konfiguriert ist

Key1 wird als kundenseitig verwalteter Schlüssel auf der Ebene des logischen Servers konfiguriert. Ein anderer kundenseitig verwalteter Schlüssel (Key2) kann auf Datenbankebene konfiguriert werden.

  • Server – Key1 als CMK festgelegt
  • Database1 – Key2 wird als CMK verwendet
  • Database2 – Key1 wird als CMK verwendet
  • Database3 – Key1 wird als CMK verwendet

Hinweis

Wenn der logische Server mit kundenseitig verwalteten Schlüsseln für TDE konfiguriert ist, kann eine einzelne Datenbank auf diesem logischen Server nicht für die Verwendung des vom Dienst verwalteten Schlüssels für transparente Datenverschlüsselung verwendet werden.

Neues unterstütztes Szenario: Logischer Server, der mit dienstseitig verwaltetem Schlüssel konfiguriert ist

Der logische Server ist mit dem dienstseitig verwalteten Schlüssel (Service-Managed Key, SMK) für TDE konfiguriert. Ein anderer kundenseitig verwalteter Schlüssel (Key2) kann auf Datenbankebene konfiguriert werden.

  • Server: Dienstseitig verwalteter Schlüssel, der als TDE-Schutz festgelegt ist
  • Database1 – Key2 als CMK festgelegt
  • Database2 – Dienstseitig verwalteter Schlüssel, der als TDE-Schutz festgelegt ist
  • Database3 – Dienstseitig verwalteter Schlüssel, der als TDE-Schutz festgelegt ist

Wiederherstellen der Verschlüsselung auf Serverebene

Database1 wird mit einem kundenseitig verwalteten Schlüssel auf Datenbankebene für TDE konfiguriert, während der logische Server mit dem dienstseitig verwalteten Schlüssel konfiguriert ist. Database1 kann so wiederhergestellt werden, dass der dienstseitig verwaltete Schlüssel auf der Ebene des logischen Servers verwendet wird.

Hinweis

Wenn der logische Server mit CMK für TDE konfiguriert ist, kann die mit CMK auf Datenbankebene konfigurierte Datenbank nicht auf Verschlüsselung auf Serverebene zurückgesetzt werden.

Obwohl der Wiederherstellungsvorgang nur unterstützt wird, wenn der logische Server bei Verwendung von TDE mit dienstseitig verwaltetem Schlüssel konfiguriert ist, kann eine mit CMK auf Datenbankebene konfigurierte Datenbank auf einem mit CMK konfigurierten Server wiederhergestellt werden, sofern der Server Zugriff auf alle von der Quelldatenbank verwendeten Schlüssel mit einer gültigen Identität besitzt.

Anforderungen an den Schlüsseltresor und die verwaltete Identität

Die gleichen Anforderungen für die Konfiguration von Azure Key Vault-Schlüsseln (AKV) und verwalteten Identitäten, einschließlich der Schlüsseleinstellungen und der für die Identität gewährten Berechtigungen, die für die CMK-Funktion (Customer Managed Key) auf Serverebene gelten, gelten auch für CMK auf Datenbankebene. Weitere Informationen finden Sie unter Transparente Datenverschlüsselung (TDE) mit CMK und verwaltete Identitäten mit CMK.

Schlüsselverwaltung

Die Rotation des TDE-Schutzes für eine Datenbank bewirkt einen Wechsel zu einem neuen asymmetrischen Schlüssel, der die Datenbanken schützt. Die Schlüsselrotation ist ein Onlinevorgang und sollte nur wenige Sekunden in Anspruch nehmen. Bei diesem Vorgang wird nur der Verschlüsselungsschlüssel der Datenbank entschlüsselt und wieder verschlüsselt, nicht die gesamte Datenbank. Nachdem einer Datenbank eine gültige benutzerseitig zugewiesene verwaltete Identität zugewiesen wurde, ist das Rotieren des Schlüssels auf Datenbankebene ein CRUD-Vorgang der Datenbank, bei dem die Verschlüsselungsschutzeigenschaft der Datenbank aktualisiert wird. Set-AzSqlDatabase und die -EncryptionProtector-Eigenschaft können verwendet werden, um Schlüssel zu rotieren. Zum Erstellen einer neuen Datenbank, die mit CMK auf Datenbankebene konfiguriert ist, kann New-AzSqlDatabase mit den Parametern -EncryptionProtector, -AssignIdentity und -UserAssignedIdentityId verwendet werden.

Neue Schlüssel können hinzugefügt und vorhandene Schlüssel mithilfe ähnlicher Anforderungen aus der Datenbank entfernt und die Schlüsseleigenschaft für die Datenbankressource geändert werden. Set-AzSqlDatabase mit den Parametern -KeyList und -KeysToRemove kann für diese Vorgänge verwendet werden. Zum Abrufen der Verschlüsselungsschutz-, Identitäts- und Schlüsseleinstellung kann Get-AzSqlDatabase verwendet werden. Die Azure Resource Manager-Ressource Microsoft.Sql/servers/databases zeigt standardmäßig nur den TDE-Schutz und die verwaltete Identität an, die für die Datenbank konfiguriert sind. Um die Liste der Schlüssel vollständig zu erweitern, sind andere Parameter wie -ExpandKeyList erforderlich. Darüber hinaus können -KeysFilter "current" und ein Zeitpunktwert (z. B. 2023-01-01) verwendet werden, um die aktuellen und in der Vergangenheit zu einem bestimmten Zeitpunkt verwendeten Schlüssel abzurufen.

Automatische Schlüsselrotation

Die automatische Schlüsselrotation ist auf Datenbankebene verfügbar und kann mit Azure Key Vault-Schlüsseln verwendet werden. Die Rotation wird ausgelöst, wenn eine neue Version des Schlüssels erkannt wird, und wird automatisch innerhalb von 24 Stunden rotiert. Informationen zum Konfigurieren der automatischen Schlüsselrotation mithilfe des Azure-Portals, der PowerShell oder der Azure-CLI finden Sie unter Automatische Schlüsselrotation auf Datenbankebene.

Berechtigung für die Schlüsselverwaltung

Je nach Berechtigungsmodell des Schlüsseltresors (Zugriffsrichtlinie oder Azure RBAC) kann der Zugriff auf den Schlüsseltresor entweder durch Erstellen einer Zugriffsrichtlinie für den Schlüsseltresor oder durch Erstellen einer neuen Azure RBAC-Rollenzuweisung gewährt werden.

Berechtigungsmodell für Zugriffsrichtlinien

Damit die Datenbank den im AKV gespeicherten TDE-Schutz für die Verschlüsselung des DEK verwenden kann, muss der Administrator des Schlüsseltresors der dem Datenbankbenutzer zugewiesenen verwalteten Identität mit ihrer eindeutigen Microsoft Entra-Identität die folgenden Zugriffsrechte erteilen:

  • get: Zum Abrufen des öffentlichen Teils und der Eigenschaften des Schlüssels in Azure Key Vault.
  • wrapKey: Zum Schützen (Verschlüsseln) des DEK.
  • unwrapKey:Zum Aufheben des Schutzes (Verschlüsselung) des DEK.

Azure RBAC-Berechtigungsmodell

Damit die Datenbank den im AKV gespeicherten TDE-Schutz für die Verschlüsselung des DEK verwenden kann, muss eine neue Azure RBAC-Rollenzuweisung mit der Rolle Key Vault Crypto Service Encryption User für die dem Datenbankbenutzer zugewiesene verwaltete Identität unter Verwendung ihrer eindeutigen Microsoft Entra-Identität hinzugefügt werden.

Mandantenübergreifende kundenseitig verwaltete Schlüsseln

Mandantenübergreifende kundenseitig verwaltete Schlüssel mit transparenter Datenverschlüsselung beschreibt das Einrichten einer Verbundclient-ID für CMK auf Serverebene. Ein ähnliches Setup muss für CMK auf Datenbankebene erfolgen, und die Verbundclient-ID muss als Teil der API-Anforderungen Set-AzSqlDatabase- oder New-AzSqlDatabase hinzugefügt werden.

Hinweis

Wenn die mehrinstanzenfähige Anwendung nicht der Zugriffsrichtlinie für den Schlüsseltresor mit den erforderlichen Berechtigungen („Abrufen“, „Schlüssel packen“, „Schlüssel entpacken“) hinzugefügt wurde, wird bei Verwendung einer Anwendung für den Identitätsverbund im Azure-Portal ein Fehler angezeigt. Stellen Sie sicher, dass die Berechtigungen ordnungsgemäß konfiguriert sind, bevor Sie die Verbundclientidentität konfigurieren.

Eine Datenbank, die mit CMK auf Datenbankebene konfiguriert ist, kann auf Verschlüsselung auf Serverebene zurückgesetzt werden, wenn der logische Server mithilfe von Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert mit einem dienstseitig verwalteten Schlüssel konfiguriert ist.

Im Falle eines nicht zugänglichen TDE-Schutzes, wie in Transparente Datenverschlüsselung (TDE) mit CMK beschrieben, kann nach Korrektur des Schlüsselzugriffs Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation verwendet werden, um auf die Datenbank zugreifen zu können.

Hinweis

Identitäts- und Schlüsselverwaltung für TDE mit kundenseitig verwalteten Schlüsseln auf Datenbankebene beschreibt die Vorgänge zur Identitäts- und Schlüsselverwaltung für CMK auf Datenbankebene ausführlich und enthält PowerShell-, Azure CLI- und REST-API-Beispiele.

Weitere Überlegungen

  • Wenn TDE mit CMK bereits auf Serverebene aktiviert ist, überschreibt das Festlegen von CMK für eine bestimmte Datenbank die CMK-Einstellung auf Serverebene (der DEK der Datenbank wird mit TDE-Schutz auf Datenbankebene erneut verschlüsselt).
  • Änderungen oder Rotationen von Schlüsseln auf der Ebene des logischen Servers wirken sich nicht auf die CMK-Einstellungen auf Datenbankebene aus, und die Datenbank verwendet weiterhin ihre eigene CMK-Einstellung.
  • CMK auf Datenbankebene wird nicht über Transact-SQL (T-SQL) unterstützt.
  • Die benutzerseitig zugewiesene verwaltete Identität (UMI) des logischen Servers kann auf Datenbankebene verwendet werden. Es wird jedoch empfohlen, eine festgelegte UMI für CMK auf Datenbankebene zu verwenden.
  • Mandantenübergreifende CMK-Einstellungen auf Serverebene wirken sich nicht auf einzelne Datenbanken aus, die mit CMK auf Datenbankebene konfiguriert sind, und sie verwenden weiterhin ihre eigene Einzelmandanten- oder mandantenübergreifende Konfiguration.
  • Auf Datenbankebene kann nur eine einzelne benutzerseitig zugewiesene verwaltete Identität festgelegt werden.

Hinweis

Die verwalteten Identitäten in der Datenbank müssen neu zugewiesen werden, wenn die Datenbank umbenannt wird.

Migration vorhandener Datenbanken zu CMK auf Datenbankebene

Neue Datenbanken können während der Erstellung mit CMK auf Datenbankebene konfiguriert werden, und vorhandene Datenbanken auf Servern, die mit dienstseitig verwalteten Schlüsseln konfiguriert sind, können mithilfe der unter Identitäts- und Schlüsselverwaltung für TDE mit kundenseitig verwalteten Schlüsseln auf Datenbankebene beschriebenen Vorgänge zu CMK auf Datenbankebene migriert werden. Zum Migrieren von Datenbanken, die mit CMK auf Serverebene oder Georeplikation konfiguriert sind, sind weitere Schritte erforderlich, die in den folgenden Abschnitten beschrieben werden.

Datenbank, die mit CMK auf Serverebene ohne Georeplikation konfiguriert ist

  1. Verwenden Sie sys.dm_db_log_info (Transact-SQL) – SQL Server für Ihre Datenbank, und suchen Sie nach aktiven virtuellen Protokolldateien (VLF-Dateien).
  2. Zeichnen Sie für alle aktiven VLF-Dateien vlf_encryptor_thumbprint aus dem sys.dm_db_log_info-Ergebnis auf.
  3. Verwenden Sie die Sicht sys.dm_database_encryption_keys (Transact-SQL) – SQL Server für Ihre Datenbank, um nach encryptor_thumbprint zu suchen. Zeichnen Sie encryptor_thumbprint auf.
  4. Verwenden Sie das Cmdlet Get-AzSqlServerKeyVaultKey, um alle Schlüssel auf Serverebene abzurufen, die auf dem logischen Server konfiguriert sind. Wählen Sie aus den Ergebnissen diejenigen aus, die denselben Fingerabdruck aufweisen, der Ihrer Liste aus dem Ergebnis oben entspricht.
  5. Führen Sie einen API-Aufruf zum Aktualisieren der Datenbank für die Datenbank aus, die Sie migrieren möchten, zusammen mit der Identität und dem Verschlüsselungsschutz. Übergeben Sie die oben genannten Schlüssel als Schlüssel auf Datenbankebene mithilfe von Set-AzSqlDatabase mit den Parametern -UserAssignedIdentityId, -AssignIdentity, -KeyList, -EncryptionProtector (und -FederatedClientId, wenn erforderlich).

Wichtig

Die Identität, die in der Anforderung zum Aktualisieren der Datenbank verwendet wird, muss Zugriff auf alle Schlüssel besitzen, die als Eingabe übergeben werden.

Datenbank, die mit CMK auf Serverebene mit Georeplikation konfiguriert ist

  1. Führen Sie die Schritte 1 bis 4 aus, die im vorherigen Abschnitt beschrieben wurden, um die Liste der Schlüssel abzurufen, die für die Migration benötigt werden.
  2. Führen Sie einen API-Aufruf zum Aktualisieren der Datenbank für die primäre und sekundäre Datenbank aus, die Sie migrieren möchten, zusammen mit der Identität und den oben genannten Schlüsseln als Schlüssel auf Datenbankebene mithilfe von Set-AzSqlDatabase und dem -KeyList-Parameter. Legen Sie den Verschlüsselungsschutz noch nicht fest.
  3. Der Schlüssel auf Datenbankebene, den Sie als primären Schutz für die Datenbanken verwenden möchten, muss der sekundären Datenbank zuerst hinzugefügt werden. Verwenden Sie Set-AzSqlDatabase mit -KeyList, um diesen Schlüssel der sekundären Datenbank hinzuzufügen.
  4. Nachdem der Verschlüsselungsschutzschlüssel der sekundären Datenbank hinzugefügt wurde, verwenden Sie Set-AzSqlDatabase, um ihn mithilfe des -EncryptionProtector-Parameters als Verschlüsselungsschutz für die primäre Datenbank festzulegen.
  5. Legen Sie den Schlüssel als Verschlüsselungsschutz für die sekundäre Datenbank fest, wie in Schritt 4 beschrieben, um die Migration abzuschließen.

Wichtig

Führen Sie die Schritte 3, 4 und 5 in diesem Abschnitt aus, um Datenbanken zu migrieren, die mit einem dienstseitig verwalteten Schlüssel auf Serverebene und Georeplikation konfiguriert sind.

Georeplikation und Hochverfügbarkeit

Sowohl in Szenarien mit aktiver Georeplikation als auch in Szenarien mit Failovergruppen können die beteiligten primären und sekundären Server entweder mit dem gleichen Schlüsseltresor (in einer beliebigen Region) oder mit separaten Schlüsseltresoren verknüpft werden. Wenn separate Schlüsseltresore mit den primären und sekundären Servern verknüpft sind, ist der Kunde dafür verantwortlich, das Schlüsselmaterial in den Schlüsseltresoren konsistent zu halten, sodass die sekundäre Geodatenbank synchron ist und bei der Übernahme der Aufgaben denselben Schlüssel aus dem verknüpften Schlüsseltresor verwenden kann, wenn die primäre Datenbank aufgrund eines Ausfalls der Region nicht mehr verfügbar ist und ein Failover ausgelöst wird. Es können bis zu vier sekundäre Datenbanken konfiguriert werden, und Verkettung (sekundäre Datenbanken von sekundären Datenbanken) wird nicht unterstützt.

Zum Einrichten von aktiver Georeplikation für eine Datenbank, die mit CMK auf Datenbankebene konfiguriert wurde, muss ein sekundäres Replikat mit einer gültigen benutzerseitig zugewiesenen verwalteten Identität und einer Liste der aktuellen Schlüssel erstellt werden, die von der primären Datenbank verwendet werden. Die Liste der aktuellen Schlüssel kann mithilfe der erforderlichen Filter und Abfrageparameter oder mithilfe von PowerShell bzw. der Azure CLI aus der primären Datenbank abgerufen werden. Zum Einrichten eines Georeplikats einer solchen Datenbank sind folgende Schritte erforderlich:

  1. Füllen Sie die Liste der von der primären Datenbank verwendeten Schlüssel mit dem Befehl Get-AzSqlDatabase und den -ExpandKeyList- und -KeysFilter "current"-Parametern vorab mit Daten auf. Schließen Sie -KeysFilter aus, wenn Sie alle Schlüssel abrufen möchten.
  2. Wählen Sie die benutzerseitig zugewiesene verwaltete Identität (und die Verbundclient-ID beim Konfigurieren von mandantenübergreifendem Zugriff) aus.
  3. Erstellen Sie eine neue Datenbank als sekundäre Datenbank mit New-AzSqlDatabaseSecondary, und geben Sie die vorab mit Daten aufgefüllte Liste von Schlüsseln, die Sie aus der Quelldatenbank abgerufen haben, sowie die oben genannte Identität (sowie die Verbundclient-ID, wenn Sie mandantenübergreifenden Zugriff konfigurieren) im API-Aufruf mit den Parametern -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (und -FederatedClientId, wenn erforderlich) an.
  4. Verwenden Sie New-AzSqlDatabaseCopy, um eine Kopie der Datenbank mit den gleichen Parametern im vorherigen Schritt zu erstellen.

Wichtig

Bei einer Datenbank, die mit CMK auf Datenbankebene konfiguriert ist, muss ein Replikat (oder eine Kopie) mit CMK auf Datenbankebene konfiguriert werden. Das Replikat kann keine Einstellungen für Verschlüsselung auf Serverebene verwenden.

Um eine mit CMK auf Datenbankebene konfigurierte Datenbank in einer Failovergruppe zu verwenden, müssen die oben genannten Schritte zum Erstellen eines sekundären Replikats mit demselben Namen wie das primäre Replikat auf dem sekundären Server verwendet werden. Sobald dieses sekundäre Replikat konfiguriert wurde, können die Datenbanken der Failovergruppe hinzugefügt werden.

Datenbanken, die mit CMK auf Datenbankebene konfiguriert sind, unterstützen keine automatisierte Erstellung sekundärer Datenbanken, wenn sie einer Failovergruppe hinzugefügt werden.

Weitere Informationen zum Einrichten von Georeplikation und Failovergruppen mithilfe von REST-APIs, PowerShell und der Azure CLI finden Sie unter Konfigurieren von Georeplikation und Sicherungswiederherstellung für transparente Datenverschlüsselung mit kundenseitig verwalteten Schlüsseln auf Datenbankebene.

Hinweis

Alle bewährten Methoden zur Georeplikation und Hochverfügbarkeit, die unter Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) mit CMK für CMK auf Serverebene beschrieben werden, gelten für CMK auf Datenbankebene.

Sichern und Wiederherstellen von Datenbanken mithilfe von TDE mit kundenseitig verwaltetem Schlüssel auf Datenbankebene

Nachdem eine Datenbank mithilfe eines Schlüssels aus Azure Key Vault mit TDE verschlüsselt wurde, werden alle neu generierten Sicherungen ebenfalls mit dem gleichen TDE-Schutz verschlüsselt. Wenn der TDE-Schutz geändert wird, werden alte Sicherungen der Datenbank für die Verwendung des aktuellen TDE-Schutzes nicht aktualisiert. Um eine Sicherung wiederherzustellen, die mit auf Datenbankebene konfigurierten TDE-Schutz von Azure Key Vault verschlüsselt wurde, stellen Sie sicher, dass das Schlüsselmaterial für die Zieldatenbank bereitgestellt wird. Es wird empfohlen, alle alten Versionen des TDE-Schutzes in einem Schlüsseltresor beizubehalten, damit Datenbanksicherungen wiederhergestellt werden können.

Wichtig

Für eine Datenbank kann nur ein TDE-Schutz festgelegt werden. Es können jedoch mehrere zusätzliche Schlüssel während der Wiederherstellung an eine Datenbank übergeben werden, ohne dass diese als TDE-Schutz gekennzeichnet werden. Diese Schlüssel werden nicht zum Schutz des DEK verwendet. Sie können aber während der Wiederherstellung aus einer Sicherung verwendet werden, wenn die Sicherungsdatei mit dem Schlüssel mit dem entsprechenden Fingerabdruck verschlüsselt ist.

Point-in-Time-Wiederherstellung

Die folgenden Schritte sind für eine Zeitpunktwiederherstellung einer Datenbank erforderlich, die mit kundenseitig verwalteten Schlüsseln auf Datenbankebene konfiguriert ist:

  1. Füllen Sie die Liste der von der primären Datenbank verwendeten Schlüssel mit dem Befehl Get-AzSqlDatabase und den -ExpandKeyList- und -KeysFilter "2023-01-01"-Parametern vorab mit Daten auf. 2023-01-01 ist ein Beispiel für den Zeitpunkt, zu dem Sie die Datenbank wiederherstellen möchten. Schließen Sie -KeysFilter aus, wenn Sie alle Schlüssel abrufen möchten.
  2. Wählen Sie die benutzerseitig zugewiesene verwaltete Identität (und die Verbundclient-ID beim Konfigurieren von mandantenübergreifendem Zugriff) aus.
  3. Verwenden Sie Restore-AzSqlDatabase mit dem Parameter -FromPointInTimeBackup, und geben Sie im API-Aufruf mit den Parametern -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (und ggf. -FederatedClientId) die vorab mit Daten aufgefüllte Liste der Schlüssel an, die Sie in den oben genannten Schritten abgerufen haben, sowie die oben genannte Identität (und die Verbundclient-ID, wenn Sie mandantenübergreifenden Zugriff konfigurieren).

Hinweis

Wenn Sie eine Datenbank ohne die -EncryptionProtector-Eigenschaft mit allen gültigen Schlüsseln wiederherstellen, wird sie auf Verwendung von Verschlüsselung auf Serverebene zurückgesetzt. Dies kann nützlich sein, um eine kundenseitig verwaltete Schlüsselkonfiguration auf Datenbankebene auf eine Konfiguration mit kundenseitig verwalteten Schlüsseln auf Serverebene zurückzusetzen.

Wiederherstellen einer gelöschten Datenbank

Die folgenden Schritte sind für die Wiederherstellung einer gelöschten Datenbank erforderlich, die mit kundenseitig verwalteten Schlüsseln auf Datenbankebene konfiguriert ist:

  1. Füllen Sie die Liste der von der primären Datenbank verwendeten Schlüssel mit Get-AzSqlDeletedDatabaseBackup und dem -ExpandKeyList-Parameter vorab mit Daten auf. Es wird empfohlen, alle Schlüssel zu übergeben, die die Quelldatenbank verwendet hat, aber alternativ kann die Wiederherstellung auch mit den Schlüsseln versucht werden, die vom Löschzeitpunkt als -KeysFilter bereitgestellt werden.
  2. Wählen Sie die benutzerseitig zugewiesene verwaltete Identität (und die Verbundclient-ID beim Konfigurieren von mandantenübergreifendem Zugriff) aus.
  3. Verwenden Sie Restore-AzSqlDatabase mit dem Parameter -FromDeletedDatabaseBackup, und geben Sie im API-Aufruf mit den Parametern -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (und ggf. -FederatedClientId) die vorab mit Daten aufgefüllte Liste der Schlüssel an, die Sie in den oben genannten Schritten abgerufen haben, sowie die oben genannte Identität (und die Verbundclient-ID, wenn Sie mandantenübergreifenden Zugriff konfigurieren).

Geowiederherstellung

Die folgenden Schritte sind für eine Geowiederherstellung einer Datenbank erforderlich, die mit kundenseitig verwalteten Schlüsseln auf Datenbankebene konfiguriert ist:

  • Füllen Sie die Liste der Schlüssel, die von der primären Datenbank verwendet werden, mit Get-AzSqlDatabaseGeoBackup und -ExpandKeyList zum Abrufen aller Schlüssel vorab mit Daten auf.
  • Wählen Sie die benutzerseitig zugewiesene verwaltete Identität (und die Verbundclient-ID beim Konfigurieren von mandantenübergreifendem Zugriff) aus.
  • Verwenden Sie Restore-AzSqlDatabase mit dem Parameter -FromGeoBackup, und geben Sie im API-Aufruf mit den Parametern -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (und ggf. -FederatedClientId) die vorab mit Daten aufgefüllte Liste der Schlüssel an, die Sie in den oben genannten Schritten abgerufen haben, sowie die oben genannte Identität (und die Verbundclient-ID, wenn Sie mandantenübergreifenden Zugriff konfigurieren).

Wichtig

Es wird empfohlen, alle von der Datenbank verwendeten Schlüssel zum Wiederherstellen der Datenbank beizubehalten. Außerdem wird empfohlen, alle diese Schlüssel an das Wiederherstellungsziel zu übergeben.

Hinweis

Sicherungen zur Sicherungslangzeitaufbewahrung (Long Term Backup Retention, LTR) enthalten nicht die Liste der Schlüssel, die von der Sicherung verwendet werden. Zum Wiederherstellen einer LTR-Sicherung müssen alle Schlüssel, die von der Quelldatenbank verwendet wurden, an das LTR-Wiederherstellungsziel übergeben werden.

Weitere Informationen zur Sicherungswiederherstellung für SQL-Datenbank-Instanzen mit CMK auf Datenbankebene mit Beispielen unter Verwendung von PowerShell, der Azure CLI und REST-APIs finden Sie unter Konfigurieren von Georeplikation und Sicherungswiederherstellung für transparente Datenverschlüsselung mit kundenseitig verwalteten Schlüsseln auf Datenbankebene.

Einschränkungen

Das Feature „kundenseitig verwaltete Schlüssel auf Datenbankebene“ unterstützt keine Schlüsselrotationen, wenn die virtuellen Protokolldateien der Datenbank mit einem alten Schlüssel verschlüsselt sind, der sich vom aktuellen primären Schutz der Datenbank unterscheidet. Der in diesem Fall ausgelöste Fehler lautet:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: Schlüsselrotation für den TDE-Schutz auf Datenbankebene wird blockiert, wenn aktive Transaktionen das mit alten Schlüsseln verschlüsselte Protokoll anhalten.

Um dieses Szenario besser zu verstehen, sehen wir uns die folgenden Zeitachse an:

Beispielzeitachse für Schlüsselrotationen für eine Datenbank, die mit kundenseitig verwalteten Schlüsseln auf Datenbankebene konfiguriert ist.

  • Zeit t0 = Eine Datenbank wird ohne Verschlüsselung erstellt.
  • Zeit t1 = Diese Datenbank wird durch Thumbprint A geschützt, wobei es sich um einen vom kundenseitig verwalteten Schlüssel auf Datenbankebene handelt.
  • Zeit t2 = Der Datenbankschutz wird auf einen neuen kundenseitig verwalteten Schlüssel auf Datenbankebene (Thumbprint B) rotiert.
  • Zeit t3 = Eine Schutzänderung für Thumbprint C wird angefordert.
  • Wenn die aktiven VLF-Dateien Thumbprint A verwenden, ist die Rotation nicht zulässig.
  • Wenn die aktiven VLF-Dateien Thumbprint A nicht verwenden, ist die Rotation zulässig.

Sie können die Sicht sys.dm_db_log_info (Transact-SQL) – SQL Server für Ihre Datenbank verwenden und nach aktiven virtuellen Protokolldateien (VLF-Dateien) suchen. Es sollte eine aktive VLF-Datei angezeigt werden, die mit dem ersten Schlüssel verschlüsselt wurde (z. B. Thumbprint A). Sobald durch das Einfügen von Daten genügend Protokoll generiert wurde, wird diese alte VLF-Datei geleert, und Sie sollten in der Lage sein, eine weitere Schlüsselrotation durchzuführen.

Wenn Sie der Meinung sind, dass ihr Protokoll länger als erwartet angehalten wird, finden Sie weitere Informationen zur Problembehandlung in der folgenden Dokumentation:

Nächste Schritte

Lesen Sie die folgende Dokumentation zu verschiedenen CMK-Vorgängen auf Datenbankebene: