Datenverschlüsselung mit kundenseitig verwalteten Schlüsseln für Azure Database for MySQL – Flexibler Server

Mithilfe der Datenverschlüsselung mit kundenseitig verwalteten Schlüsseln für Azure Database for MySQL – Flexibler Server können Sie Ihren eigenen Schlüssel (Bring Your Own Key, BYOK) zum Schutz von ruhenden Daten verwenden und die Trennung von Aufgaben für die Verwaltung von Schlüsseln und Daten implementieren. Bei vom Kunden verwalteten Schlüsseln (CMKs) ist 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 – Flexibler Server 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 Systemadministratoren

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 Database for MySQL – Flexibler Server unterstützt derzeit nur die benutzerseitig zugewiesene verwaltete Identität (User-assigned Managed Identity, UMI). Weitere Informationen finden Sie unter verwaltete Identitätstypen in Azure.

Zum Konfigurieren des CMK für eine Instanz von Azure Database for MySQL – Flexibler Server 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 der Instanz von Azure Database for MySQL – Flexibler Server gespeichert.
• Unwrap Key: zum Entschlüsseln des DEK. Azure Database for MySQL – Flexibler Server benötigt den entschlüsselten DEK zum Verschlüsseln/Entschlüsseln der Daten.

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

• Key Vault Crypto Service Encryption-Benutzer 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-Benutzer“
• Weisen Sie für ein verwaltetes HSM die Rolle Benutzer 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. Entsprechend sendet der flexible Server bei Bedarf den geschützten DEK zur Entschlüsselung an den Schlüsseltresor.

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 zum Konfigurieren der Datenverschlüsselung für Azure Database for MySQL – Flexibler Server

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 Instanz von Azure Database for MySQL – Flexibler Server müssen zum selben Microsoft Entra-Mandanten 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 Instanz von Azure Database for MySQL – Flexibler Server müssen sich in derselben Region befinden.
• Aktivieren Sie die Funktion Vorläufiges Löschen für die Key Vault-Instanz mit einem Aufbewahrungszeitraum von 90 Tagen, um Schutz vor Datenverlust zu bieten, falls ein Schlüssel (oder Key Vault) versehentlich gelöscht wird. Den Aktionen „Wiederherstellen“ und „Endgültig löschen“ sind über Key Vault-Zugriffsrichtlinien eigene Berechtigungen zugewiesen. Die Funktion zum vorläufigen Löschen ist standardmäßig deaktiviert. Sie können sie jedoch ü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 den Schlüsseltresor importieren, müssen Sie ihn in einem unterstützten Dateiformat (.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 den kundenseitig verwalteten Schlüssel

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 Instanz von Azure Database for MySQL – Flexibler Server nicht mehr auf den Schlüssel zugreifen und wechselt in den Zustand Kein Zugriff. Stellen Sie den Schlüsseltresor wieder her, und validieren Sie die Datenverschlüsselung erneut, um die Instanz von Azure Database for MySQL – Flexibler Server verfügbar zu machen.
• Wenn Sie den Schlüssel aus dem Schlüsseltresor löschen, kann Azure Database for MySQL – Flexibler Server nicht auf den Schlüssel zugreifen und wechselt in den Zustand Kein Zugriff. Stellen Sie den Schlüssel wieder her, und validieren Sie die Datenverschlüsselung erneut, um die Instanz von Azure Database for MySQL – Flexibler Server verfügbar zu machen.
• Wenn der in Azure Key Vault gespeicherte Schlüssel abläuft, wird der Schlüssel ungültig, und die Instanz von Azure Database for MySQL – Flexibler Server geht in den Zustand Kein Zugriff über. Erweitern Sie das Schlüsselablaufdatum mithilfe der CLI, und validieren Sie dann die Datenverschlüsselung erneut, um die Instanz von Azure Database for MySQL – Flexibler Server verfügbar zu machen.

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

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

• Widerrufen der Berechtigungen get, list, wrap key und unwrap 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 vom Benutzer verwalteten Identität mit einem vom Kunden 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 Kunden verwalteten Schlüssel in Key Vault

Sobald eine Instanz von Azure Database for MySQL – Flexibler Server mit dem im Key Vault gespeicherten verwalteten Schlüssel eines Kunden verschlüsselt ist, wird jede neu erstellte Kopie des Servers ebenfalls verschlüsselt. Wenn Sie versuchen, eine Instanz von Azure Database for MySQL – Flexibler Server mit einem kundenseitig verwalteten Schlüssel zu verschlüsseln, die bereits über ein oder mehrere Replikate verfügt, empfehlen wir, die Replikate zu konfigurieren, indem die verwaltete Identität und der Schlüssel hinzugefügt werden. Angenommen, die Instanz von Azure Database for MySQL – Flexibler Server 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 vom Kunden verwalteten Schlüssel in Key Vault

Wenn Sie versuchen, eine Instanz von Azure Database for MySQL – Flexibler Server wiederherzustellen, können Sie die benutzerseitig verwaltete Identität und den Schlüssel zur Verschlüsselung des Wiederherstellungsservers auswählen. Angenommen, die Instanz von Azure Database for MySQL – Flexibler Server 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 den Prozess der Wiederherstellung oder der Erstellung eines Lesereplikats von der Instanz von Azure Database for MySQL – Flexibler Server 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 vom Benutzer verwalteten Identität die in Key Vault gespeicherten Schlüsselberechtigungen Get, List, Wrap und Unwrap erteilt wurden.

Zugehöriger Inhalt

• Datenverschlüsselung für Azure Database for MySQL – Flexibler Server mithilfe der 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