Informazioni sulla crittografia trasparente dei dati (TDE, Transparent Data Encryption)
Per proteggere il database è possibile adottare alcune accortezze, tra cui la progettazione di un sistema sicuro, la crittografia dei dati riservati e la compilazione di un firewall attorno ai server database. Tuttavia, nel caso in cui i supporti fisici (ad esempio unità o nastri di backup) venissero rubati, un malintenzionato potrebbe ripristinare o collegare il database e accedere ai dati. Una soluzione per ovviare al problema consiste nel crittografare i dati sensibili nel database e proteggere mediante un certificato le chiavi utilizzate per la crittografia. In questo modo si impedisce a chi è sprovvisto delle chiavi di utilizzare i dati; tuttavia, questo tipo di protezione deve essere pianificato in anticipo.
Transparent Data Encryption (TDE) esegue la crittografia e la decrittografia I/O in tempo reale dei file di dati e di log. Per la crittografia viene utilizzata una chiave di crittografia del database (DEK), archiviata nel record di avvio del database affinché sia disponibile durante le operazioni di recupero. 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. Transparent Data Encryption 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 utilizzando gli algoritmi di crittografia AES e 3DES senza modificare applicazioni esistenti.
.gif "Nota importante") Importante |
|---|
Transparent Data Encryption non fornisce funzionalità di crittografia tramite canali di comunicazione. Per ulteriori informazioni sulla crittografia dei attraverso i canali di comunicazione, vedere Crittografia delle connessioni a SQL Server. |
Una volta protetto, il database può essere ripristinato utilizzando il certificato corretto. Per ulteriori informazioni sui certificati, vedere Certificati SQL Server e chiavi simmetriche.
Nota
Quando si abilita Transparent Data Encryption, è 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 in un altro server, è necessario disporre di copie di backup del certificato e della chiave privata, altrimenti non sarà possibile aprire il database. La chiave asimmetrica o il certificato di crittografia deve essere mantenuto anche se la funzionalità Transparent Data Encryption non è più abilitata nel database. Anche se il database non è crittografato, la chiave di crittografia del database può essere mantenuta nel database e potrebbe essere necessario accedervi per alcune operazioni. È comunque possibile utilizzare un certificato la cui data di scadenza è stata superata per crittografare e decrittografare dati con 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. Transparent Data Encryption non provoca un aumento delle dimensioni del database crittografato. Per ulteriori informazioni sulle pagine di database, vedere Informazioni su pagine ed extent.
Nella figura seguente viene illustrata l'architettura di Transparent Data Encryption:
.gif "Visualizza la gerarchia descritta nell'argomento")
Uso della crittografia trasparente dei dati
Per utilizzare Transparent Data Encryption, effettuare le operazioni seguenti:
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 utilizzare la crittografia
Nell'esempio seguente sono illustrate le operazioni di crittografia e decrittografia del database AdventureWorks2008R2 utilizzando un certificato installato su un server denominato MyServerCert.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
go
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';
go
USE AdventureWorks2008R2;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO
ALTER DATABASE AdventureWorks2008R2
SET ENCRYPTION ON;
GO
Le operazioni di crittografia e decrittografia sono pianificate sui thread di background da SQL Server. È possibile visualizzare lo stato di queste operazioni utilizzando le viste del catalogo e le DMV nell'elenco stato illustrato di seguito in questo argomento.
| Attenzione |
|---|
I file di backup dei database in cui è abilitata la funzionalità Transparent Data Encryption 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 ulteriori informazioni, vedere Certificati SQL Server e chiavi simmetriche. |
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 di modificano i certificati al fine di abilitarne la protezione tramite password in seguito all'utilizzo da parte di Transparent Data Encryption, il database diventerà inaccessibile dopo un riavvio. |
Nella tabella seguente sono inclusi collegamenti e spiegazioni delle funzioni e dei comandi correlati a Transparent Data Encryption.
Comando o funzione |
Scopo |
|---|---|
Consente di creare una chiave utilizzata per crittografare un database. |
|
Consente di modificare la chiave utilizzata per crittografare un database. |
|
Consente di rimuovere la chiave che è stata utilizzata per crittografare un database. |
|
Viene descritta l'opzione ALTER DATABASE, utilizzata per abilitare Transparent Data Encryption. |
Viste del catalogo e DMV
Nella tabella seguente vengono illustrate le viste del catalogo e le DMV di Transparent Data Encryption.
Vista del catalogo e DMV |
Scopo |
|---|---|
Vista del catalogo che consente di visualizzare le informazioni del database. |
|
Vista del catalogo che consente di visualizzare i certificati di un database. |
|
Tramite la DMV vengono fornite informazioni relative alle chiavi di crittografia utilizzate in un database e allo stato di crittografia di un database. |
Autorizzazioni
Ogni caratteristica e comando di Transparent Data Encryption ha requisiti specifici relativi alle autorizzazioni, descritti nelle tabelle precedenti.
La visualizzazione dei metadati interessati da Transparent Data Encryption richiede l'autorizzazione VIEW DEFINITION per il certificato. Per ulteriori informazioni, vedere Autorizzazione VIEW DEFINITION.
Considerazioni
Durante un'analisi di una nuova crittografia di un database, le operazioni di manutenzione per il database sono disabilitate. È possibile utilizzare l'impostazione modalità utente singolo per il database per eseguire operazioni di manutenzione. Per ulteriori informazioni, vedere Procedura: Impostazione di un database in modalità utente singolo (SQL Server Management Studio).
È possibile determinare lo stato della crittografia del database utilizzando la DMV sys.dm_database_encryption_keys. Per ulteriori informazioni, vedere la sezione precedente "Viste del catalogo e DMV"di questo argomento.
In Transparent Data Encryption 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 utilizzato 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 configurati per Transparent Data Encryption in seguito al caricamento dei dati 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 utilizza Transparent Data Encryption, l'archivio di backup non verrà compresso in modo significativo tramite l'opzione di compressione dei backup. Non è pertanto consigliabile utilizzare Transparent Data Encryption 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.
Utilizzo 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 si trovi in un provider EKM.
Crittografia trasparente dei dati e log delle transazioni
L'abilitazione di Transparent Data Encryption per un database ha l'effetto di "azzerare" la parte rimanente del log delle transazioni virtuale per forzare l'utilizzo 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 AdventureWorks2008R2;
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 SQL Server, vedere Architettura fisica del log delle transazioni.
Tutti i dati scritti nel log delle transazioni prima di una modifica della chiave di crittografia del database saranno crittografati utilizzando 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 altri database nell'istanza di SQL Server vengono crittografati tramite Transparent Data Encryption. Ciò potrebbe influire sulla prestazione dei database non crittografati presenti nella stessa istanza di SQL Server. Per ulteriori 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 Transparent Data Encryption in un formato crittografato. Se si desidera proteggere i database di distribuzione e del Sottoscrittore, è necessario abilitare separatamente Transparent Data Encryption. 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 ulteriori informazioni, vedere Procedura: Attivazione di connessioni crittografate al Motore di database (Gestione configurazione SQL Server).
Transparent Data Encryption e dati FILESTREAM
Anche se si abilita Transparent Data Encryption, i dati FILESTREAM non vengono crittografati.