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

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

Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) von 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.

Hinweis

• Dieser Artikel gilt für Azure SQL-Datenbank, Azure SQL Managed Instance und Azure Synapse Analytics (dedizierte SQL-Pools (vormals SQL DW)). Die Dokumentation zu Transparent Data Encryption für dedizierte SQL-Pools in Synapse-Arbeitsbereichen finden Sie unter Verschlüsselung für Azure Synapse Analytics-Arbeitsbereiche.
• Zum Bereitstellen von zwei Ebenen der Verschlüsselung von ruhenden Daten für Azure SQL-Kunden wird die Infrastrukturverschlüsselung (mithilfe des AES-256-Verschlüsselungsalgorithmus) mit von der Plattform verwalteten Schlüsseln eingeführt. Dadurch erhalten sie neben TDE mit vom Kunden verwalteten Schlüsseln (bereits verfügbar) eine zusätzliche Ebene der Verschlüsselung von ruhenden Daten. Für Azure SQL-Datenbank und Azure SQL Managed Instance werden alle Datenbanken verschlüsselt, einschließlich der master-Datenbank und anderer Systemdatenbanken, wenn die Infrastrukturverschlüsselung aktiviert ist. Zurzeit müssen Kunden den Zugriff anfordern, um diese Funktion verwenden zu können. Sollten Sie an dieser Funktion interessiert sein, wenden Sie sich an AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

Hinweis

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

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

Wichtig

Für diejenigen, die eine dienstseitig verwaltete TDE verwenden und auf eine kundenseitig verwalteten TDE umsteigen möchten, bleiben die Daten während der Umstellung verschlüsselt, und es kommt nicht zu Ausfallzeiten oder einer 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.

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:

• 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

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

Hinweis

Es kann etwa 10 Minuten dauern, bis alle Berechtigungsänderungen für den Schlüsseltresor 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 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. 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

Wichtig

Beim Konfigurieren der kundenseitig verwalteten TDE-Instanz für einen neuen oder vorhandenen Server oder eine neue oder vorhandene verwaltete Instanz müssen sowohl vorläufiges Löschen als auch der Löschschutz für den Schlüsseltresor aktiviert werden.

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.

Hinweis

Azure SQL unterstützt nun die Verwendung eines RSA-Schlüssels, der in einem verwalteten HSM als TDE-Schutzvorrichtung gespeichert ist. Verwaltetes HSM von Azure Key Vault ist ein vollständig verwalteter, hochverfügbarer, Einzelmandanten- und standardkonformer Clouddienst, der es Ihnen ermöglicht, kryptografische Schlüssel für Ihre Cloudanwendungen über HSMs zu schützen, die mit FIPS 140-2 Level 3 validiert sind. Erfahren Sie mehr über verwaltete HSMs.

Hinweis

Ein Problem mit Thales CipherTrust Manager-Versionen vor v2.8.0 sorgt dafür, dass Schlüssel, die in Azure Key Vault importiert werden, nicht mit Azure SQL-Datenbank oder Azure SQL Managed Instance für Szenarios mit TDE mit von Kunden verwalteten Schlüsseln verwendet werden können. Weitere Informationen zu diesem Problem finden Sie hier. Warten Sie in solchen Fällen 24 Stunden nach dem Import des Schlüssels in den Schlüsseltresor, bis Sie mit dessen Verwendung als TDE-Schutzvorrichtung für den Server oder die verwaltete Instanz beginnen. Dieses Problem wurde in Thales CipherTrust Manager v2.8.0 behoben.

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.

Hinweis

Um eine größere Flexibilität bei der Konfiguration von kundenseitig verwalteter TDE zu ermöglichen, können Azure SQL-Datenbank und Azure SQL Managed Instance in einer Region jetzt mit einem Schlüsseltresor in einer beliebigen anderen Region verknüpft werden. Der Server und der Schlüsseltresor müssen sich nicht in derselben Region befinden.

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.

Hinweis

Beim Festlegen von TDE mit CMK unter Verwendung der manuellen oder automatischen Schlüsselrotation wird immer die aktuellste Version des Schlüssels verwendet, die unterstützt wird. Das Setup lässt die Verwendung einer früheren 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 im Falle von 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, 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.

Hinweis

Wenn aufgrund eines vorübergehenden Netzwerkausfalls nicht auf die Datenbank zugegriffen werden kann, ist keine Aktion erforderlich, und die Datenbanken werden automatisch wieder online geschaltet.

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:

Hinweis

