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

Gilt für: Azure SQL-Datenbank Azure SQL Managed Instance Azure 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 Verwaltung des Lebenszyklus (Erstellen, Hochladen, Rotieren, Löschen von Schlüsseln) und der Schlüsselnutzungsberechtigungen sowie für die Überwachung von Vorgängen für Schlüssel verantwortlich.

In diesem Szenario ist der Schlüssel, der für die Verschlüsselung des Datenbank-Verschlüsselungsschlüssels (Database Encryption Key, DEK) verwendet und auch als TDE-Schutzvorrichtung bezeichnet wird, ein vom Kunden verwalteter asymmetrischer Schlüssel, der in einer kundeneigenen und vom Kunden verwalteten Azure Key Vault-Instanz (AKV) gespeichert ist, einem cloudbasierten externen Schlüsselverwaltungssystem. Key Vault bietet hochverfügbaren und skalierbaren sicheren Speicher für RSA-Kryptografieschlüssel, der optional von FIPS 140-2 Level 2-geprüften Hardwaresicherheitsmodulen (HSM) gesichert wird. Dabei wird kein direkter Zugriff auf einen gespeicherten Schlüssel zugelassen, sondern Verschlüsselung und Entschlüsselung werden mithilfe des Schlüssels für die autorisierten Entitäten bereitgestellt. Der Schlüssel kann über den Schlüsseltresor generiert, importiert oder von einem lokalen HSM-Gerät in den Schlüsseltresor übertragen werden.

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 ist die TDE-Schutzvorrichtung auf Instanzebene festgelegt und wird von allen verschlüsselten Datenbanken für diese Instanz geerbt. Sofern nicht anders angegeben, bezeichnet der Begriff Server in diesem Dokument sowohl Server in SQL-Datenbank und Azure Synapse als auch verwaltete Instanzen in SQL Managed Instance.

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.

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-Schutzvorrichtung

• Transparenz der Verwendung der TDE-Schutzvorrichtung

• Möglichkeit der Trennung von Aufgaben bei der Verwaltung von Schlüsseln und Daten innerhalb der Organisation

• Möglichkeit des Widerrufs von Schlüsselzugriffsberechtigungen durch den Key Vault-Administrator, um den Zugriff auf die verschlüsselte Datenbank zu verhindern

• Zentrale Verwaltung von Schlüsseln in Azure Key Vault

• Mehr Vertrauen der Endkunden, da AKV so entworfen wurde, dass Microsoft die Verschlüsselungsschlüssel weder einsehen noch extrahieren kann

Funktionsweise der kundenseitig verwalteten TDE

Damit der logische Server in Azure gespeicherte TDE-Schutzvorrichtung für die Verschlüsselung des DEK verwenden kann, muss der Key Vault-Administrator dem Server die folgenden Zugriffsrechte über die eindeutige Microsoft Entra-Identität gewähren. 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 Rolle Schlüsseltresor Crypto Service Verschlüsselung Benutzer wird von der Serveridentität benötigt, um den Schlüssel für Verschlüsselungs- und Entschlüsselungsvorgänge verwenden zu können.

