Datenverschlüsselung mit vom Kunden verwalteten Schlüsseln für Azure-Datenbank für MySQL

Mit der Datenverschlüsselung mit vom Kunden verwalteten Schlüsseln für Azure-Datenbank für MySQL können Sie Ihren eigenen Schlüssel (BYOK) zum Ruhezustand bringen und die Trennung von Aufgaben für die Verwaltung von Schlüsseln und Daten implementieren. Bei kundenseitig verwalteten Schlüsseln (CMKs) ist die bzw. der Kunde letztendlich 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.

Vorteile

Die Datenverschlüsselung mit kundenseitig verwalteten Schlüsseln für Azure Database for MySQL bietet die folgenden Vorteile:

• Sie steuern den Datenzugriff vollständig durch die Möglichkeit, den Schlüssel zu entfernen und so die Datenbank nicht zugänglich zu machen
• Vollständige Kontrolle über den Schlüssellebenszyklus, einschließlich der Rotation des Schlüssels zum Einhalten von Unternehmensrichtlinien
• Zentrale Verwaltung und Organisation von Schlüsseln in Azure Key Vault oder einem verwalteten HSM
• Möglichkeit zur Implementierung der Trennung von Aufgaben zwischen Sicherheitsbeauftragten, DBAs und Systemadministrierende

Wie funktioniert die Datenverschlüsselung mit einem kundenseitig verwalteten Schlüssel?

Verwaltete Identitäten in Microsoft Entra ID bieten Azure-Diensten eine Alternative zum Speichern von Anmeldeinformationen im Code, indem sie eine automatisch zugewiesene Identität bereitstellen, die zur Authentifizierung bei jedem Dienst verwendet werden kann, der die Microsoft Entra-Authentifizierung unterstützt, wie z. B. Azure Key Vault (AKV). Azure-Datenbank für MySQL unterstützt derzeit nur vom Benutzer zugewiesene verwaltete Identität (UMI). Weitere Informationen finden Sie unter verwaltete Identitätstypen in Azure.

Um den CMK für eine Azure-Datenbank für MySQL zu konfigurieren, müssen Sie die UMI mit dem Server verknüpfen und den zu verwendenden Azure Key Vault und Schlüssel angeben.

Die UMI muss den folgenden Zugriff auf den Schlüsseltresor haben:

• Get: zum Abrufen des öffentlichen Teils und der Eigenschaften des Schlüssels im Schlüsseltresor.
• List: zum Auflisten der Versionen des in einem Schlüsseltresor gespeicherten Schlüssels.
• Wrap Key: zum Verschlüsseln des DEK. Der verschlüsselte DEK wird in Azure Database for MySQL – Flexible Server gespeichert.
• Unwrap Key: zum Entschlüsseln des DEK. Die Azure-Datenbank für MySQL benötigt die entschlüsselte DEK, um die Daten zu verschlüsseln/zu entschlüsseln.

Wenn RBAC aktiviert ist, muss der UMI auch die folgende Rolle zugewiesen werden:

• Key Vault Crypto Service Encryption-Benutzende oder die Rolle mit den Berechtigungen:
  • Microsoft.KeyVault/vaults/keys/wrap/action
  • Microsoft.KeyVault/vaults/keys/unwrap/action
  • Microsoft.KeyVault/vaults/keys/read, z. B. „Key Vault Crypto Service Encryption-Benutzende“
• Weisen Sie für ein verwaltetes HSM die Rolle Benutzende der Kryptografiedienstverschlüsselung für verwaltete HSMs zu

Terminologie und Beschreibung

Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) : Ein symmetrischer AES256-Schlüssel zum Verschlüsseln einer Partition oder eines Datenblocks. Das Verschlüsseln jedes Datenblocks mit einem anderen Schlüssel erschwert Kryptoanalyseangriffe. Der Ressourcenanbieter oder die Anwendungsinstanz, die einen spezifischen Block ver- oder entschlüsselt, muss Zugriff auf die DEKs gewähren. Wenn Sie einen DEK durch einen neuen Schlüssel ersetzen, müssen nur die Daten im verknüpften Block erneut mit dem neuen Schlüssel verschlüsselt werden.

Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) : Ein Verschlüsselungsschlüssel, der zum Verschlüsseln der DEKs verwendet wird. Mit einem KEK, der Key Vault nie verlässt, können die DEKs selbst verschlüsselt und gesteuert werden. Die Entität, die auf den KEK zugreifen kann, kann sich von der Entität unterscheiden, die den DEK erfordert. Da der KEK erforderlich ist, um DEKs zu entschlüsseln, ist der KEK ein Punkt, an dem DEKs gelöscht werden können, indem der KEK gelöscht wird. Die mit den KEKs verschlüsselten DEKs werden separat gespeichert. Nur eine Entität mit Zugriff auf den KEK kann diese DEKs entschlüsseln. Weitere Informationen finden Sie unter Sicherheit bei der Verschlüsselung ruhender Daten.

