Crittografia dei dati di Database di Azure per MySQL con una chiave gestita dal cliente

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

Importante

Database di Azure per MySQL server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per MySQL server flessibile. Per altre informazioni sulla migrazione a Database di Azure per MySQL server flessibile, vedere Che cosa accade a Database di Azure per MySQL server singolo?

La crittografia dei dati con chiavi gestite dal cliente per Database di Azure per MySQL consente di usare 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, si è responsabili e in un controllo completo 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 il servizio Database di Azure per MySQL 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, importarla o fare in modo che venga trasferita da un dispositivo HSM locale.

Nota

Questa funzionalità è supportata solo per l'archiviazione "Archiviazione per utilizzo generico v2 (supporto fino a 16 TB)" disponibile nei piani tariffari Per utilizzo generico e Ottimizzato per la memoria. Per altri dettagli, vedere Archiviazione concetti. Per altre limitazioni, vedere la sezione relativa alle limitazioni .

Vantaggi

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

• Accesso ai dati completamente controllato dall'utente, grazie alla possibilità di rimuovere la chiave e rendere inaccessibile il database
• Controllo completo del ciclo di vita della chiave, inclusa la rotazione della chiave per soddisfare i criteri aziendali
• Gestione centralizzata e organizzazione delle chiavi in Azure Key Vault
• Possibilità di implementare la separazione dei compiti tra i responsabili della sicurezza, gli amministratori di database e gli amministratore di sistema

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 MySQL 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 MySQL.
• unwrapKey: per poter decrittografare la chiave DEK. Database di Azure per MySQL 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 Key Vault, se la registrazione è abilitata.

Requisiti per la configurazione della crittografia dei dati per Database di Azure per MySQL

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

• Key Vault e Database di Azure per MySQL 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.
• Abilitare la funzionalità di eliminazione temporanea nell'insieme di credenziali delle chiavi con periodo di conservazione impostato su 90 giorni, per evitare la perdita di dati se si verifica un'eliminazione accidentale della chiave (o dell'insieme di credenziali delle chiavi). Le risorse eliminate temporaneo vengono mantenute per 90 giorni per impostazione predefinita, a meno che il periodo di conservazione non sia impostato in modo esplicito su <=90 giorni. 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 funzionalità Protezione ripulitura nell'insieme di credenziali delle chiavi con periodo di conservazione impostato su 90 giorni. La protezione dalla rimozione definitiva può essere abilitata solo dopo l'abilitazione dell'eliminazione temporanea. Può essere attivato tramite l'interfaccia della riga di comando di Azure o PowerShell. Quando la protezione dall'eliminazione è attivata, non è possibile eliminare un insieme di credenziali o un oggetto nello stato eliminato finché non viene superato il periodo di conservazione. Gli insiemi di credenziali e oggetti eliminati temporaneamente possono ancora essere recuperati, assicurando il rispetto dei criteri di conservazione.
• Concedere a Database di Azure per MySQL 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 in MySQL. Per istruzioni dettagliate nel caso in cui si usi il portale di Azure, vedere Configurare la crittografia dei dati per MySQL.

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. Data di scadenza non impostata.
• La chiave deve avere lo stato Abilitato.
• La chiave deve avere l'eliminazione temporanea con periodo di conservazione impostato su 90 giorni. In questo modo viene impostato in modo implicito il valore di recoveryLevel dell'attributo chiave richiesto: "Ripristinabile". Se la conservazione è impostata su < 90 giorni, recoveryLevel: "CustomizedRecoverable", che non è il requisito, quindi assicurarsi di impostare il periodo di conservazione su 90 giorni.
• La chiave deve avere la protezione di ripulitura abilitata.
• 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 Database di Azure per MySQL si trovino nella stessa area, per garantire un accesso più rapido per le operazioni di 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 Database di Azure per MySQL con la crittografia dei dati abilitata, il nuovo server creato avrà lo stato Inaccessibile. È possibile correggere questo problema tramite il portale di Azure o l'interfaccia della riga di comando.
• Se si crea una replica in lettura per Database di Azure per MySQL con la crittografia dei dati abilitata, il server di replica avrà lo stato Inaccessibile. È possibile correggere questo problema tramite il portale di Azure o l'interfaccia della riga di comando.
• Se si elimina l'istanza di KeyVault, Database di Azure per MySQL non può accedere alla chiave e passa 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, Database di Azure per MySQL non può accedere alla chiave e passa 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 Database di Azure per MySQL passa 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 , wrapKeye unwrapKey dell'insieme di getcredenziali 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 eseguita la crittografia di Database di Azure per MySQL 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 questi passaggi nei server di origine e di replica ripristinati:

• Avviare il processo di creazione della replica di ripristino o lettura dal Database di Azure per MySQL di origine.
• 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 o di replica ripetere la convalida della chiave gestita dal cliente nelle impostazioni di crittografia dei dati per assicurarsi che il server appena creato disponga di autorizzazioni di wrapping e annullamento del wrapping per la chiave archiviata in Key Vault.

Limiti

Per Database di Azure per MySQL, 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 nei server, che supportano l'archiviazione per utilizzo generico v2 (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 MySQL creati nelle aree di Azure che supportano l'archiviazione per utilizzo generico v2, è 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 l'archiviazione per utilizzo generico del server di cui è stato effettuato il provisioning v2, è 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 si trova nell'archiviazione per utilizzo generico v1 e non supporterà la crittografia con chiavi gestite dal cliente. Tuttavia, i dati vengono crittografati con chiavi gestite dal servizio in qualsiasi momento. Se hai domande, contattati AskAzureDBforMySQL@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 database di Azure per MySQL usando il portale di Azure e l'interfaccia della riga di comando di Azure.
• Informazioni sul supporto del tipo di archiviazione per Database di Azure per MySQL - Server singolo