Transparent Data Encryption

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

Transparent Data Encryption (TDE) esegue la crittografia e la decrittografia I/O in tempo reale dei file registro transazioni e dei file di resoconto PDW speciali. 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 SQL Server PDW. 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. Questa caratteristica consente agli sviluppatori software di crittografare i dati usando gli algoritmi di crittografia AES e 3DES senza modificare applicazioni esistenti.

Una volta protetto, il database può essere ripristinato usando il certificato corretto.

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.

La figura seguente illustra la gerarchia delle chiavi per la crittografia TDE:

Uso della Transparent Data Encryption

Per usare TDE, eseguire le operazioni seguenti: I primi tre passaggi vengono eseguiti una sola volta, quando si prepara SQL Server PDW per supportare TDE.

1. Creare una chiave master nel database master.

2. Usare sp_pdw_database_encryption per abilitare TDE in SQL Server PDW. Questa operazione modifica i database temporanei per garantire la protezione dei dati temporanei futuri e avrà esito negativo se si tenta di eseguire un tentativo quando sono presenti sessioni attive con tabelle temporanee. sp_pdw_database_encryption attiva la maschera dati utente nei registri di sistema PDW. (Per altre informazioni sulla maschera dati utente nei registri di sistema PDW, vedere sp_pdw_log_user_data_masking).

3. Usare sp_pdw_add_network_credentials per creare credenziali in grado di autenticarsi e scrivere nella condivisione in cui verrà archiviato il backup del certificato. Se esiste già una credenziale per il server di archiviazione previsto, è possibile usare le credenziali esistenti.

4. Nel database master creare un certificato protetto dalla chiave master.

5. Eseguire il backup del certificato nella condivisione di archiviazione.

6. Nel database utente creare una chiave di crittografia del database e proteggerla dal certificato archiviato nel database master.

7. Usare l'istruzione ALTER DATABASE per crittografare il database usando TDE.

L'esempio seguente illustra come crittografare il database AdventureWorksPDW2012 usando un certificato denominato MyServerCert, creato in SQL Server PDW.

In primo luogo: abilitare TDE in SQL Server PDW. Questa azione è necessaria una sola volta.

USE master;  
GO  
  
-- Create a database master key in the master database  
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>';  
GO  
  
-- Enable encryption for PDW  
EXEC sp_pdw_database_encryption 1;  
GO  
  
-- Add a credential that can write to the share  
-- A credential created for a backup can be used if you wish  
EXEC sp_pdw_add_network_credentials 'SECURE_SERVER', '<domain>\<Windows_user>', '<password>';  

In secondo luogo: creare un certificato di backup nel database master. Questa azione è necessaria una sola volta. È possibile avere un certificato separato per ogni database (scelta consigliata) oppure proteggere più database con un certificato.

-- Create certificate in master  
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';  
GO  
  
-- Back up the certificate with private key  
BACKUP CERTIFICATE MyServerCert   
    TO FILE = '\\SECURE_SERVER\cert\MyServerCert.cer'  
    WITH PRIVATE KEY   
    (   
        FILE = '\\SECURE_SERVER\cert\MyServerCert.key',  
        ENCRYPTION BY PASSWORD = '<password>'   
    )   
GO  

Infine: creare la chiave DEK e usare ALTER DATABASE per crittografare un database utente. Questa azione viene ripetuta per ogni database protetto da TDE.

USE AdventureWorksPDW2012;  
GO  
  
CREATE DATABASE ENCRYPTION KEY  
WITH ALGORITHM = AES_128  
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;  
GO  
  
ALTER DATABASE AdventureWorksPDW2012 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 articolo.

Comandi e funzioni

Affinché vengano accettati dalle istruzioni indicate di seguito, è necessario che i certificati TDE siano crittografati mediante la chiave master del database.

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

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.

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 il permesso CONTROL SERVER.

Considerazioni

Durante un'analisi di una nuova crittografia di un database, le operazioni di manutenzione per il database sono disabilitate.

È possibile determinare lo stato della crittografia del database utilizzando la visualizzazione a gestione dinamica (DMV) sys.dm_pdw_nodes_database_encryption_keys. Per altre informazioni, vedere la sezione Viste del catalogo e DMV più indietro in questo argomento.

Restrizioni

Le operazioni seguenti non sono consentite durante le istruzioni CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEYDROP DATABASE ENCRYPTION KEY, o ALTER DATABASE...SET ENCRYPTION.

• Eliminazione del database.

• Uso di un comando ALTER DATABASE.

• Avvio di un backup del database.

• Avvio di un ripristino database.

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

• È in esecuzione un comando ALTER DATABASE.

