Transparent Data Encryption (TDE) con chiave gestita dal cliente a livello di database

Si applica a: Database SQL di Azure

Questo articolo descrive Transparent Data Encryption (TDE) con chiavi gestite dal cliente a livello di database per database SQL di Azure.

Panoramica

Azure SQL offre funzionalità di crittografia dei dati inattivi ai clienti tramite Transparent Data Encryption (TDE). Estendere TDE con la chiave gestita dal cliente (CMK) permette di proteggere i dati inattivi in cui la protezione TDE (la chiave di crittografia) viene archiviata in un insieme di credenziali delle chiavi di Azure che crittografa le chiavi di crittografia del database. Al momento, la protezione TDE con chiave gestita dal cliente è impostata a livello di server logico e viene ereditata da tutti i database crittografati associati al server. Questa nuova funzionalità consente di impostare individualmente la protezione TDE come chiave gestita dal cliente per ogni database all'interno del server. Qualsiasi risorsa Microsoft.Sql/servers/databases con una proprietà encryptionProtector non valida viene configurata con chiavi gestite dal cliente a livello di database.

In questo scenario, una chiave asimmetrica archiviata in un'istanza di Azure Key Vault (AKV) gestita dal cliente e gestita dal cliente può essere usata singolarmente per ogni database all'interno di un server per crittografare la chiave di crittografia del database (DEK), denominata protezione TDE. È possibile aggiungere chiavi, rimuovere chiavi e modificare l'identità gestita assegnata dall'utente per ogni database. Per altre informazioni sulle identità, vedere Tipi di identità gestite in Azure.

La seguente funzionalità è disponibile:

• Identità gestita assegnata dall'utente: è possibile assegnare un'identità gestita assegnata dall'utente al database. Questa identità può essere usata per accedere ad Azure Key Vault e gestire le chiavi di crittografia.
• Gestione delle chiavi di crittografia: è possibile abilitare una o più chiavi di crittografia a livello di database e impostare una delle chiavi aggiunte come protezione TDE. Le chiavi di crittografia aggiunte usano l'identità gestita assegnata dall'utente già assegnata al database per accedere ad Azure Key Vault.
• Identità client federata: è anche possibile abilitare una chiave gestita dal cliente da Azure Key Vault in un tenant Microsoft Entra diverso da impostare come protezione TDE a livello di database, usando l'identità client federata impostata nel database SQL di Azure. In questo modo è possibile gestire TDE con le chiavi archiviate in Azure Key Vault di un tenant diverso.

Vantaggi di Transparent Data Encryption gestita dal cliente a livello di database

Poiché più provider di servizi, noti anche come fornitori di software indipendenti (ISV), usano database SQL di Azure per creare i propri servizi, molti si stanno rivolgendo a pool elastici come modo per distribuire in modo efficiente le risorse di calcolo tra più database. Avendo ognuno dei database dei clienti in un pool elastico condiviso, gli ISV possono sfruttare la capacità del pool di ottimizzare l'utilizzo delle risorse garantendo comunque che ogni database disponga di risorse adeguate.

Tuttavia, esiste una limitazione significativa a questo approccio. Quando più database sono ospitati nello stesso server logico SQL di Azure, condividono la protezione TDE a livello di server. Gli ISV non sono in grado di offrire ai clienti funzionalità di chiavi gestite dal cliente (CMK). Senza la possibilità di gestire le proprie chiavi di crittografia, i clienti potrebbero essere esitare nell'affidare i dati sensibili al servizio degli ISV, in particolare se le normative di conformità impongono loro di mantenere il controllo completo sulle chiavi di crittografia.

Con la chiave gestita dal cliente per la protezione TDE a livello di database, gli ISV possono offrire ai clienti la funzionalità di chiave gestita dal cliente e ottenere l'isolamento della sicurezza, poiché la protezione TDE di ogni database può essere potenzialmente di proprietà del rispettivo cliente ISV in un insieme di credenziali delle chiavi di cui sono proprietari. L'isolamento della sicurezza ottenuto per i clienti ISV è sia in termini di chiave che di identità usata per accedere alla chiave.

