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

Con la crittografia dei dati con chiavi gestite dal cliente per Database di Azure per MySQL, puoi portare la tua chiave (BYOK) per la protezione dei dati a riposo e implementare la separazione dei compiti per la gestione di chiavi e dati. Con le chiavi gestite dal cliente, il cliente è responsabile e controlla in ultima analisi la gestione del ciclo di vita della chiave (creazione, caricamento, rotazione, eliminazione), delle autorizzazioni di utilizzo delle chiavi e delle operazioni di controllo sulle chiavi.

Vantaggi

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

• Controllo completo dell'accesso ai dati grazie alla possibilità di rimuovere la chiave e rendere il database inaccessibile.
• Controllo completo del ciclo di vita della chiave, inclusa la rotazione della stessa per soddisfare i criteri aziendali
• Gestione centralizzata e organizzazione delle chiavi in Azure Key Vault o in HSM gestito
• Possibilità di implementare la separazione dei compiti tra i responsabili della sicurezza, gli amministratori di database e gli amministratori di sistema

Funzionamento della 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 utilizzata per eseguire l'autenticazione a qualsiasi servizio che supporti l'autenticazione di Microsoft Entra, ad esempio Azure Key Vault (AKV). Database di Azure per MySQL supporta attualmente solo l'identità gestita assegnata dall'utente( UMI). Per altre informazioni, vedere Tipi di identità gestite in Azure.

Per configurare la chiave gestita dal cliente per un database di Azure per MySQL, è necessario collegare l'Identità Gestita Utente al server e specificare l'Azure Key Vault e la chiave da usare.

L'identità gestita assegnata dall'utente deve avere l'accesso seguente a Key Vault:

• Get: per recuperare la parte pubblica e le proprietà della chiave nel vault delle chiavi.
• Elenco: Elencare le versioni della chiave archiviate in un Key Vault.
• Avvolgere la chiave: per poter crittografare la DEK. La chiave DEK crittografata viene archiviata nell'istanza del server flessibile di Database di Azure per MySQL.
• Decrittografa la chiave: per poter decrittografare il DEK. Database di Azure per MySQL richiede la chiave DEK decrittografata per crittografare/decrittografare i dati.

Se il controllo degli accessi in base al ruolo è abilitato, all'UMI deve essere assegnato anche il ruolo seguente:

• Key Vault Crypto Service Encryption User o il ruolo con le autorizzazioni:
  • Microsoft.KeyVault/vaults/keys/wrap/action
  • Microsoft.KeyVault/vaults/keys/unwrap/action
  • Microsoft.KeyVault/vaults/keys/read come "Key Vault Crypto Service Encryption User"
• Per Managed HSM, assegnare il ruolo Utente crittografia del servizio di Managed HSM

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 principale (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 attraverso l'eliminazione della 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 nella crittografia dei dati a riposo.

Funzionamento

La crittografia dei dati con le chiavi gestite dal cliente 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 di crittografia dei dati (DEK). La chiave kek è una chiave asimmetrica archiviata in un'istanza di Azure Key Vault gestita dal 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 che usano la chiave per le entità autorizzate. Il vault delle chiavi importato può generare la chiave o essere trasferito nel vault delle chiavi da un dispositivo HSM locale.

Quando si configura un server flessibile per l'uso di una chiave gestita dal cliente archiviata in Key Vault, il server invia la chiave DEK a Key Vault affinché sia crittografata. Key Vault restituisce la chiave DEK crittografata archiviata nel database utente. Analogamente, il server flessibile invia la chiave DEK protetta all'archivio delle chiavi per decrittografare quando necessario.

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 Key Vault insights.

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

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

• Key Vault e l'istanza del server flessibile di Database di Azure per MySQL devono appartenere allo stesso tenant di Microsoft Entra. Le interazioni tra Key Vault e server flessibile tra tenant devono essere supportate. Se si spostano le risorse di Key Vault dopo aver eseguito la configurazione, sarà necessario riconfigurare la crittografia dei dati.
• Key Vault e l'istanza del server flessibile di Database di Azure per MySQL devono trovarsi nella stessa area.
• Abilitare la funzionalità cancellazione temporanea nel Key Vault con un periodo di conservazione impostato su 90 giorni per la protezione dalla perdita di dati in caso di eliminazione accidentale della chiave (o del Key Vault). Per le azioni di recupero e pulizia è possibile definire autorizzazioni specifiche nei criteri 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 eliminazione sul Key Vault e impostare il periodo di conservazione a 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 trovarsi nello stato Abilitato .
• La chiave deve avere soft delete con un periodo di conservazione impostato a 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 importi una chiave esistente nell'archivio chiavi, assicurati di fornirla nei formati di file supportati (.pfx, .byok, .backup).

Suggerimenti per la configurazione della crittografia dei dati

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

• 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 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 CMK 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 flessibile inizia a negare tutte le connessioni entro 10 minuti. Il server flessibile genera un messaggio di errore corrispondente e cambia il proprio stato in Inaccessibile. Il server può raggiungere questo stato per vari motivi.

• Se si elimina il Key Vault, l'istanza del server flessibile di Azure Database per MySQL non è in grado di accedere alla chiave e passa allo stato Inaccessibile. Ripristinare il Key Vault e riconvalidare la crittografia dei dati per rendere l'istanza del server flessibile database di Azure per MySQL Disponibile.
• Se si elimina la chiave dall'insieme di credenziali, l'istanza del server flessibile del database MySQL di Azure 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 di Database di Azure per MySQL.
• Se la chiave archiviata in Azure Key Vault scade, la chiave non è valida e l'istanza del server flessibile di Database di Azure per MySQL passa 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 di 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 del server flessibile alla chiave eseguendo le operazioni seguenti:

• Revoca delle autorizzazioni per ottenere, elencare, eseguire il wrapping e l'unwrapping della chiave dal server
• Eliminazione della chiave
• Eliminazione di Key Vault
• Modifica delle regole del firewall di Key Vault
• 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 nel Key Vault gestito dal cliente fallisce, le voci vengono aggiunte al registro delle 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.

Replica con una chiave gestita dal cliente in Key Vault

Una volta eseguita la crittografia del server flessibile 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. Quando si tenta di crittografare un'istanza del server flessibile di Database di Azure per MySQL con una chiave gestita dal cliente che dispone già di una replica, è consigliabile configurare una o più repliche aggiungendo l'identità gestita e la chiave. Si supponga che l'istanza del server flessibile di 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 con 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 di 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 di 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 con la chiave a cui l'identità ha accesso e che risiede nell'area geografica associata del server.

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

• Avviare il processo di ripristino o di creazione della replica in lettura dall'istanza del server flessibile di 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.

Contenuto correlato

• Crittografia dei dati per Database di Azure per MySQL - Server flessibile con l'interfaccia della riga di comando di Azure
• Crittografia dei dati per Database di Azure per MySQL - Server flessibile tramite il portale di Azure
• Sicurezza nella crittografia a riposo
• Autenticazione di Microsoft Entra per Database di Azure per MySQL - Server flessibile