Crittografia dei dati inattivi in Database di Azure per PostgreSQL

Tutti i dati gestiti da un'istanza di server flessibile del Database Azure per PostgreSQL sono sempre crittografati a riposo. Tali dati includono tutti i database di sistema e utente, i log del server, i segmenti di log write-ahead e i backup. La crittografia viene gestita dall'archiviazione sottostante tramite la crittografia lato server di Archiviazione dischi di Azure.

Crittografia dei dati inattivi con il servizio (SMK) o con le 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 una Azure Key Vault o un modulo di protezione hardware gestito di Azure Key Vault e configurarlo per archiviare le chiavi di crittografia utilizzate dall'istanza flessibile di Azure Database per PostgreSQL.

La modalità può essere selezionata solo in fase di creazione del server. Non può essere modificata da una modalità a un'altra per la durata del server.

Per ottenere la crittografia dei tuoi dati, il database di Azure per PostgreSQL utilizza la crittografia di archiviazione di Azure per i dati a riposo. Quando si usa la chiave gestita dal cliente, il cliente deve fornire le chiavi per crittografare e de-crittografare i dati nei servizi archiviazione BLOB e File di Azure. Queste chiavi devono essere archiviate in Azure Key Vault o nel modulo di protezione hardware gestito di Azure Key Vault. 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

Con la chiave di crittografia gestita dal cliente si assume la responsabilità. Di conseguenza, è necessario distribuire Azure Key Vault o il proprio modulo di protezione hardware Azure Key Vault. È necessario generare o importare la propria chiave. È necessario concedere le autorizzazioni necessarie per Key Vault, in modo che l'istanza del server flessibile di Database di Azure per PostgreSQL possa eseguire le azioni necessarie sulla chiave. È necessario configurare tutti gli aspetti di rete dell'Azure Key Vault in cui è memorizzata la chiave, in modo che l'istanza del server flessibile di Azure Database 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 dell'istanza 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.

Di seguito è riportato l'elenco dei requisiti per configurare la crittografia dei dati per Database di Azure per PostgreSQL:

• Per le configurazioni CMK a tenant singolo, Key Vault e l'istanza di Database di Azure per PostgreSQL - Server flessibile devono appartenere allo stesso tenant di Microsoft Entra. Per gli scenari cross-tenant, vedi Chiavi gestite dal cliente cross-tenant. Lo spostamento della risorsa Key Vault richiede successivamente di riconfigurare la crittografia dei dati.
• Si consiglia di impostare la configurazione dei 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, deve comunque essere valida. Tuttavia, se si vuole 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à di eliminazione temporanea in Key Vault per aiutare a 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 attivarla usando l'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.
• Concedere all'identità gestita assegnata dall'utente dell'istanza del server flessibile di Database di Azure per PostgreSQL l'accesso alla chiave tramite:
• Preferito: Azure Key Vault deve essere configurato con il modello di autorizzazione controllo degli accessi in base al ruolo e all'identità gestita deve essere assegnato il ruolo utente di crittografia del servizio di crittografia Key Vault..
• 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. È consigliabile 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

La chiave gestita dal cliente può essere configurata con rotazione manuale delle chiavi e aggiornamenti, o con aggiornamenti automatici delle versioni delle chiavi dopo una rotazione manuale o automatica delle chiavi, nell'insieme di credenziali delle chiavi.

Per informazioni dettagliate, 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 nell'istanza del server flessibile di Azure Database per PostgreSQL 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. Per effettuare il provisioning di questa modalità, specificare un URI della chiave, incluso il GUID della versione GUID nell'URI. Ad esempio: https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Fino a poco tempo fa questa era l'unica opzione disponibile.

