Transparent data encryption (TDE)

  • Articolo

Si applica a: SQL Server Azure SQL DatabaseIstanza gestita di SQL di Azure Azure SynapseAnalytics AnalyticsPlatform System (PDW)

Transparent data encryption (TDE) crittografa SQL Server, database Azure SQL e Azure Synapse file di dati di Analisi. Questa crittografia è nota come crittografia dei dati inattivi.

Per proteggere un database utente, è possibile prendere precauzioni come:

  • Progettazione di un sistema protetto.
  • Crittografia degli asset riservati.
  • Creazione di un firewall per i server di database.

Tuttavia, una persona dannosa che ruba supporti fisici come unità o nastri di backup può ripristinare o collegare il database e esplorare i dati.

Una soluzione consiste nel crittografare i dati sensibili in un database e usare un certificato per proteggere le chiavi di crittografia dei dati. Questa soluzione impedisce l'uso dei dati senza le chiavi. È tuttavia necessario pianificare in anticipo questo tipo di protezione.

TDE esegue la crittografia e la decrittografia delle operazioni di I/O di file di dati e log in tempo reale. Per la crittografia viene usata una chiave di crittografia del database (DEK). Il record di avvio del database archivia la chiave per la disponibilità durante il ripristino. La chiave DEK è una chiave simmetrica. È protetto da un certificato archiviato dal database del master server o da una chiave asimmetrica protetta da un modulo EKM.

TDE consente di proteggere i dati inattivi, ovvero i file di dati e di log, e assicura la conformità a numerose leggi, normative e linee guida stabilite in vari settori. Gli sviluppatori di software possono ora crittografare i dati usando gli algoritmi di crittografia AES e 3DES senza modificare applicazioni esistenti.

Nota

TDE non è disponibile per i database di sistema. Non può essere usato per crittografare master, modello o msdb. tempdb viene crittografato automaticamente quando un database utente abilitato per TDE, ma non può essere crittografato direttamente.

Importante

TDE non fornisce funzionalità di crittografia tramite canali di comunicazione. Per altre informazioni su come crittografare i dati su diversi canali di comunicazione, vedere Abilitare connessioni crittografate al motore di database (Gestione configurazione SQL Server).

Argomenti correlati:

Informazioni su TDE

La crittografia di un file di database viene eseguita a livello di pagina. Le pagine di un database crittografato vengono crittografate prima di essere scritte sul disco e decrittografate quando vengono lette in memoria. L'uso di TDE non comporta un aumento delle dimensioni del database crittografato.

Informazioni applicabili alle database SQL

Quando si usa TDE con database Azure SQL, database SQL crea automaticamente il certificato a livello di server archiviato nel master database. Per spostare un database TDE in database SQL, non è necessario decrittografare il database per l'operazione di spostamento. Per altre informazioni sull'uso di TDE con database SQL, vedere La crittografia dei dati trasparente con Azure SQL Database.

Informazioni applicabili alle SQL Server

Dopo aver protetto un database, è possibile ripristinarlo usando il certificato corretto. Per altre informazioni sui certificati, vedere SQL Server Certificates and Asymmetric Keys.

Dopo l'abilitazione di TDE, eseguire immediatamente un backup del certificato e della chiave privata associata. Se il certificato risulta non più disponibile o se il database viene ripristinato o collegato in un altro server, saranno necessari i backup del certificato e della chiave privata. In caso contrario, non sarà possibile aprire il database.

Conservare il certificato di crittografia anche se si disabilita TDE nel database. Anche se il database non è crittografato, è possibile che parti del log delle transazioni rimangano protette. Il certificato potrebbe anche essere necessario per alcune operazioni fino a quando non si esegue un backup completo del database.

È comunque possibile usare un certificato oltre la data di scadenza per crittografare e decrittografare dati con TDE.

Gerarchia di crittografia

