Transparent Data Encryption (TDE) con chiavi gestite 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.

Nota

CmK TDE a livello di database è disponibile per database SQL di Azure (tutte le edizioni database SQL). Non è disponibile per Istanza gestita di SQL di Azure, SQL Server locale, macchine virtuali di Azure e Azure Synapse Analytics (pool SQL dedicati (in precedenza SQL Data Warehouse)).

Nota

Microsoft Entra ID era precedentemente noto come Azure Active Directory (Azure AD).

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 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. Attualmente, TDE con cmk è impostato a livello di server e viene ereditato da tutti i database crittografati associati a tale server. Questa nuova funzionalità consente di impostare la protezione TDE come chiave gestita dal cliente singolarmente per ogni database all'interno del server. Qualsiasi Microsoft.Sql/servers/databases risorsa con una proprietà non valida encryptionProtector 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.

Sono disponibili le funzionalità seguenti:

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

Nota

L'identità gestita assegnata dal sistema non è supportata a livello di database.

Vantaggi del TDE gestito 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 insita nell'affidare i dati sensibili al servizio isv, in particolare se le normative di conformità li richiedono di mantenere il controllo completo sulle chiavi di crittografia.

Con la chiave cmk TDE a livello di database, gli ISV possono offrire ai clienti la funzionalità cmk 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 1DB 2e Azure Key Vault 1 con un Key 1 oggetto 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 CMK. Il Contoso tenant rappresenta un tenant client che contiene Azure Key Vault 2 con una Key 2 valutazione del database DB 2 nel tenant come parte del supporto cmk tra tenant a livello di database tramite Key 2 e UMI 2 configurazione per questo database.

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

Scenari di gestione delle chiavi supportati

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

Scenario esistente

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 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. Una chiave gestita dal cliente diversa (Key2) può essere configurata a livello di database.

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

Nota

Se il server logico è configurato con chiavi gestite dal cliente per TDE, un singolo database in questo server logico non può essere consenso esplicito per l'uso della chiave gestita dal servizio per Transparent Data Encryption.

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

Il server logico è configurato con la chiave gestita dal servizio (SMK) per TDE. Una chiave gestita dal cliente diversa (Key2) può essere configurata a livello di database.

• Server - Chiave gestita dal servizio impostata come protezione TDE
• Database1 – Key2 impostare 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.

Nota

Se il server logico è configurato con cmk per TDE, il database configurato con cmk a livello di database non può essere ripristinato alla crittografia a livello di server.

Anche se l'operazione di ripristino è supportata solo se il server logico è configurato con la chiave gestita dal servizio quando si usa TDE, un database configurato con cmk a livello di database può essere ripristinato in un server configurato con cmk, a condizione che il server abbia accesso a tutte le chiavi usate dal database di origine con un'identità valida.

Key Vault 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 cmk e identità gestite con cmk.

Gestione delle chiavi

La rotazione della protezione 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. 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 -EncryptionProtectorparametri , -AssignIdentitye -UserAssignedIdentityId .

È possibile aggiungere nuove chiavi e rimuovere chiavi esistenti dal database 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 sono necessari. Inoltre, -KeysFilter "current" e un valore temporizzato (ad esempio , 2023-01-01) può essere usato per recuperare le chiavi correnti usate e le chiavi usate in passato in un momento specifico.

Rotazione automatica delle chiavi

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

A seconda del modello di autorizzazione dell'insieme di credenziali delle chiavi (criteri di accesso o controllo degli accessi in base al ruolo di Azure), l'accesso all'insieme di credenziali delle chiavi può essere concesso creando un criterio di accesso nell'insieme di credenziali delle chiavi o creando una nuova assegnazione di ruolo controllo degli accessi in base al ruolo di Azure.

Modello di autorizzazione dei criteri di accesso

Affinché il database usi la protezione TDE archiviata in AKV 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 nell'insieme di credenziali delle chiavi di Azure.
• wrapKey : per essere in grado di proteggere (crittografare) DEK.
• unwrapKey : per essere in grado di rimuovere la protezione (decrittografare) DEK.

Modello di autorizzazioni 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 Key Vault Crypto Service Encryption User 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 cmk a livello di server. È necessario eseguire una configurazione simile per cmk a livello di database e l'ID client federato deve essere aggiunto come parte delle richieste dell'API Set-AzSqlDatabase o New-AzSqlDatabase .

Nota

Se l'applicazione multi-tenant non è stata aggiunta ai criteri di accesso dell'insieme di credenziali delle chiavi con le autorizzazioni necessarie (Get, Wrap Key, Unwrap Key), l'uso di un'applicazione per la federazione delle identità nel portale di Azure visualizzerà un errore. Assicurarsi che le autorizzazioni siano configurate correttamente prima di configurare l'identità client federata.

Un database configurato con cmk 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 CMK, dopo aver corretto l'accesso alla chiave, Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation può essere usato per rendere accessibile il database.

Nota

La gestione delle identità e delle chiavi per TDE con chiavi gestite dal cliente a livello di database descrive in dettaglio le operazioni di gestione delle identità e delle chiavi per cmk a livello di database, insieme a PowerShell, all'interfaccia della riga di comando di Azure e agli esempi di API REST.

Considerazioni aggiuntive