Ogni volta che si ruotava manualmente la chiave oppure AKV la ruotava automaticamente in base ai criteri di rotazione, era necessario aggiornare la proprietà CMK sull'istanza 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 CMK nella tua istanza PostgreSQL dopo la rotazione della chiave. PostgreSQL preleva automaticamente la nuova versione della chiave e crittografa nuovamente la chiave di crittografia dei dati. Ciò semplifica notevolmente la gestione del ciclo di vita delle chiavi, soprattutto se combinato con la rotazione automatica di Key Vault.

Per implementare l'uso di 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:

• Per impedire l'eliminazione accidentale o non autorizzata di questa risorsa critica, impostare un blocco delle risorse in Key Vault.
• 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 del server alla chiave eseguendo le operazioni seguenti:

• 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 che l'istanza del server flessibile di Database di Azure per PostgreSQL viene crittografata 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:

• Avviare il processo di ripristino o il processo di creazione di una replica in lettura dall'istanza primaria del Server flessibile 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, non è supportata la revoca delle chiavi 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 creano nuove istanze del Server flessibile di Database di Azure per PostgreSQL nel portale di Azure con la chiave gestita dal cliente è possibile scegliere HSM gestito di Azure Key Vault come archivio chiavi in alternativa ad 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, è necessario l'accesso continuo a questa chiave affinché il server rimanga online. In caso contrario, il server modifica lo stato in Inaccessibile e inizia a negare tutte le connessioni.

Alcuni dei possibili motivi per cui lo stato del server potrebbe diventare inaccessibile sono:

Ripristino dall'eliminazione dell'identità gestita

Se l'identità gestita assegnata dall'utente usata per accedere alla chiave di crittografia archiviata in Key Vault viene eliminata in Microsoft Entra ID, è necessario seguire questa procedura per ripristinare:

1. Recuperare l'identità o creare una nuova identità Entra ID gestita.
2. Se è stata creata una nuova identità, anche se ha lo stesso nome precedente all'eliminazione, aggiornare il database di Azure per le proprietà dell'istanza del server flessibile 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. Di seguito sono riportati i requisiti per configurare la crittografia dei dati con i CMK e queste funzionalità, oltre ai requisiti di base per la crittografia dei dati con CMK:

• La chiave di crittografia del backup con ridondanza geografica deve essere creata 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, è consigliabile creare l'identità gestita dall'utente nella stessa area 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. L'identità assegnata dall'utente per l'autenticazione in questa istanza di Key Vault deve essere creata 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 all'istanza del 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

Nell'istanza del cliente

1. Installare l'applicazione multi-tenant

2. Crea o usa un insieme di credenziali delle chiavi esistente o un HSM gestito esistente e concedi 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'istanza di 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'istanza di Database di Azure per PostgreSQL con chiavi gestite dal cliente, è necessario assicurarsi che abbia accesso alle chiavi usate dal cliente. Negli scenari single-tenant, si concede direttamente all'identità gestita dall'utente dell'istanza di Database di Azure per PostgreSQL l'accesso all'insieme di credenziali delle chiavi. 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 cross-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 applicazione cross-tenant, è quella che si usa quando si crea la chiave gestita dal cliente (CMK) cross-tenant per l'istanza di Database di Azure per PostgreSQL.

Ogni volta che nell'insieme di credenziali è disponibile una nuova versione della chiave, l'istanza di Database di Azure per PostgreSQL usa automaticamente la nuova versione.

Usare il portale di Azure

Per configurare chiavi gestite dal cliente tra tenant per una nuova istanza di 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

• Questa funzionalità non è ancora supportata in Azure PowerShell o interfaccia della riga di comando di Azure.
• 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'istanza del 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'istanza del server flessibile di Database di Azure per PostgreSQL esistente. In alternativa è possibile ripristinare un backup di recupero temporizzato 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 del modulo di protezione hardware gestito di Azure Key Vault o dell'istanza di Azure Key Vault in cui si prevede di archiviare la chiave di crittografia deve esistere nella stessa area in cui viene creata l'istanza di Database di Azure per il server flessibile.

Contenuti correlati

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