Il diagramma seguente riepiloga le nuove funzionalità indicate in precedenza. Presenta due tenant Microsoft Entra separati. Tenant Best Services che contiene il server logico SQL di Azure con due database e DB 1 e DB 2 e il Azure Key Vault 1 con un oggetto Key 1 che accede al database DB 1 usando UMI 1. Sia UMI 1 che Key 1 rappresentano l'impostazione a livello di server. Per impostazione predefinita, tutti i database creati inizialmente in questo server ereditano questa impostazione per TDE con chiave gestita dal cliente. Il tenant Contoso rappresenta un tenant client che contiene Azure Key Vault 2 con una valutazione Key 2 del database DB 2 nel tenant come parte del supporto chiave gestita dal cliente tra tenant a livello di database tramite la configurazione Key 2 e UMI 2 per questo database.

Per altre informazioni sulla configurazione delle identità tra tenant, vedere il documento Chiavi gestite dal cliente tra tenant con Transparent Data Encryption.

Scenari di gestione della chiave supportati

Per la sezione seguente, si supponga che sia presente un server costituito da tre database (ad esempio Database1, Database2 e Database3).

Scenari esistenti

Key1 viene configurato come chiave gestita dal cliente a livello di server logico. Tutti i database in questo server ereditano la stessa chiave.

• Server : Key1 impostato come chiave gestita dal cliente
• Database1 – Key1 usato come chiave gestita dal cliente
• Database2 – Key1 usato come chiave gestita dal cliente
• Database3 – Key1 usato come chiave gestita dal cliente

Nuovo scenario supportato: server logico configurato con chiave gestita dal cliente

Key1 viene configurato come chiave gestita dal cliente a livello di server logico. È possibile configurare una chiave gestita dal cliente diversa (Key2) a livello di database.

• Server : Key1 impostato come chiave gestita dal cliente
• Database1 – Key2 usato come chiave gestita dal cliente
• Database2 – Key1 usato come chiave gestita dal cliente
• Database3 – Key1 usato come chiave gestita dal cliente

Nuovo scenario supportato: server logico configurato con chiave gestita dal servizio

Il server logico è configurato con la chiave gestita dal servizio (SMK) per TDE. È possibile configurare una chiave gestita dal cliente diversa (Key2) a livello di database.

• Server - Chiave gestita dal servizio impostata come protezione TDE
• Database1 – Key2 impostato come chiave gestita dal cliente
• Database2 – Chiave gestita dal servizio impostata come protezione TDE
• Database3 – Chiave gestita dal servizio impostata come protezione TDE

Ripristino della crittografia a livello di server

Database1 viene configurato con una chiave gestita dal cliente a livello di database per TDE mentre il server logico è configurato con la chiave gestita dal servizio. Database1 può essere ripristinato per usare la chiave gestita dal servizio a livello di server logico.

Insieme di credenziali delle chiavi e requisiti di identità gestita

Gli stessi requisiti per la configurazione delle chiavi di Azure Key Vault (AKV) e delle identità gestite, incluse le impostazioni delle chiavi e le autorizzazioni concesse all'identità che si applicano alla funzionalità della chiave gestita dal cliente (CMK) a livello di server, si applicano anche alla chiave gestita dal cliente a livello di database. Per altre informazioni, vedere Transparent Data Encryption (TDE) con chiave gestita dal cliente e Identità gestite con chiave gestita dal cliente.

Gestione delle chiavi

Ruotare una protezione TDE per un database significa passare a una nuova chiave asimmetrica che protegge i database nel server. La rotazione delle chiavi è un'operazione online e richiede solo alcuni secondi. L'operazione decrittografa e crittografa nuovamente la chiave di crittografia del database, non l'intero database. Una volta assegnata a un database un'identità gestita assegnata dall'utente valida, la rotazione della chiave a livello di database è un'operazione CRUD del database che comporta l'aggiornamento della proprietà di protezione della crittografia del database. Set-AzSqlDatabase e la proprietà -EncryptionProtector possono essere usate per ruotare le chiavi. Per creare un nuovo database configurato con chiave gestita dal cliente a livello di database, è possibile usare New-AzSqlDatabase con i parametri -EncryptionProtector, -AssignIdentity e -UserAssignedIdentityId.

