Crittografia dei dati

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

Tutti i dati gestiti da un'istanza di Database di Azure per PostgreSQL flessibile vengono sempre crittografati inattivi. Tali dati includono tutti i database di sistema e utente, i file temporanei, i log del server, i segmenti di log write-ahead e i backup.

Per ottenere la crittografia dei dati, Database di Azure per PostgreSQL - Server flessibile usa la crittografia Archiviazione di Azure per i dati inattivi, fornendo chiavi per crittografare e decrittografare i dati nell'archiviazione BLOB e nei servizi 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 Archiviazione di Azure crittografia.

Database di Azure per PostgreSQL : il server flessibile supporta la configurazione della crittografia dei dati in due modalità diverse: chiave gestita dal servizio e chiave gestita dal cliente. La modalità di configurazione può essere selezionata solo in fase di creazione del server. Non può essere modificato da una modalità a un'altra per la durata del server.

Con la chiave di crittografia gestita dal servizio Database di Azure per PostgreSQL - Il server flessibile si occupa del provisioning dell'insieme di credenziali delle chiavi di Azure in cui vengono mantenute le chiavi e assume tutte le responsabilità di fornire la chiave con cui i dati vengono crittografati e decrittografati. Il servizio si occupa anche dell'archiviazione, della protezione, del controllo dell'accesso, della configurazione della rete e della rotazione automatica della chiave.

Con la chiave di crittografia gestita dal cliente si assume tutte le responsabilità. Di conseguenza, è necessario distribuire il proprio modulo di protezione hardware di Azure Key Vault o Azure Key Vault. È necessario generare o importare la propria chiave. È necessario concedere le autorizzazioni necessarie per Key Vault, in modo che il server flessibile Database di Azure per PostgreSQL possa eseguire le azioni necessarie sulla chiave. È necessario occuparsi della configurazione di tutti gli aspetti di rete dell'insieme di credenziali delle chiavi di Azure 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, è necessario ruotare la chiave e, quando necessario, aggiornare la configurazione del server flessibile 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 DEK (Root Data Encryption Key) per l'account con la chiave gestita dal cliente nell'insieme di credenziali delle chiavi associato o nel modulo di protezione hardware gestito. La protezione della chiave di crittografia radice cambia, ma i dati nell'account 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. Non consente l'accesso diretto a una chiave archiviata, ma fornisce servizi di crittografia e decrittografia alle entità autorizzate. Key Vault può generare la chiave, importarla o riceverla trasferita da un dispositivo HSM locale.

Vantaggi offerti da ogni modalità

La crittografia dei dati con chiavi gestite dal servizio per Database di Azure per PostgreSQL server flessibile 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 di

La crittografia dei dati con chiavi gestite dal cliente per Database di Azure per PostgreSQL server flessibile 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

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

• 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.
• È consigliabile impostare giorni per conservare la configurazione degli insiemi di credenziali eliminati per 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 facilitare la protezione 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 ed eliminazione hanno le proprie autorizzazioni associate a un insieme di credenziali delle chiavi di 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 un insieme di credenziali delle chiavi che è stato distribuito molto tempo fa, potrebbe essere ancora disabilitato l'eliminazione temporanea. 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 del server flessibile 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 Crittografia servizio crittografia crittografia key vault.
  • Legacy: se Azure Key Vault è configurato con il modello di autorizzazione criteri di accesso, concedere le autorizzazioni seguenti all'identità gestita:
    • get: per 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).

Elementi consigliati

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

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 o il recupero di chiavi da Key Vault durante le operazioni del server.

• Conservare una copia della chiave manged del cliente 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.

Considerazioni speciali

Revoca accidentale dell'accesso alla chiave da 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 Key Vault Utente crittografia servizio crittografia utente 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.

Monitoraggio delle chiavi mantenute 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.

Ripristino dei backup di un server configurato con una chiave gestita dal cliente

Dopo che Database di Azure per PostgreSQL server flessibile viene crittografato 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 o repliche in 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 del server flessibile di Database di Azure per PostgreSQL primaria.
• 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.

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 Database di Azure per PostgreSQL nel portale di Azure con la chiave gestita dal cliente, è possibile scegliere il modulo di protezione hardware 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 della chiave gestita dal cliente inaccessibile

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. Se il server perde l'accesso alla chiave mantenuta 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.

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

• Se si ruota la chiave e si dimentica di aggiornare l'istanza di Database di Azure per PostgreSQL server flessibile, in modo che punti alla nuova versione della chiave. La chiave precedente, a cui puntava l'istanza, alla fine scade e trasforma lo stato del server in Inaccessibile. Per evitare questo problema, ogni volta che si ruota la chiave, assicurarsi di aggiornare anche l'istanza del server in modo che punti alla nuova versione. A tale scopo, è possibile usare , az postgres flexible-server updateseguendo l'esempio che descrive "Modificare la chiave/identità per la crittografia dei dati. La crittografia dei dati non può essere abilitata dopo la creazione del server, ma aggiornerà solo la chiave o l'identità." In alternativa, è possibile richiamare l'API REST Servers - Update del servizio.
• 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 diventa 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 che la chiave diventa disponibile, il server potrebbe richiedere fino a 60 minuti per diventare nuovamente Accessibile .

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à dell'ID Entra gestita.
2. Se è stata creata una nuova identità, anche se ha lo stesso nome che aveva prima dell'eliminazione, aggiornare il database di 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.

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 chiavi gestite dal cliente 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 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.

Rotazione delle chiavi gestite dal cliente e chiavi senza versione (anteprima)

Come misura precauzionale, è consigliabile ruotare la chiave periodicamente o ogni volta che la chiave viene compromessa.

Nota

La maggior parte delle aziende ha requisiti esterni o interni per ruotare periodicamente le chiavi, ad esempio ogni 90 giorni. Per le chiavi generate da Key Vault, è possibile configurare l'autorotazione della chiave crittografica in Azure Key Vault. Se si abilita l'autorotazione, è necessario usare una chiave cmk senza versione (anteprima) per la crittografia dei dati in Database di Azure per PostgreSQL server flessibile per sfruttare questa funzionalità.

La rotazione manuale della chiave consente di proteggere i dati nel caso in cui la chiave venga compromessa. Per ruotare la chiave, creare o importare una nuova generazione di chiavi per la chiave compromessa.

• Se si usano chiavi gestite dal cliente senza versione (anteprima), il server preleva automaticamente la nuova chiave.
• Se si usano chiavi con versione, è necessario aggiornare l'istanza del server flessibile Database di Azure per PostgreSQL per usare la nuova versione della chiave. Solo successivamente, il server inizia a usare la nuova chiave per crittografare e decrittografare i dati.

Chiavi gestite dal cliente senza versione (anteprima)

Le chiavi senza versione sono consigliate per la crittografia dei dati in Database di Azure per PostgreSQL server flessibile. Copre correttamente uno degli scenari di rotazione delle chiavi descritti in precedenza. Dopo la disponibilità di una nuova versione della chiave, il server userà automaticamente la nuova versione della versione della chiave per crittografare e decrittografare i dati.

L'API non cambia per le chiavi senza versione. Anziché fornire l'intero URI dell'identificatore di chiave, omettere la parte della versione dell'identificatore di chiave. Questo vale per l'API, per l'interfaccia della riga di comando di Azure, per i modelli arm e per i modelli Bicep. portale di Azure dispone di una casella di controllo per abilitare la versione senza versione, che è possibile usare per selezionare solo l'identificatore di chiave senza versione.

Limiti

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

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

Contenuto correlato

• Configurare la crittografia dei dati.