Datenverschlüsselung mit einem kundenseitig verwalteten Schlüssel in Azure Database for PostgreSQL – Flexible Server

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

Azure Database for PostgreSQL – Flexible Server verwendet standardmäßig die Azure Storage-Verschlüsselung zur Verschlüsselung von Daten im Ruhezustand mit von Microsoft verwalteten Schlüsseln. Für Benutzer der Azure Database for PostgreSQL – Flexible Server ähnelt es transparenter Datenverschlüsselung in anderen Datenbanken wie SQL Server.

Viele Organisationen benötigen die vollständige Kontrolle über den Zugriff auf die Daten mit einem kundenseitig verwalteten Schlüssel (customer-managed key, CMK). Datenverschlüsselung mit CMKs für Azure Database for PostgreSQL – Flexible Server ermöglicht Ihnen BYOK (Bring Your Own Key) für den Schutz von Daten im Ruhezustand. Sie bietet Organisationen auch eine Möglichkeit der Trennung von Aufgaben bei der Verwaltung von Schlüsseln und Daten. Bei der CMK-Verschlüsselung sind Sie für die Verwaltung des Lebenszyklus von Schlüsseln und der Schlüsselnutzungsberechtigungen sowie für die Überwachung von Vorgängen für Schlüssel verantwortlich, erhalten auf diese Weise aber auch die vollständige Kontrolle.

Datenverschlüsselung mit CMKs für Azure Database for PostgreSQL – Flexible Server wird auf Serverebene festgelegt. Bei einem bestimmten Server wird eine Art von CMK verwendet, die 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. Die KEK und DEK werden weiter unten in diesem Artikel ausführlicher beschrieben.

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üsselung und Entschlüsselung werden für die autorisierten Entitäten bereitgestellt. Key Vault kann den Schlüssel generieren, importieren oder von einem lokalen HSM-Gerät übertragen lassen.

Vorteile

Die Datenverschlüsselung mit CMKs für Azure Database for PostgreSQL – Flexible 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 Schlüssel zentral im Key Vault verwalten und organisieren.

• Das Aktivieren der Verschlüsselung wirkt sich nicht auf die Leistung mit oder ohne CMKs aus, da PostgreSQL in beiden Szenarien auf der Azure Storage-Ebene für die Datenverschlüsselung basiert. Der einzige Unterschied besteht darin, dass wenn Sie CMK verwenden, der Azure Storage-Verschlüsselungsschlüssel (der die tatsächliche Datenverschlüsselung ausführt) verschlüsselt wird.

• Sie können eine der Trennung von Aufgaben zwischen Sicherheitsbeauftragten, DBAs und Systemadministrator*innen implementieren.

Terminologie