È possibile aggiungere nuove chiavi e rimuovere dal database le chiavi esistenti usando richieste simili e modificando la proprietà delle chiavi per la risorsa di database. Set-AzSqlDatabase con il parametro -KeyList e -KeysToRemove può essere usato per queste operazioni. Per recuperare l'impostazione della protezione della crittografia, dell'identità e delle chiavi, è possibile usare Get-AzSqlDatabase. La risorsa di Azure Resource Manager Microsoft.Sql/servers/databases per impostazione predefinita mostra solo la protezione TDE e l'identità gestita configurata nel database. Per espandere l'elenco completo delle chiavi, sono necessari altri parametri come -ExpandKeyList. Inoltre, è possibile usare -KeysFilter "current" e un valore temporizzato (ad esempio 2023-01-01) per recuperare le chiavi usate al momento e le chiavi usate in passato in un momento specifico.

Rotazione delle chiavi automatica

La rotazione automatica delle chiavi è disponibile a livello di database e può essere usata con le chiavi di Azure Key Vault. La rotazione viene attivata quando viene rilevata una nuova versione della chiave e verrà ruotata automaticamente entro 24 ore. Per informazioni su come configurare la rotazione automatica delle chiavi usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure, vedere Rotazione automatica delle chiavi a livello di database.

Autorizzazione per la gestione delle chiavi

In base al modello di autorizzazione dell'insieme di credenziali delle chiavi (criterio di accesso o Controllo degli accessi in base al ruolo di Azure) è possibile concedere l'accesso all'insieme di credenziali delle chiavi creando un criterio di accesso nell'insieme di credenziali delle chiavi oppure creando una nuova assegnazione di ruolo di Controllo degli accessi in base al ruolo di Azure.

Modello di autorizzazione dei criteri di accesso

Affinché il database utilizzi la protezione TDE archiviata in Azure Key Vault per la crittografia della chiave DEK, l'amministratore dell'insieme di credenziali delle chiavi deve concedere i diritti di accesso seguenti all'identità gestita assegnata dall'utente del database usando l'identità univoca di Microsoft Entra:

• get: per recuperare la parte pubblica e le proprietà della chiave in Azure Key Vault.
• wrapKey: per proteggere (crittografare) la chiave DEK.
• unwrapKey: per rimuovere la protezione (decrittografare) la chiave DEK.

Modello di autorizzazioni del Controllo degli accessi in base al ruolo di Azure

Per consentire al database di usare la protezione TDE archiviata in AKV per la crittografia della chiave DEK, è necessario aggiungere una nuova assegnazione di ruolo controllo degli accessi in base al ruolo con il ruolo Utente di crittografia del servizio di crittografia di Key Vault per l'identità gestita assegnata dall'utente del database usando l'identità univoca di Microsoft Entra.

Chiavi gestite dal cliente tra tenant

Le chiavi gestite dal cliente tra tenant con Transparent Data Encryption descrivono come configurare un ID client federato per la chiave gestita dal cliente a livello di server. È necessario eseguire una configurazione simile per chiave gestita dal cliente a livello di database e l'ID client federato deve essere aggiunto come parte delle richieste dell'API Set-AzSqlDatabase o New-AzSqlDatabase.

Un database configurato con la chiave gestita dal cliente a livello di database può essere ripristinato alla crittografia a livello di server se il server logico è configurato con una chiave gestita dal servizio tramite Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert.

In caso di protezione TDE inaccessibile come descritto in Transparent Data Encryption (TDE) con chiave gestita dal cliente, dopo aver corretto l'accesso alla chiave, è possibile usare Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation per rendere accessibile il database.

Considerazioni aggiuntive

