Transparent Data Encryption (TDE)

Transparent Data Encryption (TDE) crittografa i file di dati di SQL Server e del database SQL di Azure, noti come crittografia dei dati inattivi. È possibile adottare diverse precauzioni per proteggere il database, ad esempio la progettazione di un sistema sicuro, la crittografia degli asset riservati e la creazione di un firewall intorno ai server di database. Tuttavia, in uno scenario in cui vengono rubati i supporti fisici (ad esempio unità o nastri di backup), un utente malintenzionato può semplicemente ripristinare o collegare il database ed esplorare i dati. Una soluzione consiste nel crittografare i dati sensibili nel database e proteggere le chiavi usate per crittografare i dati con un certificato. Ciò impedisce a chiunque senza le chiavi di usare i dati, ma questo tipo di protezione deve essere pianificato in anticipo.

TDE esegue la crittografia E/O in tempo reale e la decrittografia dei file di dati e di log. La crittografia usa una chiave di crittografia del database (DEK) che viene archiviata nel record di avvio del database 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 "non operativi", ovvero i file di dati e di log, e assicura la conformità a numerose leggi, normative e linee guida stabilite in vari settori. Ciò consente agli sviluppatori di software di crittografare i dati usando algoritmi di crittografia AES e 3DES senza modificare le applicazioni esistenti.

Importante

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

Argomenti correlati:

• Transparent Data Encryption con il database SQL di Azure
• Spostare un database protetto da TDE in un'altra istanza di SQL Server
• Abilitare TDE con EKM

Informazioni su TDE

La crittografia del file di database viene eseguita a livello di pagina. Le pagine in un database crittografato vengono crittografate prima di essere scritte su disco e decrittografate quando vengono lette in memoria. TDE non aumenta le dimensioni del database crittografato.

Informazioni applicabili al database SQL

Quando si usa TDE con il database SQL V12 V12 (anteprima in alcune aree) il certificato a livello di server archiviato nel database master viene creato automaticamente dal database SQL. Per spostare un database TDE nel database SQL, è necessario decrittografare il database, spostare il database e quindi riabilitare TDE nel database SQL di destinazione. Per istruzioni dettagliate su TDE nel database SQL, vedere Transparent Data Encryption con il database SQL di Azure.

L'anteprima dello stato di TDE si applica anche nel subset di aree geografiche in cui la famiglia di versioni V12 del database SQL viene annunciata come in stato di disponibilità generale. TDE per il database SQL non è destinato all'uso nei database di produzione fino a quando Microsoft non annuncia che TDE viene alzato di livello dall'anteprima alla disponibilità generale. Per altre informazioni sul database SQL V12, vedere Novità del database SQL di Azure.

Informazioni applicabili a SQL Server

Dopo la protezione, il database può essere ripristinato usando il certificato corretto. Per altre informazioni sui certificati, vedere Certificati di SQL Server e chiavi asimmetriche.

Quando si abilita TDE, è consigliabile eseguire immediatamente il backup del certificato e della chiave privata associata al certificato. Se il certificato non è più disponibile o se è necessario ripristinare o collegare il database a un altro server, è necessario disporre di copie di backup del certificato e della chiave privata, altrimenti non sarà possibile aprire il database. Il certificato di crittografia deve essere conservato anche se TDE non è più abilitato nel database. Anche se il database non è crittografato, alcune parti del log delle transazioni potrebbero rimanere protette e il certificato potrebbe essere necessario per alcune operazioni fino a quando non viene eseguito il backup completo del database. Un certificato che ha superato la data di scadenza può comunque essere usato per crittografare e decrittografare i dati con TDE.

Gerarchia di crittografia

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.

Uso della Protezione Trasparente dei Dati

Per usare TDE, seguire questa procedura.

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 dal certificato

• Impostare il database per l'uso della crittografia

Nell'esempio seguente viene illustrata la crittografia e la decrittografia del AdventureWorks2012 database usando un certificato installato nel server denominato MyServerCert.

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_128
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO
ALTER DATABASE AdventureWorks2012
SET ENCRYPTION ON;
GO

