Freigeben über

Datenverschlüsselung

  • Artikel

GILT FÜR: Azure Database for PostgreSQL – Flexibler Server

Alle Daten, die von einer Instanz von Azure Database for PostgreSQL – Flexibler Server verwaltet werden, werden immer im Ruhezustand verschlüsselt. Diese Daten umfassen alle System- und Benutzerdatenbanken, temporären Dateien, Serverprotokolle, Write-Ahead-Protokollsegmente und Sicherungen.

Um die Verschlüsselung Ihrer Daten zu erreichen, verwendet Azure Database for PostgreSQL – Flexibler Server die Azure Storage-Verschlüsselung für ruhende Daten und stellt Schlüssel zum Verschlüsseln und Entschlüsseln von Daten in Blob Storage- und Azure Files-Diensten bereit. Diese Schlüssel müssen im Azure Key Vault oder einem mit dem Azure Key Vault verwalteten Hardwaresicherheitsmodul (HSM) gespeichert werden. Weitere Informationen finden Sie unter Kundenseitig verwaltete Schlüssel für die Azure Storage-Verschlüsselung.

Azure-Datenbank for PostgreSQL – Flexibler Server unterstützt die Konfiguration der Datenverschlüsselung in zwei verschiedenen Modi: dienstseitig verwaltete Schlüssel und kundenseitig verwaltete Schlüssel. Der Konfigurationsmodus kann nur zum Zeitpunkt der Servererstellung ausgewählt werden. Während der gesamten Lebensdauer des Servers kann dieser nicht von einem Modus in einen anderen geändert werden.

Bei dienstseitig verwalteten Verschlüsselungsschlüsseln verwaltet Azure Database for PostgreSQL – Flexibler Server die Bereitstellung der Azure Key Vault-Instanz, in der die Schlüssel aufbewahrt werden, und übernimmt die gesamte Verantwortung bei der Bereitstellung des Schlüssels, mit dem Daten verschlüsselt und entschlüsselt werden. Der Dienst kümmert sich auch um das Speichern, Schützen, Überwachen des Zugriffs, Konfigurieren von Netzwerken und automatisches Rotieren des Schlüssels.

Bei kundenseitig verwalteten Verschlüsselungsschlüsseln übernehmen Sie die Verantwortung. Daher müssen Sie Ihre eigene Azure Key Vault-Instanz oder ein eigenes Azure Key Vault-HSM bereitstellen. Sie müssen Ihren eigenen Schlüssel generieren oder importieren. Sie müssen erforderliche Berechtigungen für den Key Vault erteilen, damit Ihre Instanz von Azure Database for PostgreSQL – Flexibler Server die erforderlichen Aktionen für den Schlüssel ausführen kann. Sie müssen sich um die Konfiguration aller Netzwerkaspekte der Azure Key Vault-Instanz kümmern, in der der Schlüssel aufbewahrt wird, damit Ihre Instanz von Azure Database for PostgreSQL – Flexibler Server auf den Schlüssel zugreifen kann. Auch die Überwachung des Zugriffs auf den Schlüssel liegt in Ihrer Verantwortung. Schlussendlich sind Sie für die Rotation des Schlüssels verantwortlich. Bei Bedarf müssen Sie die Konfiguration Ihrer Instanz von Azure Database for PostgreSQL – Flexibler Server aktualisieren, damit sie auf die rotierte Version des Schlüssels verweist.

Wenn Sie kundenseitig verwaltete Schlüssel für ein Speicherkonto konfigurieren, umschließt Azure Storage den Stammdaten-Verschlüsselungsschlüssel (Data Encryption Key, DEK) für das Konto im zugeordneten Schlüsseltresor oder im verwalteten HSM mit dem kundenseitig verwalteten Schlüssel. Der Schutz des Stammverschlüsselungsschlüssels ändert sich, aber die Daten in Ihrem Azure Storage-Konto bleiben jederzeit verschlüsselt. Es sind keine zusätzlichen Maßnahmen Ihrerseits erforderlich, um sicherzustellen, dass Ihre Daten verschlüsselt bleiben. Der Schutz durch kundenseitig verwaltete Schlüssel wird sofort wirksam.