• Se TDE con chiave gestita dal cliente è già abilitato a livello di server, l'impostazione di chiave gestita dal cliente per un determinato database sostituisce l'impostazione chiave gestita dal cliente a livello di server (la chiave DEK del database viene crittografata nuovamente con la protezione TDE a livello di database).
• Le modifiche o le rotazioni delle chiavi a livello di server logico non influiscono sulle impostazioni per la chiave gestita dal cliente a livello di database e il database continua a usare la propria impostazione di chiave gestita dal cliente.
• La chiave gestita dal cliente a livello di database non è supportata tramite Transact-SQL (T-SQL).
• L'identità gestita assegnata dall'utente del server logico può essere usata a livello di database. È tuttavia consigliabile usare una messaggistica unificata designata per la chiave gestita a livello di database.
• Le impostazioni di chiave gestita dal cliente multi-tenant a livello di server non influiscono sui singoli database configurati con chiave gestita dal cliente a livello di database e continuano a usare il proprio tenant singolo o la configurazione tra tenant.
• È possibile impostare solo un'identità gestita assegnata dall'utente a livello di database.

Migrazione dei database esistenti verso chiave gestita dal cliente a livello di database

I nuovi database possono essere configurati con chiave gestita dal cliente a livello di database durante la creazione e i database esistenti nei server configurati con chiavi gestite dal servizio possono essere migrati alla chiave gestita dal cliente a livello di database usando le operazioni descritte in Gestione delle identità e delle chiavi per TDE con chiavi gestite dal cliente a livello di database. Per eseguire la migrazione di database configurati con una chiave gestita a livello di server o la replica geografica, sono necessari altri passaggi, come descritto nelle sezioni seguenti.

Database configurato con una chiave gestita dal cliente a livello di server senza replica geografica

1. Usare sys.dm_db_log_info (Transact-SQL) - SQL Server per il database e cercare i file di log virtuali attivi.
2. Per tutte le funzioni di file di log virtuale attive, registrare vlf_encryptor_thumbprint dal risultato sys.dm_db_log_info.
3. Usare la vista sys.dm_database_encryption_keys (Transact-SQL) - SQL Server per il database per verificare la presenza di encryptor_thumbprint. Registrare l'oggetto encryptor_thumbprint.
4. Usare il cmdlet Get-AzSqlServerKeyVaultKey per ottenere tutte le chiavi a livello di server configurate nel server logico. Dai risultati, selezionare quelli con la stessa identificazione personale corrispondente all'elenco dal risultato precedente.
5. Effettuare una chiamata API del database di aggiornamento al database di cui si vuole eseguire la migrazione, insieme all'identità e alla protezione della crittografia. Passare le chiavi precedenti come chiavi a livello di database usando Set-AzSqlDatabase usando i parametri -UserAssignedIdentityId, -AssignIdentity, -KeyList e -EncryptionProtector (e, se necessario, -FederatedClientId).

Database configurato con chiave gestita dal cliente a livello di server con replica geografica

1. Seguire i passaggi da (1) a (4) indicati nella sezione precedente per recuperare l'elenco di chiavi che saranno necessarie per la migrazione.
2. Eseguire una chiamata api del database di aggiornamento al database primario e secondario di cui si vuole eseguire la migrazione, insieme all'identità e alle chiavi precedenti come chiavi a livello di database usando Set-AzSqlDatabase e il -KeyListparametro. Non impostare ancora la protezione di crittografia.
3. La chiave a livello di database che si vuole usare come protezione primaria nei database deve essere prima aggiunta al database secondario. Usare Set-AzSqlDatabase con -KeyList per aggiungere questa chiave nel database secondario.
4. Dopo aver aggiunto la chiave di protezione della crittografia al database secondario, usare Set-AzSqlDatabase per impostarla come protezione di crittografia nel database primario usando il parametro -EncryptionProtector.
5. Impostare la chiave come protezione di crittografia nel database secondario come descritto in (4) per completare la migrazione.

Replica geografica e disponibilità elevata

