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

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

Importante

Database di Azure per PostgreSQL - Server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per PostgreSQL - Server flessibile. Per altre informazioni sulla migrazione a Database di Azure per PostgreSQL - Server flessibile, vedere What's happening to Database di Azure per PostgreSQL Single Server?.

Azure PostgreSQL sfrutta Archiviazione di Azure crittografia per crittografare i dati inattivi per impostazione predefinita usando chiavi gestite da Microsoft. Per gli utenti di Azure PostgreSQL, è molto simile a Transparent Data Encryption (TDE) in altri database, ad esempio SQL Server. Molte organizzazioni richiedono il controllo completo sull'accesso ai dati usando una chiave gestita dal cliente. La crittografia dei dati con chiavi gestite dal cliente per server singolo di Database di Azure per PostgreSQL consente di usare il modello Bring Your Own Key (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 gestita dal cliente, l'utente è responsabile e, in pieno controllo, del ciclo di vita di una chiave, delle autorizzazioni di utilizzo delle chiavi e del controllo delle operazioni sulle chiavi.

La crittografia dei dati con chiavi gestite dal cliente per server singolo di Database di Azure per PostgreSQL viene impostata a livello di server. Per un determinato server, una chiave gestita dal cliente, detta chiave KEK (Key Encryption Key), viene usata per crittografare la chiave DEK (Data Encryption Key) usata dal servizio. La chiave KEK è una chiave asimmetrica archiviata in un'istanza di Azure Key Vault di proprietà del cliente e gestita dal cliente. Le chiavi KEK e DEK vengono descritte in maggior dettaglio più avanti in questo articolo.

Key Vault è un sistema esterno di gestione delle chiavi basato sul cloud. È a disponibilità elevata e offre un'archiviazione sicura e scalabile per le chiavi crittografiche RSA, supportata facoltativamente da moduli di protezione hardware convalidati FIPS 140. Non consente l'accesso diretto a una chiave archiviata, ma offre servizi di crittografia e decrittografia per le entità autorizzate. Key Vault può generare la chiave, la può importare o può fare in modo che venga trasferita da un dispositivo HMS locale.

Nota

Questa funzionalità è disponibile in tutte le aree di Azure in cui il server singolo di Database di Azure per PostgreSQL supporta i piani tariffari di server per utilizzo generico e ottimizzati per la memoria. Per altre limitazioni, vedere la sezione relativa alle limitazioni .

Vantaggi

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

• L'accesso ai dati è completamente controllato dall'utente tramite la possibilità di rimuovere la chiave e rendere il database inaccessibile.
• Controllo completo del ciclo di vita delle chiavi, inclusa la rotazione della chiave da allineare ai criteri aziendali.
• Gestione centralizzata e organizzazione delle chiavi in Azure Key Vault.
• L'abilitazione della crittografia non ha alcun impatto aggiuntivo sulle prestazioni con o senza la chiave gestita dai clienti perché PostgreSQL si basa sul livello di archiviazione di Azure per la crittografia dei dati in entrambi gli scenari, l'unica differenza è quando la chiave gestita dal cliente viene usata Archiviazione di Azure chiave di crittografia che esegue la crittografia dei dati effettiva viene crittografata tramite la chiave gestita dal cliente.
• Possibilità di implementare la separazione dei compiti tra i responsabili della sicurezza e gli amministratori di sistema e DBA.

Terminologia e descrizione

Chiave DEK (Data Encryption Key): chiave AES256 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. È necessario l'accesso alle chiavi DEK per il provider di risorse o l'istanza dell'applicazione che esegue la crittografia e la decrittografia di un blocco specifico. 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): chiave di crittografia usata per crittografare i 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 la chiave DEK. Poiché è necessaria la chiave KEK per decrittografare le chiavi DEK, la chiave KEK è di fatto un singolo punto che consente di eliminare in modo efficace le chiavi DEK eliminando la chiave KEK.

Le chiavi DEK, crittografate con chiavi 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 gestita dal cliente

Affinché un server PostgreSQL usi chiavi gestite dal cliente archiviate in Key Vault per la crittografia della chiave DEK, un amministratore di Key Vault concede al server i diritti di accesso seguenti:

• get: per recuperare la parte pubblica e le proprietà della chiave nell'insieme di credenziali delle chiavi.
• wrapKey: per poter crittografare la chiave DEK. La chiave DEK crittografata viene archiviata nella Database di Azure per PostgreSQL.
• unwrapKey: per poter decrittografare la chiave DEK. Database di Azure per PostgreSQL richiede la chiave DEK decrittografata per crittografare/decrittografare i dati

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

Se il server è configurato per l'uso della chiave gestita dal cliente archiviata nell'insieme di credenziali delle chiavi, il server invia la chiave DEK all'insieme di credenziali delle chiavi per la crittografia. Key Vault restituisce la chiave DEK crittografata, che viene archiviata nel database utente. Analogamente, se necessario, il server invia la chiave DEK protetta all'insieme di credenziali delle chiavi per la decrittografia. I revisori possono usare Monitoraggio di Azure per esaminare i log degli eventi di controllo di Azure Key Vault, se la registrazione è abilitata.

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

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

