Crittografia dei dati per server flessibile di Database di Azure per PostgreSQL con una chiave gestita dal cliente

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

Il server flessibile di Database di Azure per PostgreSQL usa la crittografia di Archiviazione di Azure per crittografare i dati inattivi per impostazione predefinita, usando chiavi gestite da Microsoft. Per gli utenti del server flessibile di Database di Azure per PostgreSQL, è simile a Transparent Data Encryption in altri database, ad esempio SQL Server.

Molte organizzazioni richiedono il controllo completo dell'accesso ai dati usando una chiave gestita dal cliente (CMK). La crittografia dei dati con CMK per il server flessibile di Database di Azure per PostgreSQL consente di portare la chiave (BYOK) per la protezione dei dati inattivi. Consente anche alle organizzazioni di implementare la separazione dei compiti nella gestione delle chiavi e dei dati. Con la crittografia CMK, l'utente è responsabile e in pieno controllo del ciclo di vita di una chiave, delle autorizzazioni di uso delle chiavi e del controllo delle operazioni sulle chiavi.

La crittografia dei dati con CMK per il server flessibile di Database di Azure per PostgreSQL è impostata a livello di server. Per un determinato server, viene usato un tipo di CMK denominata chiave di KEK (chiave della chiave di crittografia) per crittografare la chiave DEK (Data Encryption Key) del servizio. La chiave KEK è una chiave asimmetrica archiviata in un'istanza di Azure Key Vault di proprietà del cliente e gestita dal cliente. La chiave KEK e la chiave DEK sono descritte in modo più dettagliato più avanti in questo articolo.

Key Vault è un sistema esterno di gestione delle chiavi 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 fare in modo che venga trasferita da un dispositivo HSM locale.

Vantaggi

La crittografia dei dati con CMK per il server flessibile di 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 le chiavi in Key Vault.

• L'attivazione della crittografia non influisce sulle prestazioni con o senza CMK, perché PostgreSQL si basa sul livello di Archiviazione di Azure per la crittografia dei dati in entrambi gli scenari. L'unica differenza è che quando si usa una chiave CMK, la chiave di crittografia di Archiviazione di Azure (che esegue la crittografia dei dati effettiva) viene crittografata.

• È possibile implementare la separazione dei compiti tra i responsabili della sicurezza, gli amministratori di database e gli amministratore di sistema.

Terminologia

Chiave DEK (Data Encryption Key): una chiave AES 256 simmetrica usata per crittografare una partizione o un blocco di dati. La crittografia di ogni blocco di dati con una chiave diversa rende più complessi gli attacchi di crittoanalisi. Il provider di risorse o l'istanza dell'applicazione che crittografa e decrittografa un blocco specifico deve accedere ai DEK. Quando una chiave DEK viene sostituita con una nuova chiave, è necessario ripetere la crittografia con la nuova chiave solo per i dati nel blocco associato.

Chiave di crittografia della chiave (KEK): una chiave di crittografia usata per crittografare le chiavi DEK. Una chiave KEK che non lascia mai Key Vault consente la crittografia e il controllo delle chiavi DEK. L'entità che ha accesso alla chiave KEK può essere diversa da quella che richiede chiavi DEK. Poiché la chiave KEK è necessaria per decrittografare i DEK, la chiave KEK è in effetti un singolo punto in base al quale è possibile eliminare le chiavi DEK (eliminando la chiave KEK).

Le chiavi DEK, crittografate con una chiave KEK, vengono archiviate separatamente. Solo un'entità con accesso alla chiave KEK può decrittografare queste chiavi DEK. Per altre informazioni, vedere Sicurezza della crittografia di dati inattivi.

Funzionamento della crittografia dei dati con una chiave CMK

Un'identità gestita assegnata dall'utente di Microsoft Entra viene usata per connettersi e recuperare una chiave gestita. Per creare un'identità, seguire questa esercitazione.

Affinché un server PostgreSQL usi chiavi CMK in Key Vault per la crittografia della chiave DEK, un amministratore di Key Vault concede all'identità gestita creata i diritti di accesso seguenti:

• get: per recuperare la parte pubblica e le proprietà della chiave nel Key Vault.

• list: per l'elenco e l'iterazione delle chiavi in Key Vault.

• wrapKey: per crittografare la chiave DEK. La chiave DEK crittografata viene archiviata in Database di Azure per PostgreSQL.

• unwrapKey: per decrittografare la chiave DEK. Database di Azure per PostgreSQL richiede la chiave DEK decrittografata per crittografare e decrittografare i dati.

L'amministratore di Key Vault può anche abilitare la registrazione degli eventi di controllo di Key Vault, in modo che possano essere controllati in un secondo momento.

In alternativa all'assegnazione dei diritti di accesso, come illustrato in precedenza, è possibile creare una nuova assegnazione di ruolo controllo degli accessi in base al ruolo con il ruolo Key Vault Crypto Service Encryption User.

Importante

Se non si specificano i diritti di accesso o l'assegnazione di controllo degli accessi in base al ruolo precedente a un'identità gestita per l'accesso a Key Vault, potrebbe non essere possibile recuperare una chiave di crittografia e non configurare la funzionalità CMK.