Der Azure Key Vault ist ein cloudbasiertes, externes Schlüsselverwaltungssystem. Es ist hochverfügbar und bietet eine skalierbare, sichere Speicherung für kryptografische RSA-Schlüssel, die optional durch FIPS 140-validierte Hardware-Sicherheitsmodule (HSMs) unterstützt werden. Dabei wird kein direkter Zugriff auf einen gespeicherten Schlüssel zugelassen, sondern Verschlüsselungs- und Entschlüsselungsdienste werden für die autorisierten Entitäten bereitgestellt. Key Vault kann den Schlüssel generieren, importieren oder von einem lokalen HSM-Gerät durch Übertragung empfangen.

Vorteile der jeweiligen Modi

Die Datenverschlüsselung mit dienstseitig verwalteten Schlüsseln für „Azure Database for PostgreSQL – Flexibler Server“ bietet die folgenden Vorteile:

  • Der Dienst steuert den Datenzugriff vollständig und automatisch.
  • Der Dienst steuert den Lebenszyklus des Schlüssels vollständig und automatisch (einschließlich der Rotation des Schlüssels).
  • Sie müssen sich keine Gedanken über das Verwalten von Datenverschlüsselungsschlüsseln machen.
  • Die Datenverschlüsselung, die auf dienstseitig verwalteten Schlüsseln basiert, wirkt sich nicht negativ auf die Leistung Ihrer Workloads aus.
  • Sie vereinfacht die Verwaltung von Verschlüsselungsschlüsseln (einschließlich ihrer regelmäßigen Rotation) und die Verwaltung der Identitäten, die für den Zugriff auf diese Schlüssel verwendet werden.

Die Datenverschlüsselung mit kundenseitig verwalteten Schlüsseln für „Azure Database for PostgreSQL – Flexibler Server“ bietet die folgenden Vorteile:

  • Sie steuern den Datenzugriff vollständig. Sie können einen Schlüssel entfernen, damit auf eine Datenbank nicht zugegriffen werden kann.
  • Sie steuern den Lebenszyklus eines Schlüssels vollständig (einschließlich der Rotation des Schlüssels), um die Unternehmensrichtlinien einzuhalten.
  • Sie können alle Verschlüsselungsschlüssel zentral in Ihren eigenen Instanzen des Azure Key Vault verwalten und organisieren.
  • Die Datenverschlüsselung, die auf kundenseitig verwalteten Schlüsseln basiert, wirkt sich nicht negativ auf die Leistung Ihrer Workloads aus.
  • Sie können die Verantwortungsbereiche von Sicherheitsbeauftragten, Datenbankadministratoren und Systemadministratoren trennen.

Anforderungen

