Crittografia dei dati inattivi nel server flessibile di Database di Azure per PostgreSQL

Database di Azure per PostgreSQL server flessibile crittografa sempre tutti i dati archiviati. Questi dati includono tutti i database di sistema e utente, i log del server, i segmenti di log write-ahead e i backup. L'archiviazione sottostante gestisce la crittografia tramite la crittografia lato server di archiviazione su disco di Azure.

Crittografia dei dati inattivi con chiavi gestite dal servizio (SMK) o chiavi gestite dal cliente (CMK)

Database di Azure per PostgreSQL supporta due modalità di crittografia dei dati inattivi: chiavi gestite dal servizio (SMK) e chiavi gestite dal cliente (CMK). La crittografia dei dati con chiavi gestite dal servizio è la modalità predefinita per il server flessibile di Database di Azure per PostgreSQL. In questa modalità, il servizio gestisce automaticamente le chiavi di crittografia usate per crittografare i dati. Non è necessario eseguire alcuna azione per abilitare o gestire la crittografia in questa modalità.

Nella modalità chiavi gestite dal cliente è possibile usare la propria chiave di crittografia per crittografare i dati. Questa modalità offre un maggiore controllo sul processo di crittografia, ma richiede anche di gestire manualmente le chiavi di crittografia. È necessario distribuire il proprio insieme di credenziali delle chiavi di Azure o il modulo HSM (Managed Hardware Security Module) di Azure Key Vault e configurarlo per archiviare le chiavi di crittografia usate dal server flessibile di Database di Azure per PostgreSQL.

È possibile selezionare la modalità solo in fase di creazione del server. Non è possibile modificare la modalità da una all'altra per la durata del server.

Per garantire la crittografia dei dati, Database di Azure per PostgreSQL usa la crittografia di Archiviazione di Azure per i dati inattivi. Quando si usa cmk, si è responsabili della fornitura di chiavi per crittografare e decrittografare i dati nei servizi gestione rete virtuale di Azure e File di Azure. È necessario archiviare queste chiavi in Azure Key Vault o Azure Key Vault modulo HSM (Managed Hardware Security Module). Per altre informazioni, vedere Chiavi gestite dal cliente per la crittografia di archiviazione di Azure.

Vantaggi offerti da ogni modalità (SMK o CMK)

La crittografia dei dati con chiavi gestite dal servizio per Database di Azure per PostgreSQL offre i vantaggi seguenti:

• Il servizio controlla automaticamente e completamente l'accesso ai dati.
• Il servizio controlla automaticamente e completamente il ciclo di vita della chiave, inclusa la rotazione della chiave.
• Non è necessario preoccuparsi della gestione delle chiavi di crittografia dei dati.
• La crittografia dei dati basata sulle chiavi gestite dal servizio non influisce negativamente sulle prestazioni dei carichi di lavoro.
• Semplifica la gestione delle chiavi di crittografia (inclusa la rotazione regolare) e la gestione delle identità usate per accedere a tali chiavi.

La crittografia dei dati con chiavi gestite dal cliente per Database di Azure per PostgreSQL offre i vantaggi seguenti:

• È possibile controllare completamente l'accesso ai dati. È possibile rimuovere una chiave per rendere un database inaccessibile.
• È possibile controllare completamente il ciclo di vita di una chiave, inclusa la rotazione della chiave per allinearsi ai criteri aziendali.
• È possibile gestire e organizzare centralmente tutte le chiavi di crittografia nelle proprie istanze di Azure Key Vault.
• La crittografia dei dati basata sulle chiavi gestite dal cliente non influisce negativamente sulle prestazioni dei carichi di lavoro.
• È possibile implementare la separazione dei compiti tra i responsabili della sicurezza, gli amministratori di database e gli amministratori di sistema.

Requisiti della chiave gestita dal cliente

Quando si usa la chiave di crittografia gestita dal cliente, si assume la responsabilità. È necessario distribuire una propria istanza di Azure Key Vault o di Azure Key Vault HSM. È necessario generare o importare la propria chiave. È necessario concedere le autorizzazioni necessarie per Key Vault, in modo che il server flessibile di Database di Azure per PostgreSQL possa eseguire le azioni necessarie sulla chiave. È necessario configurare tutti gli aspetti di rete del Azure Key Vault in cui viene mantenuta la chiave, in modo che il server flessibile Database di Azure per PostgreSQL possa accedere alla chiave. Anche il controllo dell'accesso alla chiave è responsabilità dell'utente. Infine, si è responsabili della rotazione della chiave e, quando necessario, dell'aggiornamento della configurazione del server flessibile di Database di Azure per PostgreSQL in modo che faccia riferimento alla versione ruotata della chiave.

