Transparent Data Encryption (TDE)
Transparent Data Encryption (TDE) crittografa SQL Server e Azure SQL file di dati del database, noti come crittografia dei dati inattivi. È possibile adottare diverse precauzioni per proteggere il database, ad esempio la progettazione di un sistema sicuro, la crittografia di asset riservati e la creazione di un firewall che protegga i server di database. Tuttavia, nell'ipotesi del furto dei supporti fisici, come unità o nastri di backup, un malintenzionato potrebbe semplicemente ripristinare o collegare il database e accedere ai dati in esso contenuti. Una soluzione per ovviare al problema consiste nel crittografare i dati sensibili nel database e proteggere con un certificato le chiavi usate per la crittografia. In questo modo si impedisce a chi è sprovvisto delle chiavi di usare i dati; tuttavia, questo tipo di protezione deve essere pianificato in anticipo.
TDE esegue la crittografia e la decrittografia delle operazioni di I/O di file di dati e log in tempo reale. 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 di crittografia del database è 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. Gli sviluppatori software possono ora crittografare i dati usando gli algoritmi di crittografia AES e 3DES senza modificare applicazioni esistenti.
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 del file di database viene eseguita a livello di pagina. Le pagine di un database crittografato sono 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 SQL V12 V12 (anteprima in alcune aree) il certificato a livello di server archiviato nel database master viene creato automaticamente da database SQL. Per spostare un database TDE in database SQL è necessario decrittografare il database, spostare il database e quindi riabilitare TDE nel database SQL di destinazione. Per istruzioni dettagliate su TDE in database SQL, vedere Transparent Data Encryption with Azure SQL Database (Transparent Data Encryption with Azure SQL Database).
L'anteprima dello stato di TDE si applica anche nel subset di aree geografiche in cui la famiglia di versioni V12 di database SQL viene annunciata come ora in stato di disponibilità generale. TDE per 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 su database SQL V12, vedere Novità di Azure SQL Database.
Informazioni applicabili a SQL Server
Una volta protetto, il database può essere ripristinato usando il certificato corretto. Per altre informazioni sui certificati, vedere SQL Server Certificates and Asymmetric Keys.
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 mantenuto anche se la funzionalità TDE non è più abilitata nel database. Anche se il database non è crittografato, è possibile che parti del log delle transazioni restino comunque protette e che il certificato sia necessario per alcune operazioni per l'esecuzione del backup completo del database. Un certificato che ha superato la data di scadenza può ancora essere usato per crittografare e decrittografare 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 in database SQL.
Uso della crittografia trasparente dei dati
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 AdventureWorks2012 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 sono pianificate sui thread di background da SQL Server. Per visualizzare lo stato di queste operazioni, è possibile usare le viste del catalogo e le viste a gestione dinamica nell'elenco illustrato di seguito in questo argomento.
Attenzione
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 questi backup vengono ripristinati, è necessario disporre del certificato che protegge la chiave di crittografia del database. Pertanto, oltre ad eseguire il backup del database, è necessario assicurarsi di conservare un backup dei certificati server per impedire la perdita di dati. 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é vengano accettati dalle istruzioni indicate di seguito, è necessario che i certificati TDE siano crittografati mediante la chiave master del database. Se sono crittografati solo tramite password, verranno rifiutati dalle istruzioni come componenti di crittografia.
Importante
Se si modificano i certificati per abilitarne la protezione tramite password quando vengono usati da TDE, il database diventerà 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) | Consente di creare una chiave usata per crittografare un database. |
| ALTER DATABASE ENCRYPTION KEY (Transact-SQL) | Consente di modificare la chiave usata per crittografare un database. |
| DROP DATABASE ENCRYPTION KEY (Transact-SQL) | Consente di rimuovere la chiave usata per crittografare un database. |
| Opzioni ALTER DATABASE SET (Transact-SQL) | Viene descritta l'opzione ALTER DATABASE, utilizzata per abilitare Transparent Data Encryption. |
Viste del catalogo e viste a gestione dinamica
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 di un database. |
| sys.dm_database_encryption_keys (Transact-SQL) | Tramite la vista a gestione dinamica vengono fornite informazioni relative alle chiavi di crittografia usate in un database e allo stato di 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 modalità utente singolo per il database per eseguire operazioni di manutenzione. Per altre informazioni, vedere Impostare un database in modalità utente singolo.
È possibile determinare lo stato della crittografia del database utilizzando la vista a gestione dinamica sys.dm_database_encryption_keys. Per altre informazioni, vedere la sezione "Viste del catalogo e viste a gestione dinamica" più indietro in questo argomento.
In TDE vengono crittografati tutti i file e i filegroup del database. Se un database include filegroup contrassegnati come READ ONLY, l'operazione di crittografia del database avrà esito negativo.
Se un database viene usato per il mirroring del database o il log shipping, entrambi i database saranno crittografati. Le transazioni del log verranno crittografate quando vengono inviate tra i database.
Importante
Qualsiasi nuovo indice full-text viene crittografato quando un database è impostato per la crittografia. Gli indici full-text creati in precedenza verranno importati durante l'aggiornamento e saranno in TDE dopo che i dati vengono caricati in SQL Server. L'abilitazione di un indice full-text in una colonna può provocare la scrittura in testo normale dei dati di tale colonna nel disco durante un'analisi dell'indicizzazione full-text. È consigliabile non creare un indice full-text sui dati crittografati riservati.
I dati crittografati vengono compressi molto meno rispetto ai dati equivalenti non crittografati. Se per crittografare un database si usa TDE, l'archivio di backup non verrà compresso in modo significativo tramite l'opzione di compressione dei backup. Non è quindi consigliabile usare TDE insieme all'opzione di compressione dei backup.
Restrizioni
Durante le operazioni di crittografia del database iniziale, modifica della chiave o decrittografia del database, non sono consentite le azioni seguenti:
Eliminazione di un file da un filegroup del database
Eliminazione del database
Attivazione della modalità offline per il database
Scollegamento di un database
Transizione di un database o filegroup in un stato READ ONLY
Le operazioni indicate di seguito non sono consentite durante l'esecuzione delle istruzioni CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEY e ALTER DATABASE...SET ENCRYPTION.
Eliminazione di un file da un filegroup del database.
Eliminazione del database.
Attivazione della modalità offline per il 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 condizioni indicate di seguito impediscono l'esecuzione delle istruzioni CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEY e ALTER DATABASE...SET ENCRYPTION.
Il database è di sola lettura o ha gruppi di file di sola lettura.
È in corso l'esecuzione di un comando ALTER DATABASE.
Un backup dei dati è in corso di esecuzione.
Il database è offline o è in corso di ripristino.
Uno snapshot è in corso.
Attività di manutenzione del database.
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).
Crittografia trasparente dei dati e log delle transazioni
Se si abilita TDE per un database, la parte rimanente del log delle transazioni virtuale viene "azzerata" in modo da forzare l'uso del log delle transazioni virtuale successivo. Ciò garantisce che non rimanga alcun testo non crittografato nei log delle transazioni dopo che il database viene impostato per la crittografia. È possibile determinare lo stato di crittografia dei file di log visualizzando la colonna encryption_state nella vista sys.dm_database_encryption_keys, come illustrato nell'esempio seguente:
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 del file di log SQL Server, vedere Log delle transazioni (SQL Server).
Tutti i dati scritti nel log delle transazioni prima di una modifica della chiave di crittografia del database saranno crittografati usando la chiave di crittografia del database precedente.
Dopo che una chiave di crittografia del database è stata modificata due volte, è necessario eseguire un backup del log prima che sia possibile modificare nuovamente la chiave di crittografia del database.
Transparent Data Encryption e database di sistema tempdb
Il database di sistema tempdb verrà crittografato se qualsiasi altro database nell'istanza di SQL Server viene crittografato tramite TDE. Questo 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.
Transparent Data Encryption 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, è necessario abilitare separatamente TDE. La replica snapshot, nonché la distribuzione iniziale dei dati per la replica transazionale e di tipo merge, può archiviare dati in file intermedi non crittografati, ad esempio i file con estensione bcp. Durante la replica transazionale o di tipo merge è 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).
Transparent Data Encryption e dati FILESTREAM
Anche se si abilita TDE, i dati FILESTREAM non vengono crittografati.
Transparent Data Encryption ed estensione del pool di buffer
I file correlati all'estensione del pool di buffer non vengono crittografati quando il database viene crittografato con TDE. Per tali file è necessario usare strumenti di crittografia a livello di file system, come Bitlocker o EFS.
Transparent Data Encryption e OLTP in memoria
È possibile abilitare TDE in un database contenente oggetti di OLTP in memoria. Se la funzionalità TDE è abilitata, i record del log di OLTP in memoria vengono crittografati. I dati nel filegroup MEMORY_OPTIMIZED_DATA non vengono crittografati se la funzionalità TDE è abilitata.
Vedere anche
Spostare un database protetto TDE in un'altra SQL ServerEnable TDE usando EKM Transparent Data Encryption con Azure SQL databaseSQL Server Crittografia SQL Servere chiavi di crittografia del database (Motore di database)Centro sicurezza per SQL Server database Motore e Azure SQLFILESTREAM del database (SQL Server)