Transparent data encryption (TDE)
Si applica a: SQL Server Database SQL di Azure Istanza gestita di SQL di Azure Azure Synapse Analytics Piattaforma di strumenti analitici (PDW)
Transparent Data Encryption (TDE) crittografa i file di dati di SQL Server, Database SQL di Azure e Azure Synapse Analytics. Questa crittografia è nota come crittografia dei dati inattivi.
Per proteggere un database utente, è possibile adottare precauzioni come:
- Progettazione di un sistema protetto.
- Crittografia degli asset riservati.
- Creazione di un firewall per i server di database.
Tuttavia, un utente malintenzionato che riesce a sottrarre supporti fisici come le unità o i nastri di backup può ripristinare o collegare il database ed esplorarne 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 protetta tramite un certificato archiviato nel database master
del server o 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
, model
o msdb
. tempdb
viene crittografato automaticamente quando un database utente abilita TDE, ma non può essere crittografato direttamente.
TDE non fornisce funzionalità di crittografia tramite canali di comunicazione. Per ulteriori informazioni su come crittografare i dati su diversi canali di comunicazione, vedere Configurare il motore di database di SQL Server per la crittografia delle connessioni.
Argomenti correlati:
- Transparent Data Encryption per database SQL, Istanza gestita di SQL e Azure Synapse Analytics
- Introduzione a Transparent Data Encryption (TDE) in Azure Synapse Analytics
- Spostare un database protetto da TDE in un'altra istanza di SQL Server
- Abilitare TDE in SQL Server con EKM
- Usare Connettore SQL Server con le funzionalità di crittografia SQL
- Blog sulla sicurezza di SQL Server in TDE con domande frequenti
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 a database SQL
Quando si usa TDE con Database SQL di Azure, il database SQL crea automaticamente il certificato a livello di server archiviato nel database master
. Per spostare un database TDE nel database SQL, non è necessario decriptare il database per l'operazione di spostamento. Per ulteriori informazioni sull'uso di TDE con il database SQL, vedere Transparent Data Encryption con Database SQL di Azure.
Informazioni applicabili a 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. Anche i certificati archiviati in un database di sistema indipendente devono essere sottoposti a backup.
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
La Data Protection API (DPAPI) di Windows si trova alla 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 database. SMK protegge la chiave master del database (DMK), archiviata a livello di database utente, oltre ai certificati e alle chiavi asimmetriche. Queste chiavi, a loro 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 database master
. Una nuova chiave, usata solo per TDE e denominata chiave di crittografia del database (chiave 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 nel database SQL.
Abilitare Transparent Data Encryption
Per usare TDE, eseguire le operazioni seguenti:
Si applica a: SQL Server.
- Creare una chiave master.
- Creare o ottenere un certificato protetto dalla chiave master.
- Creare una chiave di crittografia del database e proteggerla mediante il certificato.
- Impostare il database per l'uso della crittografia.
L'esempio seguente illustra come crittografare e decrittografare il database AdventureWorks2022
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 AdventureWorks2022;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO
ALTER DATABASE AdventureWorks2022
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 DEK. Di conseguenza, quando questi backup vengono ripristinati, è necessario che sia disponibile il certificato che protegge la chiave DEK. 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 | Crea una chiave per la crittografia di un database |
ALTER DATABASE ENCRYPTION KEY | Modifica la chiave per la crittografia di un database |
DROP DATABASE ENCRYPTION KEY | Rimuove la chiave per la crittografia di un database |
Opzioni ALTER DATABASE SET | Viene descritta l'opzione ALTER DATABASE , utilizzata per abilitare TDE |
Viste del catalogo e DMV
Nella tabella seguente vengono illustrate le viste del catalogo TDE e le viste a gestione dinamica (DMV).
Vista del catalogo e vista a gestione dinamica | Scopo |
---|---|
sys.databases | Vista del catalogo che consente di visualizzare le informazioni del database |
sys.certificates | Vista del catalogo che consente di visualizzare i certificati in un database |
sys.dm_database_encryption_keys | 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 ulteriori informazioni, vedere Impostare un database in modalità utente singolo.
Usare la DMV sys.dm_database_encryption_keys
per determinare lo stato della crittografia del database. Per ulteriori informazioni, vedere la sezione Viste del catalogo e DMV più indietro in questo articolo.
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 SQL Server 2005 (9.x) o in una versione precedente vengono importati nel database da SQL Server 2008 (10.0.x) 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 di Database SQL di Azure. Per SQL Server, lo stato TDE è registrato nel gruppo di azioni di controllo DATABASE_OBJECT_CHANGE_GROUP
, disponibile in Azioni e gruppi di azioni di SQL Server Audit.
Limiti
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 istruzioni CREATE DATABASE ENCRYPTION KEY
, ALTER DATABASE ENCRYPTION KEY
, DROP DATABASE ENCRYPTION KEY
o ALTER 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 istruzioni CREATE DATABASE ENCRYPTION KEY
, ALTER DATABASE ENCRYPTION KEY
, DROP DATABASE ENCRYPTION KEY
e ALTER DATABASE...SET ENCRYPTION
:
- Un database è di sola lettura o contiene filegroup di sola lettura.
- È in esecuzione 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 una chiave DEK con una chiave asimmetrica, è necessario che quest'ultima risieda in un provider EKM (Extensible Key Management).
Analisi TDE
Per abilitare TDE per un database, SQL Server deve eseguire un'analisi della 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 avere un maggiore controllo sull'analisi della crittografia, SQL Server 2019 (15.x) introduce l'analisi TDE, che include una sintassi per 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 DMV sys.dm_database_encryption_keys
. 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, viene registrato un messaggio 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 SQL di Azure, Istanza gestita di SQL di Azure e Azure Synapse Analytics.
TDE e log delle transazioni
TDE protegge i file di dati e i file di log inattivi. La crittografia dell'intero database dopo l'abilitazione di TDE in un database non crittografato è un'operazione di dati considerevole e il tempo necessario dipende dalle risorse di sistema in cui è in esecuzione il database. La DMV sys.dm_database_encryption_keys può essere usata per determinare lo stato di crittografia di un database.
Quando TDE è attivato, il motore di database forza la creazione di un nuovo log delle transazioni, che verrà crittografato dalla chiave di crittografia del database. Qualsiasi log generato dall'interleaving delle transazioni precedenti o dalle transazioni a esecuzione prolungata corrente tra la modifica dello stato TDE non viene crittografato.
I log delle transazioni possono essere monitorati usando la DMV sys.dm_db_log_info, che mostra anche se il file di log è crittografato o meno usando la colonna vlf_encryptor_thumbprint
disponibile in Azure SQL e SQL Server 2019 (15.x) e versioni successive. Per trovare lo stato di crittografia del file di log usando la colonna encryption_state
nella vista sys.dm_database_encryption_keys
, di seguito è riportato un esempio di query:
USE AdventureWorks2022;
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 ulteriori informazioni sull'architettura del file di log di SQL Server, vedere Log delle transazioni.
Prima che una chiave DEK venga modificata, la chiave DEK precedente crittografa tutti i dati scritti nel log delle transazioni.
Se si modifica una chiave DEK due volte, è necessario eseguire un backup del log prima di poterla modificare nuovamente.
TDE e database di sistema tempdb
Il database di sistema tempdb
viene crittografato se altri database nell'istanza di SQL Server vengono crittografati tramite TDE. La crittografia potrebbe influire sulle prestazioni dei database non crittografati presenti nella stessa istanza di SQL Server. Per ulteriori informazioni sul database di sistema tempdb
, 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 ulteriori informazioni, vedere Configurare il motore di database di SQL Server per la crittografia delle connessioni.
TDE e gruppi di disponibilità
È possibile aggiungere un database crittografato a un gruppo di disponibilità Always On.
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 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 DEK nella replica primaria.
TDE e dati FILESTREAM
I dati FILESTREAM non vengono crittografati neanche quando si abilita TDE.
TDE e backup
I certificati vengono comunemente usati in Transparent Data Encryption per proteggere la chiave DEK. Il certificato deve essere creato nel database master
. I file di backup dei database in cui è abilitata la funzionalità TDE vengono crittografati anche tramite la chiave DEK. Di conseguenza, quando questi backup vengono ripristinati, è necessario che sia disponibile il certificato che protegge la chiave DEK. Pertanto, oltre a eseguire il backup del database, è necessario conservare i backup dei certificati del server per impedire la perdita di dati. Se il certificato non è più disponibile, si verifica 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.
Nota
Mentre il processo di crittografia è in corso, ALTER DATABASE
le istruzioni non sono consentite nel database. Fino al termine del processo di crittografia, non è possibile iniziare a decrittografare il database.
Attendere il completamento della decrittazione prima di rimuovere la chiave DEK 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 DEK, eseguire un backup del log seguito da un nuovo backup completo del database decrittografato.
TDE ed 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 Database SQL di Azure, i dati e i record di log di OLTP in memoria vengono crittografati se si abilita TDE. In SQL Server 2014 (12.x), i record di log di OLTP in memoria vengono crittografati se si abilita TDE, ma non vengono crittografati i file nel filegroup MEMORY_OPTIMIZED_DATA
.
Linee guida sulla gestione dei certificati usati in TDE
È necessario eseguire il backup del certificato e della chiave master del database quando il database è abilitato per TDE e viene usato nel log shipping o nel mirroring del database. Anche i certificati archiviati in un database di sistema indipendente devono essere sottoposti a backup.
Il certificato usato per proteggere la chiave DEK non deve mai essere eliminato dal database master
. In questo modo, il database crittografato diventa inaccessibile.
Dopo l'esecuzione di CREATE DATABASE ENCRYPTION KEY
, se non è stato ancora eseguito il backup del certificato usato nel comando, appare un messaggio simile al seguente (errore 33091).
Avviso
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 su cui non è stato eseguito il backup da quando sono stati creati.
SELECT pvt_key_last_backup_date,
Db_name(dek.database_id) AS encrypteddatabase,
c.name AS Certificate_Name
FROM sys.certificates AS c
INNER JOIN sys.dm_database_encryption_keys AS 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 ulteriori informazioni sul backup di un certificato, vedere BACKUP CERTIFICATE.