• 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 den Schlüsseltresor verfügen:

  • get: zum Abrufen des öffentlichen Teils und der Eigenschaften des Schlüssels in Key Vault
  • wrapKey: zum Schützen (Verschlüsseln) des DEK
  • unwrapKey: zum Aufheben des Schutzes (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 der Server erstmals für die Verwendung einer TDE-Schutzvorrichtung aus Azure Key Vault konfiguriert wird, sendet der Server den DEK jeder Datenbank mit TDE zur Verschlüsselung an Key Vault. Key Vault gibt den verschlüsselten DEK zurück, der in der Benutzerdatenbank gespeichert wird.

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

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

Anforderungen an die Konfiguration der kundenseitig verwalteten TDE

Anforderungen an die Konfiguration von AKV

• Die Funktionen Vorläufiges Löschen und Löschschutz müssen für den Schlüsseltresor aktiviert sein, um Datenverluste durch versehentliches Löschen von Schlüsseln (oder des Schlüsseltresors) zu vermeiden.

• Gewähren Sie dem Server über seine Microsoft Entra-Identität Zugriff auf den Key Vault (get, wrapKey, unwrapKey) Die Serveridentität kann eine systemseitig zugewiesene verwaltete Identität oder eine benutzerseitig zugewiesene verwaltete Identität sein, die dem Server zugewiesen ist. Wenn Sie das Azure-Portal verwenden, wird die Microsoft Entra-Identität automatisch erstellt, wenn der Server erstellt wird. Bei der Verwendung von PowerShell oder Azure CLI muss die Microsoft Entra-Identität explizit erstellt werden und sollte überprüft werden. Unter Konfigurieren von TDE mit BYOK und Konfigurieren von TDE mit BYOK für SQL Managed Instance finden Sie ausführliche Anleitungen für die Verwendung von PowerShell.

  • 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 mit der Rolle Key Vault Crypto Service Encryption User gewährt werden.

• Wenn Sie eine Firewall mit AKV verwenden, müssen Sie die Option "Vertrauenswürdige Microsoft-Dienste zulassen" aktivieren, um die Firewall zu umgehen, es sei denn, Sie verwenden private Endpunkte für den AKV. Weitere Informationen finden Sie unter Konfigurieren von Azure Key Vault-Firewalls und virtuellen Netzwerken.

Aktivieren des vorläufigen Löschens und des Löschschutzes für AKV

Vorläufiges Löschen und Löschschutz sind wichtige Funktionen von Azure Key Vault, die die Wiederherstellung gelöschter Tresore und gelöschter Schlüsseltresorobjekte ermöglichen und das Risiko verringern, dass ein Benutzer versehentlich oder böswillig einen Schlüssel oder einen Schlüsseltresor löscht.

• Weich gelöschte Ressourcen werden 90 Tage lang aufbewahrt, sofern sie nicht vom Kunden wiederhergestellt oder gelöscht werden. Den Aktionen Wiederherstellen und Endgültig löschen sind über Zugriffsrichtlinien für den Schlüsseltresor eigene Berechtigungen zugewiesen. Die Funktion für vorläufiges Löschen ist für neue Schlüsseltresore standardmäßig aktiviert und kann auch über das Azure-Portal, PowerShell oder die Azure CLI aktiviert werden.

• Der Bereinigungsschutz kann mit Azure CLI oder PowerShell aktiviert werden. Wenn der Löschschutz aktiviert ist, kann ein Tresor oder ein Objekt im gelöschten Zustand erst endgültig gelöscht werden, wenn der Aufbewahrungszeitraum abgelaufen ist. Der Standardaufbewahrungszeitraum beträgt 90 Tage, kann aber über das Azure-Portal zwischen 7 und 90 Tagen konfiguriert werden.

• Azure SQL setzt voraus, dass das vorläufige Löschen und der Löschschutz für den Schlüsseltresor aktiviert ist, der den Verschlüsselungsschlüssel enthält, der als TDE-Schutzvorrichtung für den Server oder die verwaltete Instanz verwendet wird. 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.

Anforderungen an die Konfiguration der TDE-Schutzvorrichtung

• Die TDE-Schutzvorrichtung darf nur ein asymmetrischer RSA- oder RSA HSM-Schlüssel sein. Die unterstützten Schlüssellängen sind 2.048 Bit und 3.072 Bit.

• Das Schlüsselaktivierungsdatum (sofern festgelegt) muss ein Datum und eine Uhrzeit in der Vergangenheit sein. Das Ablaufdatum (sofern festgelegt) muss ein Datum und eine Uhrzeit in der Zukunft sein.

• Der Schlüssel muss sich im Zustand Aktiviert befinden.

• Wenn Sie einen vorhandenen Schlüssel in den Schlüsseltresor importieren, müssen Sie ihn in einem unterstützten Dateiformat (.pfx, .byok oder .backup) bereitstellen.

Empfehlungen für die Konfiguration einer kundenseitig verwalteten TDE

Empfehlungen für die Konfiguration von AKV

• Ordnen Sie einem Schlüsseltresor in einem Einzelabonnement insgesamt höchstens 500 universelle oder 200 unternehmenskritische Datenbanken zu, um Hochverfügbarkeit sicherzustellen, wenn der Server auf die TDE-Schutzvorrichtung im Schlüsseltresor zugreift. Diese Zahlen basieren auf Erfahrungen und sind in den Key Vault-Dienstgrenzwerten dokumentiert. Damit sollen Probleme nach einem Serverfailover verhindert werden, da dabei so viele Schlüsselvorgänge für den Tresor ausgeführt werden, wie Datenbanken auf diesem Server vorhanden sind.

• 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: Key Vault stellt Protokolle bereit, die sich problemlos in andere SIEM-Tools (Security Information & Event Management) einfügen lassen. Log Analytics in Operations Management Suite ist ein Beispiel für einen Dienst, der bereits integriert ist.

• Verknüpfen Sie jeden Server mit zwei Schlüsseltresoren in unterschiedlichen Regionen, aber mit denselben Schlüsselmaterialien, um die Hochverfügbarkeit verschlüsselter Datenbanken zu gewährleisten. Markieren Sie den Schlüssel aus einem der Schlüsseltresore als TDE-Schutzvorrichtung. Wenn es zu einem Ausfall kommt, der sich auf den Schlüsseltresor in der ersten Region auswirkt, wechselt das System automatisch zu dem Schlüsseltresor in der zweiten Region mit dem gleichen Schlüsselmaterial.

Empfehlungen für die Konfiguration der TDE-Schutzvorrichtung

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

• Wenn der Schlüssel im Schlüsseltresor generiert wird, erstellen Sie eine Schlüsselsicherung, bevor Sie den Schlüssel zum ersten Mal in AKV verwenden. Die Sicherung kann nur in einer Azure Key Vault-Instanz wiederhergestellt werden. Unter Backup-AzKeyVaultKey erfahren Sie mehr zu diesem Befehl.

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

• Lassen Sie frühere Versionen des Schlüssels beim Rotieren von Schlüsseln im Schlüsseltresor, damit ältere Datenbanksicherungen wiederhergestellt werden können. Wenn die TDE-Schutzvorrichtung für eine Datenbank geändert wird, werden alte Sicherungen der Datenbank nicht aktualisiert, um die aktuelle TDE-Schutzvorrichtung zu verwenden. Bei der Wiederherstellung ist für jede Sicherung die TDE-Schutzvorrichtung erforderlich, mit der sie zum Erstellungszeitpunkt verschlüsselt wurde. Schlüsselrotationen können anhand der Anweisungen unter Rotieren der Transparent Data Encryption-Schutzvorrichtung mithilfe von PowerShell durchgeführt werden.

• Bewahren Sie alle zuvor verwendeten Schlüssel in AKV auf, auch nachdem Sie zu dienstseitig verwalteten Schlüsseln gewechselt haben. Dadurch wird sichergestellt, dass Datenbanksicherungen mit den in AKV gespeicherten TDE-Schutzvorrichtungen wiederhergestellt werden können. Mit Azure Key Vault erstellte TDE-Schutzvorrichtungen müssen beibehalten werden, bis alle gespeicherte Sicherungen mit dienstseitig verwalteten Schlüsseln erstellt wurden. Erstellen Sie mithilfe von Backup-AzKeyVaultKey wiederherstellbare Sicherungskopien dieser Schlüssel.

• Zum Entfernen eines möglicherweise kompromittierten Schlüssels während eines Sicherheitsvorfalls ohne Risiko von Datenverlust führen Sie die Schritte unter Entfernen eines möglicherweise kompromittierten Schlüssels durch.

Rotation der TDE-Schutzvorrichtung

Die Rotation der TDE-Schutzvorrichtung für einen Server bewirkt einen Wechsel zu einem neuen asymmetrischen Schlüssel, der die Datenbanken auf dem Server 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.

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. Nach der Aktivierung überprüft der Server kontinuierlich den Schlüsseltresor auf neue Versionen des Schlüssels, die als TDE-Schutzvorrichtung verwendet werden. Wenn eine neue Version des Schlüssels erkannt wird, erfolgt innerhalb von 24 Stunden automatisch eine Rotation der TDE-Schutzvorrichtung auf dem Server in die neueste Schlüsselversion.

Bei Verwendung mit automatisierter Schlüsselrotation in Azure Key Vault ermöglicht dieses Feature die End-to-End-Zero-Touch-Rotation für die TDE-Schutzvorrichtung in Azure SQL-Datenbank und Azure SQL Managed Instance.

Ü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, der auch für den primären Server verwendet wird (und nicht auf einen anderen Schlüssel mit demselben Schlüsselmaterial). Alternativ können Sie vor dem Starten der Georeplikation sicherstellen, dass die verwaltete Identität des Sekundärservers (benutzerseitig oder systemseitig zugewiesen) über die erforderlichen Berechtigungen für den Schlüsseltresor des Primärservers verfügt, und das System versucht, den Schlüssel zum Sekundärserver hinzuzufügen.

• Bei einem bestehenden Georeplikationssetup fügen Sie vor der Aktivierung der automatischen Schlüsselrotation auf dem primären Server den als TDE-Schutzvorrichtung auf dem primären Server verwendeten Verschlüsselungsschlüssel zum sekundären Server hinzu. Der sekundäre Server benötigt Zugriff auf den Schlüssel im selben Schlüsseltresor, der auch für den primären Server verwendet wird (und nicht auf einen anderen Schlüssel mit demselben Schlüsselmaterial). Alternativ können Sie vor dem Aktivieren des automatisierten Schlüssels sicherstellen, dass die verwaltete Identität des Sekundärservers (benutzerseitig oder systemseitig zugewiesen) über die erforderlichen Berechtigungen für den Schlüsseltresor des Primärservers verfügt, und das System versucht, den Schlüssel zum Sekundärserver hinzuzufügen.

• Georeplikationsszenarios mit kundenseitig verwalteten Schlüsseln (Customer-Managed Keys, 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 keinen Zugriff mehr auf die kundenseitig verwaltete TDE-Schutzvorrichtung in AKV hat, beginnt die Datenbank nach etwa zehn Minuten, mit einer entsprechenden Fehlermeldung, alle Verbindungen zu verweigern, und ändert den Status in Kein Zugriff. Die einzige zulässige Aktion für eine Datenbank im Zustand „Kein Zugriff“ ist das Löschen der Datenbank.

Nachdem der Zugriff auf den Schlüssel wiederhergestellt wurde, erfordert die Wiederherstellung der Datenbank zusätzliche Zeit und Schritte, die je nach verstrichener Zeit ohne Zugriff auf den Schlüssel und die Größe der Daten in der Datenbank variieren kann bzw. können:

Nachfolgend sehen Sie die zusätzlichen Schritte, die im Portal ausgeführt werden müssen, um eine Datenbank, auf die nicht zugegriffen werden kann, wieder online zu schalten.

Versehentliches Sperren des Zugriffs auf die TDE-Schutzvorrichtung

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

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

• Löschen des Schlüssels

• Löschen des Schlüsseltresors

• Ändern der Firewallregeln des Schlüsseltresors

• 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 Key Vault

Bei SQL Managed Instance führen Netzwerkfehler beim Zugriff auf die TDE-Schutzkomponente in Azure Key Vault möglicherweise nicht dazu, dass die Datenbanken ihren Status in Inaccessible (Nicht zugänglich) ändern, doch sie machen die Instanz danach nicht mehr verfügbar. Dies geschieht hauptsächlich, wenn die Schlüsseltresorressource vorhanden ist, aber der Endpunkt von der verwalteten Instanz nicht erreicht werden kann. Alle Szenarien, in denen der Schlüsseltresorendpunkt erreicht werden kann, aber die Verbindung verweigert wird, fehlende Berechtigungen usw., führen dazu, dass die Datenbanken den Status in Inaccessible (Nicht zugänglich) ändern.

Die häufigsten Ursachen für fehlende Netzwerkkonnektivität zu Key Vault sind:

• Key Vault wird über einen privaten Endpunkt verfügbar gemacht, und die private IP-Adresse des AKV-Dienstes ist in den Ausgangsregeln der Netzwerksicherheitsgruppe (NSG), die mit dem Subnetz der verwalteten Instanz verbunden ist, nicht zulässig.
• Schlechte DNS-Auflösung, z. B. wenn der Schlüsseltresor-FQDN nicht aufgelöst oder in eine ungültige IP-Adresse aufgelöst wird.

Testen Sie die Konnektivität zwischen SQL Managed Instance und der Key Vault-Instanz, die 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 gehört.
  • Überprüfen Sie andere Netzwerkkonfigurationen wie Routingtabelle, Vorhandensein des virtuellen Geräts und dessen Konfiguration usw.

Überwachen der kundenseitig 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 Datenbank, auf die nicht zugegriffen werden kann und die den Zugriff auf die TDE-Schutzvorrichtung 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.

Datenbanksicherung und -wiederherstellung mit der kundenseitig verwalteten TDE

Nachdem eine Datenbank mithilfe eines Schlüssels aus Key Vault mit TDE verschlüsselt wurde, werden alle neu generierten Sicherungen ebenfalls mit der gleichen TDE-Schutzvorrichtung verschlüsselt. Wenn die TDE-Schutzvorrichtung geändert wird, werden alte Sicherungen der Datenbank nicht aktualisiert, um die aktuelle TDE-Schutzvorrichtung zu verwenden.

Zum Wiederherstellen einer Sicherung, die mit einer TDE-Schutzvorrichtung aus Key Vault verschlüsselt ist, stellen Sie sicher, dass das Schlüsselmaterial für den Zielserver verfügbar ist. Es wird daher empfohlen, alle alten Versionen der TDE-Schutzvorrichtung im Schlüsseltresor beizubehalten, damit Datenbanksicherungen wiederhergestellt werden können.

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>. Retry operation after restoring all AKV URIs.“ (Zielserver „<Servername>“ kann nicht auf alle zwischen und erstellten AKV-URIs zugreifen. 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 Sicherungswiederherstellung in SQL-Datenbank finden Sie unter Wiederherstellung mit automatisierten Datenbanksicherungen – Azure SQL-Datenbank & SQL Managed Instance. Weitere Informationen zur Sicherungswiederherstellung für dedizierte SQL-Pools in Azure Synapse Analytics finden Sie unter Sichern und Wiederherstellen in einem Azure Synapse-SQL-Pool. Informationen zur nativen Sicherung/Wiederherstellung von SQL Server mit SQL Managed Instance finden Sie unter Schnellstart: Wiederherstellen einer Datenbank in SQL Managed Instance.

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 in Azure Key Vault gespeicherte TDE-Schutzvorrichtung verwendet, wird dieser Schlüssel zur Wiederherstellungszeit auch dann benötigt, wenn die Datenbank geändert wurde und mittlerweile die dienstseitig verwaltete TDE verwendet.

Hochverfügbarkeit bei der kundenseitig verwalteten TDE

Mit dem AKV, der mehrere Redundanzebenen bereitstellt, kann TDEs mit einem vom Kunden verwalteten Schlüssel die AKV-Verfügbarkeit und -Resilienz nutzen und sich vollständig auf die AKV-Redundanzlösung verlassen.

Die mehrfachen Redundanzebenen von AKV 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.

AKV bietet die folgenden Komponenten der Verfügbarkeit und Resilienz an, die automatisch ohne Benutzereingriff bereitgestellt werden:

• Datenreplikation
• Failover innerhalb einer Region
• Failover über Regionen hinweg

Georedundante Notfallwiederherstellung und kundenseitig verwaltete TDE

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 jeder 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 georedundante sekundäre Datenbank 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.

Um Probleme bei der Einrichtung oder während der Georeplikation aufgrund von unvollständigem Schlüsselmaterial zu vermeiden, sollten Sie die folgenden Regeln befolgen, wenn Sie die kundenseitig verwaltete TDE konfigurieren (wenn separate Schlüsseltresore für die primären und sekundären Server verwendet werden):

• Alle beteiligten Schlüsseltresore müssen die gleichen Eigenschaften und Zugriffsrechte für die jeweiligen Server aufweisen.

• Alle beteiligten Schlüsseltresore müssen identische Schlüsselmaterialien enthalten. Dies gilt nicht nur für die aktuelle TDE-Schutzvorrichtung, sondern für alle vorherigen TDE-Schutzvorrichtungen, die möglicherweise bei den Sicherungsdateien verwendet werden.

• Sowohl die Ersteinrichtung als auch die Rotation der TDE-Schutzvorrichtung muss zuerst in der sekundären Datenbank und erst danach in der primären Datenbank erfolgen.

Um ein Failover zu testen, führen Sie die Schritte in Übersicht über die aktive Georeplikation aus. Das Failover sollte regelmäßig getestet werden, um sicherzustellen, dass SQL-Datenbank die Zugriffsberechtigung für beide Schlüsseltresore beibehalten hat.

Ein Azure SQL-Datenbank-Server und eine SQL Managed Instance-Instanz in einer Region können jetzt mit einer Key Vault-Instanz in einer anderen Region verknüpft werden. Der Server und der Schlüsseltresor müssen sich nicht in derselben Region befinden. Dabei können der Einfachheit halber der primäre und der sekundäre Server mit demselben Schlüsseltresor (in einer beliebigen Region) verbunden werden. Dadurch können Szenarios vermieden werden, in denen das Schlüsselmaterial nicht synchronisiert ist, wenn für beide Server getrennte Schlüsseltresore verwendet werden. Azure Key Vault verfügt über mehrere Redundanzebenen, um sicherzustellen, dass Ihre Schlüssel und Schlüsseltresore auch bei Ausfällen von Diensten oder Regionen verfügbar bleiben. Azure Key Vault: Verfügbarkeit und Redundanz

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. Wenn diese Richtlinie eingerichtet ist, schlagen alle Versuche, einen logischen Server in Azure oder eine verwaltete Instanz zu erstellen oder aktualisieren, fehl, wenn dieser nicht mit einem kundenseitig verwalteten Schlüssel konfiguriert ist. Azure Policy kann auf das gesamte Azure-Abonnement oder nur innerhalb einer Ressourcengruppe angewendet werden.

Weitere Informationen zu Azure Policy finden Sie unter Was ist Azure Policy? und Struktur von Azure Policy-Definitionen.

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 Richtlinie für kundenseitig verwaltete TDEs können Sie verwalten, indem Sie zum Azure-Portal wechseln und nach dem Dienst Policy (Richtlinie) suchen. Suchen Sie im Bereich Definitions (Definitionen) nach dem kundenseitig verwalteten Schlüssel.

Für diese Richtlinien gibt es drei Auswirkungen:

• Überwachung: Die Standardeinstellung, mit der ein Überwachungsbericht in den Azure Policy-Aktivitätsprotokollen erfasst wird
• 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 verhindert nicht, dass Benutzer einen logischen Server oder eine verwaltete Instanz ohne aktivierte kundenseitig verwaltete TDE erstellen oder aktualisieren

Wenn die Azure Policy für kundenseitig verwaltete TDE auf Verweigern festgelegt ist, schlägt die Erstellung eines logischen Azure SQL-Servers oder einer verwalteten Instanz fehl. Die Details zu diesem Fehler werden im Aktivitätsprotokoll der Ressourcengruppe aufgezeichnet.

Zugehöriger Inhalt

• Rotation der TDE-Schutzvorrichtung für Azure SQL-Datenbank
• Entfernen einer Transparent Data Encryption-Schutzvorrichtung (TDE) für SQL-Datenbank
• Verwalten der Transparent Data Encryption in SQL Managed Instance mithilfe eines eigenen Schlüssels mit PowerShell
• Microsoft Defender für SQL