Azure SQL Transparent Data Encryption mithilfe eines kundenseitig verwalteten Schlüssels

Gilt für:Azure SQL-DatenbankAzure SQL Managed InstanceAzure Synapse Analytics (nur dedizierte SQL-Pools)

Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) in Azure SQL mit kundenseitig verwalteten Schlüsseln (CMK) ermöglicht BYOK-Szenarien (Bring Your Own Key) für den Schutz von Daten im Ruhezustand und gibt Organisationen die Möglichkeit, Verwaltungsaufgaben von den Schlüsseln und Daten zu trennen. Bei vom Kunden verwalteter TDE ist der Kunde vollständig für die Kontrolle und Verwaltung des Lebenszyklus von Schlüsseln (Erstellung, Hochladen, Rotation, Löschung), der Berechtigungen zur Schlüsselnutzung sowie das Audit von Vorgängen an Schlüsseln verantwortlich.

In diesem Szenario ist der Transparent Data Encryption (TDE)-Schutz ein vom Kunden verwalteter Schlüssel, der den Datenbank-Verschlüsselungsschlüssel (DEK) sichert. Man speichert den TDE-Schutz entweder im Azure Key Vault oder im Azure Key Vault Managed HSM, die sichere cloudbasierte Schlüsselverwaltungsdienste sind, die auf hohe Verfügbarkeit und Skalierbarkeit ausgelegt sind. Beide Dienste unterstützen kryptografische Schlüssel, die durch FIPS 140-2-validierte Hardware geschützt sind: Azure Key Vault unterstützt FIPS 140-2 Level 2, und Azure Key Vault Managed HSM unterstützt FIPS 140-2 Level 3. Beide Dienste unterstützen außerdem asymmetrische und symmetrische Schlüsseltypen, und die unterstützten Algorithmen sowie die Nutzung hängen vom TDE-Bereitstellungsmodell ab. Sie können den Schlüssel im Dienst generieren, importieren oder sicher von lokalen HSMs übertragen. Der direkte Zugriff auf Schlüssel ist eingeschränkt, sodass autorisierte Dienste kryptografische Operationen durchführen, ohne das Schlüsselmaterial offenzulegen.

Bei Azure SQL-Datenbank und Azure Synapse Analytics wird der TDE-Schutz auf der Serverebene festgelegt und von allen verschlüsselten Datenbanken geerbt, die diesem Server zugeordnet sind. Bei der verwalteten Azure SQL-Instanz wird der TDE-Verschlüsselungsschutz auf der Instanzebene festgelegt und von allen verschlüsselten Datenbanken auf dieser Instanz geerbt. Der Begriff "Server" bezieht sich sowohl auf einen Server in der SQL-Datenbank und Azure Synapse als auch auf eine verwaltete Instanz in SQL Managed Instance in diesem Artikel, es sei denn, es wird anders angegeben.

Die Verwaltung der TDE-Schutzvorrichtung auf Datenbankebene in Azure SQL-Datenbank ist verfügbar. Weitere Informationen finden Sie unter Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) mit kundenseitig verwalteten Schlüsseln auf Datenbankebene.

Hinweis

Dieser Artikel gilt für Azure SQL-Datenbank, Azure SQL Managed Instance und Azure Synapse Analytics (dedizierte SQL-Pools (vormals SQL DW)). Weitere Informationen zur transparenten Datenverschlüsselung für dedizierte SQL-Pools in Synapse-Arbeitsbereichen finden Sie unter Azure Synapse Analytics-Verschlüsselung.

Hinweis

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

Vom Kunden verwalteter Schlüssel (CMK) und Bring Your Own Key (BYOK)

In diesem Artikel werden die Begriffe Customer Managed Key (CMK) und Bring Your Own Key (BYOK) austauschbar verwendet, stellen jedoch einige Unterschiede dar.

  • vom Kunden verwalteter Schlüssel (Customer Managed Key, CMK) – Der Kunde verwaltet den Schlüssellebenszyklus, einschließlich Schlüsselerstellung, Drehung und Löschung. Der Schlüssel wird in Azure Key Vault oder azure Managed HSM gespeichert und für die Verschlüsselung des Datenbankverschlüsselungsschlüssels (DEK) in Azure SQL, SQL Server auf Azure VM und sql Server lokal verwendet.

  • Bring Your Own Key (BYOK) – Der Kunde bringt oder importiert sicher seinen eigenen Schlüssel aus einem lokalen Hardwaresicherheitsmodul (HSM) in Azure Key Vault oder azure Managed HSM. Solche importierten Schlüssel können als anderer Schlüssel im Azure Key Vault verwendet werden, einschließlich als vom Kunden verwalteter Schlüssel für die Verschlüsselung der DEK. Weitere Informationen finden Sie unter Import von durch HSM geschützte Schlüssel in ein Managed HSM (BYOK).

Vorteile der kundenseitig verwalteten TDE

Eine kundenseitig verwaltete TDE bietet Kunden die folgenden Vorteile:

  • Vollständige und präzise Kontrolle über die Verwendung und Verwaltung der TDE-Schutzkomponente.

  • Transparenz der TDE-Schutzverwendung.

  • Möglichkeit, die Trennung von Aufgaben in der Verwaltung von Schlüsseln und Daten innerhalb der Organisation zu implementieren.

  • Der Azure Key Vault-Administrator kann Schlüsselzugriffsberechtigungen widerrufen, um auf verschlüsselte Datenbanken nicht zugreifen zu können.

  • Zentrale Verwaltung von Schlüsseln in Azure Key Vault.

  • Größeres Vertrauen ihrer Endbenutzer, da Azure Key Vault so konzipiert ist, dass Microsoft keine Verschlüsselungsschlüssel sehen oder extrahieren kann.

Wichtig

Für Diejenigen, die dienstverwaltete TDE verwenden möchten, die mit der Verwendung von vom Kunden verwalteten TDE beginnen möchten, bleiben Die Daten während des Wechsels verschlüsselt, und es gibt keine Ausfallzeiten oder eine erneute Verschlüsselung der Datenbankdateien. Der Wechsel von einem dienstseitig verwalteten Schlüssel zu einem kundenseitig verwalteten Schlüssel erfordert lediglich eine erneute Verschlüsselung des Datenbankverschlüsselungsschlüssels (DEK), die schnell und online durchzuführen ist.

Berechtigungen zum Konfigurieren von kundengesteuerten TDE

Diagramm, dass die Einrichtung und Funktionsweise der kundenseitig verwalteten TDE zeigt.

Wählen Sie den Typ von Azure Key Vault aus, den Sie verwenden möchten.

