Customer-managed TDE for Azure Synapse Analytics

Gilt für: Dedizierte SQL-Pools (früher SQL DW) in Azure Synapse Analytics

Tip

Microsoft Fabric Data Warehouse ist ein relationales Enterprise-Warehouse auf einem Data Lake-Fundament mit zukunftsfähiger Architektur, integrierter KI und neuen Features. Wenn Sie mit Data Warehouse noch nicht vertraut sind, beginnen Sie mit Fabric Data Warehouse. Vorhandene dedizierte SQL-Pool-Workloads können auf Fabric aktualisieren, um neue Funktionen in den Bereichen Data Science, Echtzeitanalyse und Berichterstellung zu nutzen.

Transparente Datenverschlüsselung (TDE) mit kundenseitig verwaltetem Schlüssel (CMK) ermöglicht ein BYOK-Szenario (Bring Your Own Key) zum Schutz ruhender Daten und erlaubt es Organisationen, die Trennung von Zuständigkeiten bei der Verwaltung von Schlüsseln und Daten umzusetzen. Durch die Nutzung von kundenseitig verwaltetem TDE übernehmen Sie die Verantwortung für die Verwaltung des Schlüssellebenszyklus (Schlüsselerstellung, Upload, Rotation, Löschung), für Berechtigungen zur Schlüsselnutzung und für die Auditierung von Vorgängen mit Schlüsseln und haben die volle Kontrolle darüber.

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.

Note

Dieser Artikel behandelt eigenständige dedizierte SQL-Pools (früher SQL DW).

  • Für Azure Synapse Analytics dedizierte SQL-Pools (früher SQL DW) setzen Sie den TDE-Schutz auf Serverebene. Alle verschlüsselten Datenbanken, die diesem Server zugeordnet sind, übernehmen die TDE-Schutzvorrichtung.
  • Verschlüsseln Sie die Daten in dedizierten SQL-Pools und serverlosen SQL-Pools in einem Synapse-Arbeitsbereich, indem Sie den vom Kunden verwalteten Schlüssel verwenden, der auf Arbeitsbereichsebene konfiguriert ist. Weitere Informationen zur transparenten Datenverschlüsselung für dedizierte SQL-Pools in Synapse-Arbeitsbereichen finden Sie unter Azure Synapse Analytics-Verschlüsselung.

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.

  • Customer Managed Key (CMK) – Sie verwalten den Schlüssellebenszyklus, einschließlich Schlüsselerstellung, Rotation und Löschung. Speichern Sie den Schlüssel in Azure Key Vault oder Azure Managed HSM und verwenden Sie ihn zum Verschlüsseln des Datenbankverschlüsselungsschlüssels (DEK).

  • Bring Your Own Key (BYOK) – Sie bringen Ihren eigenen Schlüssel sicher aus einem lokalen Hardware-Sicherheitsmodul (HSM) in Azure Key Vault ein oder importieren ihn. 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

Kundenverwaltetes TDE bietet folgende 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.

Important

Für diejenigen, die Service-Managed TDE nutzen und mit kundenverwaltetem TDE beginnen möchten, bleiben die Daten während des Umstiegs verschlüsselt, und es gibt keine Ausfallzeiten oder Neuverschlü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 kundenseitig verwaltetem TDE im Azure Key Vault

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

Damit der SQL-logische Server in Azure die in Azure Key Vault gespeicherte TDE-Schutzvorrichtung zur Verschlüsselung des DEK verwenden kann, muss der Key Vault Administrator dem Server unter Verwendung seiner eindeutigen 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 User, um den Schlüssel für Verschlüsselungs- und Entschlüsselungsvorgänge zu verwenden.

  • 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 benötigt folgende Berechtigungen für den Schlüsseltresor:

    • 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. Für Schritt-für-Schritt-Anweisungen zur Einrichtung einer Azure Key Vault-Zugriffskonfiguration für TDE siehe Einrichten der erweiterbaren Schlüsselverwaltung (Extensible Key Management) für SQL Server TDE mit 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 Sie einen Server so konfigurieren, dass er einen TDE-Schutz aus Azure Key Vault verwendet, sendet der Server das DEK jeder TDE-fähigen Datenbank zur Verschlüsselung an den Key Vault. Der Schlüsseltresor gibt das verschlüsselte DEK zurück, das der Server in der Benutzerdatenbank speichert.