Funktionsweise

Die Datenverschlüsselung mit CMKs wird auf Serverebene festgelegt. Bei einem bestimmten Server wird ein CMK verwendet, der als Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) bezeichnet wird, um den vom Dienst verwendeten Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) zu verschlüsseln. Der KEK ist ein asymmetrischer Schlüssel, der in einer vom Kunden verwalteten Azure Key Vault-Instanz im Besitz des Kunden gespeichert wird. Key Vault ist ein hochverfügbarer und skalierbarer sicherer Speicher für kryptografische RSA-Schlüssel, der optional durch FIPS 140-validierte Hardware-Sicherheitsmodule (HSMs) unterstützt wird. Key Vault lässt keinen direkten Zugriff auf einen gespeicherten Schlüssel zu, sondern stellt stattdessen die Verschlüsselung und Entschlüsselung mithilfe des Schlüssels für die autorisierten Entitäten bereit. Der importierte Schlüsseltresor kann den Schlüssel generieren oder von einem lokalen HSM-Gerät in den Schlüsseltresor übertragen werden.

Wenn Sie einen flexiblen Server für die Verwendung eines CMK konfigurieren, der im Schlüsseltresor gespeichert ist, sendet der Server den DEK zur Verschlüsselung an den Schlüsseltresor. Key Vault gibt den verschlüsselten DEK zurück, der in der Benutzerdatenbank gespeichert wird. Ebenso sendet der flexible Server die geschützte DEK bei Bedarf an den Schlüsseltresor zur Entschlüsselung.

Nach Aktivierung der Protokollierung können Prüfer mithilfe von Azure Monitor das Überwachungsereignisprotokoll von Key Vault überprüfen. Informationen zum Aktivieren der Protokollierung von Key Vault-Überwachungsereignissen finden Sie unter „Überwachen des Schlüsseltresordiensts mit Key Vault-Erkenntnissen“.

Anforderungen für die Konfiguration der Datenverschlüsselung für Azure Database for MySQL

Bevor Sie versuchen, Key Vault oder das verwaltete HSM zu konfigurieren, vergewissern Sie sich, dass die folgenden Anforderungen erfüllt sind.

• Der Key Vault und die flexible Serverinstanz von Azure Database for MySQL müssen zum selben Microsoft Entra-Mieter gehören. Mandantenübergreifende Interaktionen zwischen Key Vault und dem flexiblen Server müssen unterstützt werden. Wenn Sie nach der Ausführung der Konfiguration Key Vault-Ressourcen verschieben, müssen Sie die Datenverschlüsselung neu konfigurieren.
• Der Key Vault und die flexible Serverinstanz von Azure Database for MySQL müssen sich in derselben Region befinden.
• Aktivieren Sie die Funktion zur weichen Löschung im Schlüsseltresor und legen Sie einen Aufbewahrungszeitraum von 90 Tagen fest, um vor Datenverlust zu schützen, falls versehentlich ein Schlüssel oder der Schlüsseltresor gelöscht wird. Den Aktionen „Wiederherstellen“ und „Endgültig löschen“ sind über Key Vault-Zugriffsrichtlinien eigene Berechtigungen zugewiesen. Das Feature für vorläufiges Löschen ist standardmäßig deaktiviert, Sie können es aber über das Azure-Portal oder mithilfe von PowerShell oder der Azure CLI aktivieren.
• Aktivieren Sie die Funktion Bereinigungsschutz für den Schlüsseltresor und legen Sie einen Aufbewahrungszeitraum von 90 Tagen fest. Bei aktiviertem Bereinigungsschutz kann ein Tresor oder ein Objekt im gelöschten Zustand erst nach Ablauf der Aufbewahrungsdauer endgültig gelöscht werden. Sie können dieses Feature mithilfe von PowerShell oder der Azure CLI aktivieren, und nur nachdem Sie das vorläufige Löschen aktiviert haben.