Quando si configurano chiavi gestite dal cliente per un account di archiviazione, Archiviazione di Azure esegue il wrapping della chiave di crittografia dei dati (DEK) radice per l'account con la chiave gestita dal cliente nell'insieme di credenziali delle chiavi associato o nell'HSM gestito. La protezione della chiave di crittografia radice cambia, ma i dati nell'account di archiviazione di Azure rimangono sempre crittografati. Non è necessaria alcuna azione aggiuntiva da parte dell'utente per assicurarsi che i dati rimangano crittografati. La protezione da chiavi gestite dal cliente diventa effettiva immediatamente.

Azure Key Vault è un sistema di gestione delle chiavi esterno basato sul cloud. Offre disponibilità elevata e fornisce una risorsa di archiviazione scalabile e sicura per le chiavi di crittografia RSA, supportata facoltativamente da moduli di protezione hardware (HSM) con convalida di tipo FIPS 140. Un insieme di credenziali delle chiavi non consente l'accesso diretto a una chiave archiviata, ma offre servizi di crittografia e decrittografia alle entità autorizzate. Key Vault può generare la chiave, importarla o riceverla trasferita da un dispositivo HSM locale.

L'elenco seguente descrive i requisiti per configurare la crittografia dei dati per Database di Azure per PostgreSQL:

• Per le configurazioni cmk a tenant singolo, Key Vault e il server flessibile Database di Azure per PostgreSQL devono appartenere allo stesso tenant Microsoft Entra. Per gli scenari tra tenant, vedere Chiavi gestite dal cliente tra tenant. Lo spostamento della risorsa Key Vault richiede successivamente la riconfigurazione della crittografia dei dati.
• Impostare la configurazione Giorni per conservare gli insiemi di credenziali eliminati di Key Vault su 90 giorni. Se è stata configurata un'istanza di Key Vault esistente con un numero inferiore, rimane valida. Tuttavia, se si desidera modificare questa impostazione e aumentare il valore, è necessario creare una nuova istanza di Key Vault. Dopo aver creato un'istanza, non è possibile modificare questa impostazione.
• Abilitare la funzionalità eliminata temporaneamente in Key Vault per proteggere dalla perdita di dati se una chiave o un'istanza di Key Vault viene eliminata accidentalmente. Key Vault conserva le risorse eliminate temporaneamente per 90 giorni, a meno che l'utente non recuperi o elimini le risorse nel frattempo. Le azioni di ripristino e eliminazione hanno ognuna autorizzazioni specifiche, associate a un Key Vault, a un ruolo Controllo degli accessi in base al ruolo o a un'autorizzazione dei criteri di accesso. La funzionalità di eliminazione temporanea è attivata per impostazione predefinita. Se si dispone di uno o più Key Vault distribuiti molto tempo fa, potrebbero ancora avere l'eliminazione temporanea disabilitata. In tal caso, è possibile attivarlo usando interfaccia della riga di comando di Azure.
• Abilita la protezione dall'eliminazione per imporre un periodo di conservazione obbligatorio per gli insiemi di credenziali e gli oggetti degli insiemi di credenziali eliminati.
• Concedi all'identità gestita assegnata dall'utente del server flessibile Database di Azure per PostgreSQL l'accesso alla chiave come segue:
• Consigliato: configurare Azure Key Vault con il modello di autorizzazioni RBAC e assegnare all'identità gestita il ruolo Key Vault Crypto Service Encryption User.
• Legacy: se Azure Key Vault è configurato con il modello di autorizzazione Criteri di accesso, concedere le autorizzazioni seguenti all'identità gestita:
• ottenere: recuperare le proprietà e la parte pubblica della chiave in Key Vault.
• list: per elencare e scorrere le chiavi archiviate in Key Vault.
• wrapKey: per crittografare la chiave di crittografia dei dati.
• unwrapKey: per decrittografare la chiave di crittografia dei dati.
• La chiave usata per crittografare la chiave di crittografia dei dati può essere solo asimmetrica, RSA o RSA-HSM. Sono supportate le dimensioni delle chiavi pari a 2.048, 3.072 e 4.096. Usare una chiave a 4.096 bit per una maggiore sicurezza.
• La data e l'ora per l'attivazione della chiave (se impostata) devono essere passate. La data e l'ora di scadenza (se impostata) devono essere future.
• La chiave deve essere in stato Abilitato.
• Se si importa una chiave esistente in Key Vault, specificarla nei formati di file supportati (.pfx, .byok o .backup).