Damit der logische Server in Azure den in Azure Key Vault gespeicherten TDE-Schutz zur Verschlüsselung des DEK nutzen kann, muss der Key Vault Administrator dem Server mit seiner einzigartigen Microsoft Entra-Identität Zugriffsrechte gewähren. Die Serveridentität kann eine systemseitig zugewiesene verwaltete Identität oder eine benutzerseitig zugewiesene verwaltete Identität sein, die dem Server zugewiesen ist. Es gibt zwei Zugriffsmodelle, um dem Server Zugriff auf den Schlüsseltresor zu gewähren:

  • Rollenbasierte Zugriffssteuerung von Azure (RBAC) – Verwenden Sie Azure RBAC, um einem Benutzer, einer Gruppe oder einer Anwendung Zugriff auf den Schlüsseltresor zu gewähren. Diese Methode wird wegen ihrer Flexibilität und Granularität empfohlen. Die Serveridentität benötigt die Rolle Key Vault Crypto Service Encryption-Benutzer*in, damit sie den Schlüssel für Verschlüsselungs- und Entschlüsselungsvorgänge verwenden kann.

  • Tresorzugriffsrichtlinie – Verwenden Sie die Zugriffsrichtlinie für den Schlüsseltresor, um dem Server Zugriff auf den Schlüsseltresor zu gewähren. Diese Methode ist einfacher und unkomplizierter, aber weniger flexibel. Die Serveridentität muss über die folgenden Berechtigungen für das Key Vault verfügen:

    • abrufen – zum Abrufen des öffentlichen Teils und der Eigenschaften des Schlüssels im Azure Key Vault
    • wrapKey – um den DEK schützen (verschlüsseln) zu können
    • unwrapKey: zum Aufheben des Schutzes (der Verschlüsselung) des DEK

Im Zugriffskonfiguration Azure-Portal Menü des Schlüsseltresors haben Sie die Möglichkeit, die Azure-rollenbasierte Zugriffssteuerung oder Tresor-Zugriffsrichtlinie auszuwählen. Schrittweise Anleitungen zum Einrichten einer Azure Key Vault-Zugriffskonfiguration für TDE finden Sie unter Einrichten von SQL Server TDE Extensible Key Management mithilfe von Azure Key Vault. Weitere Informationen zu den Zugriffsmodellen finden Sie unter Azure Key Vault – Sicherheit.

Ein Key Vault-Administrator kann auch die Protokollierung von Key Vault-Überwachungsereignissen aktivieren, damit sie später überprüft werden können.

Wenn ein Server für die Verwendung einer TDE-Schutzkomponente aus Azure Key Vault konfiguriert ist, sendet der Server die DEK jeder TDE-fähigen Datenbank an den Schlüsseltresor für die Verschlüsselung. Key Vault gibt den verschlüsselten DEK zurück, der in der Benutzerdatenbank gespeichert wird.

Falls erforderlich, sendet der Server den geschützten DEK zur Entschlüsselung an die Schlüsselverwaltung.

Prüfer können Azure Monitor verwenden, um die AuditEvent-Protokolle von Key Vault zu überprüfen, sofern die Protokollierung aktiviert wurde.

Hinweis

Es kann ca. 10 Minuten dauern, bis alle Berechtigungsänderungen für den Key Vault wirksam werden. Dies umfasst das Aufheben der Zugriffsberechtigungen für die TDE-Schutzvorrichtung in AKV, und innerhalb dieses Zeitraums können Benutzer weiterhin über Zugriffsberechtigungen verfügen.

Anforderungen zum Konfigurieren von vom Kunden verwalteten TDE

  • Soft-Delete und Löschschutz müssen im Azure Key Vault aktiviert sein. Dadurch kann verhindert werden, dass ein Schlüsseltresor oder ein Schlüssel versehentlich oder böswillig gelöscht wird, was zum Wechsel der Datenbank in den Zustand Kein Zugriff führen kann. Beim Konfigurieren der TDE-Schutzvorrichtung auf einem vorhandenen Server oder während der Servererstellung überprüft Azure SQL, ob das vorläufige Löschen und der Löschschutz für den verwendeten Schlüsseltresor aktiviert sind. Wenn das vorläufige Löschen und der Löschschutz für den Schlüsseltresor nicht aktiviert sind, tritt beim Setup der TDE-Schutzvorrichtung ein Fehler auf. In diesem Fall müssen zuerst das vorläufige Löschen und der Löschschutz für den Schlüsseltresor aktiviert werden, und anschließend sollte das Setup der TDE-Schutzvorrichtung ausgeführt werden.

  • Wenn Sie eine Firewall mit Azure Key Vault verwenden, müssen Sie die Option Aktivieren, dass vertrauenswürdige Microsoft-Dienste die Firewall umgehen können, es sei denn, Sie verwenden private Endpunkte für den Azure Key Vault. Weitere Informationen finden Sie unter Konfigurieren von Azure Key Vault-Firewalls und virtuellen Netzwerken.

Wichtige Anforderungen für die Konfiguration der TDE-Schutzkomponente

Transparent Data Encryption mit kundenverwalteten Schlüsseln verwendet einen externen Schlüssel, der als TDE-Schutz bezeichnet wird und in Azure Key Vault oder Azure Managed HSM gespeichert wird, um den Datenbankverschlüsselungsschlüssel (DEK) zu schützen.

Die folgenden Anforderungen gelten.

Unterstützte Schlüsseltypen und Größen

Je nach Azure SQL- und TDE-Konfiguration kann die TDE-Schutzkomponente entweder durch asymmetrische oder symmetrische Schlüssel gesichert werden, die in Azure Key Vault oder Azure Key Vault verwalteten HSM gespeichert sind.

  • Asymmetrische Schlüssel (RSA oder RSA HSM)

    • Unterstützt in Azure Key Vault und Azure Key Vault verwaltetem HSM
    • Unterstützte Schlüsselgrößen: 2.048-Bit und 3.072-Bit
    • Unterstützt für Azure SQL-Datenbank, Azure SQL Managed Instance und Azure Synapse Analytics

  • Symmetrische Schlüssel (AES)

    • Unterstützt in Azure Key Vault Premium (Preview) und Azure Key Vault Managed HSM
    • Unterstützte Tastengrößen: 128-Bit, 192-Bit und 256-Bit
    • Unterstützt nur für Azure SQL-Datenbank, derzeit in der öffentlichen Vorschau

Hinweis

Transparent Data Encryption mit symmetrischen Schlüsseln (AES) befindet sich derzeit in der Vorschau. Vorschaufunktionen werden mit begrenzten Funktionen veröffentlicht, aber Microsoft stellt sie auf Vorschaubasis zur Verfügung, damit Kunden frühzeitig Zugang erhalten und Feedback geben können. Vorschaufeatures unterliegen separaten ergänzenden Vorschaubedingungen und unterliegen nicht SLAs. Sie erhalten in bestimmten Fällen den bestmöglichen Support. Der Microsoft-Support ist jedoch an Ihrem Feedback zu den Vorschaufunktionen interessiert und bietet möglicherweise in bestimmten Fällen bestmöglichen Support. Vorschaufunktionen sind gegebenenfalls begrenzt oder funktionell eingeschränkt und eventuell nur in ausgewählten geografischen Regionen verfügbar.