Le operazioni di crittografia e decrittografia vengono pianificate in thread in background da SQL Server. È possibile visualizzare lo stato di queste operazioni usando le viste del catalogo e le viste a gestione dinamica nell'elenco visualizzato più avanti in questo argomento.

Attenzione

Anche i file di backup dei database con TDE abilitato vengono crittografati usando la chiave di crittografia del database. Di conseguenza, quando si ripristinano questi backup, il certificato che protegge la chiave di crittografia del database deve essere disponibile. Ciò significa che, oltre al backup del database, è necessario assicurarsi di mantenere i backup dei certificati del server per evitare la perdita di dati. La perdita di dati genererà se il certificato non è più disponibile. Per altre informazioni, vedere SQL Server Certificates and Asymmetric Keys.

Comandi e funzioni

I certificati TDE devono essere crittografati dalla chiave master del database per essere accettati dalle istruzioni seguenti. Se sono crittografati solo con una password, le dichiarazioni li rifiuteranno come cifratori.

Importante

Se si modificano i certificati in modo che siano protetti da password dopo l'uso da parte di TDE, il database diventa inaccessibile dopo un riavvio.

Nella tabella seguente vengono forniti collegamenti e spiegazioni dei comandi e delle funzioni TDE.

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

Viste del catalogo e viste di gestione dinamica

La tabella seguente mostra le viste del catalogo TDE e le viste a gestione dinamica.

Vista del catalogo o vista di gestione dinamica	Scopo
sys.databases (Transact-SQL)	Vista del catalogo che visualizza le informazioni sul database.
sys.certificates (Transact-SQL)	Vista del catalogo che mostra i certificati in un database.
sys.dm_database_encryption_keys (Transact-SQL)	Visualizzazione a gestione dinamica che fornisce informazioni sulle chiavi di crittografia usate in un database e sullo stato della crittografia di un database.

Autorizzazioni

Ogni funzionalità TDE e ogni comando hanno requisiti di autorizzazione individuali, descritti nelle tabelle illustrate in precedenza.

La visualizzazione dei metadati coinvolti in TDE richiede l'autorizzazione VIEW DEFINITION per il certificato.

Considerazioni

Mentre è in corso un'analisi di ricrittografazione per un'operazione di crittografia del database, le operazioni di manutenzione per il database sono disabilitate. È possibile utilizzare l'impostazione della modalità utente singola per il database per eseguire l'operazione di manutenzione. Per altre informazioni, vedere Impostare un database sulla modalità utente singolo.

È possibile trovare lo stato della crittografia del database usando la sys.dm_database_encryption_keys vista a gestione dinamica. Per altre informazioni, vedere la sezione "Viste del catalogo e viste a gestione dinamica" più indietro in questo argomento.

In TDE tutti i file e i filegroup nel database vengono crittografati. Se un filegroup in un database è contrassegnato come SOLA LETTURA, l'operazione di crittografia del database avrà esito negativo.

Se un database viene usato nel mirroring del database o nel log shipping, entrambi i database verranno crittografati. Le transazioni di log verranno crittografate quando vengono inviate tra di esse.

Importante

Tutti i nuovi indici full-text verranno crittografati quando viene impostato un database per la crittografia. Gli indici full-text creati in precedenza verranno importati durante l'aggiornamento e saranno in TDE dopo il caricamento dei dati in SQL Server. L'abilitazione di un indice full-text in una colonna può causare la scrittura dei dati della colonna in testo normale sul disco durante un'analisi di indicizzazione full-text. È consigliabile non creare un indice full-text sui dati crittografati sensibili.

I dati crittografati comprimeno in modo significativo meno dei dati non crittografati equivalenti. Se TDE viene usato per crittografare un database, la compressione dei backup non sarà in grado di comprimere in modo significativo l'archiviazione di backup. Pertanto, l'uso di TDE e la compressione dei backup insieme non è consigliabile.

Restrizioni

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

• Eliminazione di un file da un filegroup nel database

• Eliminazione del database