L'API Protezione dati di Windows (DPAPI) si trova nella radice dell'albero di crittografia, protegge la gerarchia delle chiavi a livello di computer e viene usata per proteggere la chiave master del servizio (SMK) per l'istanza del server di database. SmK protegge la chiave master del database (DMK), archiviata a livello di database utente e protegge i certificati e le chiavi asimmetriche. Queste chiavi, a sua volta, proteggono le chiavi simmetriche, che proteggono i dati. TDE usa una gerarchia simile fino al certificato. Quando si usa TDE, il DMK e il certificato devono essere archiviati nel master database. Una nuova chiave, usata solo per TDE e denominata chiave di crittografia del database (DEK), viene creata e archiviata nel database utente.

La figura seguente illustra l'architettura della crittografia TDE: Solo gli elementi a livello di database (la chiave di crittografia del database e le parti ALTER DATABASE) sono configurabili dall'utente quando si usa TDE in database SQL.

Architettura Di crittografia del database trasparente.

Abilitare TDE

Per usare TDE, eseguire le operazioni seguenti:

Si applica a: SQL Server.

  1. Creare una chiave master.

  2. Creare o ottenere un certificato protetto dalla chiave master.

  3. Creare una chiave di crittografia del database e proteggerla mediante il certificato.

  4. Impostare il database per l'uso della crittografia.

L'esempio seguente illustra come crittografare e decrittografare il database AdventureWorks2012 usando un certificato denominato MyServerCert installato nel server.

USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
GO
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';
GO
USE AdventureWorks2012;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO
ALTER DATABASE AdventureWorks2012
SET ENCRYPTION ON;
GO

Le operazioni di crittografia e decrittografia sono pianificate sui thread di background da SQL Server. Per visualizzare lo stato di queste operazioni, usare le viste del catalogo e le viste a gestione dinamica nella tabella riportata più avanti in questo argomento.

Attenzione

Anche i file di backup per i database in cui è abilitata la funzionalità TDE vengono crittografati tramite la chiave di crittografia del database. Di conseguenza, quando questi backup vengono ripristinati, è necessario che sia disponibile il certificato che protegge la chiave di crittografia del database. Quindi, oltre a eseguire un backup del database, assicurarsi di conservare i backup dei certificati del server. Se il certificato non è più disponibile, si verificherà la perdita di dati.

Per altre informazioni, vedere SQL Server Certificates and Asymmetric Keys.

Comandi e funzioni

Affinché le istruzioni seguenti accettino certificati TDE, usare una chiave master del database per crittografarli. Se vengono crittografati solo tramite password, verranno rifiutati dalle istruzioni come componenti di crittografia.

Importante

Se si proteggono i certificati con password dopo l'uso da parte di TDE, il database diventa inaccessibile dopo un riavvio.

Nella tabella seguente sono inclusi collegamenti e spiegazioni delle funzioni e dei comandi correlati a TDE:

Comando o funzione Scopo
CREATE DATABASE ENCRYPTION KEY (Transact-SQL) Crea una chiave per la crittografia di un database
ALTER DATABASE ENCRYPTION KEY (Transact-SQL) Modifica la chiave per la crittografia di un database
DROP DATABASE ENCRYPTION KEY (Transact-SQL) Rimuove la chiave per la crittografia di un database
Opzioni ALTER DATABASE SET (Transact-SQL) Descrive l'opzione ALTER DATABASE usata per abilitare TDE

Viste del catalogo e DMV

Nella tabella seguente vengono illustrate le viste del catalogo e le viste a gestione dinamica di TDE.

Vista del catalogo e vista a gestione dinamica Scopo
sys.databases (Transact-SQL) Vista del catalogo che consente di visualizzare le informazioni del database
sys.certificates (Transact-SQL) Vista del catalogo che consente di visualizzare i certificati in un database
sys.dm_database_encryption_keys (Transact-SQL) DMV che fornisce informazioni sulle chiavi di crittografia e lo stato della crittografia di un database

Autorizzazioni

