Condividi tramite

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

Nota

HSM gestito di Azure Key Vault è attualmente supportato per le chiavi gestite dal cliente per il server flessibile di Database di Azure per MySQL.

Vantaggi

La crittografia dei dati con chiavi gestite dal cliente per Database di Azure per MySQL server flessibile 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 server flessibile supporta attualmente solo l'identità gestita assegnata dall'utente( UMI). Per altre informazioni, vedere Tipi di identità gestita 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'identità gestita assegnata dall'utente deve avere l'accesso seguente a Key Vault:

  • Get: per recuperare la parte pubblica e le proprietà della chiave in Key Vault.
  • List: per elencare le versioni della chiave archiviate in Key Vault.
  • Wrap Key: per poter crittografare la chiave DEK. La chiave DEK crittografata viene archiviata nell'istanza del server flessibile Database di Azure per MySQL.
  • Unwrap Key: per poter decrittografare la chiave DEK. Database di Azure per MySQL server flessibile 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:

  • Utente di crittografia del servizio di crittografia di Key Vault 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 HSM gestito assegnare il ruolo Managed HSM Crypto Service Encryption User

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 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 della crittografia di dati inattivi.

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 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 (HSM) con convalida di tipo 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. Key Vault importato può generare la chiave o trasferirla a Key Vault 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 invierà la chiave DEK protetta a Key Vault affinché sia decrittografata, quando necessario.

Diagramma del funzionamento della crittografia dei dati con una chiave gestita dal cliente.

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 le informazioni dettagliate di Key Vault.

Nota

Le modifiche alle autorizzazioni possono richiedere fino a 10 minuti per influire su Key Vault. Ciò include la revoca delle autorizzazioni di accesso alla protezione TDE in Azure Key Vault 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 o HSM gestito, 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. 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.
  • 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 in Key Vault con periodo di conservazione impostato su 90 giorni per la protezione dalla perdita di dati in caso di eliminazione accidentale della chiave o di 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 PowerShell o l'interfaccia della riga di comando di Azure.
  • Abilitare la funzionalità Protezione dalla rimozione definitiva inl Key Vault 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 obbligatorio recoveryLevel: "Ripristinabile".
  • La chiave deve avere la protezione dalla rimozione definitiva abilitata.
  • Se si importa una chiave esistente in Key Vault, assicurarsi di specificarla nei formati di file supportati (.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.

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.

Nota

  • È consigliabile usare un Key Vault della stessa area, ma, se necessario, è possibile utilizzare un Key Vault proveniente da un'altra area, specificando le informazioni riportate in "Immettere l'identificatore chiave". HSM gestito di Key Vault deve trovarsi nella stessa area del server flessibile MySQL.

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 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 di 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 del server flessibile alla chiave eseguendo le operazioni seguenti:

  • Revoca delle autorizzazioniget, list, wrap key e unwrap key 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 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 dell'utente.

Replica con una chiave gestita dal cliente in Key Vault

Una volta crittografata un'istanza del server flessibile Database di Azure per MySQL 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 di 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 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 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 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 keyper la chiave archiviata in Key Vault.

Nota

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

Passaggi successivi