Bei Bedarf sendet der Server das geschützte DEK zur Entschlüsselung an den Schlüsseltresor.

Auditoren können Azure Monitor verwenden, um Keyvault-AuditEvent-Logs zu überprüfen, sofern das Logging aktiviert ist.

Note

Es kann etwa 10 Minuten dauern, bis Berechtigungsänderungen für den Schlüsseltresor wirksam werden. Dies umfasst diesmal auch den Widerruf der Zugriffsberechtigungen für den TDE-Schutz in AKV, und Benutzer könnten weiterhin Zugriffsrechte haben.

Anforderungen zur Konfiguration vom Kunden verwalteten TDE in Azure Key Vault

  • Aktivieren Sie die Soft-Delete- und Purge-Schutz-Funktionen im Azure Key Vault. Diese Konfiguration hilft, versehentliche oder böswillige Löschungen von Schlüsseltresoren oder Schlüsseln zu verhindern, die dazu führen können, dass die Datenbank in den Status Inaccessible versetzt wird. Wenn du den TDE-Schutz auf einem bestehenden Server oder während der Servererstellung konfigurierst, validiert Azure SQL, dass der von dir verwendete Key Vault einen Soft-Delete- und Purge-Schutz aktiviert hat. 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 aktivieren Sie Soft-Delete und Bereinigungsschutz im Schlüsseltresor, und führen Sie dann die Einrichtung des TDE-Schutzors durch.

  • 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 gespeichert ist, um den Datenbankverschlüsselungsschlüssel (DEK) zu schützen.

Die folgenden Anforderungen gelten.

Unterstützte Schlüsseltypen und Größen

Der TDE-Schutz kann durch asymmetrische Schlüssel gesichert werden, die in Azure Key Vault gespeichert sind. Unterstützte Schlüsselgrößen sind 2.048 Bit und 3.072 Bit.

Schlüsselstatus- und Gültigkeitsanforderungen

  • Wenn du ein Schlüsselaktivierungsdatum angibst, setze es auf ein Datum und eine Uhrzeit in der Vergangenheit.
  • Wenn du ein Ablaufdatum des Schlüssels angibst, setze es auf ein Datum und eine Uhrzeit in der Zukunft.
  • 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

Empfehlungen zur Konfiguration von kundenverwaltetem TDE in Azure Key Vault

Um hohe Verfügbarkeit aufrechtzuerhalten und Drosselungen zu vermeiden, befolgen Sie die nachfolgenden Richtlinien pro Abonnement:

  • 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 Drosselverhalten finden Sie in den Throttling-Leitlinien von Azure Key Vault.

    • Die Anzahl der Hyperscale-Datenbanken, die Sie mit einem einzelnen Azure Key Vault verknüpfen können, hängt von der Anzahl der Seitenserver ab. Jeder Seitenserver ist mit einer logischen Datendatei verknüpft. Um die Anzahl der Seitenserver zu bestimmen, führen Sie die folgende Abfrage aus.

      -- # 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 Azure Key Vault überwachen und Azure Key Vault-Warnungen konfigurieren.

  • 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. Um mehr über Ressourcensperren zu erfahren.

  • 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.