Quando si configura il server per l'uso della chiave gestita dal cliente archiviato in Key Vault, il server invia la chiave DEK all'insieme di credenziali delle chiavi per la crittografia. Key Vault restituisce la chiave DEK crittografata archiviata nel database utente. Quando necessario, il server invia la chiave DEK protetta a Key Vault per la decrittografia. I revisori possono usare Monitoraggio di Azure per esaminare i log degli eventi di controllo di Key Vault, se la registrazione è attiva.

Requisiti per la configurazione della crittografia dei dati per il server flessibile di Database di Azure per PostgreSQL

Di seguito sono illustrati i requisiti per la configurazione di Key Vault:

• Key Vault e il server flessibile di Database di Azure per PostgreSQL devono appartenere allo stesso tenant di Microsoft Entra. Le interazioni di server e Key Vault tra più tenant non sono supportate. Lo spostamento della risorsa Key Vault richiede successivamente di riconfigurare la crittografia dei dati.

• L'impostazione Giorni per conservare gli insiemi di credenziali eliminati per Key Vault deve essere 90. Se l'istanza di Key Vault esistente è stata configurata con un numero inferiore, è necessario creare una nuova istanza di Key Vault perché non è possibile modificare un'istanza dopo la creazione.

• È consigliabile impostare giorni per conservare la configurazione degli insiemi di credenziali eliminati per Key Vault su 90 giorni. Nel caso in cui sia 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 modificarne la configurazione.

• Abilitare la funzionalità di eliminazione temporanea 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 le proprie autorizzazioni associate ai criteri di accesso di Key Vault.

  La funzionalità di eliminazione temporanea è disattivata per impostazione predefinita, ma è possibile attivarla tramite PowerShell o l'interfaccia della riga di comando di Azure. Non è possibile attivarla tramite il portale 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'istanza del server flessibile di Database di Azure per PostgreSQL l'accesso a Key Vault con le autorizzazioni get, list, wrapKey e unwrapKey usando la relativa identità gestita univoca. In alternativa, creare una nuova assegnazione di ruolo controllo degli accessi in base al ruolo con il ruolo Key Vault Crypto Service Encryption User per l'identità gestita.

Ecco i requisiti per la configurazione della chiave gestita dal cliente nel server flessibile di Database di Azure per PostgreSQL:

• La chiave CMK da usare per crittografare la chiave DEK può essere solo asimmetrica, RSA o RSA-HSM. Sono supportate le dimensioni delle chiavi pari a 2.048, 3.072 e 4.096.

• 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 avere lo stato *Enabled-.

• Se si importa una chiave esistente in Key Vault, specificarla nei formati di file supportati (.pfx, .byok o .backup).

Consigli

Quando si usa una chiave gestita dal cliente per la crittografia dei dati, ecco le raccomandazioni per la configurazione di Key Vault:

• Impostare un blocco della risorsa in Key Vault per controllare chi può eliminare questa risorsa critica e per impedire l'eliminazione accidentale o non autorizzata.

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

  

Nota

Dopo aver selezionato Disabilita accesso pubblico e Consenti ai servizi Microsoft attendibili di ignorare questo firewall, è possibile che venga visualizzato un errore simile al seguente quando si tenta di usare l'accesso pubblico per amministrare Key Vault tramite il portale: "È stato abilitato il controllo di accesso alla rete. Solo le reti consentite avranno accesso a questo insieme di credenziali delle chiavi." Questo errore non impedisce la possibilità di fornire chiavi durante l'installazione della chiave gestita dal cliente o recuperare chiavi da Key Vault durante le operazioni del server.

Ecco le raccomandazioni per la configurazione di una chiave gestita dal cliente:

• Mantenere una copia della chiave CMK in un luogo sicuro o depositarla 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.

Revoca accidentale dell'accesso alla chiave da 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:

• Revoca delle autorizzazioni list, get, wrapKey e unwrapKey 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.

Monitoraggio della chiave gestita dal cliente in Key Vault

Per monitorare lo stato del database e attivare gli avvisi per la perdita di accesso alla protezione Transparent Data Encryption, 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.

Ripristino con la chiave gestita di un cliente in Key Vault

Dopo che il server flessibile di Database di Azure per PostgreSQL viene crittografato con la chiave CMK archiviata in Key Vault, viene crittografata anche qualsiasi copia del server appena creata. È possibile eseguire questa nuova copia tramite un'operazione di ripristino temporizzato o repliche in lettura.

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

• Avviare il processo di ripristino o il processo di creazione di una replica in lettura dall'istanza del server flessibile di Database di Azure per PostgreSQL primaria.

• Nel server di replica o ripristinato è possibile modificare la chiave CMK e/o l'identità di Microsoft Entra usata per accedere a Key Vault nelle impostazioni di crittografia dei dati. In questo modo ci si assicura che il server appena creato riceva autorizzazioni list, wrap e unwrap per la chiave archiviata in Key Vault.

• Non revocare la chiave originale dopo il ripristino. Al momento, non è supportata la revoca delle chiavi dopo il ripristino di un server abilitato per CMK in un altro server.

