Share via

Crittografia dei dati con chiavi gestite dal cliente per Database di Azure per MySQL - Server flessibile

  • Articolo

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

Con la crittografia dei dati con chiavi gestite dal cliente per Database di Azure per MySQL server flessibile, è possibile usare la propria chiave (BYOK) per la protezione dei dati inattivi e implementare la separazione dei compiti per la gestione di chiavi e dati. Con le chiavi gestite dal cliente (CMK), il cliente è responsabile e infine controlla la gestione del ciclo di vita delle chiavi (creazione, caricamento, rotazione, eliminazione), autorizzazioni di utilizzo delle chiavi e operazioni di controllo sulle chiavi.

Vantaggi

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

  • È possibile controllare completamente l'accesso ai dati grazie alla 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
  • Possibilità di implementare la separazione dei compiti tra i responsabili della sicurezza, il DBA e gli amministratori di sistema

Come funziona la crittografia dei dati con una chiave gestita dal cliente?

Le identità gestite in Microsoft Entra ID forniscono ai servizi di Azure un'alternativa all'archiviazione delle credenziali nel codice effettuando il provisioning di un'identità assegnata automaticamente che può essere usata per eseguire l'autenticazione a qualsiasi servizio che supporta l'autenticazione di Microsoft Entra, ad esempio Azure Key Vault (AKV). Database di Azure per MySQL server flessibile supporta attualmente solo l'identità gestita assegnata dall'utente. Per altre informazioni, vedere Tipi di identità gestite in Azure.

Per configurare la chiave gestita dal cliente per un server flessibile Database di Azure per MySQL, è necessario collegare l'messaggistica unificata al server e specificare l'insieme di credenziali delle chiavi di Azure e la chiave da usare.

L'UMI deve avere l'accesso seguente all'insieme di credenziali delle chiavi:

  • Get: per recuperare la parte pubblica e le proprietà della chiave nell'insieme di credenziali delle chiavi.
  • Elenco: elencare le versioni della chiave archiviate in un insieme di credenziali delle chiavi.
  • Eseguire il wrapping della chiave: per poter crittografare la chiave DEK. La chiave DEK crittografata viene archiviata nell'istanza del server flessibile Database di Azure per MySQL.
  • Annulla il wrapping della chiave: per poter decrittografare la chiave DEK. Database di Azure per MySQL server flessibile richiede la chiave DEK decrittografata per crittografare/decrittografare i dati.

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. L'accesso ai DEK è necessario dal provider di risorse o dall'istanza dell'applicazione che crittografa e decrittografa 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é la chiave di crittografia della chiave di crittografia della chiave è necessaria per decrittografare i DEK, la chiave di crittografia della chiave di crittografia è effettivamente un singolo punto in base al quale i DEK possono essere eliminati in modo efficace 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 nei dati inattivi di crittografia.

Funzionamento

La crittografia dei dati con cmk viene impostata a livello di server. Per un determinato server, una chiave gestita dal cliente, denominata chiave di crittografia della chiave (KEK), viene usata 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. Key Vault è un'archiviazione sicura a disponibilità elevata e scalabile per le chiavi crittografiche RSA, supportata facoltativamente da moduli di protezione hardware convalidati FIPS 140. Key Vault non consente l'accesso diretto a una chiave archiviata, ma fornisce invece servizi di crittografia/decrittografia usando la chiave per le entità autorizzate. L'insieme di credenziali delle chiavi, importato, può generare la chiave o trasferirla all'insieme di credenziali delle chiavi da un dispositivo HSM locale.

Quando si configura un server flessibile per l'uso di una chiave gestita dal cliente archiviato 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 archiviata nel database utente. Analogamente, il server flessibile invierà la chiave DEK protetta all'insieme di credenziali delle chiavi per la decrittografia quando necessario.

Diagram of how data encryption with a customer-managed key work.