Aggiornamenti delle versioni delle chiavi CMK

È possibile configurare cmk per la rotazione manuale delle chiavi e gli aggiornamenti oppure per gli aggiornamenti automatici delle versioni delle chiavi dopo una rotazione manuale o automatica delle chiavi nel Key Vault.

Per altre informazioni, vedere Configurare la crittografia dei dati con la chiave gestita dal cliente durante il provisioning del server.

Rotazione e aggiornamenti manuali delle chiavi

Quando si configura CMK con aggiornamenti manuali delle chiavi, è necessario aggiornare manualmente la versione della chiave in Database di Azure per PostgreSQL server flessibile dopo una rotazione manuale o automatica delle chiavi nel Key Vault. Il server continua a usare la versione precedente della chiave fino a quando non viene aggiornato. Si esegue il provisioning di questa modalità specificando un URI della chiave che include la versione GUID nell'URI. Ad esempio: https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Fino a poco tempo fa, questa opzione era l'unica opzione disponibile.

Ogni volta che si ruotava manualmente la chiave o che AKV la ruotava automaticamente in base ai relativi criteri di rotazione, era necessario aggiornare la proprietà CMK sul server PostgreSQL. Questo approccio ha dimostrato di essere soggetto a errori per gli operatori, o ha richiesto uno script personalizzato per gestire la rotazione, soprattutto quando si usa la funzionalità di rotazione automatica di Key Vault.

Aggiornamenti automatici delle versioni delle chiavi

Per abilitare gli aggiornamenti automatici della versione delle chiavi, usare un URI della chiave senza versione. Questo approccio elimina la necessità di aggiornare la proprietà della versione della chiave cmk nel server PostgreSQL dopo una rotazione delle chiavi. PostgreSQL preleva automaticamente la nuova versione della chiave e crittografa nuovamente la chiave di crittografia dei dati. Questo approccio semplifica significativamente la gestione del ciclo di vita delle chiavi, in particolare se combinato con la rotazione automatica di Key Vault.

Per implementare questo approccio usando Azure Resource Manager, Bicep, Terraform, Azure PowerShell o interfaccia della riga di comando di Azure, omettere la versione GUID dall'URI della chiave.

Nel portale selezionare la casella di controllo per guidare l'interfaccia utente a eliminare i GUID della versione durante la selezione interattiva e quando si convalida l'URI.

Recommendations

Quando si usa una chiave gestita dal cliente per la crittografia dei dati, seguire queste indicazioni per configurare Key Vault:

• Impostare un blocco delle risorse su Key Vault per impedire l'eliminazione accidentale o non autorizzata di questa risorsa critica.
• Abilitare il controllo e la creazione di report per tutte le chiavi di crittografia. Key Vault include log che si inseriscono facilmente in altri strumenti di gestione di sicurezza delle informazioni e degli eventi (SIEM). Log di Monitoraggio di Azure è un esempio di servizio già integrato.
• Bloccare Key Vault selezionando Disabilita accesso pubblico e Consenti ai servizi Microsoft attendibili di ignorare questo firewall.
• Abilitare gli aggiornamenti automatici della versione della chiave.

• Conservare una copia della chiave gestita dal cliente in un luogo sicuro o inserirla nel servizio di deposito.
• Se Key Vault genera la chiave, crearne un backup prima di usarla per la prima volta. Il backup può essere ripristinato solo in Key Vault.

Considerazioni speciali

Revoca accidentale dell'accesso alle chiavi da Azure Key Vault

Un utente con diritti di accesso sufficienti per Key Vault potrebbe disabilitare accidentalmente l'accesso al server alla chiave tramite:

• Annullamento dell'assegnazione del ruolo Controllo degli accessi in base al ruolo Utente di crittografia del servizio di crittografia di Key Vault o revoca delle autorizzazioni dall'identità usata per recuperare la chiave in Key Vault.
• Eliminazione della chiave.
• Eliminazione dell'istanza di Key Vault.
• Modifica delle regole del firewall di Key Vault.
• Eliminazione dell'identità gestita del server in Microsoft Entra ID.

Monitorare le chiavi archiviate in Azure Key Vault

Per monitorare lo stato del database e attivare gli avvisi per la perdita di accesso alla protezione di crittografia dei dati, configurare le funzionalità di Azure seguenti:

• Integrità risorse: un database che ha perso l'accesso alla chiave gestita dal cliente viene visualizzato come Inaccessibile dopo la negazione della prima connessione al database.
• Log attività: quando l'accesso alla chiave CMK nell'istanza di Key Vault gestita dal cliente ha esito negativo, le voci vengono aggiunte al log attività. È possibile ripristinare l'accesso se si creano avvisi per questi eventi il prima possibile.
• Gruppi di azioni: definire questi gruppi per ricevere notifiche e avvisi in base alle preferenze.

Ripristinare i backup di un server configurato con una chiave gestita dal cliente

Dopo aver crittografato il server flessibile Database di Azure per PostgreSQL con una chiave gestita dal cliente archiviata in Key Vault, viene crittografata anche qualsiasi copia del server appena creata. È possibile eseguire questa nuova copia tramite un'operazione di ripristino temporizzato (PITR) o usando le repliche di lettura.

Quando si configura la crittografia dei dati con la chiave gestita dal cliente, durante un'operazione come il ripristino di un backup o la creazione di una replica in lettura, è possibile evitare problemi seguendo questa procedura nei server primario e ripristinato o di replica:

• Avvia il processo di ripristino o di creazione di una replica in lettura dal server flessibile primario di Database di Azure per PostgreSQL.
• Nel server di replica o ripristinato è possibile modificare la chiave gestita dal cliente e l'identità gestita assegnata dall'utente usata per accedere a Key Vault. Assicurarsi che l'identità assegnata nel server appena creato disponga delle autorizzazioni necessarie per l'insieme di credenziali delle chiavi.
• Non revocare la chiave originale dopo il ripristino. Al momento, la revoca delle chiavi non è supportata dopo il ripristino di un server con chiave gestita dal cliente in un altro server.

Moduli di protezione hardware gestiti

I moduli di protezione hardware sono dispositivi hardware resistenti alle manomissioni che consentono di proteggere i processi crittografici generando, proteggendo e gestendo le chiavi usate per crittografare i dati, decrittografare i dati, creare firme digitali e creare certificati digitali. I moduli di protezione hardware vengono testati, convalidati e certificati per i più elevati standard di sicurezza, inclusi FIPS 140 e Criteri comuni.

Il modulo di protezione hardware gestito di Azure Key Vault è un servizio cloud completamente gestito, a disponibilità elevata, a tenant singolo e conforme agli standard. È possibile usarla per proteggere le chiavi crittografiche per le applicazioni cloud tramite moduli di protezione hardware convalidati FIPS 140-3.

Quando si crea un nuovo server flessibile di Database di Azure per PostgreSQL nel portale di Azure con la chiave gestita dal cliente, è possibile scegliere Azure Key Vault Managed HSM come archivio delle chiavi, in alternativa a Azure Key Vault. I prerequisiti, in termini di identità e autorizzazioni definiti dall'utente, sono uguali a quelli di Azure Key Vault (come indicato in precedenza in questo articolo). Per altre informazioni su come creare un'istanza del modulo di protezione hardware gestito, sui vantaggi e sulle differenze rispetto a un archivio certificati basato su Key Vault condiviso e su come importare chiavi nel modulo di protezione hardware gestito, vedere Che cos'è l'HSM gestito di Azure Key Vault?.

Condizione inaccessibile della chiave gestita dal cliente

Quando si configura la crittografia dei dati con una chiave gestita dal cliente archiviata in Key Vault, il server richiede l'accesso continuo a questa chiave per rimanere online. Se il server perde l'accesso, lo stato diventa Inaccessibile e inizia a negare tutte le connessioni.

