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

  • Artikel

GILT FÜR: Azure Database for MySQL – Flexible Server

Mithilfe der Datenverschlüsselung mit kundenseitig verwalteten Schlüsseln für Azure Database for MySQL – Flexible Server können Sie Ihren eigenen Schlüssel (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 – Flexible 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
  • 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 – Flexible Server unterstützt derzeit nur die vom Benutzer 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 Azure Database for MySQL – Flexibler Server-Instanz 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. Azure Database for MySQL – Flexible Server benötigt den entschlüsselten DEK zum Verschlüsseln/Entschlüsseln der Daten.

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.

Diagram of how data encryption with a customer-managed key work.

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

Hinweis

Es kann bis zu 10 Minuten dauern, bis sich die Berechtigungsänderungen auf den Schlüsseltresor auswirken. 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 Datenverschlüsselung für Azure Database for MySQL – Flexible Server

Bevor Sie versuchen, Key Vault zu konfigurieren, achten Sie darauf, 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 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 die erforderliche Schlüsselattribut-Wiederherstellungsebene implizit festgelegt: „Wiederherstellbar“.
  • 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.

Hinweis

Ausführliche, schrittweise Anleitungen zum Konfigurieren der Datenverschlüsselung für einen Azure Database for MySQL – Flexibler Server über das Azure-Portal finden Sie unter Konfigurieren der Datenverschlüsselung für MySQL – Flexibler Server.

Empfehlungen zum Konfigurieren der Datenverschlüsselung

Wenn Sie Key Vault 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.

Hinweis

  • Es wird empfohlen, einen Schlüsseltresor aus derselben Region zu verwenden. Bei Bedarf können Sie jedoch auch einen Schlüsseltresor aus einer anderen Region verwenden, indem Sie unter „Schlüsselbezeichner eingeben“ die entsprechenden Informationen angeben.
  • Der RSA-Schlüssel, der in Azure Key Vault Managed HSMgespeichert ist, wird derzeit nicht unterstützt.

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 flexible Serverinstanz von Azure Database for MySQL nicht mehr auf den Schlüssel zugreifen und wechselt in den Zustand Kein Zugriff. Stellen Sie den Schlüsseltresor wieder her, und aktualisieren Sie die Datenverschlüsselung, um die Azure-Datenbank für mySQL flexible Serverinstanz verfügbarzu machen.
  • Wenn Sie den Schlüssel aus der Key Vault-Instanz löschen, kann Azure Database for MySQL – Flexible Server nicht auf den Schlüssel zugreifen und wechselt daher in den Zustand Kein Zugriff. Stellen Sie den Schlüssel wieder her, und aktualisieren Sie die Datenverschlüsselung, um die Azure-Datenbank für mySQL flexible Serverinstanz verfügbarzu machen.
  • Wenn der in Azure Key Vault gespeicherte Schlüssel abläuft, wird der Schlüssel ungültig und die flexible Serverinstanz von Azure Database for MySQL geht in den Zustand Kein Zugriff über. Erweitern Sie das Schlüsselablaufdatum mithilfe der CLI , und aktualisieren Sie dann die Datenverschlüsselung, um die Azure-Datenbank für mySQL flexible Serverinstanz verfügbarzu 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 flexible Serverinstanz von Azure Database for MySQL 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 flexible Serverinstanz von Azure Database for MySQL mit einem vom Kunden verwalteten Schlüssel zu verschlüsseln, der bereits über ein oder mehrere Replikate verfügt, empfehlen wir, die Replikate zu konfigurieren, indem Sie die verwaltete Identität und den Schlüssel hinzufügen. 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 vom Kunden verwalteten Schlüssel in Key Vault

Wenn Sie versuchen, eine flexible Serverinstanz von Azure Database for MySQL wiederherzustellen, können Sie die vom Benutzer 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 Azure Database for MySQL flexible Serverinstanz 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.

Hinweis

Die Verwendung derselben Identität und desselben Schlüssels wie auf dem Quellserver ist bei der Durchführung einer Wiederherstellung nicht obligatorisch.

Nächste Schritte