Schlüsselverwaltungsverhalten für symmetrische (AES) Schlüssel

Sie können symmetrische (AES) Schlüssel verwenden, die in Azure Key Vault Premium (Vorschau) oder Azure Key Vault Managed HSM gespeichert sind, als TDE-Schutz. Um mit einem Schlüssel aus einem lokalen Hardware-Sicherheitsmodul (HSM) zu beginnen, importieren Sie den Schlüssel in einen der beiden Dienste. Nach dem ersten Import finden alle laufenden Schlüssellebenszyklusoperationen in Azure Key Vault Premium (Vorschau) oder Azure Key Vault Managed HSM statt. Point-in-Time-Wiederherstellung, geografische Notfallwiederherstellung und erneute Schlüsselvalidierung hängen alle davon ab, dass der Schlüssel dort weiterhin verfügbar bleibt. Führen Sie lokale Backups importierter Schlüssel zur Unterstützung von Wiederherstellungs- und Revalidierungsszenarien. Dieses Verhalten gilt nur für symmetrische (AES) Schlüssel, nicht für asymmetrische (RSA) Schlüssel.

Schlüsselstatus- und Gültigkeitsanforderungen

  • Wenn ein Schlüsselaktivierungsdatum angegeben ist, muss es auf ein Datum und eine Uhrzeit in der Vergangenheit festgelegt werden.
  • Wenn ein Schlüsselablaufdatum angegeben ist, muss es in der Zukunft auf ein Datum und eine Uhrzeit festgelegt werden.
  • Der Schlüssel muss sich im Zustand Aktiviert befinden.

Wichtige Importanforderungen

Wenn Sie einen bestehenden Schlüssel in Azure Key Vault importieren, stellen Sie den Schlüssel in einem der folgenden unterstützten Formate bereit:

  • .pfx
  • .byok
  • .backup

Informationen zum Importieren von HSM-geschützten Schlüsseln in Azure Managed HSM finden Sie unter Importieren von HSM-geschützten Schlüsseln in Verwaltetes HSM (BYOK).To import HSM-protected keys into Azure Managed HSM, see Import HSM-protected keys to Managed HSM (BYOK).

Hinweis

Ein Problem mit Thales CipherTrust Manager-Versionen vor v2.8.0 verhindert, dass neu importierte Schlüssel in Azure Key Vault mit Azure SQL-Datenbank oder azure SQL Managed Instance für kundenverwaltete TDE-Szenarien verwendet werden. Weitere Informationen zu diesem Problem finden Sie in den Versionshinweisen zu CipherTrust Cloud Key Manager. Warten Sie für solche Fälle 24 Stunden nach dem Importieren des Schlüssels in Azure Key Vault, um sie als TDE-Schutzkomponente für den Server oder die verwaltete Instanz zu verwenden. Dieses Problem wurde in Thales CipherTrust Manager v2.8.0 behoben.

Empfehlungen zum Konfigurieren von vom Kunden verwalteten TDE

  • Um optimale Leistung und Zuverlässigkeit zu gewährleisten, verwenden Sie ein dediziertes Azure Key Vault für Azure SQL. Teilen Sie diesen Schlüsseltresor nicht mit anderen Diensten. Wenn der Schlüsseltresor aufgrund gemeinsamer Nutzung oder übermäßiger Schlüsseloperationen stark belastet ist, kann dies die Datenbankleistung negativ beeinflussen, insbesondere während des Schlüsselzugriffs auf die Verschlüsselung. Azure Key Vault erzwingt Drosselungsgrenzen. Wenn diese Grenzwerte überschritten werden, können Vorgänge verzögert oder fehlschlagen. Dieses Risiko ist am höchsten bei Server-Failovers, die Schlüsseloperationen für jede Datenbank auf dem Server auslösen.

    Weitere Informationen zum Drosselungsverhalten finden Sie im Azure Key Vault Drosselungsleitfaden.

    Um Hochverfügbarkeit zu gewährleisten und Drosselungsprobleme zu vermeiden, befolgen Sie diese Richtlinien pro Abonnement:

    • Verwenden Sie einen dedizierten Azure Key Vault für Azure SQL-Ressourcen.

    • Ordnen Sie nicht mehr als 500 Allgemeine Datenbanken einem einzelnen Azure Key Vault zu.

    • Ordnen Sie nicht mehr als 200 Business Critical-Datenbanken einem einzigen Azure Key Vault zu.

    • Die Anzahl der Hyperscale-Datenbanken, die einem einzelnen Azure Key Vault zugeordnet werden können, wird durch die Anzahl der Seitenserver bestimmt. Jeder Seitenserver ist mit einer logischen Datendatei verknüpft. Führen Sie die folgende Abfrage aus, um die Anzahl der Seitenserver zu finden.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Verknüpfen Sie nicht mehr als 500 Page-Server mit einem einzelnen Azure Key Vault. Wenn die Datenbank wächst, nimmt die Anzahl der Seitenserver automatisch zu, daher ist es wichtig, die Datenbankgröße regelmäßig zu überwachen. Wenn die Anzahl der Seitenserver 500 übersteigt, verwenden Sie für jede Hyperscale-Datenbank einen eigenen Azure Key Vault und teilen Sie diesen Key Vault nicht mit anderen Azure SQL-Ressourcen.

    • Überwachen und Konfigurieren von Azure Key Vault-Warnungen. Weitere Informationen zur Überwachung und Warnung finden Sie unter Überwachen von Azure Key Vault und Konfigurieren von Azure Key Vault-Warnungen.

  • Um mit der langfristigen Planung der kryptographischen Resilienz in Einklang zu kommen, sollten Sie AES-256 symmetrische Schlüssel als TDE-Schutz verwenden.

    Großflächige Quantencomputing wird voraussichtlich öffentlich-schlüssel-kryptographische Algorithmen wie RSA zerstören. Symmetrische Kryptographie, einschließlich AES, gilt bei ausreichend großen Schlüsselgrößen als quantenresistent.

    Microsofts umfassendere, quantensichere Sicherheitsstrategie legt den Schwerpunkt auf Krypto-Agilität. Führen Sie stärkere symmetrische Algorithmen an, wo sie unterstützt werden, und planen Sie für zukünftige kryptographische Übergänge, sobald sich Richtlinien und Standards weiterentwickeln.

    Wichtig

    Transparent Data Encryption mit symmetrischen Schlüsseln (AES) wird derzeit nur für Azure SQL-Datenbank unterstützt und befindet sich in der öffentlichen Vorschau.

  • Legen Sie eine Ressourcensperre für den Schlüsseltresor fest, um zu steuern, wer diese wichtige Ressource löschen kann, und um ein versehentliches oder nicht autorisiertes Löschen zu verhindern. Erfahren Sie mehr über Ressourcensperren.

  • Aktivieren Sie die Überwachung und Berichterstellung für alle Verschlüsselungsschlüssel: Azure Key Vault stellt Protokolle bereit, die einfach in andere Sicherheitsinformationen und Ereignisverwaltungstools eingefügt werden können. Log Analytics in Operations Management Suite ist ein Beispiel für einen Dienst, der bereits integriert ist.

  • Verwenden Sie einen Key Vault aus einer Azure-Region, die ihre Inhalte in eine gekoppelte Region replizieren kann, um maximale Verfügbarkeit zu gewährleisten. Weitere Informationen finden Sie unter Bewährte Methoden für die Verwendung von Azure Key Vault und Verfügbarkeit und Redundanz von Azure Key Vault.