Ogni funzionalità e comando di TDE ha requisiti specifici relativi alle autorizzazioni, descritti nelle tabelle precedenti.

La visualizzazione dei metadati interessati da TDE richiede l'autorizzazione VIEW DEFINITION per il certificato.

Considerazioni

Durante un'analisi di una nuova crittografia di un database, le operazioni di manutenzione per il database sono disabilitate. È possibile usare l'impostazione della modalità utente singolo per il database per eseguire operazioni di manutenzione. Per altre informazioni, vedere Impostare un database in modalità utente singolo.

Usare la sys.dm_database_encryption_keys vista gestione dinamica per trovare lo stato della crittografia del database. Per altre informazioni, vedere la sezione "Viste del catalogo e DMV" più indietro in questo argomento.

Con TDE vengono crittografati tutti i file e i filegroup in un database. Se un database include un filegroup contrassegnato come READ ONLY, l'operazione di crittografia del database ha esito negativo.

Se si usa un database per il mirroring del database o il log shipping, entrambi i database vengono crittografati. Le transazioni del log vengono crittografate quando vengono inviate tra i database.

Importante

Gli indici full-text vengono crittografati quando un database viene impostato per la crittografia. Gli indici creati in una versione di SQL Server precedente a SQL Server 2008 vengono importati nel database da SQL Server 2008 o versioni successive e crittografati con TDE.

Suggerimento

Per monitorare le modifiche dello stato TDE di un database, usare SQL Server Audit o il servizio di controllo del database SQL. Per SQL Server, lo stato TDE è registrato nel gruppo di azioni di controllo DATABASE_CHANGE_GROUP, disponibile in Azioni e gruppi di azioni di SQL Server Audit.

Restrizioni

Durante le operazioni di crittografia del database iniziale, modifica della chiave o decrittografia del database, non sono consentite le operazioni seguenti:

  • Eliminazione di un file da un filegroup in un database

  • Rimozione di un database

  • Attivazione della modalità offline per un database

  • Scollegamento di un database

  • Transizione di un database o filegroup in un stato READ ONLY

Le operazioni seguenti non sono consentite durante le CREATE DATABASE ENCRYPTION KEYistruzioni , , ALTER DATABASE ENCRYPTION KEYDROP DATABASE ENCRYPTION KEYeALTER DATABASE...SET ENCRYPTION:

  • Eliminazione di un file da un filegroup in un database

  • Rimozione di un database

  • Attivazione della modalità offline per un database

  • Scollegamento di un database

  • Transizione di un database o filegroup in un stato READ ONLY

  • Uso di un comando ALTER DATABASE

  • Avvio del backup di un database o di un file di database

  • Avvio del ripristino di un database o di un file di database

  • Creazione di uno snapshot

Le operazioni o le condizioni seguenti impediscono le CREATE DATABASE ENCRYPTION KEYistruzioni , , ALTER DATABASE ENCRYPTION KEYDROP DATABASE ENCRYPTION KEYeALTER DATABASE...SET ENCRYPTION:

  • Un database è di sola lettura o contiene filegroup di sola lettura.

  • È in corso l'esecuzione di un comando ALTER DATABASE.

  • È in corso l'esecuzione di un backup dei dati.

  • Un database è offline o è in corso di ripristino.

  • Uno snapshot è in corso.

  • Le attività di manutenzione del database sono in esecuzione.

Durante la creazione dei file di database, l'inizializzazione immediata dei file non è disponibile se è abilitata la crittografia TDE.

Per crittografare la chiave di crittografia del database con una chiave asimmetrica, è necessario che quest'ultima risieda in un provider EKM (Extensible Key Management).

Analisi TDE

Per abilitare TDE in un database, SQL Server deve eseguire un'analisi di crittografia. L'analisi legge ogni pagina dai file di dati nel pool di buffer e quindi scrive le pagine crittografate di nuovo su disco.

