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.
  • Die Verwaltung wird vereinfacht.

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 sehen 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 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:

  • Legen Sie eine Ressourcensperre für Key Vault fest, um ein versehentliches oder nicht autorisiertes Löschen dieser kritischen Ressource 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 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 der Server den Zugriff auf den in Key Vault gespeicherten Schlüssel verliert, beginnt der Server innerhalb von zehn Minuten damit, alle Verbindungen zu verweigern. Der Server gibt eine entsprechende Fehlermeldung aus und ändert den Serverstatus in Zugriff nicht möglich.

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

  • 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 die Instanz verwiesen hat, läuft schließlich ab, wodurch der Serverstatus in Kein Zugriff geändert wird. Um dies zu vermeiden, stellen Sie bei jedem Rotieren des Schlüssels sicher, dass Sie auch die Instanz des Servers so anpassen, 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. Alternativ können Sie die REST-API Server: Update des Diensts aufrufen.
  • 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 wieder 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 geworden ist, kann der Server bis zu 60 Minuten benötigen, bis der Status wieder Zugänglich 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 – 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 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