• Key Vault e Database di Azure per PostgreSQL server singolo 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'insieme di credenziali delle chiavi deve essere impostato con 90 giorni per "Giorni per conservare gli insiemi di credenziali eliminati". Se l'insieme di credenziali delle chiavi esistente è stato configurato con un numero inferiore, sarà necessario creare un nuovo insieme di credenziali delle chiavi perché non può essere modificato dopo la creazione.
• Abilitare la funzionalità di eliminazione temporanea nell'insieme di credenziali delle chiavi per evitare la perdita di dati in caso di eliminazione accidentale della chiave (o di Key Vault). Le risorse eliminate temporaneamente vengono conservate per 90 giorni, a meno che nel frattempo non vengano recuperate o rimosse definitivamente dall'utente. Alle azioni di recupero e rimozione definitiva sono associate autorizzazioni specifiche nei criteri di accesso di Key Vault. La funzionalità di eliminazione temporanea è disattivata per impostazione predefinita, ma è possibile abilitarla tramite PowerShell o con l'interfaccia della riga di comando di Azure (si noti che non è possibile abilitarla tramite il portale di Azure).
• Abilitare la protezione ripulitura per applicare un periodo di conservazione obbligatorio per gli insiemi di credenziali eliminati e gli oggetti dell'insieme di credenziali
• Concedere al server singolo di Database di Azure per PostgreSQL l'accesso all'insieme di credenziali delle chiavi con le autorizzazioni get, wrapKey e unwrapKey usando l'identità gestita univoca. Nell'portale di Azure, l'identità univoca "Servizio" viene creata automaticamente quando la crittografia dei dati è abilitata nel server singolo PostgreSQL. Per le istruzioni dettagliate nel caso si usi il portale di Azure, vedere Crittografia dei dati per server singolo di Database di Azure per PostgreSQL tramite il portale di Azure.

Di seguito sono riportati i requisiti per la configurazione della chiave gestita dal cliente:

• La chiave gestita dal cliente da usare per la crittografia della chiave DEK può essere solo di tipo RSA 2048 e asimmetrica.
• La data di attivazione della chiave (se impostata) deve essere una data/ora nel passato. La data di scadenza (se impostata) deve essere una data/ora nel futuro.
• La chiave deve avere lo stato Abilitato.
• Se si importa una chiave esistente nell'insieme di credenziali delle chiavi, assicurarsi di specificarla nei formati di file supportati (.pfx, .byok, .backup).

Consigli

Se si usa la crittografia dei dati con una chiave gestita dal cliente, 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 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 possono essere facilmente inseriti in altri strumenti di informazioni di sicurezza e gestione degli eventi (SIEM, Security Information and Event Management). Log Analytics di Monitoraggio di Azure è un esempio di un servizio già integrato.

• Assicurarsi che Key Vault e il server singolo di Database di Azure per PostgreSQL risiedano nella stessa area, per garantire un accesso più rapido per le operazioni wrapping e annullamento del wrapping della chiave DEK.

• Bloccare Azure KeyVault per limitarne l'accesso solo all'endpoint privato e alle reti selezionate e consentire solo a servizi Microsoft attendibili di proteggere le risorse.

  

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

• 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. Per altre informazioni sul comando di backup, vedere Backup-AzKeyVaultKey.

Condizione inaccessibile della chiave gestita dal cliente

Quando si configura la crittografia dei dati con una chiave gestita dal cliente in Key Vault, è necessario l'accesso continuo a questa chiave affinché il server resti online. Se perde l'accesso alla chiave gestita dal cliente 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 motivi per cui il server può raggiungere questo stato:

• Se si crea un server di ripristino temporizzato per il server singolo di Database di Azure per PostgreSQL, per cui è abilitata la crittografia dei dati, il server appena creato avrà lo stato Inaccessibile. È possibile correggere lo stato del server tramite il portale di Azure o l'interfaccia della riga di comando.
• Se si crea una replica in lettura per il server singolo di Database di Azure per PostgreSQL, per cui è abilitata la crittografia dei dati, il server di replica avrà lo stato Inaccessibile. È possibile correggere lo stato del server tramite il portale di Azure o l'interfaccia della riga di comando.
• Se si elimina l'istanza di KeyVault, il server singolo di Database di Azure per PostgreSQL non potrà accedere alla chiave e passerà allo stato Inaccessibile. Recuperare Key Vault e ripetere la convalida della crittografia dei dati per rendere il server Disponibile.
• Se si elimina la chiave da KeyVault, il server singolo di Database di Azure per PostgreSQL non potrà accedere alla chiave e passerà allo stato Inaccessibile. Recuperare lachiave e ripetere la convalida della crittografia dei dati per rendere il server Disponibile.
• Se la chiave archiviata in Azure KeyVault scade, diventa non valida e il server singolo di Database di Azure per PostgreSQL passerà allo stato Inaccessibile. Estendere la data di scadenza della chiave usando l'interfaccia della riga di comando e ripetere la convalida della crittografia dei dati per rendere il server Disponibile.

