Verschlüsselung von ruhenden Daten in Azure Database for PostgreSQL – Flexible Server

Azure Database for PostgreSQL flexible Server verschlüsselt immer alle ruhenden Daten. Diese Daten umfassen alle System- und Benutzerdatenbanken, Serverprotokolle, Schreibzugriffsprotokollsegmente und Sicherungen. Der zugrunde liegende Speicher verarbeitet die Verschlüsselung über die serverseitige Verschlüsselung von Azure Disk Storage.

Verschlüsselung ruhender Daten mit dienstverwalteten Schlüsseln (SMK) oder kundenseitig verwalteten Schlüsseln (CMK)

Azure Database for PostgreSQL unterstützt zwei Modi der ruhenden Datenverschlüsselung: dienstverwaltete Schlüssel (SMK) und vom Kunden verwaltete Schlüssel (CMK). Die Datenverschlüsselung mit dienstseitig verwalteten Schlüsseln ist der Standardmodus für Azure Database for PostgreSQL – Flexibler Server. In diesem Modus verwaltet der Dienst automatisch die Verschlüsselungsschlüssel, die zum Verschlüsseln Ihrer Daten verwendet werden. Sie müssen keine Maßnahmen ergreifen, um die Verschlüsselung in diesem Modus zu aktivieren oder zu verwalten.

Im Modus mit kundenseitig verwalteten Schlüsseln können Sie Ihren eigenen Verschlüsselungsschlüssel zum Verschlüsseln Ihrer Daten verwenden. Dieser Modus bietet Ihnen mehr Kontrolle über den Verschlüsselungsprozess, erfordert aber auch, dass Sie die Verschlüsselungsschlüssel selbst verwalten. Sie müssen Ihr eigenes Azure Key Vault- oder Azure Key Vault Managed Hardware Security Module (HSM) bereitstellen und so konfigurieren, dass die Verschlüsselungsschlüssel gespeichert werden, die von Ihrer Azure-Datenbank für flexiblen Server für PostgreSQL verwendet werden.

Sie können den Modus nur bei der Servererstellung auswählen. Sie können den Modus für die Lebensdauer des Servers nicht von einem in einen anderen ändern.

Um die Verschlüsselung Ihrer Daten zu erreichen, verwendet Azure Database for PostgreSQL Azure Storage Verschlüsselung für ruhende Daten. Wenn Sie CMK verwenden, sind Sie dafür verantwortlich, Schlüssel zum Verschlüsseln und Entschlüsseln von Daten in Blob Storage und Azure Files Diensten bereitzustellen. Sie müssen diese Schlüssel in Azure Key Vault oder Azure Key Vault Managed Hardware Security Module (HSM) speichern. Weitere Informationen finden Sie unter Kundenseitig verwaltete Schlüssel für die Azure Storage-Verschlüsselung.

Vorteile, die von jedem Modus (SMK oder CMK) bereitgestellt werden

Die Datenverschlüsselung mit vom Dienst verwalteten Schlüsseln für Azure Database for PostgreSQL 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 Drehung) und die Verwaltung der Identitäten, die für den Zugriff auf diese Schlüssel verwendet werden.

Die Datenverschlüsselung mit vom Kunden verwalteten Schlüsseln für Azure Database for PostgreSQL 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.

CMK-Anforderungen

Wenn Sie den vom Kunden verwalteten Verschlüsselungsschlüssel verwenden, übernehmen Sie die Verantwortung. Sie müssen Ihren eigenen Azure Key Vault oder Azure Key Vault HSM bereitstellen. Sie müssen Ihren eigenen Schlüssel generieren oder importieren. Sie müssen die erforderlichen Berechtigungen für den Key Vault gewähren, damit Ihr Azure Database for PostgreSQL Flexible Server die erforderlichen Vorgänge mit dem Schlüssel ausführen kann. Sie müssen alle Netzwerkaspekte der Azure Key Vault konfigurieren, in der der Schlüssel aufbewahrt wird, damit Ihr 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. Schließlich sind Sie dafür verantwortlich, den Schlüssel zu drehen und bei Bedarf die Konfiguration Ihrer Azure-Datenbank für PostgreSQL flexiblen Server zu aktualisieren, damit sie auf die gedrehte 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 ihn von einem lokalen HSM-Gerät übertragen erhalten.