Hinweis

Um eine größere Flexibilität beim Konfigurieren von vom Kunden verwalteten TDE zu ermöglichen, können Azure SQL-Datenbank und azure SQL Managed Instance in einer Region jetzt mit Azure Key Vault in jeder anderen Region verknüpft werden. Der Server und der Schlüsseltresor müssen sich nicht in derselben Region befinden.

Empfehlungen zum Konfigurieren der TDE-Schutzkomponente

  • Bewahren Sie eine Kopie der TDE-Schutzvorrichtung an einem sicheren Ort auf oder hinterlegen Sie sie bei einem Treuhanddienst.

  • Wenn der Schlüssel im Schlüsseltresor generiert wird, erstellen Sie eine Schlüsselsicherung, bevor Sie den Schlüssel zum ersten Mal in Azure Key Vault verwenden. Die Sicherung kann nur in einer Azure Key Vault-Instanz wiederhergestellt werden. Unter Backup-AzKeyVaultKey erfahren Sie mehr zu diesem Befehl. Azure Managed HSM unterstützt das Erstellen einer vollständigen Sicherung des gesamten Inhalts des HSM, einschließlich aller Schlüssel, Versionen, Attribute, Tags und Rollenzuweisungen. Weitere Informationen finden Sie unter Vollständige Sicherung und Wiederherstellung und Selektive Schlüsselwiederherstellung.

  • Erstellen Sie immer dann eine neue Sicherung, wenn Änderungen am Schlüssel (z. B. Schlüsselattribute, Tags, ACLs) vorgenommen werden.

  • Bewahre frühere Versionen des Schlüssels im Key Vault oder im verwalteten HSM auf, wenn du die Schlüssel rotierst, damit du ältere Datenbank-Backups wiederherstellen kannst. Wenn der TDE-Schutz für eine Datenbank geändert wird, werden alte Backups der Datenbank nicht aktualisiert , um den neuesten TDE-Schutz zu verwenden. Bei der Wiederherstellung ist für jede Sicherung die TDE-Schutzvorrichtung erforderlich, mit der sie zum Erstellungszeitpunkt verschlüsselt wurde. Um Schlüssel zu drehen, folgen Sie den Anweisungen im Artikel Rotate the Transparent Data Encryption (TDE) Protector.

  • Behalten Sie alle zuvor verwendeten Schlüssel in Azure Key Vault oder azure Managed HSM bei, auch nachdem Sie zu dienstverwalteten Schlüsseln gewechselt haben. Es stellt sicher, dass Datenbanksicherungen mit den TDE-Schutzkomponenten wiederhergestellt werden können, die in Azure Key Vault oder azure Managed HSM gespeichert sind. TDE-Schutzkomponenten, die mit Azure Key Vault oder azure Managed HSM erstellt wurden, müssen verwaltet werden, bis alle verbleibenden gespeicherten Sicherungen mit dienstverwalteten Schlüsseln erstellt wurden. Erstellen Sie mithilfe von Backup-AzKeyVaultKey wiederherstellbare Sicherungskopien dieser Schlüssel.

  • Wenn Sie einen potenziell kompromittierten Schlüssel während eines Sicherheitsvorfalls ohne Datenverlust entfernen möchten, führen Sie die Schritte im Artikel Entfernen einer transparenten Datenverschlüsselungskomponente (Transparent Data Encryption, TDE) mithilfe von PowerShell aus. Führen Sie stets eine Rotation zu einem neuen TDE-Schutzelement durch und verifizieren Sie, dass alle Datenbanken den neuen Schlüssel verwenden, bevor Sie den kompromittierten Schlüssel löschen oder deaktivieren. Das Löschen oder Deaktivieren des Schlüssels ohne vorherige Rotation führt dazu, dass alle verschlüsselten Datenbanken unzugänglich werden, und macht zuvor gesicherte und in einem anderen Tresor wiederhergestellte Schlüsselkopien nicht ungültig.

Tipp

Verwendung von versionierten und versionslosen Azure Key Vault-Schlüsseln für TDE

Wenn Sie die TDE-Schutzkomponente festlegen, können Sie auf einen Azure Key Vault-Schlüssel verweisen, indem Sie entweder eine bestimmte Schlüsselversion oder einen versionslosen Schlüsselbezeichner verwenden.

In beiden Fällen bestimmt und verwendet die Azure SQL-Datenbank immer die neueste aktivierte Schlüsselversion in Azure Key Vault oder Azure Key Vault Managed HSM. Verwenden Sie versionslose Schlüsselbezeichner, um das Einbetten einer bestimmten Schlüsselversion in die TDE-Schutzkonfiguration zu vermeiden.

Versionslose Schlüsselbezeichner werden derzeit nur für Azure SQL-Datenbank unterstützt.

Beispiele:

  • Schlüsselkennung, die eine bestimmte Version enthält

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • Versionslose Schlüssel-ID

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

Rotation der TDE-Schutzvorrichtung

Wenn Sie die TDE-Schutzkomponente drehen, können Sie den Schlüssel ersetzen, der zum Schutz des Datenbankverschlüsselungsschlüssels (DEK) verwendet wird. 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.

Sie können die TDE-Schutzkomponente drehen, indem Sie die Konfiguration wechseln, um einen neuen Schlüssel zu verwenden, der in Azure Key Vault oder Azure Key Vault verwalteten HSM gespeichert ist. Je nach Azure SQL Angebot und unterstützter Konfiguration kann dies Folgendes umfassen:

  • Wechseln zu einer neuen Schlüsselversion desselben Schlüssels
  • Wechseln zu einem anderen Schlüssel
  • Wechseln zwischen unterstützten Schlüsseltypen, z. B. asymmetrischen (RSA) und symmetrischen Schlüsseln (AES)

Hinweis

Transparent Data Encryption mit symmetrischen Schlüsseln (AES) wird derzeit nur für Azure SQL-Datenbank unterstützt und befindet sich in der öffentlichen Vorschau.

Die Rotation der TDE-Schutzvorrichtung kann entweder manuell oder unter Verwendung des Features zur automatisierten Rotation erfolgen.

Die automatische Rotation der TDE-Schutzvorrichtung kann beim Konfigurieren der TDE-Schutzvorrichtung für den Server aktiviert werden. Die automatisierte Rotation ist standardmäßig deaktiviert. Wenn diese Option aktiviert ist, überprüft der Server kontinuierlich den Schlüsseltresor oder das verwaltete Hardware-Sicherheitsmodul (HSM) auf neue Versionen des Schlüssels, der als TDE-Schutz verwendet wird. Wenn eine neue Version des Schlüssels erkannt wird, wird die TDE-Schutzkomponente auf dem Server oder der Datenbank innerhalb von 24 Stunden automatisch in die neueste Schlüsselversion gedreht.