• Portare offline il database

• Scollegamento di un database

• Transizione di un database o di un filegroup in uno 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 nel database.

• Eliminazione del database.

• Portare offline il database.

• Scollegamento di un database.

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

• Utilizzo di un comando ALTER DATABASE.

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

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

• Creazione di uno snapshot.

Le operazioni o le condizioni seguenti impediranno le istruzioni CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEY o ALTER DATABASE...SET ENCRYPTION.

• Il database è di sola lettura o ha gruppi di file di sola lettura.

• È in esecuzione un comando ALTER DATABASE.

• È in esecuzione un backup dei dati.

• Il database si trova in una condizione offline o di ripristino.

• È in corso uno snapshot.

• Attività di manutenzione del database.

Quando si creano file di database, l'inizializzazione immediata dei file non è disponibile quando TDE è abilitato.

Per crittografare la chiave di crittografia del database con una chiave asimmetrica, la chiave asimmetrica deve risiedere in un provider di gestione delle chiavi estendibile.

Transparent Data Encryption e i Log delle Transazioni

L'abilitazione di un database per l'uso di TDE ha l'effetto di "azzerare" la parte rimanente del log delle transazioni virtuali per forzare la creazione del log delle transazioni virtuali successivo. In questo modo non viene lasciato testo non crittografato nei log delle transazioni dopo che il database è impostato per la crittografia. È possibile trovare lo stato della crittografia dei file di log visualizzando la encryption_state colonna nella sys.dm_database_encryption_keys vista, 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 dei file di log di SQL Server, vedere Log delle transazioni (SQL Server).

Tutti i dati scritti nel log delle transazioni prima di una modifica nella chiave di crittografia del database verranno crittografati usando la chiave di crittografia del database precedente.

Dopo aver modificato due volte una chiave di crittografia del database, è necessario eseguire un backup del log prima che la chiave di crittografia del database possa essere modificata nuovamente.

Transparent Data Encryption e il database di sistema tempdb

Il database di sistema tempdb verrà crittografato se un altro database nell'istanza di SQL Server viene crittografato tramite TDE. Ciò potrebbe avere un effetto sulle prestazioni per i database non crittografati nella stessa istanza di SQL Server. Per altre informazioni sul database di sistema tempdb, vedere Database tempdb.

Crittografia dei dati trasparente e replicazione

La replica non replica automaticamente i dati da un database abilitato per TDE in un formato crittografato. È necessario abilitare separatamente TDE se si desidera proteggere i database di distribuzione e sottoscrittore. La replica snapshot, nonché la distribuzione iniziale dei dati per la replica transazionale e di tipo merge, può archiviare i dati in file intermedi non crittografati; ad esempio i file bcp. Durante la replica transazionale o di tipo merge, la crittografia può essere abilitata per proteggere il canale di comunicazione. Per altre informazioni, vedere Abilitare le connessioni crittografate al motore di database (Gestione configurazione SQL Server).

Transparent Data Encryption e FILESTREAM DATA

I dati FILESTREAM non vengono crittografati anche quando TDE è abilitato.

Crittografia dati trasparente e estensione del pool di buffer

I file correlati all'estensione del pool di buffer (BPE) non vengono crittografati quando il database viene crittografato tramite TDE. È necessario usare strumenti di crittografia a livello di file system come Bitlocker o EFS per i file correlati a BPE.

Transparent Data Encryption e OLTP In-Memory

TDE può essere abilitato in un database con In-Memory oggetti OLTP. In-Memory i record di log OLTP vengono crittografati se TDE è abilitato. I dati in un filegroup MEMORY_OPTIMIZED_DATA non vengono crittografati se TDE è abilitato.

Vedere anche

Spostare un database protetto da TDE in un'altra istanza di SQL Serverabilitare TDE usando TransparentData Encryption EKM con Crittografia SQL Server di SQL Serverdi Azure e chiavi di crittografia del database (motore di database)Centro sicurezza per il motore di database di SQL Server e FILESTREAM del database SQL di Azure (SQL Server)