Dopo aver abilitato la registrazione, i revisori possono usare Monitoraggio di Azure per esaminare i log eventi di controllo di Key Vault. Per abilitare la registrazione degli eventi di controllo di Key Vault, vedere Monitoraggio del servizio key vault con informazioni dettagliate sull'insieme di credenziali delle chiavi.

Nota

Le modifiche alle autorizzazioni possono richiedere fino a 10 minuti per influire sull'insieme di credenziali delle chiavi. Ciò include la revoca delle autorizzazioni di accesso alla protezione TDE in AKV e gli utenti entro questo intervallo di tempo potrebbero comunque avere autorizzazioni di accesso.

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

Prima di tentare di configurare Key Vault, assicurarsi di soddisfare i requisiti seguenti.

  • L'insieme di credenziali delle chiavi e Database di Azure per MySQL'istanza del server flessibile deve appartenere allo stesso tenant di Microsoft Entra. È necessario supportare l'insieme di credenziali delle chiavi tra tenant e le interazioni tra server flessibili. Se si spostano le risorse di Key Vault dopo aver eseguito la configurazione, sarà necessario riconfigurare la crittografia dei dati.
  • L'insieme di credenziali delle chiavi e Database di Azure per MySQL'istanza del server flessibile deve trovarsi nella stessa area.
  • Abilitare la funzionalità di eliminazione temporanea nell'insieme di credenziali delle chiavi con un periodo di conservazione impostato su 90 giorni per la protezione dalla perdita di dati in caso di eliminazione accidentale della chiave (o dell'insieme di credenziali delle chiavi). Le azioni di ripristino e eliminazione hanno le proprie autorizzazioni in un criterio di accesso di Key Vault. La funzionalità di eliminazione temporanea è disattivata per impostazione predefinita, ma è possibile abilitarla tramite il portale di Azure o tramite PowerShell o l'interfaccia della riga di comando di Azure.
  • Abilitare la funzionalità Protezione ripulitura nell'insieme di credenziali delle chiavi e impostare il periodo di conservazione su 90 giorni. Quando la protezione dall'eliminazione è attivata, un insieme di credenziali o un oggetto nello stato eliminato non può essere ripulito finché non è terminato il periodo di conservazione. È possibile abilitare questa funzionalità usando PowerShell o l'interfaccia della riga di comando di Azure e solo dopo aver abilitato l'eliminazione temporanea.

Prima di tentare di configurare la chiave gestita dal cliente, assicurarsi di soddisfare i requisiti seguenti.

  • La chiave gestita dal cliente per crittografare la chiave DEK può essere solo asimmetrica, RSA\RSA-HSM(Insiemi di credenziali con SKU Premium) 2048,3072 o 4096.
  • 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 recupero dell'attributo chiave obbligatorioLevel: "Ripristinabile".
  • 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 (con estensione pfx, byok, backup).

Nota

Per istruzioni dettagliate su come configurare la crittografia della data per Database di Azure per MySQL server flessibile tramite il portale di Azure, vedere Configurare la crittografia dei dati per Database di Azure per MySQL server flessibile.

Consigli per la configurazione della crittografia dei dati

Quando si configura Key Vault per l'uso della crittografia dei dati usando una chiave gestita dal cliente, tenere presenti le raccomandazioni seguenti.

  • 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.
  • Conservare una copia della chiave gestita dal 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. Per altre informazioni sul comando di backup, vedere Backup-AzKeyVaultKey.

