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

Durch die Verwendung der Datenverschlüsselung mit vom Kunden verwalteten Schlüsseln für Azure Database for MySQL können Sie Ihren eigenen Schlüssel (BYOK) zum Schutz ruhender Daten mitbringen, um die Trennung von Aufgaben für die Verwaltung von Schlüsseln und Daten zu implementieren. Wenn Sie vom Kunden verwaltete Schlüssel (CMKs) verwenden, steuern Sie Folgendes:

  • Verwaltung des Schlüssellebenszyklus, einschließlich Schlüsselerstellung, des Hochladens, der Schlüsselrotation und der Löschung
  • Schlüsselverwendungsberechtigungen
  • Prüfung von Vorgängen auf Schlüsseln

Vorteile von vom Kunden verwalteten Schlüsseln (CMK)

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

  • Sie steuern den Datenzugriff vollständig, indem Sie den Schlüssel entfernen und die Datenbank unzugänglich machen.
  • Sie haben die vollständige Kontrolle über den Lebenszyklus des Schlüssels, einschließlich der Schlüsselrotation, um ihn an die Unternehmensrichtlinien anzupassen.
  • Sie können Schlüssel zentral in Azure Key Vault oder verwaltetem HSM verwalten und organisieren.
  • Sie können die Trennung von Aufgaben zwischen Sicherheitsbeauftragten, DBA und Systemadministratoren implementieren.

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

Verwaltete Identitäten in Microsoft Entra ID bieten eine sicherere Möglichkeit, Clients bei Diensten zu authentifizieren. CMK-Verschlüsselung verwendet die verwaltete Identität des Azure-Datenbankservers für MySQL, um eine Verbindung zu dem Azure Key Vault herzustellen, in dem die CMK gespeichert wird. Azure Database for MySQL unterstützt derzeit nur vom Benutzer zugewiesene verwaltete Identität (UAMI) für den Zugriff auf die Key Vault. Weitere Informationen finden Sie unter verwaltete Identitätstypen in Azure.

Um den CMK für einen Server von Azure Database for MySQL zu konfigurieren, verknüpfen Sie die UAMI mit dem Server und geben den zu verwendenden Azure Key Vault sowie den zu verwendenden Schlüssel an.

Die UAMI benötigt die folgenden Zugriffsrechte auf den Key Vault:

  • Get: zum Abrufen des öffentlichen Teils und der Eigenschaften des Schlüssels im Schlüsseltresor.
  • Liste: So listen Sie die Versionen des Schlüssels auf, der in einem Key Vault gespeichert ist.
  • Umbruchschlüssel: So verschlüsseln Sie die DEK. Der verschlüsselte DEK wird in Azure Database for MySQL – Flexible Server gespeichert.
  • Entschlüsselungsschlüssel: Zum Entschlüsseln der DEK. Azure Database for MySQL benötigt die entschlüsselte DEK, um die Daten zu verschlüsseln oder zu entschlüsseln.

Wenn Azure RBAC aktiviert ist, weisen Sie der UAMI Anstelle des individuellen Zugriffs Rollen zu.

  • 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

Legen Sie die Datenverschlüsselung mit CMKs auf Serverebene fest. Verwenden Sie für einen bestimmten Server einen CMK, der als Schlüsselverschlüsselungsschlüssel (KEK) bezeichnet wird, um den Datenverschlüsselungsschlüssel (DEK) des Diensts 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 ermöglicht keinen direkten Zugriff auf einen gespeicherten Schlüssel, sondern stellt Verschlüsselungs- und Entschlüsselungsdienste mithilfe des Schlüssels für autorisierte Entitäten bereit. Der Schlüsseltresor kann den Schlüssel generieren oder ihn von einem lokalen HSM-Gerät in den Schlüsseltresor übertragen.

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.

Diagramm der Funktionsweise der Datenverschlüsselung mit einem kundenseitig verwalteten Schlüssel.

Nachdem Sie die Protokollierung aktiviert haben, können Auditoren Azure Monitor verwenden, um Key Vault Überwachungsereignisprotokolle zu überprüfen. Informationen zum Aktivieren der Protokollierung von Key Vault-Überwachungsereignissen finden Sie unter „Überwachen des Schlüsseltresordiensts mit Key Vault-Erkenntnissen“.

Note

Es kann bis zu 10 Minuten dauern, bis sich die Berechtigungsänderungen auf den Schlüsseltresor auswirken.

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. Sie müssen die Datenverschlüsselung neu konfigurieren, wenn Sie Key Vault Ressourcen verschieben, nachdem Sie die Konfiguration ausgeführt haben.
  • 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 " im Schlüsseltresor.
  • Aktivieren Sie den Löschschutz.
  • Legen Sie den Aufbewahrungszeitraum auf 90 Tage fest.
    • Den Aktionen „Wiederherstellen“ und „Endgültig löschen“ sind über Key Vault-Zugriffsrichtlinien eigene Berechtigungen zugewiesen.
    • Das Feature "Vorläufiges Löschen" ist standardmäßig deaktiviert.

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

  • Der vom Kunden verwaltete Schlüssel zum Verschlüsseln des DEK kann nur asymmetrisch sein, RSA\RSA-HSM(Vaults with Premium SKU) 2048, 3072 oder 4096.
  • 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. Diese Einstellung legt implizit das erforderliche Schlüsselattribute recoveryLevel auf Recoverable.
  • 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.