Nachfolgend finden Sie die Liste der Anforderungen zum Konfigurieren der Datenverschlüsselung für „Azure Database for PostgreSQL – Flexibler Server“:

  • Key Vault und der Azure Database for PostgreSQL Flexible Server müssen demselben Microsoft Entra-Mandanten angehören. Mandantenübergreifende Interaktionen zwischen Key Vault und dem Server werden nicht unterstützt. Wenn Sie die Key Vault-Ressourcen später verschieben möchten, müssen Sie die Datenverschlüsselung neu konfigurieren.
  • Es wird empfohlen, die Konfiguration der Aufbewahrungsdauer für gelöschte Tresore in Tagen für Key Vault auf 90 Tage festzulegen. Wenn Sie eine vorhandene Key Vault-Instanz mit einer niedrigeren Zahl konfiguriert haben, sollte sie weiterhin gültig sein. Wenn Sie diese Einstellung jedoch ändern und den Wert erhöhen möchten, müssen Sie eine neue Key Vault-Instanz erstellen. Nachdem eine Instanz erstellt wurde, ist es nicht möglich, diese Einstellung zu ändern.
  • Aktivieren Sie das Feature zum vorläufigen Löschen in Key Vault, um sich vor Datenverlust zu schützen, wenn ein Schlüssel oder eine Key Vault-Instanz versehentlich gelöscht wird. Vorläufig gelöschte Ressourcen werden von Key Vault 90 Tage lang aufbewahrt, sofern sie der Benutzer nicht in der Zwischenzeit wiederherstellt oder bereinigt. Die Wiederherstellungs- und Bereinigungsaktionen weisen eigene Berechtigungen auf, die einer Key Vault-Instanz, einer RBAC-Rolle oder einer Zugriffsrichtlinienberechtigung zugewiesen sind. Das Feature für vorläufiges Löschen ist standardmäßig aktiviert. Wenn Sie über eine Key Vault-Instanz verfügen, die vor langer Zeit bereitgestellt wurde, ist die Funktion für vorläufiges Löschen möglicherweise weiterhin deaktiviert. In diesem Fall können Sie sie mithilfe der Azure CLI aktivieren.
  • Aktivieren Sie den Löschschutz, um einen obligatorischen Aufbewahrungszeitraum für gelöschte Tresore und Tresorobjekte zu erzwingen.
  • Gewähren Sie der benutzerseitig zugewiesenen verwalteten Identität für Azure Database for PostgreSQL – Flexibler Server Zugriff auf den Schlüssel, indem Sie einen der folgenden Schritte ausführen:
    • Bevorzugt: Der Azure Key Vault sollte mit dem RBAC-Berechtigungsmodell konfiguriert werden, und der verwalteten Identität sollte die Benutzerrolle Kryptografiedienstsverschlüsselung für Schlüsseltresore zugewiesen werden.
    • Legacymethode: Wenn der Azure Key Vault mit dem Zugriffsrichtlinien-Berechtigungsmodell konfiguriert ist, gewähren Sie der verwalteten Identität die folgenden Berechtigungen:
      • get: Abrufen der Eigenschaften und des öffentlichen Teils des Schlüssels in Key Vault
      • list:: Auflisten und Durchlaufen der in Key Vault gespeicherten Schlüssel
      • wrapKey: Verschlüsseln des Datenverschlüsselungsschlüssels
      • unwrapKey: Entschlüsseln des Datenverschlüsselungsschlüssels
  • Der Schlüssel, der zum Verschlüsseln des Datenverschlüsselungsschlüssels verwendet wird, kann nur ein asymmetrischer Schlüssel, ein RSA-Schlüssel oder ein RSA-HSM sein. Schlüsselgrößen von 2.048, 3.072 und 4.096 werden unterstützt. Für mehr Sicherheit wird die Verwendung eines 4.096-Bit-Schlüssels empfohlen.
  • Das Datum und die Uhrzeit für die Schlüsselaktivierung (sofern festgelegt) müssen in der Vergangenheit liegen. Das Datum und die Uhrzeit für den Ablauf (sofern festgelegt) müssen in der Zukunft liegen.
  • Der Schlüssel muss den Status Aktiviert aufweisen.
  • Wenn Sie einen vorhandenen Schlüssel in Key Vault importieren, müssen Sie ihn in einem der unterstützten Dateiformate (.pfx, .byok oder .backup) bereitstellen.

Empfehlungen

Wenn Sie einen kundenseitig verwalteten Schlüssel für die Datenverschlüsselung verwenden, befolgen Sie diese Empfehlungen zum Konfigurieren von Key Vault:

  • Um ein versehentliches oder nicht autorisiertes Löschen dieser kritischen Ressource zu verhindern, legen Sie eine Ressourcensperre für Key Vault fest.
  • 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. Azure Monitor Logs ist ein Beispiel für einen Dienst, der bereits integriert ist.
  • Sperren Sie Key Vault, indem Sie den öffentlichen Zugriff deaktivieren und vertrauenswürdige Microsoft-Dienste zulassen, um diese Firewall zu umgehen.