• Se TDE con CMK è già abilitato a livello di server, l'impostazione di CMK per un determinato database sostituisce l'impostazione cmk a livello di server (la chiave DEK del database viene ricrittografata con la protezione TDE a livello di database).
• Le modifiche o le rotazioni delle chiavi a livello di server logico non influiscono sulle impostazioni cmk a livello di database e il database continua a usare la propria impostazione cmk.
• CmK a livello di database non è supportato 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 cmk multi-tenant a livello di server non influiscono sui singoli database configurati con cmk 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.

Nota

Le identità gestite nel database devono essere riassegnate se il database viene rinominato.

Migrazione dei database esistenti a livello di database cmk

I nuovi database possono essere configurati con cmk a livello di database durante la creazione e i database esistenti nei server configurati con chiavi gestite dal servizio possono essere migrati al cmk 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 cmk a livello di server senza replica geografica

1. Usare il 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 AVL attive, registrare dal vlf_encryptor_thumbprintsys.dm_db_log_info risultato.
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 -UserAssignedIdentityIdparametri , -KeyList-AssignIdentity, , -EncryptionProtector (e, se necessario, -FederatedClientId).

Importante

L'identità usata nella richiesta di aggiornamento del database deve avere accesso a tutte le chiavi passate come input.

Database configurato con cmk 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 -KeyList parametro . 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 -EncryptionProtector parametro .
5. Impostare la chiave come protezione di crittografia nel database secondario come descritto in (4) per completare la migrazione.

Importante

Per eseguire la migrazione dei database configurati con una chiave gestita dal servizio a livello di server e la replica geografica, seguire i passaggi (3), (4) e (5) da questa sezione.

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 database secondari 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 -ExpandKeyList parametri 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 -KeyListparametri , -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (e, se necessario, -FederatedClientId).
4. Usare New-AzSqlDatabaseCopy per creare una copia del database con gli stessi parametri nel passaggio precedente.

Importante

Un database configurato con cmk a livello di database deve avere una replica (o una copia) configurata con cmk a livello di database. La replica non può usare le impostazioni di crittografia a livello di server.

Per usare un database configurato con cmk a livello di database in un gruppo di failover, i passaggi precedenti per creare una replica secondaria con lo stesso nome della replica primaria devono essere usati nel server secondario. Dopo aver configurato questa replica secondaria, è possibile aggiungere i database al gruppo di failover.

I database configurati con cmk a livello di database non supportano la creazione secondaria automatica quando vengono aggiunti a un gruppo di failover.

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.

Nota

Tutte le procedure consigliate per la replica geografica e la disponibilità elevata evidenziate in Transparent Data Encryption (TDE) con cmk per cmk a livello di server si applicano alla chiave gestita a livello di database.

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, anche 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 una protezione TDE da Azure Key Vault configurato a livello di database, assicurarsi che il materiale della chiave venga fornito al database di destinazione. È consigliabile mantenere tutte le versioni precedenti della protezione TDE in un insieme di credenziali delle chiavi, in modo che i backup del database possano essere ripristinati.

Importante

È possibile impostare una sola protezione TDE per un database. Tuttavia, è possibile passare più chiavi aggiuntive a un database durante il ripristino senza contrassegnarle come protezione TDE. Queste chiavi non vengono usate per proteggere la chiave DEK, ma possono essere usate durante il ripristino da un backup, se il file di backup viene crittografato con la chiave con l'identificazione personale corrispondente.

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 -ExpandKeyList parametri 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 -FromPointInTimeBackup parametro 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 -KeyListparametri , -AssignIdentity, -UserAssignedIdentityId( -EncryptionProtector e, se necessario, -FederatedClientId) .

Nota

Il ripristino di un database senza la -EncryptionProtector proprietà con tutte le chiavi valide lo reimposta per l'uso della crittografia a livello di server. Ciò può essere utile per ripristinare una configurazione della chiave gestita dal cliente a livello di database alla configurazione della chiave gestita dal cliente a livello di server.

Ripristino del database eliminato

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 -ExpandKeyList parametro . È 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 -KeyListparametri , -AssignIdentity, -UserAssignedIdentityId( -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 per -ExpandKeyList 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 -KeyListparametri , -AssignIdentity, -UserAssignedIdentityId( -EncryptionProtector e, se necessario, -FederatedClientId).

Importante

È consigliabile mantenere tutte le chiavi usate dal database per ripristinare il database. È anche consigliabile passare tutte queste chiavi alla destinazione di ripristino.

Nota

I backup di conservazione dei backup a lungo termine (LTR) non forniscono l'elenco delle chiavi usate dal backup. Per ripristinare un backup con conservazione a lungo termine, tutte le chiavi usate dal database di origine devono essere passate alla destinazione di ripristino con conservazione a lungo termine.

Per altre informazioni sul ripristino di backup per database SQL con cmk a livello di database con esempi con PowerShell, l'interfaccia della riga di comando di Azure e le API REST, vedere Configurare la replica geografica e il ripristino del backup per Transparent Data Encryption con chiavi gestite dal cliente a livello di database.

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:

• Ora t0 = Viene creato un database senza crittografia
• Time t1 = Questo database è protetto da , ovvero una chiave gestita dal Thumbprint Acliente 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.
• Ora 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 VVL 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 possibili log_truncation_holdup_reason .
• Risolvere l'errore completo del log delle transazioni 9002.

Passaggi successivi

Vedere la documentazione seguente su 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