Per dare maggiore controllo sull'analisi della crittografia, SQL Server 2019 (15.x) introduce l'analisi TDE, che ha una sintassi di sospensione e ripresa. È possibile sospendere l'analisi mentre il carico di lavoro nel sistema è elevato o durante le ore di picco delle attività aziendali e quindi riprendere l'analisi in un secondo momento.

Per sospendere l'analisi della crittografia TDE, usare la sintassi seguente:

ALTER DATABASE <db_name> SET ENCRYPTION SUSPEND;

In modo analogo, per sospendere l'analisi della crittografia TDE, usare la sintassi seguente:

ALTER DATABASE <db_name> SET ENCRYPTION RESUME;

La colonna encryption_scan_state è stata aggiunta alla sys.dm_database_encryption_keys visualizzazione gestione dinamica. Indica lo stato corrente dell'analisi della crittografia. È disponibile anche una nuova colonna denominata encryption_scan_modify_date, che contiene la data e l'ora dell'ultima modifica dello stato di analisi della crittografia.

Se l'istanza di SQL Server viene riavviata durante la sospensione dell'analisi della crittografia, un messaggio viene registrato nel log degli errori durante l'avvio. Il messaggio indica che un'analisi esistente è stata sospesa.

Importante

La funzionalità di sospensione e ripresa dell'analisi TDE non è attualmente disponibile in database Azure SQL, Istanza gestita di SQL di Azure e Azure Synapse Analytics.

TDE e log delle transazioni

Se si consente a un database di usare TDE, viene rimossa la parte rimanente del log delle transazioni virtuale corrente. La rimozione forza la creazione del log delle transazioni successivo. Questo comportamento garantisce che non rimanga alcun testo non crittografato nei log dopo l'impostazione del database per la crittografia.

Per determinare lo stato di crittografia dei file di log, vedere la colonna encryption_state nella vista sys.dm_database_encryption_keys, come in questo esempio:

USE AdventureWorks2012;
GO
/* The value 3 represents an encrypted state
   on the database and transaction logs. */
SELECT *
FROM sys.dm_database_encryption_keys
WHERE encryption_state = 3;
GO

Per altre informazioni sull'architettura SQL Server file di log, vedere Log delle transazioni (SQL Server).

Prima della modifica della chiave di crittografia del database, la chiave di crittografia del database precedente crittografa tutti i dati scritti nel log delle transazioni.

Se si modifica una chiave di crittografia del database due volte, è necessario eseguire un backup del log prima di poter modificare di nuovo la chiave di crittografia del database.

TDE e il database di tempdb sistema

Il tempdb database di sistema viene crittografato se qualsiasi altro database nell'istanza di SQL Server viene crittografato tramite TDE. La crittografia potrebbe influire sulle prestazioni dei database non crittografati presenti nella stessa istanza di SQL Server. Per altre informazioni sul database di tempdb sistema, vedere Database tempdb.

TDE e replica

La replica non consente di replicare automaticamente dati da un database abilitato per TDE in un formato crittografato. Per proteggere i database di distribuzione e del Sottoscrittore, abilitare separatamente TDE.

La replica snapshot può archiviare dati in file intermedi non crittografati, come i file BCP, così come la distribuzione iniziale dei dati per la replica transazionale e di tipo merge. Durante questo tipo di replica, è possibile abilitare la crittografia per proteggere il canale di comunicazione.

Per altre informazioni, vedere Abilitare le connessioni crittografate al motore di database (Gestione configurazione SQL Server).

Gruppi di disponibilità e TDE

È possibile aggiungere un database crittografato a un gruppo di disponibilità.

Per crittografare i database che fanno parte di un gruppo di disponibilità, creare i certificati e la chiave master o la chiave asimmetrica (EKM) in tutte le repliche secondarie prima di creare la chiave di crittografia del database nella replica primaria.

Se un certificato viene usato per proteggere la chiave di crittografia del database (chiave DEK), eseguire il backup del certificato creato nella replica primaria e quindi creare il certificato da un file in tutte le repliche secondarie prima di creare la chiave di crittografia del database nella replica primaria.