HSM 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 funzionalità CMK, è possibile scegliere HSM gestito di Azure Key Vault come archivio chiavi come 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 CMK inaccessibile

Quando si configura la crittografia dei dati con una chiave CMK in Key Vault, è necessario l'accesso continuo a questa chiave affinché il server resti online. Se perde l'accesso alla chiave CMK in Key Vault, il server inizia a negare tutte le connessioni entro 10 minuti. Il server genera un messaggio di errore corrispondente e cambia il proprio stato in Inaccessibile.

Ecco alcuni dei motivi per cui lo stato del server diventa inaccessibile:

• Se si elimina l'istanza di Key Vault, l'istanza del server flessibile di Database di Azure per PostgreSQL non può accedere alla chiave e passa a uno stato Inaccessibile. Per rendere Disponibile server, ripristinare l'istanza di Key Vault e riconvalidare la crittografia dei dati.
• Se si elimina la chiave da Key Vault, l'istanza del server flessibile di Database di Azure per PostgreSQL non può accedere alla chiave e passa a uno stato Inaccessibile. Per rendere il server Disponibile, ripristinare la chiave e riconvalidare la crittografia dei dati.
• Se si elimina a Microsoft Entra ID un'identità gestita usata per recuperare una chiave da Key Vault o eliminando l'assegnazione di ruolo controllo degli accessi in base al ruolo con il ruolo Utente crittografia del servizio di crittografia di Key Vault. L'istanza del server flessibile di Database di Azure per PostgreSQL non può accedere alla chiave e passa a uno stato Inaccessibile. Per rendere Disponibile il server, ripristinare l'identità e riconvalidare la crittografia dei dati.
• Se si revocano i criteri di accesso di Key Vault list, get, wrapKey, and unwrapKey dall'identità gestita usata per recuperare una chiave da Key Vault, l'istanza del server flessibile di Database di Azure per PostgreSQL non può accedere alla chiave e passa a uno stato Inaccessibile. Aggiungere i criteri di accesso necessari all'identità in Key Vault.
• Se si configurano regole del firewall di Key Vault eccessivamente restrittive, il server flessibile di Database di Azure per PostgreSQL non può comunicare con Key Vault per recuperare le chiavi. Quando si configura un firewall di Key Vault, assicurarsi di selezionare l'opzione per consentire ai servizi Microsoft attendibili di ignorare il firewall.

Nota

Quando una chiave è disabilitata, eliminata, scaduta o non raggiungibile, un server con dati crittografati tramite tale chiave diventa Inaccessibile, come indicato in precedenza. Il server non sarà disponibile finché non si riabilita la chiave o si assegna una nuova chiave.

In genere, un server diventa Inaccessibile entro 60 minuti dopo che una chiave è disabilitata, eliminata, scaduta o non raggiungibile. Dopo aver reso disponibile la chiave, il server potrebbe richiedere fino a 60 minuti per diventare nuovamente Accessibile.

Ripristino dall'eliminazione dell'identità gestita

In rari casi, quando l'identità gestita Entra ID, che viene usata dal CMK per recuperare una chiave da Azure Key Vault (AKV), viene eliminata in Microsoft Entra ID seguendo questa procedura consigliata per il ripristino:

1. Ripristinare o creare una nuova identità Entra ID gestita
2. Assicurarsi che questa identità disponga delle autorizzazioni appropriate per le operazioni sulla chiave in Azure Key Vault (AKV). A seconda del modello di autorizzazione dell'insieme di credenziali delle chiavi (criteri di accesso o controllo degli accessi in base al ruolo di Azure), è possibile concedere l'accesso all'insieme di credenziali delle chiavi creando criteri di accesso nell'insieme di credenziali delle chiavi (criteri di accesso list, get, wrapKey, and unwrapKey), oppure creando una nuova assegnazione di ruolo controllo degli accessi in base al ruolo di Azure con il ruolo Key Vault Crypto Service Encryption User.
3. Riconvalidare la crittografia dei dati CMK con un'identità nuova o ripristinata nel portale di Azure di Database di Azure per PostgreSQL - Crittografia dei dati del server flessibile.

Importante

La creazione di una nuova identità Entra ID con lo stesso nome dell'identità eliminata non viene ripristinata dall'eliminazione dell'identità gestita.

Uso della crittografia dei dati con CMK e funzionalità di continuità aziendale con ridondanza geografica

Il server flessibile di 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 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.

Limiti

Di seguito sono riportate le limitazioni correnti per la configurazione della chiave gestita dal cliente nel server flessibile di Database di Azure per PostgreSQL:

• È possibile configurare la crittografia CMK solo durante la creazione di un nuovo server, non come aggiornamento a un'istanza del server flessibile di Database di Azure per PostgreSQL esistente. È invece possibile ripristinare un backup di recupero temporizzato in un nuovo server con crittografia CMK.

• Dopo aver configurato la crittografia CMK, non è possibile rimuoverla. Se si vuole rimuovere questa funzionalità, l'unico modo consiste nel ripristinare il server in un server non CMK.

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

Passaggi successivi

• Informazioni su Microsoft Entra Domain Services.