• Un backup dei dati è in corso di esecuzione.

Durante la creazione dei file di database, l'inizializzazione immediata dei file non è disponibile se è abilitata la crittografia TDE.

Aree non protette da TDE

TDE non protegge le tabelle esterne.

TDE non protegge le sessioni di diagnostica. Gli utenti devono prestare attenzione a non eseguire query con parametri sensibili mentre le sessioni di diagnostica sono in uso. Le sessioni di diagnostica che rivelano informazioni riservate devono essere eliminate non appena non sono più necessarie.

I dati protetti da TDE vengono decifrati quando vengono inseriti nella memoria SQL Server PDW. I dump di memoria vengono creati quando si verificano determinati problemi nell'appliance. I file di dump rappresentano il contenuto della memoria al momento dell'aspetto del problema e possono contenere dati sensibili in un formato non crittografato. Il contenuto dei dump di memoria deve essere esaminato prima che vengano condivisi con altri utenti.

Il database master non è protetto da TDE. Anche se il database master non contiene dati utente, contiene informazioni come i nomi di accesso.

Crittografia trasparente dei dati e log delle transazioni

Se si abilita TDE per un database, la parte rimanente del log delle transazioni virtuale viene "azzerato" 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 su ciascun nodo PDW visualizzando la colonna encryption_state nella vista sys.dm_pdw_nodes_database_encryption_keys, come illustrato nell'esempio seguente:

WITH dek_encryption_state AS   
(  
    SELECT ISNULL(db_map.database_id, dek.database_id) AS database_id, encryption_state  
    FROM sys.dm_pdw_nodes_database_encryption_keys AS dek  
        INNER JOIN sys.pdw_nodes_pdw_physical_databases AS node_db_map  
           ON dek.database_id = node_db_map.database_id AND dek.pdw_node_id = node_db_map.pdw_node_id  
        LEFT JOIN sys.pdw_database_mappings AS db_map  
            ON node_db_map .physical_name = db_map.physical_name  
        INNER JOIN sys.dm_pdw_nodes AS nodes  
            ON nodes.pdw_node_id = dek.pdw_node_id  
    WHERE dek.encryptor_thumbprint <> 0x  
)  
SELECT TOP 1 encryption_state  
       FROM dek_encryption_state  
       WHERE dek_encryption_state.database_id = DB_ID('AdventureWorksPDW2012 ')  
       ORDER BY (CASE encryption_state WHEN 3 THEN -1 ELSE encryption_state END) DESC;  

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.

Log attività PDW

SQL Server PDW gestisce un set di log destinati alla risoluzione dei problemi. (Si noti che non si tratta del log delle transazioni, del log degli errori di SQL Server o del registro eventi di Windows) Questi log attività PDW possono contenere istruzioni complete in testo non crittografato, alcune delle quali possono contenere dati utente. Gli esempi tipici sono le istruzioni INSERT e UPDATE. La maschera dei dati utente può essere attivata o disattivata in modo esplicito tramite sp_pdw_log_user_data_masking. L'abilitazione della crittografia in SQL Server PDW attiva automaticamente la maschera dei dati utente nei log attività PDW per proteggerli. sp_pdw_log_user_data_masking può essere usato anche per mascherare le istruzioni quando non si usa TDE, ma questo non è consigliato perché riduce significativamente la capacità del team supporto tecnico Microsoft di analizzare i problemi.

Transparent Data Encryption e database di sistema tempdb

Il database di sistema tempdb viene crittografato quando la crittografia è abilitata tramite sp_pdw_database_encryption. Questa operazione è necessaria prima che qualsiasi database possa usare TDE. Ciò potrebbe influire sulla prestazione dei database non crittografati presenti nella stessa istanza di SQL Server PDW.

Gestione chiavi

La chiave di crittografia (DEK) del database è protetta dai certificati archiviati nel database master. Questi certificati sono protetti dalla chiave master del database (DMK) del database master. La DMK deve essere protetta dalla chiave master del servizio (SMK) per poter essere usata per TDE.

Il sistema può accedere alle chiavi senza richiedere l'intervento umano (ad esempio fornire una password). Se il certificato non è disponibile, il sistema restituirà un errore che indica che la chiave DEK non può essere decifrata fino a quando non è disponibile il certificato appropriato.

Quando si sposta un database da un'appliance a un'altra, il certificato usato per proteggere la chiave DEK deve essere ripristinato per primo nel server di destinazione. È quindi possibile ripristinare il database come di consueto. Per altre informazioni, vedere la documentazione standard SQL Server Spostare un database protetto da TDE in un'altra istanza di SQL Server.

