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.

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.

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

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.

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

Viste del catalogo e DMV

Nella tabella seguente vengono illustrate le viste del catalogo TDE e le viste a gestione dinamica (DMV).

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.

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.

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.

Attendere il completamento della decrittazione prima di rimuovere la chiave DEK usando DROP DATABASE ENCRYPTION KEY.

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

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.

Contenuto correlato

• Sicurezza per il motore di Database di SQL Server e il Database SQL di Azure
• FILESTREAM (SQL Server)
• Crittografia di SQL Server
• Chiavi di crittografia del database e di SQL Server (Motore di database)