Note

Ausführliche, schrittweise Anleitungen zum Konfigurieren der Datenverschlüsselung finden Sie unter Datenverschlüsselung für Azure-Datenbank für MySQL mit dem Azure-Portal oder datenverschlüsselung für Azure Database for MySQL – Flexible Server mit Azure CLI.

Empfehlungen zum Konfigurieren der Datenverschlüsselung

Wenn Sie Key Vault oder verwaltete HSM für die Verwendung der Datenverschlüsselung mit einem vom Kunden verwalteten Schlüssel konfigurieren, sollten Sie die folgenden Empfehlungen berücksichtigen:

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

Note

Der verwendete Schlüsseltresor muss sich aus derselben Region wie der Datenbankserver befinden.

Kein Zugriff auf die Bedingung des kundenseitig verwalteten Schlüssels

Wenn Sie die Datenverschlüsselung mit einem CMK in Key Vault konfigurieren, benötigt der Server kontinuierlichen Zugriff auf diesen Schlüssel, um online zu bleiben. 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 Flexible Server nicht auf den Schlüssel zugreifen und wechselt in den Zustand Inaccessible. So erstellen Sie die Serverinstanz Available:

  • Stellen Sie den Key Vault wieder her.
  • Aktualisieren sie die Datenverschlüsselung.

Wenn Sie den Schlüssel aus dem Key Vault löschen, kann die Instanz von Azure Database for MySQL Flexible Server nicht mehr auf den Schlüssel zugreifen und wechselt in den Status Inaccessible. So erstellen Sie die Serverinstanz Available:

  • Stellen Sie den Schlüssel wieder her.
  • Aktualisieren sie die Datenverschlüsselung.

Note

Auch wenn der Schlüssel abläuft, bleibt der Server entwurfsweise zugänglich, um Ausfallzeiten zu vermeiden.

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

Jemand mit ausreichenden Zugriffsrechten für Key Vault kann versehentlich den flexiblen Serverzugriff auf den Schlüssel deaktivieren, indem:

  • 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 Datenbankstatus zu überwachen und warnungen für den Verlust des transparenten Zugriffs auf die Datenverschlüsselungsschutzkomponente zu aktivieren:

  • Aktivitätsprotokoll: Wenn der Zugriff auf den Kundenschlüssel im kundenseitig verwalteten Schlüsseltresor nicht möglich ist, 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

Wenn Sie eine Azure Database for MySQL flexible Serverinstanz mit dem verwalteten Schlüssel eines Kunden verschlüsseln, der in Key Vault gespeichert ist, wird auch jede neu erstellte Kopie des Servers verschlüsselt. Wenn Sie versuchen, eine Azure Database for MySQL flexible Serverinstanz mit einem vom Kunden verwalteten Schlüssel zu verschlüsseln, der bereits über ein Replikat verfügt, konfigurieren Sie ein oder mehrere Replikate, indem Sie die verwaltete Identität und den verwalteten Schlüssel hinzufügen. Wenn Sie die Instanz von Azure Database for MySQL – Flexible Server mit georedundanter Sicherung konfigurieren, müssen Sie das Replikat mit der verwalteten Identität und dem Schlüssel konfigurieren, auf den die Identität Zugriff hat und der sich in der gepaarten Region des Servers befindet.

Wiederherstellen mit einem kundenseitig verwalteten Schlüssel in Key Vault

Wenn Sie eine Azure Database for MySQL flexible Serverinstanz wiederherstellen, wählen Sie die vom Benutzer verwaltete Identität und den Schlüssel aus, um den Wiederherstellungsserver zu verschlüsseln. Wenn die Instanz von Azure Database for MySQL – Flexible Server mit einer georedundanten Sicherung konfiguriert ist, müssen Sie den Wiederherstellungsserver mit der verwalteten Identität und dem Schlüssel konfigurieren, auf den diese Identität Zugriff hat und der sich in der gepaarten Region des Servers befindet.

Führen Sie während der Wiederherstellung oder beim Erstellen eines Lesereplikats die folgenden Schritte auf den Quell-, Wiederherstellungs- oder Replikatservern aus:

  • Starten Sie die Wiederherstellung oder die Erstellung eines Lese-Replikats von der flexible Serverinstanz von Azure Database for MySQL aus.
  • Aktualisieren Sie auf dem wiederhergestellten oder Replikatserver die CMK in den Datenverschlüsselungseinstellungen, um die UAMI-Berechtigungen für den Schlüssel zu überprüfen.

Note

Sie müssen nicht dieselbe Identität (UAMI) und denselben Schlüssel wie auf dem Quellserver verwenden, wenn Sie eine Wiederherstellung durchführen.

Verwandte Inhalte

  • Last updated on