In entrambi gli scenari di replica geografica attiva e gruppi di failover, i database primari e secondari coinvolti possono essere collegati allo stesso insieme di credenziali delle chiavi (in qualsiasi area) o a insiemi di credenziali delle chiavi separati. Se ai server primari e secondari sono collegati insiemi di credenziali delle chiavi separati, il cliente è responsabile di mantenere la coerenza del materiale delle chiavi negli insiemi di credenziali delle chiavi, affinché la replica geografica secondaria sia sincronizzata e possa sostituire quella primaria usando la stessa chiave dell'insieme di credenziali collegato se il server primario diventa inaccessibile a causa di un'interruzione di servizio nell'area e viene attivato il failover. È possibile configurare fino a quattro repliche secondarie e il concatenamento (database secondari di database secondari) non è supportato.

Per stabilire la replica geografica attiva per un database configurato con la chiave gestita a livello di database, è necessario creare una replica secondaria con un'identità gestita assegnata dall'utente valida e un elenco di chiavi correnti usate dal database primario. L'elenco delle chiavi correnti può essere recuperato dal database primario usando i filtri e i parametri di query necessari oppure tramite PowerShell e l'interfaccia della riga di comando di Azure. I passaggi necessari per configurare una replica geografica di tale database sono:

1. Prepopolare l'elenco di chiavi usate dal database primario usando il comando Get-AzSqlDatabase e i parametri -ExpandKeyList e -KeysFilter "current". Escludere -KeysFilter se si desidera recuperare tutte le chiavi.
2. Selezionare l'identità gestita assegnata dall'utente (e l'ID client federato se si configura l'accesso tra tenant).
3. Creare un nuovo database come secondario usando New-AzSqlDatabaseSecondary e specificare l'elenco prepopolato di chiavi ottenute dal database di origine e l'identità precedente (e l'inserimento di dipendenze client federate se si configura l'accesso tra tenant) nella chiamata API usando i parametri -KeyList, -AssignIdentity, -UserAssignedIdentityId e -EncryptionProtector (e, se necessario, -FederatedClientId).
4. Usare New-AzSqlDatabaseCopy per creare una copia del database con gli stessi parametri nel passaggio precedente.

Per altre informazioni, Configurare la replica geografica e il ripristino del backup per Transparent Data Encryption con chiavi gestite dal cliente a livello di database descrive come configurare la replica geografica e i gruppi di failover usando le API REST, PowerShell e l'interfaccia della riga di comando di Azure.

Backup e ripristino per i database tramite TDE con chiave gestita dal cliente a livello di database

Quando un database viene crittografato con TDE usando una chiave di Azure Key Vault, vengono crittografati anche eventuali nuovi backup generati con la stessa protezione TDE. Quando la protezione TDE viene modificata, i backup precedenti del database non vengono aggiornati per l'uso della protezione TDE più recente. Per ripristinare un backup crittografato con la protezione TDE di Azure Key Vault configurata a livello di database, assicurarsi che il materiale della chiave sia disponibile per il database di destinazione. È consigliabile tenere tutte le versioni precedenti della protezione TDE in un insieme di credenziali delle chiavi in modo che i backup del database possano essere ripristinati.

Ripristino temporizzato

Per un ripristino temporizzato di un database configurato con chiavi gestite dal cliente a livello di database sono necessari i passaggi seguenti:

1. Prepopolare l'elenco di chiavi usate dal database primario usando il comando Get-AzSqlDatabase e i parametri -ExpandKeyList e -KeysFilter "2023-01-01". 2023-01-01 è un esempio del momento in cui si desidera ripristinare il database. Escludere -KeysFilter se si desidera recuperare tutte le chiavi.
2. Selezionare l'identità gestita assegnata dall'utente (e l'ID client federato se si configura l'accesso tra tenant).
3. Usare Restore-AzSqlDatabase con il parametro -FromPointInTimeBackup e specificare l'elenco prepopolato di chiavi ottenute dai passaggi precedenti e l'identità precedente (e l'ID client federato se si configura l'accesso tra tenant) nella chiamata API usando i parametri -KeyList, -AssignIdentity, -UserAssignedIdentityId e -EncryptionProtector(e, se necessario, -FederatedClientId).

Ripristinare database eliminati

