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). L'estensione di TDE con la chiave gestita dal cliente (CMK) consente la protezione dei dati a riposo dove il protettore TDE (la chiave di crittografia) viene archiviato in un'istanza di Azure Key Vault o in un Azure Managed HSM che crittografa le chiavi di crittografia del database. TDE con cmk può essere impostato a livello di server e viene ereditato da tutti i database crittografati associati a tale server. È anche possibile impostare la protezione TDE come chiave gestita dal cliente singolarmente per ogni database all'interno del server. Qualsiasi risorsa Microsoft.Sql/servers/databases con una proprietà encryptionProtector valida e non vuota viene configurata con chiavi gestite dal cliente a livello di database. Le chiavi gestite dal cliente supportano sia chiavi asimmetriche (RSA) che simmetriche (AES), a seconda dell'archivio chiavi selezionato.

In questo scenario, una chiave asimmetrica o simmetrica archiviata in un Azure Key Vault o in un Azure Managed HSM, di proprietà e gestito dal cliente, può essere usata singolarmente per ciascun database all'interno di un server per crittografare la chiave di crittografia del database (DEK); questa chiave è chiamata TDE protector. È 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 o al modulo di protezione hardware gestito di Azure 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 o al modulo di protezione hardware gestito di Azure.
• Identità client federata: è anche possibile abilitare una chiave gestita dal cliente da Azure Key Vault o dal modulo di protezione hardware gestito di Azure 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 o in un modulo di protezione hardware gestito di Azure 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 il TDE CMK a livello di database, gli ISV possono offrire ai propri clienti la funzionalità CMK e ottenere l'isolamento della sicurezza, poiché il protettore TDE di ogni database può essere di proprietà del rispettivo cliente ISV in un key vault o HSM gestito che essi possiedono. 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. Il tenant Best Services che contiene il server logico Azure SQL con due database, DB 1 e DB 2, e il Azure Key Vault 1 con un Key 1 che accede al database DB 1 tramite 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 Key 2 che valuta il database DB 2 nell'intero tenant come parte del supporto cross-tenant per CMK a livello di database, usando la configurazione Key 2 e UMI 2 per questo database.

Per altre informazioni sulla configurazione delle identità cross-tenant, vedere il documento a livello di server Chiavi gestite dal cliente cross-tenant con crittografia trasparente dei dati.