Alcuni possibili motivi per cui lo stato del server diventa inaccessibile includono:

Ripristinare dall'eliminazione dell'identità gestita

Se si elimina l'identità gestita assegnata dall'utente che accede alla chiave di crittografia archiviata in Key Vault in Microsoft Entra ID, seguire questa procedura per ripristinare:

1. Ripristinare l'identità o creare una nuova identità dell'ID Entra gestita.
2. Se è stata creata una nuova identità, anche se ha esattamente lo stesso nome dell'identità eliminata, aggiornare il database Azure per le proprietà del server flessibili in modo che sappia che deve usare questa nuova identità per accedere alla chiave di crittografia.
3. Assicurarsi che questa identità disponga delle autorizzazioni appropriate per le operazioni sulla chiave in Azure Key Vault (AKV).
4. Attendere circa un'ora fino a quando il server riconvalida la chiave.

Usare la crittografia dei dati con chiavi gestite dal cliente e funzionalità di continuità aziendale con ridondanza geografica

Database di Azure per PostgreSQL supporta funzionalità avanzate di ripristino dei dati , ad esempio repliche e backup con ridondanza geografica. I seguenti requisiti si applicano alla configurazione della crittografia dei dati con le CMK e all'uso di queste funzionalità, oltre ai requisiti di base per la crittografia dei dati con le CMK:

• È necessario creare la chiave di crittografia del backup con ridondanza geografica in un'istanza di Key Vault che deve esistere nell'area in cui è archiviato il backup con ridondanza geografica.
• La versione dell'API REST di Azure Resource Manager per il supporto dei server CMK abilitati per il backup con ridondanza geografica è 2022-11-01-preview. Se si vogliono usare modelli di Azure Resource Manager per automatizzare la creazione di server che usano sia la crittografia con i servizi di gestione cloud che con le funzionalità di backup con ridondanza geografica, usare questa versione dell'API.
• Non è possibile usare la stessa identità gestita dall'utente per l'autenticazione per l'istanza di Key Vault del database primario e l'istanza di Key Vault che contiene la chiave di crittografia per il backup con ridondanza geografica. Per mantenere la resilienza a livello di area geografica, creare l'identità gestita dall'utente nella stessa area geografica dei backup con ridondanza geografica.
• Se si configura un database di replica in lettura da crittografare con i CMK durante la creazione, la relativa chiave di crittografia deve trovarsi in un'istanza di Key Vault nell'area in cui risiede il database di replica di lettura. È necessario creare l'identità assegnata dall'utente per eseguire l'autenticazione per questa istanza di Key Vault nella stessa area.

Chiavi multitenant gestite dal cliente (CMK) (anteprima)

Le chiavi gestite dal cliente tra tenant consentono di usare le chiavi di crittografia archiviate in un'istanza di Key Vault o HSM gestita che appartiene a un Microsoft Entra ID diverso rispetto al server flessibile Database di Azure per PostgreSQL. La configurazione di CMK tra tenant richiede impostazioni aggiuntive e coordinamento tra tenant. Nello scenario tra tenant, la risorsa Database di Azure per PostgreSQL risiede in un tenant gestito da un fornitore di software indipendente (ISV) denominato provider di servizi. La chiave usata per la crittografia della risorsa Database di Azure per PostgreSQL risiede in un Key Vault in un tenant diverso gestito dal cliente.

Panoramica della configurazione

Nel tenant dell'ISV

• Creare un'applicazione multi-tenant

  • Configurare l'identità gestita assegnata dall'utente come credenziale federata nell'applicazione

Nel tenant del cliente

1. Installare l'applicazione multi-tenant

2. Creare o usare un insieme di credenziali delle chiavi esistente o un HSM gestito esistente e concedere le autorizzazioni delle chiavi all'applicazione multi-tenant

   1. Creare una nuova chiave o usarne una esistente

   2. Recuperare la chiave da Azure Key Vault o dal modulo di protezione hardware gestito di Azure e registrare l'identificatore di chiave

Nel tenant dell'ISV

Finora hai configurato l'applicazione multi-tenant nel tenant del provider di servizi. È stata installata anche l'applicazione nel tenant del cliente e sono stati configurati l'insieme di credenziali delle chiavi e la chiave nel tenant del cliente. Successivamente è possibile creare un server Database di Azure per PostgreSQL nel tenant del provider di servizi e configurare le chiavi gestite dal cliente con la chiave dal tenant del cliente.