Datenverschlüsselungsschlüssel (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.

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 zum Entschlüsseln der DEKs erforderlich ist, ist der KEK effektiv ein einzelner Punkt, mit dem Sie DEKs löschen können (durch Löschen des KEK).

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 der Datenverschlüsselung mit einem CMK

Eine vom Microsoft Entra zugewiesene verwaltete Identität wird verwendet, um ein CMK zu verbinden und abzurufen. Um eine Identität zu erstellen, folgen Sie diesem Tutorial.

Damit ein PostgreSQL-Server CMKs, die in Key Vault gespeichert sind, für die Verschlüsselung des DEK verwenden kann, erteilt ein Key Vault-Administrator der von Ihnen erstellten verwalteten Identität die folgenden Zugriffsrechte:

• get: Zum Abrufen des öffentlichen Teils und der Eigenschaften des Schlüssels in Key Vault.

• list: Zum Auflisten und Durchlaufen der Schlüssel in Key Vault.

• wrapKey: Zum Verschlüsseln der DEK. Der verschlüsselte DEK wird in Azure Database for PostgreSQL gespeichert.

• unwrapKey: Zum Entschlüsseln der DEK. Azure Database for PostgreSQL benötigt den entschlüsselten DEK zum Verschlüsseln und Entschlüsseln der Daten.

Der Key Vault-Administrator kann auch die Protokollierung von Key Vault-Überwachungsereignissen aktivieren, damit sie später überprüft werden können.

Alternativ zur Zugriffsberechtigungszuweisung können Sie, wie oben erläutert, eine neue Azure RBAC-Rollenzuweisung mit der Rolle Key Vault Crypto Service Encryption Usererstellen.

Wichtig

Wenn Sie einer verwalteten Identität für den Zugriff auf Key Vault nicht die vorhergehenden Zugriffsrechte oder RBAC-Zuweisungen zuweisen, kann dies dazu führen, dass ein Verschlüsselungsschlüssel nicht abgerufen und die CMK-Funktion nicht eingerichtet werden kann.

Wenn Sie den Server für die Verwendung des im Key Vault gespeicherten CMK konfigurieren, sendet der Server die DEK zur Verschlüsselung an Key Vault. Key Vault gibt den verschlüsselten DEK zurück, der in der Benutzerdatenbank gespeichert wird. Bei Bedarf sendet der Server die geschützte DEK zur Entschlüsselung an Key Vault. Prüfer können Azure Monitor verwenden, um die Überwachungsereignisprotokoll von Key Vault zu überprüfen, sofern die Protokollierung aktiviert wurde.

Anforderungen für die Konfiguration der Datenverschlüsselung für flexible Azure Database for PostgreSQL-Server

Hier werden die Anforderungen für die Konfiguration von Key Vault aufgeführt:

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

• Die Einstellung Tage zum Aufbewahren gelöschter Tresore für Key Vault muss 90 sein. Wenn Sie die vorhandene Key Vault-Instanz mit einer niedrigeren Zahl konfiguriert haben, müssen Sie eine neue Key Vault-Instanz erstellen, da Sie eine Instanz nach der Erstellung nicht ändern können.

• Es wird empfohlen, die Konfiguration Aufbewahrungsdauer für gelöschte Tresore in Tagen für Key Vault auf 90 Tage festzulegen. Falls Sie eine vorhandene Key Vault-Instanz mit einem niedrigeren Wert 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. Nach der Erstellung einer Instanz kann die Konfiguration nicht mehr geändert werden.

• Aktivieren Sie das Feature zum vorläufigen Löschen in Key Vault, um den Schutz vor Datenverlust zu ermöglichen, 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. Den Aktionen zum Wiederherstellen und endgültigen Löschen sind über Key Vault-Zugriffsrichtlinien eigene Berechtigungen zugewiesen.

  Das Feature zum vorläufigen Löschen ist standardmäßig deaktiviert, Sie können es jedoch über PowerShell oder die Azure CLI aktivieren. Sie können es nicht über das Azure-Portal aktivieren.

• Aktivieren Sie den Löschschutz, um einen obligatorischen Aufbewahrungszeitraum für gelöschte Tresore und Tresorobjekte zu erzwingen.

• Gewähren Sie der Instanz von Azure Database for PostgreSQL – Flexible Server Zugriff auf den Key Vault mit den Berechtigungen get, list, wrapKey und unwrapKey unter Verwendung ihrer eindeutigen verwalteten Identität. Erstellen Sie alternativ eine neue Azure RBAC-Rollenzuweisung mit der Rolle Key Vault Crypto Service Encryption User für die verwaltete Identität.

Hier sind Anforderungen für die Konfiguration des CMK in Azure Database for PostgreSQL – Flexible Server:

• Das für die Verschlüsselung des DEK zu verwendende CMK kann nur asymmetrisch, RSA oder RSA-HSM sein. Schlüsselgrößen von 2.048, 3.072 und 4.096 werden unterstützt.

• 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 sich im Zustand *Enabled- befinden.

• 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 ein CMK für die Datenverschlüsselung verwenden, finden Sie hier Empfehlungen zum Konfigurieren von Key Vault:

• 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. 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 CMK-Setups Schlüssel bereitgestellt oder während Servervorgängen Schlüssel aus Key Vault abgerufen werden können.

Hier finden Sie Empfehlungen zum Konfigurieren eines CMK:

• Bewahren Sie eine Kopie des CMKs an einem sicheren Ort auf, oder hinterlegen Sie sie 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.

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

Ein Benutzer mit ausreichenden Zugriffsrechten für Key Vault könnte den Serverzugriff auf den Schlüssel versehentlich durch eine der folgende Aktionen deaktivieren:

• Aufheben der Berechtigungen list, get, wrapKey und unwrapKey für die Identität, die zum Abrufen des Schlüssels aus dem 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 des CMK im 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:

• 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 mit dem verwalteten Schlüssel eines Kunden im Key Vault

Nachdem der flexible Azure Database for PostgreSQL-Server mit dem vom Kunden verwalteten Schlüssel, der in Key Vault gespeichert ist, verschlüsselt wurde, wird jede neu erstellte Kopie des Servers ebenfalls verschlüsselt. Sie können diese neue Kopie über einen PITR-Vorgang (Point-in-Time Restore) oder Lesereplikate erstellen.

Wenn Sie die Verschlüsselung von vom Kunden verwalteten Daten während der Wiederherstellung oder Erstellung eines Lesereplikats einrichten, können Sie Probleme vermeiden, indem Sie die folgenden Schritte auf den primären und wiederhergestellten/Replikatservern 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 dem Replikatserver können Sie die CMK und/oder die Microsoft Entra-Identität ändern, die für den Zugriff auf Key Vault in den Datenverschlüsselungseinstellungen verwendet wird. Stellen Sie sicher, dass dem neu erstellten Server die Berechtigungen list, wrap und unwrap für den in Key Vault gespeicherten Schlüssel erteilt werden.

• Widerrufen Sie den ursprünglichen Schlüssel nach der Wiederherstellung nicht. Zurzeit unterstützen wir die Schlüsselsperrung nicht, nachdem Sie einen CMK-fähigen Server auf einem anderen Server wiederhergestellt haben.

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 neue Instanzen von Azure Database for PostgreSQL – Flexible Server mit dem CMK-Feature erstellen, können Sie Azure Key Vault Managed HSM als Alternative zu Azure Key Vault auswählen. 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?.

Nicht zugängliche CMK-Bedingung

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 Server in Key Vault den Zugriff auf den CMK verliert, beginnt der Server innerhalb von 10 Minuten damit, alle Verbindungen zu verweigern. Der Server gibt eine entsprechende Fehlermeldung aus und ändert den Serverstatus in Zugriff nicht möglich.

Einige der Gründe, warum der Serverstatus zu Zugriff nicht möglich wird, sind:

• Wenn Sie die Key Vault-Instanz löschen, kann die Instanz von Azure Database for PostgreSQL – Flexible Server nicht auf den Schlüssel zugreifen und in einen Zustand vonZugriff nicht möglich verschoben werden. Um den Server Verfügbar zu machen, die Key Vault-Instanz wiederherzustellen und die Datenverschlüsselung erneut zu aktualisieren.
• Wenn Sie den Schlüssel aus Key Vault löschen, kann die Azure Database for PostgreSQL – Flexible Serverinstanz nicht auf den Schlüssel zugreifen und wechselt zu dem Zustand Zugriff nicht möglich. Um den Server Verfügbar zu machen, den Schlüssel wiederherzustellen und die Datenverschlüsselung erneut zu aktualisieren.
• Wenn Sie aus Microsoft Entra ID eine verwaltete Identität löschen, die zum Abrufen eines Schlüssels aus Key Vault verwendet wird, oder wenn Sie eine Azure RBAC-Rollenzuweisung mit der Rolle Key Vault Crypto Service Encryption User löschen. Die Azure Database for PostgreSQL – Flexibler Serverinstanz kann nicht auf den Schlüssel zugreifen und wechselt zu dem Zustand Zugriff nicht möglich. Um den Server Verfügbar zu machen, stellen Sie die Identität wieder her und validieren Sie die Datenverschlüsselung erneut.
• Wenn Sie der verwalteten Identität, die zum Abrufen eines Schlüssels aus dem Key Vault verwendet wird, die Berechtigungen list, get, wrapKey und unwrapKey entziehen, kann die Instanz von Azure Database for PostgreSQL – Flexible Server nicht auf den Schlüssel zugreifen und wechselt in den Status Zugriff nicht möglich. Fügen Sie der Identität die erforderlichen Zugriffsrichtlinien im Key Vault hinzu.
• Wenn Sie übermäßig restriktive Key Vault-Firewallregeln einrichten, kann Azure Database for PostgreSQL – Flexible Server nicht mit Key Vault kommunizieren, um Schlüssel abzurufen. Achten Sie beim Konfigurieren einer Key Vault-Firewall darauf, die Option vertrauenswürdige Microsoft-Dienste auszuwählen, damit die Firewall umgangen werden kann.

Hinweis

Wenn ein Schlüssel deaktiviert, gelöscht, abgelaufen oder nicht erreichbar ist, wird ein Server, der Daten über diesen Schlüssel verschlüsselt hat, in den Zustand Zugriff nicht möglich versetzt – wie bereits erwähnt. Der Server wird erst verfügbar, wenn Sie den Schlüssel erneut aktivieren oder einen neuen Schlüssel zuweisen.

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 ist, kann der Server bis zu 60 Minuten benötigen, bis er erneut Verfügbar ist.

Wiederherstellung nach der Löschung von verwalteten Identitäten

In dem seltenen Fall, dass eine von Entra ID verwaltete Identität, die von CMK zum Abrufen eines Schlüssels aus Azure Key Vault (AKV) verwendet wird, in Microsoft Entra ID gelöscht wird, werden folgende Schritte zur Wiederherstellung empfohlen:

1. Stellen Sie entweder die Identität wieder her oder erstellen Sie eine neue verwaltete Entra ID-Identität
2. 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. Je nach Berechtigungsmodell des Schlüsseltresors (Zugriffsrichtlinie oder Azure RBAC) kann der Zugriff auf den Schlüsseltresor entweder durch die Erstellung einer Zugriffsrichtlinie für den Schlüsseltresor (Zugriffsrichtlinien list, get, wrapKey und unwrapKey) oder durch die Erstellung einer neuen Azure RBAC Rollenzuweisung mit der Rolle Key Vault Crypto Service Encryption User gewährt werden.
3. Bestätigen Sie die CMK-Datenverschlüsselung mit einer neuen oder wiederhergestellten Identität im Azure-Bildschirm Datenverschlüsselung der Azure Database for PostgreSQL – Flexibler Server-Instanz.

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 CMKs und georedundanten Geschäftskontinuitätsfeatures

Azure Database for PostgreSQL – Flexible 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 in der Region erstellt werden, in der 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.

Begrenzungen

Hier sind die aktuellen Einschränkungen für die Konfiguration des CMK in Azure Database for PostgreSQL – Flexible Server:

• Sie können die CMK-Verschlüsselung nur während der Erstellung eines neuen Servers konfigurieren, nicht als Aktualisierung der vorhandenen Azure Database for PostgreSQL – Flexible Serverinstanz. Sie können stattdessen eine PITR-Sicherung auf einem neuen Server mit CMK-Verschlüsselung wiederherstellen.

• Nachdem Sie die CMK-Verschlüsselung konfiguriert haben, können Sie sie nicht entfernen. Wenn Sie dieses Feature entfernen möchten, besteht die einzige Möglichkeit darin, den Server auf einem Nicht-CMK-Server wiederherzustellen.

• Die Instanz des verwalteten Azure Key Vault-HSM oder die Instanz von Azure Key Vault, in der Sie den Verschlüsselungsschlüssel speichern möchten, muss sich in derselben Region befinden, in der die Instanz der Azure-Datenbank für flexible Server erstellt wird.

Nächste Schritte

• Erfahren Sie mehr über Microsoft Entra Domain Services.