Hinweis

Nachdem Sie den öffentlichen Zugriff deaktiviert und vertrauenswürdige Microsoft-Dienste zum Umgehen dieser Firewall zugelassen haben, wird möglicherweise die folgende Fehlermeldung angezeigt, wenn Sie versuchen, den öffentlichen Zugriff zum Verwalten von Key Vault über das Portal zu verwenden: „Sie haben die Netzwerkzugriffskontrolle aktiviert. Nur zulässige Netzwerke haben Zugriff auf diesen Schlüsseltresor.“ Dieser Fehler schließt nicht aus, dass während des Setups für kundenseitig verwaltete Schlüssel andere Schlüssel bereitgestellt werden oder dass während Servervorgängen Schlüssel aus Key Vault gefetcht werden.

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

Besondere Überlegungen

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

Durch eine der folgenden Aktionen könnten Benutzende mit ausreichenden Zugriffsrechten für Key Vault den Serverzugriff auf den Schlüssel deaktivieren:

  • Aufheben der Zuweisung der RBAC-Benutzerrolle Kryptografiedienstsverschlüsselung für Schlüsseltresore oder Widerrufen der Berechtigungen der Identität, die zum Abrufen des Schlüssels in Key Vault verwendet wird
  • Löschen des Schlüssels.
  • Löschen der Key Vault-Instanz.
  • Ändern der Firewallregeln des Key Vault.
  • Löschen der verwalteten Identität des Servers in Microsoft Entra ID

Überwachen der im Azure Key Vault gespeicherten Schlüssel

Konfigurieren Sie die folgenden Azure-Features, um den Datenbankstatus zu überwachen und Warnungen bei Zugriffsverlust auf die Datenverschlüsselungs-Schutzvorrichtung zu aktivieren:

  • Ressourcenintegrität: Eine Datenbank, die den Zugriff auf den CMK verloren hat, wird als Zugriff nicht möglich angezeigt, nachdem die erste Verbindung mit der Datenbank verweigert wurde.
  • Aktivitätsprotokoll: Ist der Zugriff auf den CMK in der vom Kunden verwalteten Key Vault-Instanz 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 erhalten.

Wiederherstellen von Sicherungen eines Servers, der mit einem kundenseitig verwalteten Schlüssel konfiguriert ist

Sobald „Azure Database for PostgreSQL – Flexibler Server“ mit einem kundenseitig verwalteten Schlüssel verschlüsselt wurde, der in Key Vault gespeichert ist, werden auch alle neu erstellten Serverexemplare verschlüsselt. Sie können diese neue Kopie über einen PITR-Vorgang (Point-in-Time Restore) oder Lesereplikate erstellen.

Wenn Sie die Datenverschlüsselung mit kundenseitig verwalteten Schlüsseln einrichten, können Sie während Vorgängen wie der Wiederherstellung einer Sicherung oder der Erstellung eines Lesereplikats Probleme vermeiden, indem Sie die folgenden Schritte auf dem primären Server bzw. auf dem wiederhergestellten Server oder Replikatserver ausführen:

  • Initiieren Sie den Wiederherstellungsvorgang oder den Prozess der Erstellung eines Lesereplikats aus der primären Azure Database for PostgreSQL – Flexible Serverinstanz.
  • Auf dem wiederhergestellten Server oder Replikatserver können Sie den kundenseitig verwalteten Schlüssel und die benutzerseitig zugewiesene verwaltete Identität ändern, die für den Zugriff auf Key Vault verwendet wird. Stellen Sie sicher, dass die auf dem neu erstellten Server zugewiesene Identität über die erforderlichen Berechtigungen für Key Vault verfügt.
  • Widerrufen Sie den ursprünglichen Schlüssel nach der Wiederherstellung nicht. Derzeit wird die Schlüsselsperrung nach dem Wiederherstellen eines Servers mit einem benutzerseitig verwalteten Schlüssel auf einem anderen Server nicht unterstützt.