Nota

  • È consigliabile usare un insieme di credenziali delle chiavi della stessa area, ma, se necessario, è possibile usare un insieme di credenziali delle chiavi da un'altra area specificando le informazioni di immissione dell'identificatore di chiave.
  • La chiave RSA archiviata nel modulo di protezione hardware gestito di Azure Key Vault non è attualmente supportata.

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 rimanga online. Se il server flessibile perde l'accesso alla chiave gestita dal cliente in Key Vault, il server inizia a negare tutte le connessioni entro 10 minuti. Il server flessibile genera un messaggio di errore corrispondente e modifica lo stato del server in Inaccessibile. Il server può raggiungere questo stato per vari motivi.

  • Se si elimina l'insieme di credenziali delle chiavi, l'istanza del server flessibile Database di Azure per MySQL non sarà in grado di accedere alla chiave e passerà allo stato Inaccessibile. Ripristinare l'insieme di credenziali delle chiavi e riconvalidare la crittografia dei dati per rendere disponibile l'istanza del server flessibile Database di Azure per MySQL.
  • Se si elimina la chiave dall'insieme di credenziali delle chiavi, l'istanza del server flessibile Database di Azure per MySQL non sarà in grado di accedere alla chiave e passerà allo stato Inaccessibile. Ripristinare la chiave e riconvalidare la crittografia dei dati per rendere disponibile l'istanza del server flessibile Database di Azure per MySQL.
  • Se la chiave archiviata in Azure Key Vault scade, la chiave non sarà più valida e l'istanza del server flessibile Database di Azure per MySQL passerà allo stato Inaccessibile. Estendere la data di scadenza della chiave usando l'interfaccia della riga di comando e quindi riconvalidare la crittografia dei dati per rendere disponibile l'istanza del server flessibile Database di Azure per MySQL.

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 flessibile del server alla chiave tramite:

  • Revoca delle autorizzazioni get, list, wrap key e unwrap key dell'insieme di credenziali delle chiavi dal server
  • Eliminazione della chiave
  • Eliminazione dell'insieme di credenziali delle chiavi
  • Modifica delle regole del firewall dell'insieme di credenziali delle chiavi
  • Eliminazione dell'identità gestita dall'utente usata per la crittografia nel server flessibile con una chiave gestita dal cliente 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:

  • 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à. È possibile ripristinare l'accesso il prima possibile se si creano avvisi per questi eventi.
  • Gruppi di azioni: definire questi gruppi per inviare notifiche e avvisi in base alle preferenze.

Replica con una chiave gestita dal cliente in Key Vault

Quando un'istanza del server flessibile Database di Azure per MySQL viene crittografata con la chiave gestita di un cliente archiviata in Key Vault, viene crittografata anche qualsiasi copia appena creata del server. Quando si tenta di crittografare un'istanza del server flessibile Database di Azure per MySQL con una chiave gestita dal cliente che dispone già di una o più repliche, è consigliabile configurare le repliche aggiungendo l'identità gestita e la chiave. Si supponga che l'istanza del server flessibile Database di Azure per MySQL sia configurata con il backup con ridondanza geografica. In tal caso, la replica deve essere configurata con l'identità gestita e la chiave a cui l'identità ha accesso e che risiede nell'area geografica associata del server.

Eseguire il ripristino con una chiave gestita dal cliente in Key Vault

Quando si tenta di ripristinare un'istanza del server flessibile Database di Azure per MySQL, è possibile selezionare l'identità gestita dall'utente e la chiave per crittografare il server di ripristino. Si supponga che l'istanza del server flessibile Database di Azure per MySQL sia configurata con il backup con ridondanza geografica. In tal caso, è necessario configurare il server di ripristino con l'identità gestita e la chiave a cui l'identità ha accesso e che risiede nell'area geografica associata del server.

Per evitare problemi durante la configurazione della crittografia dei dati gestita dal cliente durante il ripristino o la creazione di repliche in lettura, è essenziale seguire questi passaggi nei server di origine e di replica ripristinati:

  • Avviare il processo di creazione della replica di ripristino o lettura dall'istanza del server flessibile Database di Azure per MySQL di origine.
  • Nel server ripristinato/di replica riconvalidare la chiave gestita dal cliente nelle impostazioni di crittografia dei dati per assicurarsi che all'identità gestita dall'utente vengano concesse le autorizzazioni Get, List, Wrap key e Unwrap key per la chiave archiviata in Key Vault.

Nota

L'uso della stessa identità e della stessa chiave del server di origine non è obbligatorio quando si esegue un ripristino.

Passaggi successivi