Per un ripristino del database eliminato di un database configurato con chiavi gestite dal cliente a livello di database sono necessari i passaggi seguenti:

1. Prepopolare l'elenco di chiavi usate dal database primario usando Get-AzSqlDeletedDatabaseBackup e il parametro -ExpandKeyList. È consigliabile passare tutte le chiavi in uso nel database di origine, ma in alternativa, è anche possibile provare a eseguire il ripristino con le chiavi fornite dall'ora di eliminazione come -KeysFilter.
2. Selezionare l'identità gestita assegnata dall'utente (e l'ID client federato se si configura l'accesso tra tenant).
3. Usare Restore-AzSqlDatabase con il -FromDeletedDatabaseBackup parametro e fornire l'elenco prepopolato di chiavi ottenute dai passaggi precedenti e l'identità precedente (e l'ID client federato se si configura l'accesso tra tenant) nella chiamata API usando i parametri -KeyList, -AssignIdentity, -UserAssignedIdentityId e -EncryptionProtector (e, se necessario, -FederatedClientId).

Ripristino geografico

Per un ripristino geografico di un database configurato con chiavi gestite dal cliente a livello di database sono necessari i passaggi seguenti:

• Prepopolare l'elenco di chiavi usate dal database primario usando Get-AzSqlDatabaseGeoBackup e -ExpandKeyList per recuperare tutte le chiavi.
• Selezionare l'identità gestita assegnata dall'utente (e l'ID client federato se si configura l'accesso tra tenant).
• Usare Restore-AzSqlDatabase con il -FromGeoBackup parametro e fornire l'elenco prepopolato di chiavi ottenute dai passaggi precedenti e l'identità precedente (e l'ID client federato se si configura l'accesso tra tenant) nella chiamata API usando i parametri -KeyList, -AssignIdentity, -UserAssignedIdentityId e -EncryptionProtector (e, se necessario, -FederatedClientId).

Limiti

La funzionalità chiavi gestite dal cliente a livello di database non supporta le rotazioni delle chiavi quando i file di log virtuali del database vengono crittografati con una chiave precedente diversa dalla protezione primaria corrente del database. L'errore generato in questo caso è:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: la rotazione delle chiavi per la protezione TDE a livello di database viene bloccata quando le transazioni attive mantengono il log crittografato con le chiavi precedenti.

Per comprendere ulteriormente questo scenario, si consideri la sequenza temporale seguente:

• Time t0 = Viene creato un database senza crittografia
• Time t1 = Questo database è protetto da Thumbprint A, ovvero una chiave gestita dal cliente a livello di database.
• Time t2 = La protezione del database viene ruotata su una nuova chiave gestita dal cliente a livello di database, Thumbprint B.
• Time t3 = Richiesta di una modifica della protezione in Thumbprint C.
• Se i file VLF attivi usano Thumbprint A, la rotazione non è consentita.
• Se i file VLF attivi non usano Thumbprint A, la rotazione è consentita.

È possibile usare la vista sys.dm_db_log_info (Transact-SQL) - SQL Server per il database e cercare i file di log virtuali attivi. Dovrebbe essere visualizzato un file VLF attivo crittografato con la prima chiave (ad esempio Thumbprint A). Dopo aver generato un numero sufficiente di log tramite l'inserimento di dati, il file VLF precedente viene scaricato e dovrebbe essere possibile eseguire un'altra rotazione della chiave.

Se si ritiene che un elemento stia tenendo premuto il log per un periodo più lungo del previsto, vedere la documentazione seguente per ulteriori operazioni di risoluzione dei problemi:

• sys.dm_db_log_stats (Transact-SQL) per i valori log_truncation_holdup_reason possibili.
• Risoluzione dell'errore di log delle transazioni pieno 9002.

Passaggi successivi

Vedere la documentazione seguente su varie operazioni della chiave gestita dal cliente a livello di database:

• Gestione delle identità e delle chiavi per TDE con chiavi gestite dal cliente a livello di database

• Configurare la replica geografica e il ripristino del backup per Transparent Data Encryption con chiavi gestite dal cliente a livello di database