I certificati usati per crittografare i DEK devono essere conservati purché siano presenti backup del database che li usano. I backup dei certificati devono includere la chiave privata del certificato, perché senza la chiave privata non è possibile usare un certificato per il ripristino database. I backup delle chiavi private del certificato vengono archiviati in un file separato, protetto da una password che deve essere fornita per il ripristino del certificato.

Ripristinare il database master

Il database master può essere ripristinato usando DWConfig, come parte del ripristino di emergenza.

• Se il nodo di controllo non è stato modificato, vale a dire se il database master viene ripristinato nello stesso dispositivo e non modificato da cui è stato eseguito il backup del database master, DMK e tutti i certificati saranno leggibili senza ulteriori azioni.

• Se il database master viene ripristinato in un'appliance diversa o se il nodo di controllo è stato modificato dopo il backup del database master, saranno necessari passaggi aggiuntivi per rigenerare la DMK.

  1. Aprire DMK:

     OPEN MASTER KEY DECRYPTION BY PASSWORD = '<password>';  
     

  2. Aggiungere la crittografia tramite SMK:

     ALTER MASTER KEY   
         ADD ENCRYPTION BY SERVICE MASTER KEY;  
     

  3. Riavviare l'appliance.

Aggiornare e sostituire Macchine virtuali

Se esiste una DMK nell'appliance in cui è stata eseguita l'operazione Aggiorna o Sostituisci VM, è necessario specificare la password DMK come parametro.

Esempio dell'azione di aggiornamento. Sostituire <password> con la password DMK.

setup.exe /Action=ProvisionUpgrade ... DMKPassword='<password>'

Esempio dell'azione per sostituire una macchina virtuale.

setup.exe /Action=ReplaceVM ... DMKPassword='<password>'

Durante l'aggiornamento, se un database utente è crittografato e la password DMK non viene specificata, l'azione di aggiornamento avrà esito negativo. Durante la sostituzione, se la password corretta non viene specificata quando esiste una DMK, l'operazione ignora il passaggio di ripristino DMK. Tutti gli altri passaggi verranno completati alla fine dell'azione di sostituzione della macchina virtuale, ma l'azione segnala un errore alla fine per indicare che sono necessari passaggi aggiuntivi. Nei log di installazione (che si trovano in \ProgramData\Microsoft\Microsoft SQL Server Parallel Data Warehouse\100\Logs\Setup\\<time-stamp>\Detail-Setup), l'avviso seguente verrà visualizzato vicino alla fine.

*** WARNING \*\*\* DMK is detected in master database, but could not be recovered automatically! The DMK password was either not provided or is incorrect!

Eseguire manualmente queste istruzioni in PDW e riavviare l'appliance dopo questa operazione per ripristinare DMK:

OPEN MASTER KEY DECRYPTION BY PASSWORD = '<password>';  
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;  

Usare la procedura descritta nel paragrafo Ripristino del database master per ripristinare il database e quindi riavviare l'appliance.

Se la DMK esiste prima ma non è stata ripristinata dopo l'azione, verrà generato il messaggio di errore seguente quando viene eseguita una query su un database.

Msg 110806;  
A distributed query failed: Database '<db_name>' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.

Impatto sulle prestazioni

L'impatto di TDE sulle prestazioni varia a seconda del tipo di dati, della modalità di archiviazione e del tipo di attività del carico di lavoro in SQL Server PDW. In presenza della protezione di TDE, le operazioni I/O di lettura e decrittografia dei dati, oppure la crittografia e la scrittura dei dati, richiedono un uso intensivo della CPU e hanno un impatto più significativo quando in contemporanea vengono eseguite altre attività con uso intensivo della CPU. Poiché TDE crittografa tempdb, TDE può influire sulle prestazioni dei database non crittografati. Per ottenere un'idea accurata delle prestazioni, è necessario testare l'intero sistema con i dati e l'attività di query.

Contenuto correlato

I collegamenti seguenti contengono informazioni generali su come SQL Server gestisce la crittografia. Questi articoli consentono di comprendere la crittografia di SQL Server, ma questi articoli non contengono informazioni specifiche per SQL Server PDW e illustrano le funzionalità non presenti in SQL Server PDW.

• Crittografia di SQL Server

• Gerarchia di crittografia

• Chiavi di crittografia del database e di SQL Server

Vedi anche

ALTER DATABASE
CREATE MASTER KEY
CREATE DATABASE ENCRYPTION KEY
BACKUP CERTIFICATE
sp_pdw_database_encryption
sp_pdw_database_encryption_regenerate_system_keys
sp_pdw_log_user_data_masking
sys.certificates
sys.dm_pdw_nodes_database_encryption_keys