• Bei Wiederherstellung des Schlüsselzugriffs innerhalb von 30 Minuten wird die Datenbank innerhalb der nächsten Stunde automatisch repariert.
• Wenn der Schlüsselzugriff nach mehr als 30 Minuten wiederhergestellt wird, ist keine automatische Reparatur der Datenbank möglich. Die erneute Aktivierung der Datenbank erfordert zusätzliche Schritte im Azure-Portal und kann je nach Größe der Datenbank sehr lange dauern.
• Sobald die Datenbank wieder online ist, gehen zuvor konfigurierte Einstellungen auf Serverebene verloren, darunter möglicherweise die Konfiguration von Failovergruppen und Tags sowie Einstellungen auf Datenbankebene wie die Konfiguration von Pools für elastische Datenbanken, die Leseskalierung, automatische Pausen, der Point-in-Time-Wiederherstellungsverlauf oder die Richtlinie für langfristige Aufbewahrung. Daher wird Kund*innen empfohlen, ein Benachrichtigungssystem zu implementieren, das den Verlust des Verschlüsselungsschlüsselzugriffs innerhalb von 30 Minuten erkennt. Sobald das 30-Minuten-Fenster abgelaufen ist, wird empfohlen, alle Einstellungen auf Server- und Datenbankebene für die wiederhergestellte Datenbank zu überprüfen.

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 für 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.

Wichtig

Zu jedem Zeitpunkt kann nur eine TDE-Schutzvorrichtung für einen Server festgelegt werden. Dabei handelt es sich um den Schlüssel, der im Bereich des Azure-Portals mit „Legen Sie den ausgewählten Schlüssel als TDE-Standardschutzvorrichtung fest“ gekennzeichnet ist. Es können jedoch mehrere zusätzliche Schlüssel mit einem Server verknüpft werden, ohne diese als TDE-Schutzvorrichtung zu kennzeichnen. Diese Schlüssel werden nicht zum Schutz des DEK verwendet. Sie können aber während der Wiederherstellung aus einer Sicherung verwendet werden, wenn die Sicherungsdatei mit dem Schlüssel mit dem entsprechenden Fingerabdruck verschlüsselt ist.

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

Selbst ohne konfigurierte Georedundanz wird dringend empfohlen, den Server für die Verwendung von zwei verschiedenen Schlüsseltresoren in zwei unterschiedlichen Regionen mit demselben Schlüsselmaterial zu konfigurieren. Der Schlüssel im sekundären Schlüsseltresor in der anderen Region sollte nicht als TDE-Schutzvorrichtung gekennzeichnet werden. Daher ist dies auch nicht zulässig. Nur bei einem Ausfall, der den primären Schlüsseltresor betrifft, wechselt das System automatisch zum anderen verknüpften Schlüssel mit demselben Fingerabdruck im sekundären Schlüsseltresor (sofern vorhanden). Beachten Sie jedoch, dass der Wechsel nicht erfolgt, wenn auf die TDE-Schutzvorrichtung nicht zugegriffen werden kann, weil die Zugriffsrechte entzogen wurden oder weil der Schlüssel oder der Schlüsseltresor gelöscht wurde. Dies kann darauf hindeuten, dass der Kunde absichtlich den Zugriff des Servers auf den Schlüssel einschränken möchte. Die Bereitstellung desselben Schlüsselmaterials für zwei Schlüsseltresore in verschiedenen Regionen kann erfolgen, indem der Schlüssel außerhalb des Schlüsseltresors erstellt und in beide Schlüsseltresore importiert wird.

Alternativ kann der Schlüssel mithilfe des primären Schlüsseltresors in einer Region generiert und in einen Schlüsseltresor in einer anderen Azure-Region geklont werden. Rufen Sie mit dem Cmdlet Backup-AzKeyVaultKey den Schlüssel in einem verschlüsselten Format aus dem primären Schlüsseltresor ab. Geben Sie dann mit dem Cmdlet Restore-AzKeyVaultKey einen Schlüsseltresor in der zweiten Region für das Klonen des Schlüssels an. Alternativ können Sie das Azure-Portal verwenden, um den Schlüssel zu sichern und wiederherzustellen. Der Sicherungs-/Wiederherstellungsvorgang für Schlüssel ist nur zwischen Schlüsseltresoren innerhalb desselben Azure-Abonnements und derselben Azure-Region zulässig.

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.

Wichtig

Frühere Versionen integrierter Richtlinien für kundenseitig verwaltete TDE mit dem AuditIfNotExist-Effekt sind veraltet. Bestehende Richtlinienzuweisungen unter Verwendung veralteter Richtlinien sind nicht betroffen und funktionieren weiter wie zuvor.

Nächste Schritte

Möglicherweise sollten Sie sich auch die folgenden PowerShell-Beispielskripts für allgemeine Vorgänge mit der kundenseitig verwalteten TDE ansehen:

• 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

Aktivieren Sie außerdem Microsoft Defender für SQL, um Ihre Datenbanken und ihre Daten mit verschiedenen Funktionen zu schützen. Hierzu zählen Funktionen zum Entdecken und Mindern potenzieller Datenbanksicherheitsrisiken sowie zum Erkennen anomaler Aktivitäten, die auf eine Bedrohung für Ihre Datenbanken hinweisen könnten.