Verwaltete HSMs

Hardwaresicherheitsmodule (HSMs) sind manipulationssichere Hardwaregeräte, die helfen kryptografische Prozesse abzusichern, indem sie Schlüssel für die Ver- und Entschlüsselung von Daten, die Erstellung digitaler Signaturen und Zertifikate erzeugen, schützen und verwalten. HSMs werden nach den höchsten Sicherheitsstandards getestet, validiert und zertifiziert, darunter FIPS 140 und Common Criteria.

Azure Key Vault Managed HSM ist ein vollständig verwalteter, hochverfügbarer, einzelmandantenfähiger, standardkonformer Clouddienst. Sie können ihn verwenden, um kryptografische Schlüssel für Ihre Cloudanwendungen über FIPS 140-3 validierte HSMs zu schützen.

Wenn Sie mit dem kundenseitig verwalteten Schlüssel im Azure-Portal neue Instanzen von Azure Database for PostgreSQL – Flexibler Server erstellen, können Sie Über Azure Key Vault verwaltetes HSM als Schlüsselspeicher auswählen (als Alternative zum Azure Key Vault). Die Voraussetzungen in Bezug auf die benutzerdefinierte Identität und die Berechtigungen sind die gleichen wie bei Azure Key Vault (wie bereits weiter vorne in diesem Artikel aufgeführt). Weitere Informationen zum Erstellen einer Managed HSM-Instanz, zu den Vorteilen und Unterschieden eines freigegebenen Schlüsseltresor-basierten Zertifikatspeichers und zum Importieren von Schlüsseln in Managed HSM finden Sie unter Was ist Azure Key Vault Managed HSM?.

Kein Zugriff auf den kundenseitig verwalteten Schlüssel

Wenn Sie die Datenverschlüsselung mit einem kundenseitig verwalteten Schlüssel konfigurieren, der in Key Vault gespeichert ist, wird fortlaufender Zugriff auf diesen Schlüssel benötigt, damit der Server online bleiben kann. Wenn dies nicht der Fall ist, ändert der Server seinen Status in Kein Zugriff. Der Server beginnt dann, alle Verbindungen zu verweigern.

Dies sind einige der möglichen Gründe, warum der Serverstatus in Kein Zugriff geändert wurde:

Ursache Lösung
Für jeden der vom Server angegebenen Verschlüsselungsschlüssel sind ein Ablaufdatum und eine Ablaufuhrzeit konfiguriert, und dieses Datum und diese Uhrzeit wurden erreicht. Sie müssen das Ablaufdatum des Schlüssels verlängern. Anschließend müssen Sie warten, bis der Dienst den Schlüssel erneut überprüft und den Serverstatus automatisch auf Bereit umstellt. Erst wenn sich der Server wieder im Status Bereit befindet, können Sie den Schlüssel zu einer neueren Version rotieren oder einen neuen Schlüssel erstellen und den Server so aktualisieren, dass er sich auf diese neue Version desselben Schlüssels oder auf den neuen Schlüssel bezieht.
Sie rotieren den Schlüssel und vergessen, die Instanz von „Azure Database for PostgreSQL – Flexibler Server“ zu aktualisieren, damit sie auf die neue Version des Schlüssels verweist. Der alte Schlüssel, auf den der Server verweist, läuft ab, wodurch der Serverstatus in Kein Zugriff geändert wird. Um diese Situation zu vermeiden, stellen Sie bei jedem Rotieren des Schlüssels sicher, dass Sie auch die Instanz des Servers so aktualisieren, dass sie auf die neue Version verweist. Dazu können Sie az postgres flexible-server update verwenden, wie im Beispiel Schlüssel/Identität für die Datenverschlüsselung ändern. Die Datenverschlüsselung kann nach der Servererstellung nicht aktiviert werden. Dadurch wird nur der Schlüssel bzw. die Identität aktualisiert.“ Wenn Sie es vorziehen, für die Aktualisierung die API zu verwenden, können Sie den Endpunkt Server – Update des Diensts aufrufen.
Sie löschen die Key Vault-Instanz, und die Instanz von „Azure Database for PostgreSQL – Flexibler Server“ kann nicht auf den Schlüssel zugreifen. Sie wechselt dann in den Status Kein Zugriff. Stellen Sie die Key Vault-Instanz wieder her, und warten Sie, bis der Dienst den Schlüssel planmäßig neu überprüft und den Serverstatus automatisch in Bereit ändert.
Sie löschen aus Microsoft Entra ID eine verwaltete Identität, die zum Abrufen eines der in Key Vault gespeicherten Verschlüsselungsschlüssel verwendet wird. Stellen Sie die Identität wieder her, und warten Sie, bis der Dienst den Schlüssel planmäßig neu überprüft und den Serverstatus automatisch in Bereit ändert.
Das Key Vault-Berechtigungsmodell ist für die rollenbasierte Zugriffssteuerung konfiguriert. Sie entfernen die RBAC-Rollenzuweisung Benutzer für Key Vault-Kryptodienstverschlüsselung aus den verwalteten Identitäten, die zum Abrufen eines der Schlüssel konfiguriert sind. Weisen Sie der verwalteten Identität die RBAC-Rolle neu zu, und warten Sie, bis der Dienst den Schlüssel planmäßig neu überprüft und den Serverstatus automatisch in Bereit ändert. Ein alternativer Ansatz besteht darin, die Rolle in Key Vault einer anderen verwalteten Identität zuzuweisen und den Server so zu aktualisieren, dass er diese andere verwaltete Identität für den Zugriff auf den Schlüssel verwendet.
Das Key Vault-Berechtigungsmodell ist für Zugriffsrichtlinien konfiguriert. Sie widerrufen die Zugriffsrichtlinien list, get, wrapKey oder unwrapKey der RBAC-Rollenzuweisung Benutzer für Key Vault-Kryptodienstverschlüsselung von den verwalteten Identitäten, die zum Abrufen eines der Schlüssel konfiguriert sind. Weisen Sie der verwalteten Identität die RBAC-Rolle neu zu, und warten Sie, bis der Dienst den Schlüssel planmäßig neu überprüft und den Serverstatus automatisch in Bereit ändert. Ein alternativer Ansatz besteht darin, die erforderlichen Zugriffsrichtlinien für Key Vault einer anderen verwalteten Identität zuzuweisen und den Server so zu aktualisieren, dass er diese andere verwaltete Identität für den Zugriff auf den Schlüssel verwendet.
Sie richten übermäßig restriktive Key Vault-Firewallregeln ein, sodass „Azure Database for PostgreSQL – Flexibler Server“ nicht mit Key Vault kommunizieren kann, um die Schlüssel abzurufen. Stellen Sie beim Konfigurieren einer Key Vault-Firewall sicher, dass Sie die entsprechende Option auswählen, um vertrauenswürdige Microsoft-Dienste zuzulassen, damit Ihre Instanz von „Azure Database for PostgreSQL – Flexibler Server“ die Firewall umgehen kann.

Hinweis

Wenn ein Schlüssel deaktiviert oder gelöscht wurde bzw. abgelaufen oder nicht erreichbar ist, wird ein Server, der Daten über diesen Schlüssel verschlüsselt hat, in den Zustand Kein Zugriff versetzt – wie bereits erwähnt. Der Serverstatus ändert sich erst wieder in Bereit, wenn der Server die Verschlüsselungsschlüssel neu überprüfen kann.