Bei Verwendung mit automatisierter Schlüsselrotation in Azure Key Vault oder Autorotation in Azure Managed HSM ermöglicht dieses Feature die End-to-End-Zero-Touch-Drehung für die TDE-Schutzkomponente in Azure SQL-Datenbank und azure SQL Managed Instance.

Hinweis

Das Festlegen von TDE mit CMK mit manueller oder automatisierter Drehung von Schlüsseln verwendet immer die neueste Version des unterstützten Schlüssels. Das Setup lässt die Verwendung einer vorherigen oder niedrigeren Version von Schlüsseln nicht zu. Die Verwendung der neuesten Schlüsselversion entspricht der Azure SQL-Sicherheitsrichtlinie, die frühere Schlüsselversionen, die kompromittiert sein könnten, nicht zulässt. Die früheren Versionen des Schlüssels werden möglicherweise für Datenbanksicherungen oder -wiederherstellungen benötigt, insbesondere für Langzeitsicherungen, bei denen die älteren Schlüsselversionen erhalten bleiben müssen. Für Georeplikationssetups müssen alle vom Quellserver benötigten Schlüssel auf dem Zielserver vorhanden sein.

Überlegungen zur Georeplikation beim Konfigurieren der automatisierten Rotation der TDE-Schutzvorrichtung

Wenn die automatische Rotation der TDE-Schutzvorrichtung auf dem primären oder sekundären Server aktiviert ist, sollten Sie unbedingt die folgenden Regeln beim Konfigurieren der Georeplikation befolgen, um Probleme beim Einrichten oder während der Verwendung der Georeplikation zu vermeiden:

  • Sowohl der primäre als auch der sekundäre Server müssen über die Berechtigungen Get, wrapKey und unwrapKey für den Schlüsseltresor des primären Servers (des Schlüsseltresors, der den Schlüssel der TDE-Schutzvorrichtung für den primären Servers enthält) verfügen.

  • Bei einem Server mit aktivierter automatischer Schlüsselrotation fügen Sie vor dem Start der Georeplikation den auf dem primären Server als TDE-Schutzvorrichtung verwendeten Verschlüsselungsschlüssel zum sekundären Server hinzu. Der sekundäre Server benötigt Zugriff auf den Schlüssel im selben Schlüsseltresor oder in einem verwalteten HSM, das mit dem primären Server verwendet wird (und nicht auf einen anderen Schlüssel mit demselben Schlüsselmaterial). Stellen Sie alternativ vor dem Initiieren der Georeplikation sicher, dass die verwaltete Identität des sekundären Servers (vom Benutzer zugewiesen oder vom System zugewiesen) über erforderliche Berechtigungen für den Schlüsseltresor oder das verwaltete HSM des primären Servers verfügt, und das System versucht, den Schlüssel zum sekundären Server hinzuzufügen.

  • Bei einer vorhandenen Georeplikationskonfiguration sollten Sie, bevor Sie die automatische Schlüsselrotation auf dem primären Server aktivieren, den als TDE-Schutzelement auf dem primären Server verwendeten Verschlüsselungsschlüssel dem sekundären Server hinzufügen. Der sekundäre Server benötigt Zugriff auf den Schlüssel im selben Schlüsseltresor oder in einem verwalteten HSM, das mit dem primären Server verwendet wird (und nicht auf einen anderen Schlüssel mit demselben Schlüsselmaterial). Stellen Sie alternativ vor dem Aktivieren des automatisierten Schlüssels sicher, dass die verwaltete Identität des sekundären Servers (vom Benutzer zugewiesen oder vom System zugewiesen) über erforderliche Berechtigungen für den Schlüsseltresor des primären Servers verfügt, und das System versucht, den Schlüssel zum sekundären Server hinzuzufügen.

  • Geo-Replikationsszenarien mit kundenverwalteten Schlüsseln (CMK) für TDE werden unterstützt. TDE mit automatischer Schlüsselrotation muss auf allen Servern konfiguriert werden, wenn Sie TDE im Azure-Portal konfigurieren. Weitere Informationen zum Einrichten der automatischen Schlüsselrotation für Georeplikationskonfigurationen mit TDE finden Sie unter Automatische Schlüsselrotation für Georeplikationskonfigurationen.

Nicht zugängliche TDE-Schutzvorrichtungen

Wenn TDE für die Verwendung eines kundenseitig verwalteten Schlüssels konfiguriert ist, ist dauerhafter Zugriff auf die TDE-Schutzvorrichtung erforderlich, damit die Datenbank online bleiben kann. Wenn der Server den Zugriff auf die vom Kunden verwaltete TDE-Schutzkomponente in Azure Key Vault oder azure Managed HSM verliert, beginnt eine Datenbank in bis zu 10 Minuten, alle Verbindungen mit der entsprechenden Fehlermeldung zu verweigern und den Status in "Nicht zugänglich" zu ändern. Die einzige zulässige Aktion für eine Datenbank im Zustand „Kein Zugriff“ ist das Löschen der Datenbank.

Nicht zugänglicher Zustand

Wenn auf die Datenbank aufgrund eines zeitweiligen Netzwerkausfalls (z. B. eines 5XX-Fehlers) nicht zugegriffen werden kann, ist keine Aktion erforderlich, da die Datenbanken automatisch wieder online sind. Um die Auswirkungen von Netzwerkfehlern oder Ausfällen beim Zugriff auf die TDE-Schutzkomponente in Azure Key Vault oder azure Managed HSM zu verringern, wird ein 24-Stunden-Puffer eingeführt, bevor der Dienst versucht, die Datenbank in einen nicht zugänglichen Zustand zu verschieben. Wenn ein Failover auftritt, bevor der nicht zugängliche Zustand erreicht wird, wird die Datenbank aufgrund des Verlusts des Verschlüsselungscaches nicht verfügbar.

Wenn der Server den Zugriff auf die vom Kunden verwaltete TDE-Schutzkomponente in Azure Key Vault oder azure Managed HSM aufgrund eines Azure Key Vault-Fehlers (z. B. einen 4XX-Fehler) verliert, wird die Datenbank nach 30 Minuten in einen nicht zugänglichen Zustand verschoben.

Wiederherstellen des Datenbankzugriffs nach einem Azure Key Vault- oder Azure Managed HSM-Fehler

Nachdem der Zugriff auf den Schlüssel wiederhergestellt wurde, erfordert das Wiedereinstellen der Datenbank zusätzliche Zeit und Schritte, die je nach Dauer der Nichtverfügbarkeit von Schlüsseln und der Größe der Daten in der Datenbank variieren können.

