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, è possibile usare una chiave gestita dal cliente (BYOK) per la protezione dei dati archiviati, così da garantire la separazione dei ruoli nella gestione delle chiavi e dei dati. Quando si usano chiavi gestite dal cliente (CMK), si controllano:

  • Gestione del ciclo di vita delle chiavi, tra cui creazione, caricamento, rotazione ed eliminazione delle chiavi
  • Autorizzazioni di utilizzo delle chiavi
  • Operazioni di controllo sulle chiavi

Vantaggi delle chiavi gestite dal cliente

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

  • È possibile controllare completamente l'accesso ai dati rimuovendo la chiave e rendendo il database inaccessibile.
  • Hai il pieno controllo sul ciclo di vita della chiave, compresa la rotazione della chiave per allinearsi alle policy aziendali.
  • È possibile gestire e organizzare centralmente le chiavi in Azure Key Vault o HSM gestito.
  • È possibile implementare la separazione dei compiti tra responsabili della sicurezza, amministratore di database e amministratori di sistema.

Funzionamento della crittografia dei dati con una chiave gestita dal cliente

Le identità gestite in Microsoft Entra ID offrono un modo più sicuro per autenticare i client ai servizi. La crittografia CMK utilizza l'identità gestita del server di Azure Database per MySQL per connettersi all'Azure Key Vault che archivia il CMK. Database di Azure per MySQL supporta attualmente solo l'identità gestita assegnata dall'utente per l'accesso al Key Vault. Per altre informazioni, vedere Tipi di identità gestite in Azure.

Per configurare la chiave gestita dal cliente per Database di Azure per MySQL, associare l'UAMI al server e specificare l'Azure Key Vault e la chiave da usare.

L'UAMI necessita dei seguenti accessi al Key Vault:

  • Get: per recuperare la parte pubblica e le proprietà della chiave in Key Vault.
  • Elenco: per elencare le versioni della chiave archiviate in un Key Vault.
  • Chiave di wrapping: Per crittografare la DEK. La chiave DEK crittografata viene archiviata nell'istanza del server flessibile di Database di Azure per MySQL.
  • Rimuovi il wrapping della chiave: per decrittografare la DEK. Database di Azure per MySQL richiede la chiave DEK decrittografata per crittografare o decrittografare i dati.

Se è abilitato il controllo degli accessi in base al ruolo di Azure, assegnare i ruoli all'UAMI invece di concedere l'accesso ai singoli utenti.

  • 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

Impostare la crittografia dei dati con i cmk a livello di server. Per un dato server, utilizzare una CMK, denominata chiave di crittografia della chiave (KEK), per crittografare la chiave di crittografia dei dati (DEK) del servizio. 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 e decrittografia usando la chiave per le entità autorizzate. Il Key Vault può generare la chiave o trasferirla al Key Vault da un dispositivo HSM installato in 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.

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

Note

Le modifiche alle autorizzazioni possono richiedere fino a 10 minuti per influire su Key Vault.

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. È necessario riconfigurare la crittografia dei dati se si spostano Key Vault risorse dopo aver eseguito la configurazione.
  • Key Vault e l'istanza del server flessibile di Database di Azure per MySQL devono trovarsi nella stessa area.
  • Abilitare la funzionalità Eliminazione temporanea nell'insieme di credenziali delle chiavi.
  • Abilitare la protezione ripulitura.
  • Impostare il periodo di conservazione su 90 giorni.
    • 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.

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 di tipo asimmetrico: 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. La data di scadenza non è impostata.
  • La chiave deve avere lo stato Abilitato.
  • La chiave deve avere soft delete con un periodo di conservazione impostato a 90 giorni. Questa impostazione imposta in modo implicito l'attributo recoveryLevel di chiave richiesto su Recoverable.
  • 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).

Note

Per istruzioni dettagliate su come configurare la crittografia dei dati, vedere Crittografia dei dati per Database di Azure per MySQL con il portale di Azure o Crittografia dei dati per Database di Azure per MySQL - Server flessibile con l'interfaccia della riga di comando di Azure.

Suggerimenti per la configurazione della crittografia dei dati

Quando si configura Key Vault o HSM gestito per l'uso della crittografia dei dati con 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).
  • 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.

Note

L'insieme di credenziali delle chiavi che usi deve trovarsi nella stessa area del server del database.

Condizione inaccessibile della chiave gestita dal cliente

Quando si configura la crittografia dei dati con una chiave gestita dal cliente (CMK) in Key Vault, il server deve avere accesso continuo a questa chiave per rimanere operativo. 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 di Database di Azure per MySQL - Server flessibile non può accedere alla chiave e passa allo stato Inaccessible. Per creare l'istanza del server Available :

  • Ripristinare il Key Vault.
  • Riconvalidare la crittografia dei dati.

Se si elimina la chiave dall'insieme di credenziali, l'istanza di Database di Azure per MySQL - Server flessibile non può accedere alla chiave e passa allo stato Inaccessible. Per creare l'istanza del server Available :

  • Recuperare la chiave.
  • Riconvalidare la crittografia dei dati.

Note

Anche se la chiave scade, il server rimane accessibile per progettazione per evitare interruzioni del servizio.

Revoca accidentale dell'accesso alla chiave da Key Vault

Un utente con diritti di accesso sufficienti per Key Vault potrebbe disabilitare accidentalmente l'accesso flessibile del server alla chiave tramite:

  • Revoca delle autorizzazioniget, list, wrap key e unwrapping 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 l'invio di avvisi per la perdita dell'accesso alla protezione 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 inviare notifiche e avvisi in base alle preferenze.

Replica con una chiave gestita dal cliente in Key Vault

Quando si crittografa 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 Database di Azure per MySQL con una chiave gestita dal cliente che dispone già di una replica, configurare una o più repliche aggiungendo l'identità gestita e la chiave. Se si configura l'istanza del server flessibile Database di Azure per MySQL con il backup con ridondanza geografica, è necessario configurare la replica 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 ripristina un'istanza del server flessibile Database di Azure per MySQL, selezionare l'identità gestita dall'utente e la chiave per crittografare il server di ripristino. Se l'istanza del server flessibile Database di Azure per MySQL è configurata con il backup con ridondanza geografica, è 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.

Durante il ripristino o la creazione di repliche di lettura, seguire questi passaggi sui server di origine e su quelli ripristinati o di replica:

  • 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 o nel server di replica, convalidare nuovamente la CMK nelle impostazioni di crittografia dei dati per verificare che UAMI disponga delle autorizzazioni per la chiave.

Note

Non è necessario usare la stessa identità (UAMI) e la stessa chiave del server di origine quando si esegue un ripristino.

Contenuti correlati

  • Last updated on