Condividi tramite

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

  • Articolo

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

Importante

Il server singolo del Database di Azure per MySQL è in fase di ritiro. È consigliabile eseguire l'aggiornamento al server flessibile del Database di Azure per MySQL. Per altre informazioni sulla migrazione a un server flessibile del Database di Azure per MySQL, vedere Che cosa sta succedendo al server singolo del Database di Azure per MySQL?

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, 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 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. 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 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 nell'archiviazione "Archiviazione per utilizzo generico v2 (supporto fino a 16 TB)" disponibile nei piani tariffari Per utilizzo generico e Ottimizzata per la memoria. Per altri dettagli, vedere Concetti relativi all'archiviazione. Per altre limitazioni, vedere la sezione relativa alla limitazione.

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): una 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): una 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 nel Key Vault.
  • wrapKey: per poter crittografare la chiave DEK. La chiave DEK crittografata viene archiviata in 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 Azure 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 temporaneamente 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 dalla rimozione definitiva 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 attivata tramite l'interfaccia della riga di comando di Azure o PowerShell. Quando la protezione dalla rimozione definitiva è attivata, un insieme di credenziali o un oggetto nello stato eliminato non può essere rimosso finché non ha 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. Nel portale di Azure l'identità “Servizio” univoca 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 eliminazione temporanea con periodo di conservazione impostato su 90 giorni. In questo modo viene impostato in modo implicito l'attributo chiave richiesto recoveryLevel: “Recuperabile”. Se la conservazione è impostata su < 90 giorni, recoveryLevel: "CustomizedRecoverable", che non è il requisito, assicurarsi di impostare il periodo di conservazione su 90 giorni.
  • La chiave deve avere la protezione dalla rimozione definitiva 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 dell'insieme di credenziali get, wrapKey e unwrapKey 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:

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

  • Log attività: quando l'accesso alla chiave del cliente nell'istanza di Key Vault gestita dal cliente non riesce, nel log attività vengono aggiunte voci. Se si creano avvisi per questi eventi, è possibile ripristinare l'accesso tempestivamente.

  • Gruppi di azioni: definire questi gruppi per l'invio di 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 con la configurazione della crittografia dei dati gestita dal cliente durante il ripristino o la creazione della replica in lettura, è importante seguire questa procedura nei server di origine e di replica o ripristinato:

  • Avviare il processo di ripristino o di creazione della replica in lettura dall'istanza di origine di Database di Azure per MySQL.
  • 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 Ottimizzata per la memoria.

  • Questa funzionalità è supportata solo in aree e 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 relativa all’archiviazione nella documentazione qui

    Nota

    • Per 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 di ripristino temporizzato (PITR) o la replica in lettura non sono idonei, anche se in teoria sono "nuovi".
    • Per convalidare 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 in archiviazione per utilizzo generico v1 e non supporterà la crittografia con chiavi gestite dal cliente. Tuttavia, i dati vengono crittografati in qualsiasi momento, usando le chiavi gestite dal servizio.

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

Passaggi successivi