Empfehlungen zum Konfigurieren der TDE-Schutzkomponente

  • Bewahren Sie eine Kopie des TDE-Protektors an einem sicheren Ort auf oder hinterlegen Sie sie bei einem Escrow-Dienst.

  • Wenn du den Schlüssel im Key Vault erstellst, erstelle ein Schlüssel-Backup, bevor du den Schlüssel zum ersten Mal in Azure Key Vault verwendest. Du kannst das Backup nur in einem Azure Key Vault wiederherstellen. Um mehr zu erfahren, siehe den Befehl Backup-AzKeyVaultKey. Azure Managed HSM unterstützt die Erstellung eines vollständigen Backups 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.

  • Erstelle ein neues Backup, sobald du Änderungen am Schlüssel vornimmst (zum Beispiel Schlüsselattribute, Tags, ACLs).

  • 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 benötigt jede Sicherungskopie das TDE-Schutzmodul, mit dem sie bei ihrer Erstellung verschlüsselt wurde. Um Schlüssel zu drehen, folgen Sie den Anweisungen im Artikel Rotate the Transparent Data Encryption (TDE) Protector.

  • Bewahre alle zuvor verwendeten Schlüssel im Azure Key Vault auf, auch nach dem Wechsel zu service-managed Keys. Es stellt sicher, dass Datenbank-Backups mit den TDE-Protektoren, die in Azure Key Vault gespeichert sind, wiederhergestellt werden können. TDE-Schutzvorrichtungen, die mit Azure Key Vault erstellt wurden, müssen beibehalten werden, bis alle verbleibenden gespeicherten Backups mit serviceverwalteten Schlüsseln erstellt wurden. Erstellen Sie wiederherstellbare Sicherungskopien dieser Schlüssel mit Backup-AzKeyVaultKey.

  • 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. Drehen Sie immer zu einer neuen TDE-Schutzkomponente, und stellen Sie sicher, 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.

Rotation der TDE-Schutzvorrichtung

Wenn Sie den TDE-Schutz rotieren, ersetzen Sie den Schlüssel, der den Datenbankverschlüsselungsschlüssel (DEK) schützt. Die Schlüsselrotation erfolgt online und dauert nur wenige Sekunden. Diese Operation entschlüsselt und verschlüsselt nur den Datenbankverschlüsselungsschlüssel, nicht die gesamte Datenbank.

Du kannst den TDE-Schutz rotieren, indem du die Konfiguration so umstellst, dass ein neuer Schlüssel verwendet wird, der in Azure Key Vault gespeichert ist. Je nach Angebot und unterstützter Konfiguration kann dieser Schlüssel folgende Werte haben:

  • Wechseln zu einer neuen Schlüsselversion desselben Schlüssels
  • Wechseln zu einem anderen Schlüssel

Die Rotation des TDE-Schutzes kann manuell oder mit der automatisierten Rotationsfunktion erfolgen.

Du kannst die automatische Rotation des TDE-Protector aktivieren, wenn du den TDE-Protector für den Server konfigurierst. Die automatisierte Rotation ist standardmäßig deaktiviert. Wenn aktiviert, überprüft der Server kontinuierlich den Schlüsseltresor auf neue Versionen des Schlüssels, der als TDE-Schutzvorrichtung verwendet wird. Wenn der Server eine neue Version des Schlüssels erkennt, rotiert er die TDE-Schutzvorrichtung auf dem Server oder der Datenbank innerhalb von 24 Stunden automatisch auf die neueste Schlüsselversion.

Note

Wenn du TDE mit CMK durch manuelle oder automatisierte Schlüsselrotation einstellst, verwendest du immer die neueste vom System unterstützte Version des 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.

Nicht zugängliche TDE-Schutzvorrichtungen

Wenn Sie TDE so konfigurieren, dass ein vom Kunden verwalteter Schlüssel verwendet wird, benötigt die Datenbank kontinuierlichen Zugriff auf die TDE-Schutzvorrichtung, um online zu bleiben. Wenn der Server den Zugriff auf die vom Kunden verwaltete TDE-Schutzvorrichtung in Azure Key Vault verliert, beginnt die Datenbank, alle Verbindungen innerhalb von 10 Minuten abzulehnen, zeigt eine Fehlermeldung an und ändert ihren Status auf Nicht zugänglich. 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 den TDE-Schutz in Azure Key Vault zu verringern, führt der Dienst einen 24-Stunden-Puffer ein, bevor er versucht, die Datenbank in einen unzugänglichen Zustand zu versetzen. 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 in Azure Key Vault aufgrund eines Azure Key Vault Fehlers (wie einem 4XX-Fehler) den Zugriff auf den vom Kunden verwalteten TDE-Schutz verliert, wechselt die Datenbank nach 30 Minuten in einen unzugänglichen Zustand.