Wenn der Schlüsselzugriff innerhalb von 30 Minuten wiederhergestellt wird, wird die Datenbank im Laufe der nächsten Stunde automatisch repariert. Wenn der Schlüsselzugriff jedoch nach mehr als 30 Minuten wiederhergestellt wird, ist die automatische Wiederherstellung der Datenbank nicht möglich. In solchen Fällen umfasst das Wiederherstellen der Datenbank zusätzliche Verfahren über das Azure-Portal und kann je nach Größe der Datenbank zeitaufwändig sein.

Sobald die Datenbank wieder online ist, sind zuvor konfigurierte Einstellungen auf Serverebene, einschließlich Failovergruppenkonfigurationen, Tags und Einstellungen auf Datenbankebene, wie elastische Poolkonfigurationen, Lesemaßstab, automatische Pause, Point-in-Time-Wiederherstellungsverlauf, langfristige Aufbewahrungsrichtlinie und andere verloren gegangen. Daher wird empfohlen, dass Kunden ein Benachrichtigungssystem implementieren, um den Verlust des Zugriffs auf Verschlüsselungsschlüssel innerhalb von 30 Minuten zu erkennen. Nachdem das 30-Minütige Fenster abgelaufen ist, empfehlen wir, alle Einstellungen auf Server- und Datenbankebene für die wiederhergestellte Datenbank zu überprüfen.

Im Folgenden sehen Sie sich die zusätzlichen Schritte an, die im Portal erforderlich sind, um eine nicht zugängliche Datenbank wieder online zu schalten.

Screenshot einer nicht zugänglichen TDE BYOK-Datenbank.

Versehentliches Sperren des Zugriffs auf die TDE-Schutzvorrichtung

Es kann vorkommen, dass ein Benutzer mit ausreichenden Zugriffsrechten für den Schlüsseltresor oder verwaltetes HSM den Serverzugriff auf den Schlüssel versehentlich durch eine der folgende Aktionen deaktiviert:

  • Widerrufen der Berechtigungen get, wrapKey, unwrapKey des Schlüsseltresors oder des verwalteten HSM vom Server

  • Löschen des Schlüssels

  • Löschen des Schlüsseltresors oder des verwalteten HSM

  • Ändern der Firewallregeln des Schlüsseltresors oder des verwalteten HSM

  • Löschen der verwalteten Identität des Servers in Microsoft Entra ID

Erfahren Sie mehr über häufige Ursachen für Zugriffsprobleme bei Datenbanken.

Blockierte Konnektivität zwischen SQL Managed Instance und Azure Key Vault oder azure Managed HSM

Die Netzwerkverbindungsunterbrechung zwischen einer SQL Managed Instance und einem Schlüsseltresor oder verwalteten HSM tritt hauptsächlich auf, wenn die Schlüsseltresor- oder verwaltete HSM-Ressource zwar vorhanden ist, der Endpunkt jedoch von der verwalteten Instanz nicht erreicht werden kann. Alle Szenarien, in denen der Schlüsseltresor oder der verwaltete HSM-Endpunkt erreicht werden kann, aber die Verbindung verweigert wird, fehlende Berechtigungen usw. führen dazu, dass die Datenbanken ihren Status in "Nicht zugänglich" ändern.

Die häufigsten Ursachen für mangelnde Netzwerkkonnektivität mit Azure Key Vault oder azure Managed HSM sind:

  • Azure Key Vault oder Azure Managed HSM wird über einen privaten Endpunkt verfügbar gemacht, und die private IP-Adresse des Azure Key Vault- oder azure Managed HSM-Diensts ist in den ausgehenden Regeln der Netzwerksicherheitsgruppe (Network Security Group, NSG), die dem verwalteten Instanzsubnetz zugeordnet ist, nicht zulässig.

  • Schlechte DNS-Auflösung, z. B. wenn der FQDN des Schlüsseltresors oder des verwalteten HSM nicht aufgelöst oder in eine ungültige IP-Adresse aufgelöst wird.