In der folgenden Liste werden die Anforderungen zum Konfigurieren der Datenverschlüsselung für Azure Database for PostgreSQL beschrieben:

• Für Single-Tenant-CMK-Konfigurationen müssen Key Vault und Ihr flexibler Azure Database for PostgreSQL-Server zum selben Microsoft Entra-Mandanten gehören. Informationen zu mandantenübergreifenden Szenarien finden Sie unter Mandantenübergreifende kundenverwaltete Schlüssel. Wenn Sie die Key Vault Ressource danach verschieben, muss die Datenverschlüsselung neu konfiguriert werden.
• Legen Sie die Konfiguration Tage zum Aufbewahren gelöschter Tresore für Key Vault auf 90 Tage fest. Wenn Sie eine vorhandene Key Vault Instanz mit einer niedrigeren Zahl konfiguriert haben, bleibt sie gültig. 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, können Sie diese Einstellung nicht mehr ändern.
• Aktivieren Sie das Feature "Vorläufig gelöscht" in Key Vault, um 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 "Vorläufig gelöscht" ist standardmäßig aktiviert. Wenn Sie über eine Schlüsseltresor-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 mit 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 von Azure Database for PostgreSQL – Flexibler Server wie folgt Zugriff auf den Schlüssel:
• Bevorzugt: Konfigurieren Sie Azure Key Vault mit dem RBAC-Berechtigungsmodell, und weisen Sie die verwaltete Identität der rolle "Key Vault Crypto Service Encryption User" zu.
• 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
• Liste: Auflisten und Durchlaufen der im Key Vault gespeicherten Schlüssel.
• wrapKey: Um den Datenverschlüsselungsschlüssel zu verschlüsseln.
• 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. Verwenden Sie einen 4.096-Bit-Schlüssel, um eine bessere Sicherheit zu gewährleisten.
• 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.

Aktualisierungen der CMK-Schlüsselversionen

Sie können CMK für manuelle Schlüsseldrehung und -updates oder für automatische Schlüsselversionsupdates nach einer manuellen oder automatischen Schlüsseldrehung im Key Vault konfigurieren.

Weitere Informationen finden Sie unter Konfigurieren der Datenverschlüsselung mit vom Kunden verwaltetem Schlüssel während der Serverbereitstellung.

Manuelle Schlüsselrotation und Aktualisierungen

Wenn Sie CMK mit manuellen Schlüsselupdates konfigurieren, müssen Sie die Schlüsselversion in Azure Database for PostgreSQL Flexible Server nach einer manuellen oder automatischen Schlüsselrotation im Key Vault manuell aktualisieren. Der Server verwendet weiterhin die alte Schlüsselversion, bis Sie sie aktualisieren. Sie stellen diesen Modus bereit, indem Sie einen Schlüssel-URI angeben, der die Version GUID im URI enthält. Beispiel: https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Bis vor kurzem war diese Option die einzige Verfügbare.

Wenn Sie den Schlüssel manuell drehen oder wenn AKV den Schlüssel basierend auf seiner Rotationsrichtlinie automatisch rotiert, mussten Sie die CMK-Eigenschaft bei Ihrem PostgreSQL-Server aktualisieren. Dieser Ansatz erwies sich als fehleranfällig für die Operatoren oder erforderte ein benutzerdefiniertes Skript für die Verarbeitung der Rotation, insbesondere bei Verwendung der automatischen Rotationsfunktion von Key Vault.

Automatische Updates der Schlüsselversion

Verwenden Sie zum Aktivieren von automatischen Schlüsselversionsupdates einen versionslosen Schlüssel-URI. Dieser Ansatz beseitigt die Notwendigkeit, die CMK-Versionseigenschaft auf Ihrem PostgreSQL-Server nach einer Schlüsseldrehung zu aktualisieren. PostgreSQL nimmt automatisch die neue Schlüsselversion auf und verschlüsselt den Datenverschlüsselungsschlüssel erneut. Dieser Ansatz vereinfacht die Verwaltung des Schlüssellebenszyklus erheblich, insbesondere in Kombination mit der automatischen Schlüsselrotation von Key Vault.