Scenari di gestione delle chiavi 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 su CMK
• Database1 – Key1 usato come chiave gestita dal cliente
• Database2 – Key1 usato come CMK (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 CMK
• Database1 – Key2 usato come CMK
• 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 CMK
• Database2 – Chiave gestita dal servizio impostata come elemento di protezione TDE
• Database3 – Chiave gestita dal servizio impostata come elemento di 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 reimpostato per usare la chiave gestita dal servizio a livello di server logico.

Transparent Data Encryption con chiavi gestite dal cliente usa una chiave esterna, denominata protezione TDE, archiviata in Azure Key Vault o Azure modulo di protezione hardware gestito per proteggere la chiave di crittografia del database (DEK).

Tipi di chiavi e dimensioni supportati

A seconda dell'offerta Azure SQL e della configurazione TDE, la protezione TDE può essere supportata da chiavi asimmetriche o simmetriche archiviate in Azure Key Vault o Azure Key Vault modulo di protezione hardware gestito.

• Chiavi asimmetriche (RSA o RSA HSM)

  • Supportato da Azure Key Vault e Azure Key Vault Managed HSM
  • Dimensioni delle chiavi supportate: 2048 bit e 3072 bit
  • Supportato per database SQL di Azure, Istanza gestita di SQL di Azure e Azure Synapse Analytics

• Chiavi simmetriche (AES)

  • Supportato in Azure Key Vault modulo di protezione hardware gestito
  • Dimensioni delle chiavi supportate: 128 bit, 192 bit e 256 bit
  • Supportato solo per database SQL di Azure, attualmente in anteprima pubblica. Questa funzionalità può essere visualizzata nel tempo a seconda dell'area geografica e dello stato di distribuzione del servizio.

Limitazioni per le chiavi simmetriche (AES)

Quando si usano chiavi simmetriche (AES) come protezione TDE, solo le chiavi archiviate in Azure Key Vault o Azure Key Vault modulo di protezione hardware gestito sono supportate per le operazioni del ciclo di vita delle chiavi in corso. I clienti possono importare una chiave da un modulo di protezione hardware locale una volta in Azure Key Vault o Azure Key Vault modulo di protezione hardware gestito. Dopo l'importazione iniziale, tutte le successive operazioni del ciclo di vita della chiave, tra cui il ripristino a un momento specifico, il ripristino di emergenza geografica e la riconvalida della chiave, devono basarsi sull'infrastruttura di Azure Key Vault o di Azure Key Vault Managed HSM. I clienti sono responsabili della gestione dei backup locali delle chiavi importate per supportare scenari di ripristino e riconvalida. Queste limitazioni si applicano solo alle chiavi simmetriche (AES) e non si applicano alle chiavi asimmetriche (RSA).

Stato della chiave e requisiti di validità

• Se viene specificata una data di attivazione della chiave, deve essere impostata su una data e un'ora nel passato.
• Se viene specificata una data di scadenza della chiave, deve essere impostata su una data e un'ora in futuro.
• La chiave deve avere lo stato Abilitato.

Requisiti di importazione delle chiavi

Se si importa una chiave esistente in Azure Key Vault, la chiave deve essere fornita in uno dei formati supportati seguenti:

• .pfx
• .byok
• .backup

Per importare chiavi protette da HSM in HSM gestito di Azure, vedere Importare chiavi protette da HSM in HSM gestito (BYOK).

Azure Key Vault e Azure Managed HSM - requisiti di identità gestita

Gli stessi requisiti per la configurazione delle chiavi di Azure Key Vault o delle chiavi del modulo di protezione hardware gestito di Azure 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 il protettore TDE per un database significa passare a una nuova chiave asimmetrica che protegge il database. 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.

È possibile ruotare la protezione TDE modificando la configurazione in modo da usare una nuova chiave archiviata in Azure Key Vault o in Azure Key Vault Managed HSM. A seconda dell'offerta Azure SQL e della configurazione supportata, questo può includere:

• Passaggio a una nuova versione della stessa chiave
• Passare a un'altra chiave
• Passaggio tra tipi di chiave supportati, ad esempio chiavi asimmetriche (RSA) e chiavi simmetriche (AES)

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 CMK 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 Azure Key Vault o le chiavi del modulo di protezione hardware gestito di Azure. 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

Selezionare il tipo di Key Vault da utilizzare.

Chiavi tra tenant gestite dal cliente

Le chiavi gestite dal cliente tra tenant con Crittografia dati trasparente descrive come configurare un ID client federato per CMK a livello di server. È necessario eseguire una configurazione simile anche per la CMK a livello di database e l'ID client federato deve essere aggiunto come parte delle richieste API Set-AzSqlDatabase o New-AzSqlDatabase.

Un database configurato con una CMK a livello di database può essere riportato alla crittografia a livello di server se il server logico è configurato con una chiave gestita dal servizio usando Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert.

In caso di protector TDE inaccessibile come descritto in Transparent Data Encryption (TDE) con CMK, una volta corretto l'accesso alla chiave, è possibile usare Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation per rendere accessibile il database.

Considerazioni aggiuntive

• Se TDE con CMK è già abilitata a livello di server, l'impostazione di una CMK per un database specifico ha la precedenza sull'impostazione CMK a livello di server, con la conseguente nuova crittografia della DEK del database tramite il sistema di 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 CMK a livello di database non è supportata mediante 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 CMK tra tenant a livello di server non influiscono sui singoli database configurati con CMK a livello di database e questi continuano a usare la propria configurazione a tenant singolo o tra tenant.
• È possibile impostare solo un'identità gestita assegnata dall'utente a livello di database.

Migrazione dei database esistenti a una CMK 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 CMK a livello di server senza georeplica

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. Tra i risultati, selezionare quelli che hanno la stessa impronta digitale corrispondente all'elenco del risultato precedente.
5. Eseguire una chiamata API di aggiornamento del database per il database che si desidera migrare, insieme all'identità e all'elemento di 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 CMK a livello di server con georeplicazione

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. Effettuare una chiamata API di aggiornamento del database ai database primario e secondario che si desidera migrare, assieme all'identità e alle chiavi sopra indicate come chiavi a livello di database, utilizzando Set-AzSqlDatabase e il parametro -KeyList. 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 o al modulo di protezione hardware gestito (in qualsiasi area) o per separare gli insiemi di credenziali delle chiavi o i moduli di protezione hardware gestiti. Se insiemi di credenziali separati o moduli di protezione hardware gestiti sono collegati ai server primari e secondari, il cliente è responsabile di mantenere coerente il materiale delle chiavi negli insiemi di credenziali o nei moduli di protezione hardware gestiti, affinché il geo-secondario sia sincronizzato e possa utilizzare la stessa chiave dal suo insieme di credenziali collegato o modulo di protezione hardware gestito nel caso in cui il primario diventi inaccessibile a causa di un'interruzione nella regione e venga attivato un failover. È possibile configurare fino a quattro secondari e il concatenamento (secondari di secondari) non è supportato.

Per configurare la georeplica attiva per un database configurato con CMK a livello di database, è necessario creare una replica secondaria con un'identità gestita assegnata dall'utente valida e un elenco delle chiavi attualmente 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 fornire, nella chiamata API, l'elenco precompilato di chiavi ottenute dal database di origine e l'identità sopra indicata (e il DI del client federato, se si configura l'accesso tra tenant diversi) utilizzando i parametri -KeyList, -AssignIdentity, -UserAssignedIdentityId, -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

Dopo che un database viene crittografato con TDE usando una chiave di Azure Key Vault o HSM gestito di Azure, tutti i backup appena generati vengono crittografati 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 un TDE protector da Azure Key Vault o Azure Managed HSM configurato a livello di database, assicurarsi che il materiale della chiave venga fornito al database di destinazione. È consigliabile mantenere tutte le vecchie versioni del protezione TDE nel key vault o nel managed HSM, 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).

Ripristino di 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 = Viene richiesta la sostituzione del dispositivo di protezione con Thumbprint C.
• Se i file VLF attivi usano Thumbprint A, la rotazione non è consentita.
• Se i 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). Una volta che l'inserimento dei dati ha generato una quantità sufficiente di log, questo vecchio VLF viene svuotato e dovrebbe essere possibile eseguire un'altra rotazione della chiave.

Se ritieni che qualcosa stia causando un ritardo del log più a lungo del previsto, consulta la documentazione seguente per ulteriori informazioni sulla risoluzione dei problemi:

• sys.dm_db_log_stats (Transact-SQL) per i valori log_truncation_holdup_reason possibili.
• Risolvere i problemi relativi all'errore 9002: log delle transazioni completo.

Passaggi successivi

Consulta la seguente documentazione sulle varie operazioni CMK 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