Quando si crea un server Database di Azure per PostgreSQL con chiavi gestite dal cliente, è necessario assicurarsi che abbia accesso alle chiavi usate dal cliente. Negli scenari a tenant singolo, si concede l'accesso diretto all'insieme di credenziali all'identità gestita assegnata dall'utente del server Database di Azure per PostgreSQL. In uno scenario multi-tenant, non è più possibile fare affidamento sull'accesso diretto a Key Vault perché si trova in un tenant diverso, gestito dal cliente. Questo vincolo spiega perché, nelle sezioni precedenti, è stata creata un'applicazione tra tenant ed è stata registrata un'identità gestita all'interno dell'applicazione, per consentirle di accedere all'insieme di credenziali delle chiavi del cliente. Questa identità gestita, associata all'ID dell'applicazione tra tenant, è ciò che si utilizza durante la creazione della chiave gestita dal cliente (CMK) tra tenant per il server di Database di Azure per PostgreSQL.

Ogni volta che una nuova versione della chiave è disponibile nell'insieme di credenziali, il server Database di Azure per PostgreSQL acquisisce automaticamente la nuova versione.

Usare il portale di Azure

Per configurare chiavi gestite dal cliente tra tenant per un nuovo server Database di Azure per PostgreSQL nel portale di Azure, seguire questa procedura:

1. Nella finestra per la creazione della risorsa Database di Azure per PostgreSQL, selezionare la scheda Sicurezza nel portale di Azure e quindi selezionare Chiave gestita dal cliente.

2. Assegnare l'identità gestita assegnata dall'utente, creata come Identità gestita assegnata dall'utente.

3. Assegnare l'applicazione multi-tenant utilizzando il nome dell'applicazione.

4. Immettere un identificatore di chiave nel metodo Selezione chiave usando l'identificatore di chiave del cliente ottenuto dal tenant client.

Usare i modelli JSON di Azure Resource Manager e le API REST

Distribuire un modello di Resource Manager con i parametri specifici seguenti:

Ecco un esempio di API REST con i tre parametri configurati:

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

Esempio di corpo della richiesta:

{
"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>"
        }
    }
}

Ecco un esempio di API REST per la rotazione delle chiavi. L'esempio PATCH aggiorna solo l'URI della chiave CMK per ruotare la chiave di crittografia senza ricreare il server.

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

Corpo della richiesta (esempio di rotazione della chiave):

{
    "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>"
        }
    }
}

Limitazioni dell'anteprima delle chiavi gestite dal cliente (CMK) tra tenant

• Azure PowerShell e interfaccia della riga di comando di Azure non supportano ancora questa funzionalità.
• La creazione di un server con backup con ridondanza geografica e l'abilitazione di operazioni di backup con conservazione a lungo termine non sono attualmente supportate.
• L'anteprima è attualmente supportata solo in queste aree:
  • Stati Uniti orientali 2
  • West US 2 (Regione Ovest degli Stati Uniti 2)
  • Stati Uniti centrali
  • Australia Southeast
  • Australia orientale
  • North Europe

Limitazioni delle chiavi gestite dal cliente

Queste sono le limitazioni correnti per la configurazione della chiave gestita dal cliente in un server flessibile di Database di Azure per PostgreSQL:

• È possibile configurare la crittografia della chiave gestita dal cliente solo durante la creazione di un nuovo server, non come aggiornamento a un server flessibile Database di Azure per PostgreSQL esistente. È invece possibile ripristinare un backup pitr in un nuovo server con crittografia cmk.
• Dopo aver configurato la crittografia della chiave gestita dal cliente, non è possibile ripristinare la chiave gestita dal sistema. Se si vuole ripristinare il server, è necessario ripristinarne uno nuovo con crittografia dei dati configurata con la chiave gestita dal sistema.
• L'istanza di Azure Key Vault modulo di protezione hardware gestito o l'istanza di Azure Key Vault in cui si prevede di archiviare la chiave di crittografia deve esistere nella stessa area in cui si sta creando il Azure Database per il server flessibile.

Contenuti correlati

• Configurare la crittografia dei dati in Database di Azure per PostgreSQL