Um diesen Ansatz mithilfe von Azure Resource Manager, Bicep, Terraform, Azure PowerShell oder Azure CLI zu implementieren, lassen Sie die Version GUID von Ihrem Schlüssel-URI weg.

Aktivieren Sie im Portal das Kontrollkästchen, um die Benutzeroberfläche anzuweisen, Versions-GUIDs während der interaktiven Auswahl und bei der Validierung des URI zu unterdrücken.

Recommendations

Wenn Sie einen vom Kunden verwalteten Schlüssel für die Datenverschlüsselung verwenden, befolgen Sie die folgenden Empfehlungen, um Key Vault zu konfigurieren:

• Legen Sie eine Ressourcensperre für Key Vault fest, um 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.
• Aktivieren Sie automatische Updates der Schlüsselversion.

• 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 Azure Key Vault

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

• 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 in Azure Key Vault gespeicherten Schlüssel

Um den Datenbankstatus zu überwachen und Warnungen für den Verlust des Zugriffs auf die Datenverschlüsselungskomponente zu aktivieren, konfigurieren Sie die folgenden Azure Features:

• 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 vom Kunden verwalteten Schlüssel konfiguriert ist

Nachdem Sie Ihren Azure Database for PostgreSQL flexiblen Server mit einem vom Kunden verwalteten Schlüssel verschlüsselt haben, der in Key Vault gespeichert ist, werden alle neu erstellten Serverkopien ebenfalls 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:

• Starten Sie den Wiederherstellungsvorgang oder den Vorgang zum Erstellen eines Lesereplikats vom primären Azure Database for PostgreSQL Flexible Server.
• 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. Zurzeit wird der Schlüsselwiderruf nicht unterstützt, nachdem Sie einen Server mit einem vom Kunden verwalteten Schlüssel 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 im Azure-Portal einen neuen Azure Database for PostgreSQL – Flexibler Server mit einem kundenseitig verwalteten Schlüssel erstellen, können Sie Azure Key Vault Managed HSM als Schlüsselspeicher anstelle von 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?.

Kein Zugriff auf den kundenseitig verwalteten Schlüssel

Wenn Sie die Datenverschlüsselung mit einem vom Kunden verwalteten Schlüssel konfigurieren, der in Key Vault gespeichert ist, erfordert der Server kontinuierlichen Zugriff auf diesen Schlüssel, um online zu bleiben. Wenn der Server den Zugriff verliert, ändert er seinen Zustand in " Nicht zugänglich " und beginnt, alle Verbindungen zu verweigern.

Mögliche Gründe für den Serverstatus, auf den nicht zugegriffen werden kann, sind:

Gelöschte verwaltete Identitäten wiederherstellen

Wenn Sie die vom Benutzer zugewiesene verwaltete Identität löschen, die auf den in Key Vault in Microsoft Entra ID gespeicherten Verschlüsselungsschlüssel zugreift, führen Sie die folgenden Schritte aus, um wiederherzustellen:

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, auch wenn sie den genauen Namen wie die gelöschte Identität aufweist, aktualisieren Sie die Azure-Datenbank für flexible Servereigenschaften, damit sie weiß, dass sie diese neue Identität für den Zugriff auf den Verschlüsselungsschlüssel verwenden muss.
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.

Verwenden Sie Datenverschlüsselung mit vom Kunden verwalteten Schlüsseln und georedundanten Funktionen für die Geschäftskontinuität

Azure Database for PostgreSQL unterstützt erweiterte Datenwiederherstellungsfeatures wie Replikate und georedundante Sicherung. Die folgenden Anforderungen gelten für das Einrichten der Datenverschlüsselung mit CMKs und diesen Features zusätzlich zu grundlegenden Anforderungen für die Datenverschlüsselung mit CMKs:

• Sie müssen den georedundanten Sicherungsverschlüsselungsschlüssel in einer Key Vault Instanz erstellen, die in der Region vorhanden sein muss, 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, erstellen Sie die vom Benutzer verwaltete Identität in derselben Region wie die georedundanten Sicherungen.
• 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. Sie müssen die vom Benutzer zugewiesene Identität erstellen, um sich bei dieser Key Vault Instanz in derselben Region zu authentifizieren.

Mandantenübergreifende vom Kunden verwaltete Schlüssel (CMK) (Vorschau)

Mandantenübergreifende vom Kunden verwaltete Schlüssel ermöglichen ihnen die Verwendung von Verschlüsselungsschlüsseln, die in einer Key Vault- oder verwalteten HSM-Instanz gespeichert sind, die zu einem anderen Microsoft Entra ID als Ihrem Azure Database for PostgreSQL flexiblen Server gehört. Das mandantenübergreifende CMK-Setup erfordert zusätzliche Konfiguration und Koordination zwischen Mandanten. Im mandantenübergreifenden Szenario befindet sich die Azure Database for PostgreSQL Ressource in einem Mandanten, der von einem unabhängigen Softwareanbieter (ISV) verwaltet wird, der als Dienstanbieter bezeichnet wird. Der schlüssel, der für die Verschlüsselung der Azure Database for PostgreSQL-Ressource verwendet wird, befindet sich in einem Schlüsseltresor in einem anderen Mandanten, den der Kunde verwaltet.

Übersicht über die Einrichtung

Im ISV-Mandanten

• Erstellen einer Mehrinstanzenanwendung

  • Konfigurieren der benutzerseitig zugewiesenen verwalteten Identität als Anmeldeinformationen für eine Verbundidentität für die Anwendung

Im Clientmandanten

1. Installieren der Mehrinstanzenanwendung

2. Erstellen Sie einen neuen oder verwenden Sie einen vorhandenen Schlüsseltresor oder ein verwaltetes HSM und erteilen Sie der mehrmandantenfähigen Anwendung Schlüsselberechtigungen

   1. Erstellen eines neuen oder Verwenden eines vorhandenen Schlüssels

   2. Abrufen des Schlüssels aus Azure Key Vault oder azure Managed HSM und Aufzeichnen des Schlüsselbezeichners

Im ISV-Mandanten

Bis zu diesem Punkt haben Sie die Mehrinstanzenanwendung für den Mandanten des Dienstanbieters konfiguriert. Sie haben die Anwendung im Mandanten des Kunden installiert sowie den Schlüsseltresor und Schlüssel im Mandanten des Kunden konfiguriert. Als Nächstes können Sie einen Azure Database for PostgreSQL-Server im Mandanten des Dienstanbieters erstellen und kundenseitig verwaltete Schlüssel unter Verwendung des Schlüssels aus dem Mandanten des Kunden konfigurieren.

Wenn Sie einen Azure Database for PostgreSQL Server mit vom Kunden verwalteten Schlüsseln erstellen, müssen Sie sicherstellen, dass er Zugriff auf die vom Kunden verwendeten Schlüssel hat. In Single-Tenant-Szenarien gewähren Sie der benutzerverwalteten Identität des Azure Database for PostgreSQL-Servers direkten Zugriff auf den Schlüsseltresor. In einem mandantenübergreifenden Szenario können Sie sich nicht mehr auf den direkten Zugriff auf den Schlüsseltresor verlassen, da sich der Schlüsseltresor in einem anderen, vom Kunden verwalteten Mandanten befindet. Diese Einschränkung ist der Grund, warum Sie in den vorherigen Abschnitten eine tenantübergreifende Anwendung erstellt und in der Anwendung eine verwaltete Identität registriert haben, damit sie auf den Schlüsseltresor des Kunden zugreifen kann. Diese verwaltete Identität, gekoppelt mit der mandantenübergreifenden Anwendungs-ID, ist, was Sie beim Erstellen des mandantenübergreifenden CMK für den Azure Database for PostgreSQL-Server verwenden.