Im Allgemeinen erreicht ein Server den Zustand Zugriff nicht möglich innerhalb von 60 Minuten nach dem Deaktivieren, Löschen, Ablaufen oder nicht Erreichen. Nachdem der Schlüssel verfügbar geworden ist, kann der Server bis zu 60 Minuten benötigen, bis der Status wieder Bereit lautet.

Wiederherstellung nach der Löschung von verwalteten Identitäten

Wenn die benutzerseitig zugewiesene verwaltete Identität, die für den Zugriff auf den in Key Vault gespeicherten Verschlüsselungsschlüssel verwendet wird, in Microsoft Entra ID gelöscht wird, sollten Sie diese Schritte für die Wiederherstellung ausführen:

  1. Stellen Sie die Identität wieder her, oder erstellen Sie eine neue verwaltete Entra ID-Identität.
  2. Wenn Sie eine neue Identität erstellt haben und der Name dieser Identität identisch ist mit dem Namen der gelöschten Identität, aktualisieren Sie die Eigenschaften für Azure Database for PostgreSQL – Flexibler Server, damit die Identität weiß, dass diese neue Identität für den Zugriff auf den Verschlüsselungsschlüssel verwendet werden soll.
  3. Vergewissern Sie sich, dass diese Identität über die richtigen Berechtigungen für Vorgänge auf dem Schlüssel in Azure Key Vault (AKV) verfügt.
  4. Warten Sie etwa eine Stunde, bis der Server den Schlüssel erneut validiert hat.

Wichtig

Das einfache Erstellen einer neuen Entra ID-Identität mit demselben Namen wie die gelöschte Identität kann das Löschen der verwalteten Identität nicht wiederherstellen.

Verwenden der Datenverschlüsselung mit kundenseitig verwalteten Schlüsseln und georedundanten Geschäftskontinuitätsfeatures

„Azure Database for PostgreSQL – Flexibler Server“ unterstützt erweiterte Features für die Datenwiederherstellung, z. B. Replikate und georedundante Sicherungen. Im Folgenden finden Sie die Anforderungen für das Einrichten der Datenverschlüsselung mit CMK und diesen Features, zusätzlich zu den grundlegenden Anforderungen für die Datenverschlüsselung mit CMKs:

  • Der georedundante Sicherungsverschlüsselungsschlüssel muss in einer Key Vault-Instanz erstellt werden, die sich in der Region befindet, in der auch die georedundante Sicherung gespeichert ist.
  • Die REST-API-Version von Azure Resource Manager zur Unterstützung von Servern mit aktivierter georedundanter Sicherung mit CMK ist „2022-11-01-preview“. Wenn Sie Azure Resource Manager-Vorlagen verwenden möchten, um die Erstellung von Servern zu automatisieren, die sowohl Verschlüsselung mit CMKs als auch georedundanten Sicherungsfunktionen verwenden, nutzen Sie diese API-Version.
  • Sie können nicht dieselbe vom Benutzer verwaltete Identität verwenden, um sich für die Key Vault-Instanz der primären Datenbank und die Key Vault-Instanz, die den Verschlüsselungsschlüssel für georedundante Sicherung enthält, zu authentifizieren. Um die regionale Resilienz aufrechtzuerhalten, empfehlen wir, die vom Benutzer verwaltete Identität in derselben Region wie die georedundanten Sicherungen zu erstellen.
  • Wenn Sie eine Lesereplikatdatenbank einrichten, die während der Erstellung mit CMKs verschlüsselt werden soll, muss sich der Verschlüsselungsschlüssel in einer Key Vault-Instanz in der Region befinden, in der sich die Lesereplikatdatenbank befindet. Die benutzerseitig zugewiesene Identität zur Authentifizierung bei dieser Key Vault-Instanz muss in derselben Region erstellt werden.

Einschränkungen

Hier finden Sie die aktuellen Einschränkungen für die Konfiguration des kundenseitig verwalteten Schlüssels in „Azure Database for PostgreSQL – Flexibler Server“:

Zugehöriger Inhalt