Bevor Sie versuchen, den CMK zu konfigurieren, achten Sie darauf, dass die folgenden Anforderungen erfüllt sind.

• Der kundenseitig verwaltete Schlüssel zur Verschlüsselung des DEK kann nur asymmetrisch, RSA\RSA-HSM (Tresore mit Premium-SKU) 2048,3072 oder 4096 sein.
• Das Schlüsselaktivierungsdatum (sofern festgelegt) muss ein Datum und eine Uhrzeit in der Vergangenheit sein. Das Ablaufdatum ist nicht festgelegt.
• Der Schlüssel muss sich im Zustand Aktiviert befinden.
• Für den Schlüssel muss das vorläufige Löschen mit einem Aufbewahrungszeitraum von 90 Tagen festgelegt sein. Dadurch wird das erforderliche recoveryLevel-Schlüsselattribut implizit auf „Recoverable“ festgelegt.
• Für den Schlüssel muss der Bereinigungsschutz aktiviert sein.
• Wenn Sie einen vorhandenen Schlüssel in Key Vault importieren, müssen Sie ihn in einem der unterstützten Dateiformate (.pfx, .byok, .backup) bereitstellen.

Empfehlungen zum Konfigurieren der Datenverschlüsselung

Wenn Sie Key Vault oder ein verwaltetes HSM für die Verwendung der Datenverschlüsselung mithilfe eines kundenseitig verwalteten Schlüssels konfigurieren, beachten Sie die folgenden Empfehlungen.

• Legen Sie eine Ressourcensperre für Key Vault fest, um zu steuern, wer diese wichtige Ressource löschen kann, und um ein versehentliches oder nicht autorisiertes Löschen zu verhindern.
• 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 Azure Monitor ist ein Beispiel für einen Dienst, der bereits integriert ist.
• Bewahren Sie eine Kopie des kundenseitig verwalteten Schlüssels an einem sicheren Ort auf, oder hinterlegen Sie ihn bei einem entsprechenden Dienst.
• Wenn Key Vault den Schlüssel generiert, erstellen Sie eine Schlüsselsicherung, bevor Sie den Schlüssel erstmals verwenden. Sie können nur die Sicherung in Key Vault wiederherstellen. Weitere Informationen zum Sicherungsbefehl finden Sie unter Backup-AzKeyVaultKey.

Kein Zugriff auf die Bedingung des kundenseitig verwalteten Schlüssels

Wenn Sie die Datenverschlüsselung mit einem CMK Azure Key Vault konfigurieren, wird fortlaufender Zugriff auf diesen Schlüssel benötigt, damit der Server online bleiben kann. Wenn der flexible Server in Key Vault den Zugriff auf den vom Kunden verwalteten Schlüssel verliert, beginnt der Server innerhalb von 10 Minuten damit, alle Verbindungen zu verweigern. Der flexible Server gibt eine entsprechende Fehlermeldung aus und ändert den Serverstatus in „Kein Zugriff“. Der Server kann diesen Zustand aus verschiedenen Gründen erreichen.

• Wenn Sie den Schlüsseltresor löschen, kann die Flexible Serverinstanz der Azure-Datenbank für MySQL nicht auf den Schlüssel zugreifen und geht in den Zustand Unzugänglich über. Stellen Sie den Schlüsseltresor wieder her, und aktualisieren Sie die Datenverschlüsselung, um die flexible Serverinstanz von Azure Database for mySQL verfügbarzu machen.
• Wenn Sie den Schlüssel aus dem Schlüsseltresor löschen, kann die flexible Azure-Datenbank für MySQL-Serverinstanz nicht auf den Schlüssel zugreifen und in den Zustand " Nicht zugänglich " verschoben werden. Stellen Sie den Schlüssel wieder her, und aktualisieren Sie die Datenverschlüsselung, um die fflexible Serverinstanz von Azure Database for mySQL verfügbarzu machen.

Versehentliche Sperrung des Zugriffs auf den Schlüssel durch Key Vault