Wenn eine neue Version des Schlüssels im Key Vault verfügbar ist, nimmt der Azure Database for PostgreSQL Server automatisch die neue Version auf.

Verwenden des Azure-Portals

Führen Sie die folgenden Schritte aus, um mandantenübergreifende vom Kunden verwaltete Schlüssel für einen neuen Azure Database for PostgreSQL-Server im Azure-Portal zu konfigurieren:

1. Wählen Sie beim Erstellen der Ressource Azure Database for PostgreSQL im Azure-Portal die Registerkarte Security aus, und wählen Sie dann Customer-managed key aus.

2. Weisen Sie die erstellte benutzerseitig zugewiesene verwaltete Identität als Benutzerseitig zugewiesene verwaltete Identität zu.

3. Weisen Sie die Mehrinstanzenanwendung mithilfe des Anwendungsnamens zu.

4. Geben Sie einen Schlüsselbezeichner in die Schlüsselauswahlmethode ein, indem Sie den Schlüsselbezeichner des Kunden verwenden, der vom Clientmandanten abgerufen wurde.

Verwenden von Azure Resource Manager JSON-Vorlagen und REST-API

Stellen Sie eine ARM-Vorlage mit den folgenden spezifischen Parametern bereit:

Hier ist ein Beispiel für eine REST-API mit den drei konfigurierten Parametern:

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Beispiel für Anforderungstext:

{
"location": "eastus2",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
        "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>": {}
        }
    },
    "sku": {
        "name": "Standard_D2s_v3",
        "tier": "GeneralPurpose"
    },
    "properties": {
        "createMode": "Create",
        "version": "16",
        "minorVersion": "5",
        "storage": {
        "storageSizeGB": 32
        },
        "network": {
        "publicNetworkAccess": "Enabled"
        },
        "backup": {
        "backupRetentionDays": 7,
        "geoRedundantBackup": "Disabled"
        },
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Hier ist ein Beispiel für eine REST-API für die Drehung von Schlüsseln. Im PATCH-Beispiel wird nur der CMK-Schlüssel-URI aktualisiert, um den Verschlüsselungsschlüssel zu drehen, ohne den Server neu zu erstellen.

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Anforderungstext (Beispiel für die Schlüsselrotation):

{
    "properties": {
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<new-key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Einschränkungen der Vorschauversion für mandantenübergreifende kundenverwaltete Schlüssel (CMK)

• Azure PowerShell und Azure CLI unterstützen diese Funktion noch nicht.
• Das Erstellen eines Servers mit georedundanten Sicherungen und die Aktivierung langfristiger Aufbewahrungssicherungsvorgänge werden derzeit nicht unterstützt.
• Die Vorschau wird derzeit nur in diesen Regionen unterstützt:
  • Ost-USA 2
  • Westliches USA 2
  • US Central
  • Australia Southeast
  • Australia East
  • North Europe

Einschränkungen von vom Kunden verwalteten Schlüsseln (CMK)

Dies sind die aktuellen Einschränkungen für die Konfiguration des vom Kunden verwalteten Schlüssels in einer Azure-Datenbank für PostgreSQL flexible Server:

• Sie können die vom Kunden verwaltete Schlüsselverschlüsselung nur während der Erstellung eines neuen Servers konfigurieren, nicht als Update auf einen vorhandenen Azure Database for PostgreSQL flexiblen Server. Stattdessen können Sie eine PITR-Sicherung auf einem neuen Server mit CMK-Verschlüsselung wiederherstellen.
• Nachdem Sie die kundenseitig verwaltete Schlüsselverschlüsselung konfiguriert haben, ist eine Rückkehr zu einem vom System verwalteten Schlüssel nicht mehr möglich. Wenn Sie wieder zur anderen Option wechseln möchten, müssen Sie den Server auf einem neuen Server wiederherstellen, bei dem die Datenverschlüsselung mit systemseitig verwalteten Schlüsseln konfiguriert ist.
• Die Instanz von Azure Key Vault Managed 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 Sie die Azure Database for Flexible Server erstellen.

Verwandte Inhalte

• Konfigurieren der Datenverschlüsselung in Azure Database for PostgreSQL