Datenbankzugriff wiederherstellen nach einem Fehler bei Azure Key Vault

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.

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

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 den Mangel an Netzwerkverbindung zu Azure Key Vault sind:

  • Azure Key Vault ist über einen privaten Endpunkt verfügbar, und die private IP-Adresse des Azure Key Vault-Dienstes ist in den Outbound-Regeln der Network Security Group (NSG), die mit dem verwalteten Instanz-Subnetz verbunden ist, nicht erlaubt.

  • 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.

Teste die Verbindung von der SQL Managed Instance zum Azure Key Vault, der die TDE-Schutzvorrichtung hostet.

  • 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 unzugängliche Datenbank, die den Zugriff auf den TDE-Protektor verloren hat, wird als „Nicht verfügbar“ angezeigt, nachdem der erste Verbindungsversuch 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. Indem Sie Benachrichtigungen für diese Ereignisse erstellen, können Sie den Zugang so schnell wie möglich wiederherstellen.

  • Aktionsgruppen können so definiert werden, dass sie Ihnen Benachrichtigungen und Warnungen basierend auf Ihren Präferenzen senden, zum Beispiel E-Mail, SMS, Push, Sprache, Logic App, Webhook, ITSM oder Automation Runbook.

Datenbanksicherung und -wiederherstellung mit kundenverwaltetem TDE

Sobald eine Datenbank mit TDE mit einem Schlüssel aus Azure Key Vault verschlüsselt ist, werden alle neu erstellten Backups ebenfalls mit demselben 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 ein mit einem TDE-Schutz verschlüsseltes Backup aus Azure Key Vault wiederherzustellen, stellen Sie sicher, dass das Schlüsselmaterial dem Zielserver zur Verfügung steht. Daher sollten alle alten Versionen der TDE-Schutzvorrichtung im Key Vault oder im verwalteten HSM aufbewahrt werden, damit Datenbank-Backups wiederhergestellt werden können.

Important

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 des DEK verwendet, können aber während der Wiederherstellung aus einem Backup verwendet werden, wenn die Backup-Datei 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 für dedizierte SQL-Pools in Azure Synapse Analytics finden Sie unter Wiederherstellung eines dedizierten SQL-Pools.

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 Logdatei einen TDE-Schutz verwendet, der in Azure Key Vault gespeichert ist, wird dieser Schlüssel zur Wiederherstellungszeit benötigt, selbst wenn die Datenbank inzwischen auf Service-Managed TDE umgestellt wurde.

Hochverfügbarkeit bei der kundenseitig verwalteten TDE

Durch die Nutzung der vielfältigen Redundanzschichten von Azure Key Vault können TDEs, die einen kundenverwalteten Schlüssel verwenden, von der Verfügbarkeit und Robustheit von Azure Key Vault profitieren. Sie können sich voll und ganz auf die Redundanzlösung von Azure Key Vault verlassen.

Die multiplen Redundanzschichten von Azure Key Vault gewährleisten den Schlüsselzugriff, selbst wenn einzelne Servicekomponenten ausfallen oder Azure-Regionen oder Verfügbarkeitszonen ausfallen. Weitere Informationen finden Sie unter Azure Key Vault: Verfügbarkeit und Redundanz.

Azure Key Vault bietet automatisch folgende Komponenten für Verfügbarkeit und Widerstandsfähigkeit ohne Benutzereingriff:

Verwandte Inhalte

  • Zuletzt aktualisiert um