Es kann vorkommen, dass Benutzende mit ausreichenden Zugriffsrechten für Key Vault den Zugriff des flexiblen Servers auf den Schlüssel versehentlich durch eine der folgende Aktionen deaktivieren:

• Widerrufen der Berechtigungen „get“, „list“, „wrap key“ und „unwrapping key“ vom Server
• Löschen des Schlüssels
• Löschen des Schlüsseltresors
• Ändern der Firewallregeln des Schlüsseltresors
• Löschen der für die Verschlüsselung auf dem flexiblen Server verwendeten benutzerseitig verwalteten Identität mit einem kundenseitig verwalteten Schlüssel in Microsoft Entra ID

Überwachen des kundenseitig verwalteten Schlüssels in Key Vault

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

• Aktivitätsprotokoll: Ist der Zugriff auf den Kundenschlüssel im vom Kunden verwalteten Schlüsseltresor nicht möglich, werden dem Aktivitätsprotokoll entsprechende Einträge hinzugefügt. Sie können den Zugriff so bald wie möglich wiederherstellen, wenn Sie Warnungen für diese Ereignisse erstellen.
• Aktionsgruppen: Definieren Sie diese Gruppen, um Benachrichtigungen und Warnungen gemäß Ihren Voreinstellungen zu senden.

Replikat mit einem vom kundenseitig verwalteten Schlüssel in Key Vault

Sobald eine flexible Serverinstanz von Azure Database for MySQL mit dem im Key Vault gespeicherten verwalteten Schlüssel einer Kundin oder eines Kunden verschlüsselt ist, wird jede neu erstellte Kopie des Servers ebenfalls verschlüsselt. Wenn Sie versuchen, eine Azure-Datenbank für mySQL flexible Serverinstanz mit einem vom Kunden verwalteten Schlüssel zu verschlüsseln, der bereits über ein Replikat verfügt, empfehlen wir, ein oder mehrere Replikate durch Hinzufügen der verwalteten Identität und des Schlüssels zu konfigurieren. Angenommen, die flexible Serverinstanz von Azure Database for MySQL ist mit einem georedundanten Backup konfiguriert. In diesem Fall muss das Replikat mit der verwalteten Identität und dem Schlüssel konfiguriert werden, auf die die Identität Zugriff hat und die sich in der geografisch gekoppelten Region des Servers befinden.

Wiederherstellen mit einem kundenseitig verwalteten Schlüssel in Key Vault

Wenn Sie versuchen, eine flexible Serverinstanz von Azure Database for MySQL wiederherzustellen, können Sie die benutzerseitig verwaltete Identität und den Schlüssel zur Verschlüsselung des Wiederherstellungsservers auswählen. Angenommen, die flexible Serverinstanz von Azure Database for MySQL ist mit einem georedundanten Backup konfiguriert. In diesem Fall müssen Sie den Wiederherstellungsserver mit der verwalteten Identität und dem Schlüssel konfigurieren, auf die die Identität Zugriff hat und die sich in der geografisch gekoppelten Region des Servers befinden.

Um Probleme bei der Einrichtung von kundenseitig verwalteter Datenverschlüsselung während der Wiederherstellung oder der Lesereplikaterstellung zu vermeiden, sollten Sie unbedingt die folgenden Schritte auf dem Quellserver und den wiederhergestellten Servern bzw. Replikatservern ausführen:

• Starten Sie die Wiederherstellung oder die Erstellung eines Lese-Replikats von der flexible Serverinstanz von Azure Database for MySQL aus.
• Überprüfen Sie auf dem wiederhergestellten Server oder dem Replikatserver erneut den kundenseitig verwalteten Schlüssel in den Einstellungen zur Datenverschlüsselung, um sicherzustellen, dass der benutzerseitig verwalteten Identität die in Key Vault gespeicherten Schlüsselberechtigungen Get, List, Wrap und Unwrap erteilt wurden.

Verwandte Inhalte

• Datenverschlüsselung für Azure Database for MySQL – Flexibler Server mit Azure CLI
• Datenverschlüsselung für Azure Database for MySQL – Flexibler Server mithilfe des Azure-Portals
• Sicherheit der Verschlüsselung im Ruhezustand
• Microsoft Entra-Authentifizierung für Azure Database for MySQL – Flexibler Server