Revoca accidentale dell'accesso alla chiave da Key Vault

È possibile che un utente con diritti di accesso sufficienti per Key Vault disabiliti accidentalmente l'accesso del server alla chiave eseguendo le operazioni seguenti:

• Revoca delle autorizzazioni get, wrapKey e unwrapKey dell'insieme di credenziali delle chiavi dal server.

• Eliminazione della chiave.

• Eliminare il key vault.

• Modifica delle regole del firewall dell'insieme di credenziali delle chiavi.

• Eliminazione dell'identità gestita del server in Microsoft Entra ID.

Monitorare la chiave gestita dal cliente in Key Vault

Per monitorare lo stato del database e abilitare gli avvisi per la perdita dell'accesso alla protezione di Transparent Data Encryption, configurare le funzionalità di Azure seguenti:

• Azure Integrità risorse: un database inaccessibile che ha perso l'accesso alla chiave del cliente viene visualizzato come "Inaccessibile" dopo che la prima connessione al database è stata negata.

• Log attività: quando l'accesso alla chiave del cliente nell'insieme di credenziali delle chiavi gestito dal cliente ha esito negativo, le voci vengono aggiunte al log attività. Se si creano avvisi per questi eventi, è possibile ripristinare l'accesso tempestivamente.

• Gruppi di azioni: definire questi gruppi per inviare notifiche e avvisi in base alle preferenze.

Eseguire il ripristino e la replica con una chiave gestita del cliente in Key Vault

Una volta crittografato il server singolo di Database di Azure per PostgreSQL con una chiave gestita dal cliente archiviata in Key Vault, viene crittografata anche qualsiasi nuova copia creata del server. Questa nuova copia può essere creata tramite un'operazione di ripristino locale o geografico oppure tramite repliche in lettura. Tuttavia, la copia può essere modificata in modo da riflettere una nuova chiave gestita dal cliente per la crittografia. Quando la chiave gestita dal cliente cambia, i backup precedenti del server iniziano a usare la chiave più recente.

Per evitare problemi durante la configurazione della crittografia dei dati gestita dal cliente durante il ripristino o la creazione di repliche in lettura, è importante seguire questa procedura nei server primario e ripristinato/replica:

• Avviare il processo di creazione della replica di ripristino o lettura dal server singolo Database di Azure per PostgreSQL primario.
• Mantenere il server appena creato (ripristinato/di replica) in uno stato inaccessibile, perché la relativa identità univoca non ha ancora ricevuto le autorizzazioni per Key Vault.
• Nel server ripristinato/replica ripetere la convalida della chiave gestita dal cliente nelle impostazioni di crittografia dei dati. In questo modo ci si assicura che il server appena creato riceva autorizzazioni di wrapping e annullamento del wrapping per la chiave archiviata in Key Vault.

Limiti

Per Database di Azure per PostgreSQL, il supporto per la crittografia dei dati inattivi tramite la chiave gestita dai clienti (CMK) presenta alcune limitazioni:

• Il supporto per questa funzionalità è limitato ai piani tariffari per utilizzo generico e ottimizzato per la memoria.

• Questa funzionalità è supportata solo nelle aree e sui server che supportano l'archiviazione fino a 16 TB. Per l'elenco delle aree di Azure che supportano l'archiviazione fino a 16 TB, vedere la sezione archiviazione nella documentazione qui

  Nota

  • Tutti i nuovi server PostgreSQL creati nelle aree elencate in precedenza, è disponibile il supporto per la crittografia con le chiavi di Customer Manager. Il server temporizzato ripristinato (PITR) o la replica di lettura non sarà idoneo anche se in teoria sono "new".
  • Per verificare se il server di cui è stato effettuato il provisioning supporta fino a 16 TB, è possibile passare al pannello del piano tariffario nel portale e visualizzare le dimensioni massime di archiviazione supportate dal server di cui è stato effettuato il provisioning. Se è possibile spostare il dispositivo di scorrimento fino a 4 TB, il server potrebbe non supportare la crittografia con chiavi gestite dal cliente. Tuttavia, i dati vengono crittografati con chiavi gestite dal servizio in qualsiasi momento. Se hai domande, contattati AskAzureDBforPostgreSQL@service.microsoft.com .

• La crittografia è supportata solo con la chiave crittografica RSA 2048.

Passaggi successivi

Informazioni su come configurare la crittografia dei dati con una chiave gestita dal cliente per il server singolo di Database di Azure per PostgreSQL usando il portale di Azure.