Testen Sie die Konnektivität von SQL Managed Instance mit dem Azure Key Vault oder azure Managed HSM, das die TDE-Schutzkomponente hosten.

  • Der Endpunkt ist Ihr Tresor-FQDN, z. B. <vault_name>.vault.azure.net (ohne https://).
  • Der zu testende Port ist 443.
  • Das Ergebnis für RemoteAddress sollte existieren und die richtige IP-Adresse sein
  • Das Ergebnis für TCP-Test sollte tcpTestSucceededed: True sein.

Wenn der Test TcpTestSucceededed: False zurückgibt, überprüfen Sie die Netzwerkkonfiguration:

  • Überprüfen Sie die aufgelöste IP-Adresse, und bestätigen Sie, dass sie gültig ist. Ein fehlender Wert bedeutet, dass Probleme mit der DNS-Auflösung auftreten.

    • Vergewissern Sie sich, dass die Netzwerksicherheitsgruppe in der verwalteten Instanz über eine Ausgangsregel verfügt, die die aufgelöste IP-Adresse auf Port 443 abdeckt, insbesondere, wenn die aufgelöste Adresse zum privaten Endpunkt des Schlüsseltresors oder des verwalteten HSM gehört.

    • Überprüfen Sie andere Netzwerkkonfigurationen wie Routingtabelle, Vorhandensein des virtuellen Geräts und dessen Konfiguration usw.

"Überwachung der vom Kunden verwalteten TDE"

Konfigurieren Sie die folgenden Azure-Features, um den Datenbankzustand zu überwachen und Warnungen bei Verlust des Zugriffs auf die TDE-Schutzvorrichtung zu aktivieren:

  • Azure Resource Health: Eine nicht zugängliche Datenbank, die den Zugriff auf die TDE-Schutzkomponente verloren hat, wird als "Nicht verfügbar" angezeigt, nachdem die erste Verbindung mit der Datenbank verweigert wurde.

  • Aktivitätsprotokoll: Ist der Zugriff auf die TDE-Schutzvorrichtung im vom Kunden verwalteten Schlüsseltresor nicht möglich, werden dem Aktivitätsprotokoll entsprechende Einträge hinzugefügt. Durch die Erstellung von Warnungen für diese Ereignisse können Sie den Zugriff schnellstmöglich wiederherstellen.

  • Aktionsgruppen können definiert werden, um Ihnen Benachrichtigungen und Warnungen aufgrund Ihrer Präferenzen zu senden – beispielsweise per E-Mail/SMS/Pushbenachrichtigung/Sprachnachricht, per Logik-App, Webhook, ITSM oder Automation-Runbook.

Datenbank backup und restore mit kundenseitig verwalteter TDE

Sobald eine Datenbank mit TDE mit einem Schlüssel aus Azure Key Vault oder azure Managed HSM verschlüsselt wurde, werden alle neu generierten Sicherungen auch mit derselben TDE-Schutzkomponente 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 mit einer TDE-Schutzkomponente verschlüsselte Sicherung aus Azure Key Vault oder azure Managed HSM wiederherzustellen, stellen Sie sicher, dass das Schlüsselmaterial auf dem Zielserver verfügbar ist. Daher wird empfohlen, alle älteren Versionen des TDE-Schutzes im Key Vault oder verwalteten HSM zu behalten, damit Datenbanksicherungen wiederhergestellt werden können.

Wichtig

Es kann zu jedem Zeitpunkt nicht mehr als eine TDE-Schutzkomponente für einen Server festgelegt werden. Der mit Legen Sie den ausgewählten Schlüssel als TDE-Standardschutzvorrichtung fest gekennzeichnete Schlüssel ist die TDE-Standardschutzkomponente im Azure-Portalbereich. Mehrere Schlüssel können jedoch mit einem Server verknüpft werden, ohne sie als TDE-Schutz zu kennzeichnen. Diese Schlüssel werden nicht zum Schutz der DEK verwendet, 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.

Wenn der Schlüssel, der für die Wiederherstellung einer Sicherung benötigt wird, nicht mehr für den Zielserver verfügbar ist, wird beim Wiederherstellungsversuch die folgende Fehlermeldung zurückgegeben: „Target server <Servername> does not have access to all AKV URIs created between <Timestamp #1> and <Timestamp #2>. Wiederholen Sie den Vorgang, nachdem alle AKV-URIs wiederhergestellt wurden.“

Gehen Sie bei der Problembehandlung wie folgt vor: Führen Sie das Cmdlet Get-AzSqlServerKeyVaultKey für den Zielserver oder das Cmdlet Get-AzSqlInstanceKeyVaultKey für die verwaltete Zielinstanz aus, um die Liste der verfügbaren Schlüssel zurückzugeben und die fehlenden Schlüssel zu ermitteln. Um sicherzustellen, dass alle Sicherungen wiederhergestellt werden können, vergewissern Sie sich, dass der Zielserver für die Wiederherstellung auf alle erforderlichen Schlüssel zugreifen kann. Diese Schlüssel müssen nicht als TDE-Schutzvorrichtung gekennzeichnet sein.

Weitere Informationen zur Wiederherstellung der Sicherung für SQL-Datenbank finden Sie unter Wiederherstellen einer Datenbank aus einer Sicherung in der Azure SQL-Datenbank. Weitere Informationen zur Wiederherstellung für dedizierte SQL-Pools in Azure Synapse Analytics finden Sie unter Wiederherstellung eines dedizierten SQL-Pools. Informationen zur nativen Sicherung/Wiederherstellung von SQL Server mit SQL Managed Instance finden Sie in der Schnellstartanleitung: Wiederherstellen einer Datenbank in azure SQL Managed Instance with SSMS.

Weitere Hinweise zu Protokolldateien: Gesicherte Protokolldateien bleiben mit der ursprünglichen TDE-Schutzvorrichtung verschlüsselt, selbst wenn diese rotiert wurde und die Datenbank jetzt eine neue TDE-Schutzvorrichtung verwendet. Zur Wiederherstellungszeit werden beide Schlüssel benötigt, um die Datenbank wiederherzustellen. Wenn die Protokolldatei eine TDE-Schutzkomponente verwendet, die in Azure Key Vault oder azure Managed HSM gespeichert ist, wird dieser Schlüssel zur Wiederherstellungszeit benötigt, auch wenn die Datenbank in der Zwischenzeit geändert wurde, um dienstverwaltete TDE zu verwenden.

Hochverfügbarkeit bei der kundenseitig verwalteten TDE

Mit dem Azure Key Vault oder azure Managed HSM, das mehrere Redundanzebenen bereitstellt, können TDEs mit einem vom Kunden verwalteten Schlüssel die Verfügbarkeit und Ausfallsicherheit von Azure Key Vault oder azure Managed HSM nutzen und sich vollständig auf die Azure Key Vault- oder Azure Managed HSM-Redundanzlösung verlassen.

Azure Key Vault mehrere Redundanzebenen sorgen für den Schlüsselzugriff, auch wenn einzelne Dienstkomponenten fehlschlagen oder Azure-Regionen oder Verfügbarkeitszonen ausfallen. Weitere Informationen finden Sie unter Azure Key Vault: Verfügbarkeit und Redundanz.

Azure Key Vault bietet die folgenden Komponenten der Verfügbarkeit und Resilienz, die automatisch ohne Benutzereingriff bereitgestellt werden:

Hinweis

Für alle Paarregionen werden Azure Key Vault-Schlüssel in beide Regionen repliziert, und es gibt Hardwaresicherheitsmodule (HSM) in beiden Regionen, die mit diesen Schlüsseln arbeiten können. Weitere Informationen finden Sie unter Datenreplikation. Dies gilt für die Azure Key Vault-Dienstebenen „Standard“ und „Premium“ sowie für Software- oder Hardwareschlüssel.

Mit azure Managed HSM Multi-Region-Replikation können Sie einen Azure Managed HSM-Pool von einer Azure-Region (als primäre Region bezeichnet) auf eine andere Azure-Region (als erweiterte Region bezeichnet) erweitern. Nach der Konfiguration sind beide Regionen aktiv, können Anforderungen verarbeiten und bei automatisierter Replikation dasselbe Schlüsselmaterial, dieselben Rollen und Berechtigungen gemeinsam nutzen. Weitere Informationen finden Sie unter Aktivieren der Multi-Region-Replikation auf azure Managed HSM.

Geowiederherstellung nach Katastrophen mit kundenseitig verwaltetem TDE

Aktive Georeplikation und Failovergruppen unterstützen kundenseitig verwaltete TDE. Die primären und sekundären Server können in jeder unterstützten Region ein Azure Key Vault oder ein Azure Managed HSM verwenden. Die Server und der Key Store müssen nicht in derselben Region sein.

Für ein erfolgreiches Failover müssen beide Server Zugriff auf jeden Azure Key Vault oder Azure Managed HSM haben, der einen erforderlichen Schlüssel enthält.

Konfigurationsüberlegungen

Die folgenden Überlegungen gelten, wenn Sie aktive Geo-Replikation oder eine Failover-Gruppe im Azure-Portal konfigurieren:

  • TDE-Schutzstandort: Der primäre und sekundäre Server können denselben Azure Key Vault oder Azure Managed HSM verwenden. Die Verwendung desselben Schlüsselspeichers verringert das Risiko, dass das Schlüsselmaterial nicht mehr synchron ist. Wenn Sie separate Schlüsseltresore in mehreren Regionen verwenden, müssen Sie das erforderliche Schlüsselmaterial synchronisiert halten. Informationen zur Key-Store-Resilienz finden Sie unter Azure Key Vault Verfügbarkeit und Redundanz sowie Multi-Region-Replikation in Managed HSM.

  • Zonenredundanz: Wo verfügbar, bietet Zonenredundanz für Azure SQL-Datenbank oder Azure SQL Managed Instance zusätzliche Widerstandsfähigkeit innerhalb einer Region. Weitere Informationen finden Sie unter Was sind Azure-Verfügbarkeitszonen?.

  • Schlüsselberechtigungen: Sowohl der primäre als auch der sekundäre Server müssen die erforderlichen Berechtigungen für jeden Azure Key Vault oder Azure Managed HSM besitzen, der einen erforderlichen TDE-Schutz enthält.

  • Schlüsselverfügbarkeit: Stellen Sie sicher, dass die erforderlichen Schlüssel sowohl auf dem primären als auch auf dem sekundären Server verfügbar sind. Die Server müssen keine identischen TDE-Schutzmechanismen verwenden, aber jeder Server muss dasselbe Schlüsselmaterial besitzen. Sie können Schlüssel zu einem Server hinzufügen, indem Sie das Azure Portal, PowerShell, Azure CLI oder die Azure SQL REST API verwenden. Wenn die erforderlichen Schlüssel zum Zeitpunkt des Failovers nicht verfügbar sind, kann die Datenbank unzugänglich werden.

  • Private Endpunkte: Die Konfiguration könnte eine komplexere DNS-Zone erfordern, wenn du private Endpunkte in Azure SQL verwendest (zum Beispiel kann es nicht zwei private Endpunkte für dieselbe Ressource in derselben DNS-Zone erstellen).

  • Anwendungskonnektivität: Anwendungen sollten Retry-Logik verwenden, um vorübergehende Fehler während des Failovers zu handhaben.

Informationen zum Konfigurieren der Azure SQL Geo-Notfallwiederherstellungsressource finden Sie unter Aktive Georeplikation oder Failover-Gruppen: Übersicht und bewährte Methoden.

Wichtig

Wenn Sie eine Geo-Replikationsverbindung oder eine Failover-Gruppe erstellen, validiert Azure SQL, dass beide Server auf alle erforderlichen, vom Kunden verwalteten Schlüssel zugreifen können. Wenn einer der Server keinen erforderlichen Schlüssel erreichen kann, schlägt die Erstellungsoperation fehl. Wenn zum Beispiel der primäre und der sekundäre Server Key A bzw. Key B verwenden, fügen Sie beide Schlüssel zu beiden Servern hinzu, bevor Sie die Geo-Replikationsverbindung oder Failover-Gruppe erstellen.

Das folgende Diagramm zeigt die Azure SQL-Geo-Replikation mit einer Failover-Gruppe und das regionsübergreifende Failover von Azure Key Vault in einer Konfiguration mit gekoppelten Regionen:

Diagramm, das die regionsübergreifende Failoverunterstützung von Azure Key Vault für eine gekoppelte Region zeigt.

Azure Key Vault-Verhalten während des Failovers

  • Azure Key Vault initiiert das Failover, nicht Sie.
  • Während der Schlüsseltresor in der Hauptregion nicht verfügbar ist, ist der Schlüsseltresor schreibgeschützt.
  • Du kannst Schlüssel nur erstellen, importieren und drehen, solange der Schlüsseltresor in der Hauptregion verfügbar ist. Nach einem Failover bleibt die Schlüsselrotation blockiert, bis die Primärregion wieder erreichbar ist.
  • Du kannst weder auswählen noch überprüfen, in welcher Region sich der Schlüsseltresor derzeit befindet, und du kannst nicht manuell eine Verbindung mit der sekundären Region herstellen.

Wiederherstellung von einer unzugänglichen TDE-Schutzvorrichtung

Wenn eine Datenbank in einer aktiven Geo-Replikationsbeziehung oder Failover-Gruppe unzugänglich wird, bricht die Azure SQL-Kontrollebene die Verbindung ab und wandelt die Datenbank in eine eigenständige Datenbank um.

Nachdem Sie die Schlüsselberechtigungen wiederhergestellt haben, können Sie in der Regel die primäre Datenbank wieder online stellen. Du kannst die sekundäre Datenbank nicht wieder online bringen, weil Azure SQL keine vollständigen Backups von sekundären Datenbanken macht. Löschen Sie die sekundäre Datenbank, und stellen Sie dann die Georeplikationsverbindung oder die Failovergruppe wieder her.

Azure Policy für kundenseitig verwaltete TDEs

Azure Policy kann zum Erzwingen kundenseitig verwalteter TDEs während der Erstellung oder Aktualisierung eines Azure SQL-Datenbank-Servers oder von Azure SQL Managed Instance verwendet werden. Bei dieser Richtlinie schlagen alle Versuche zum Erstellen oder Aktualisieren eines logischen Servers in Azure oder verwalteter Instanz fehl, wenn sie nicht mit einem vom Kunden verwalteten Schlüssel konfiguriert ist. Azure Policy kann auf das gesamte Azure-Abonnement oder nur innerhalb einer Ressourcengruppe angewendet werden.

Weitere Informationen zur Azure-Richtlinie finden Sie unter Was ist Azure Policy und Azure-Richtliniendefinitionsstruktur.

Die folgenden zwei integrierten Richtlinien werden für kundenseitig verwaltete TDEs in Azure Policy unterstützt:

  • SQL Server-Instanzen müssen kundenseitig verwaltete Schlüssel zur Verschlüsselung ruhender Daten verwenden
  • Für SQL Managed Instance sollten kundenseitig verwaltete Schlüssel zur Verschlüsselung ruhender Daten verwendet werden.

Die kundenseitig verwaltete TDE-Richtlinie können Sie verwalten, indem Sie zum Azure-Portal wechseln und nach dem Dienst "Richtlinie" (Policy) suchen. Suchen Sie im Bereich Definitions (Definitionen) nach dem kundenseitig verwalteten Schlüssel.

Für diese Richtlinien gibt es drei Auswirkungen:

  • Überwachung – Die Standardeinstellung und erfasst nur einen Überwachungsbericht in den Azure-Richtlinienaktivitätsprotokollen.

  • Verweigern: Verhindert die Erstellung oder Aktualisierung eines logischen Servers oder einer verwalteten Instanz, wenn kein kundenseitig verwalteter Schlüssel konfiguriert ist

  • Deaktiviert – Deaktiviert die Richtlinie und schränkt Benutzer nicht daran ein, einen logischen Server oder eine verwaltete Instanz zu erstellen oder zu aktualisieren, ohne dass vom Kunden verwaltete TDE aktiviert ist.

Wenn die Azure-Richtlinie für vom Kunden verwaltete TDE auf "Verweigern" festgelegt ist, schlägt die Erstellung von logischen Azure SQL-Servern oder verwalteten Instanzen fehl. Die Details dieses Fehlers werden im Aktivitätsprotokoll der Ressourcengruppe aufgezeichnet.

Wichtig

Frühere Versionen integrierter Richtlinien für vom Kunden verwaltete TDE, die den AuditIfNotExists Effekt enthalten, sind veraltet. Vorhandene Richtlinienzuweisungen, die die veralteten Richtlinien verwenden, sind nicht betroffen und funktionieren weiterhin wie zuvor.

Zugehöriger Inhalt

  • Last updated on