TDE e dati FILESTREAM

I dati FILESTREAM non vengono crittografati anche quando si abilita TDE.

TDE e backup

I certificati vengono comunemente usati in Transparent Data Encryption per proteggere la chiave DEK (Database Encryption Key). Il certificato deve essere creato nel master database. I file di backup dei database in cui è abilitata la funzionalità TDE vengono crittografati anche tramite la chiave di crittografia del database. Di conseguenza, quando si esegue il ripristino da questi backup, il certificato che protegge la chiave di crittografia del database deve essere disponibile. Ciò significa che, oltre al backup del database, è necessario mantenere i backup dei certificati server per evitare la perdita di dati. Se il certificato non è più disponibile, si verificherà la perdita di dati.

Rimuovere TDE

Rimuovere la crittografia dal database usando l'istruzione ALTER DATABASE.

ALTER DATABASE <db_name> SET ENCRYPTION OFF;

Per visualizzare lo stato della crittografia del database, usare la DMV sys.dm_database_encryption_keys.

Attendere il completamento della decrittografia prima di rimuovere la chiave di crittografia del database usando DROP DATABASE ENCRYPTION KEY.

Importante

Eseguire il backup della chiave master e del certificato usati per TDE in una posizione sicura. La chiave master e il certificato sono necessari per ripristinare i backup eseguiti quando il database era crittografato con TDE. Dopo aver rimosso la chiave di crittografia del database, eseguire un backup del log seguito da un nuovo backup completo del database decrittografato.

TDE e l'estensione del pool di buffer

Quando si crittografa un database tramite TDE, i file correlati all'estensione del pool di buffer non vengono crittografati. Per questi file, usare strumenti di crittografia come BitLocker o EFS a livello di file system.

TDE e OLTP in memoria

È possibile abilitare TDE in un database contenente oggetti OLTP in memoria. In SQL Server 2016 (13.x) e Azure SQL Database In-Memory i record e i dati di log OLTP vengono crittografati se si abilita TDE. In SQL Server 2014 (12.x), In-Memory record di log OLTP vengono crittografati se si abilita TDE, ma i file nel filegroup MEMORY_OPTIMIZED_DATA non sono crittografati.

Linee guida sulla gestione dei certificati usati in TDE

Il backup del certificato e della chiave master del database è necessario quando il database è abilitato per TDE e viene usato nel log shipping o nel mirroring del database.

È anche importante ricordare che il certificato usato per proteggere la chiave di crittografia del database non deve mai essere eliminato dal master database. In questo modo il database crittografato diventa inaccessibile.

Viene generato un messaggio di avviso simile al seguente dopo l'esecuzione di Create Database Encryption Key se il certificato usato nel comando non è già stato sottoposto a backup.

Il certificato usato per crittografare la chiave di crittografia del database non è stato sottoposto a backup. Eseguire subito il backup del certificato e della chiave privata associata. Se il certificato non è mai disponibile o se è necessario ripristinare o collegare il database in un altro server, è necessario disporre di backup del certificato e della chiave privata oppure non sarà possibile aprire il database.

La query seguente può essere usata per identificare i certificati usati in TDE di cui non è stato eseguito il backup dal momento in cui è stato creato.

SELECT pvt_key_last_backup_date,
    Db_name(dek.database_id) AS encrypteddatabase ,c.name AS Certificate_Name
FROM sys.certificates c
    INNER JOIN sys.dm_database_encryption_keys dek
    ON c.thumbprint = dek.encryptor_thumbprint

Se la colonna pvt_key_last_backup_date è NULL, il database corrispondente a tale riga è stato abilitato per TDE, ma il certificato usato per proteggere la chiave DEK non è stato sottoposto a backup. Per altre informazioni sul backup di un certificato, vedere BACKUP CERTIFICATE nella documentazione online di SQL Server.

Vedere anche