La protezione dei dati è fondamentale per garantire che la tua organizzazione sia conforme agli standard di conformità normativa come il GDPR e per soddisfare le aspettative dei tuoi clienti e partner commerciali. Non solo le violazioni dei dati possono comportare multe elevate, ma il danno alla reputazione può essere altrettanto grande. Per aiutare, Microsoft SQL Server supporta 5 diversi tipi di crittografia per la protezione dei dati. Questo articolo spiega ciascuno di essi e dove dovrebbero essere utilizzati.

SSL Transport Encryption

Come i siti web che proteggono il traffico tra browser e server, SQL Server può essere configurato per utilizzare Secure Sockets Layer (SSL) per crittografare il traffico mentre viaggia tra l’istanza del server e l’applicazione client. Inoltre, il client può convalidare l’identità del server utilizzando il certificato del server. SSL protegge solo i dati mentre viaggiano attraverso la rete, ma, a differenza della maggior parte delle altre forme di crittografia SQL Server, SSL è disponibile in tutte le versioni supportate di SQL Server e in tutte le edizioni.

Prima di abilitare SSL, è necessario installare un certificato sul server SQL. Il modo migliore per farlo è richiedendo un certificato dalla propria autorità di certificazione aziendale (CA). Windows Server può essere configurato come CA ed è possibile impostare i client in modo che si fidino dei certificati emessi. In alternativa, è possibile utilizzare certificati autofirmati, sebbene ciò sia più adatto agli ambienti di test.

SQL Server Transparent Data Encryption (TDE)

Transparent Data Encryption (TDE) in SQL Server protegge i dati a riposo crittografando i dati del database e i file di registro su disco. Funziona in modo trasparente per le applicazioni esistenti del client, quindi non è necessario modificarle quando TDE è abilitato. TDE utilizza la crittografia in tempo reale a livello di pagina. Le pagine vengono crittografate prima di essere scritte su disco, senza aumentare le dimensioni dei dati e dei file di registro e le pagine vengono decifrate quando vengono lette in memoria. TDE è disponibile solo nelle edizioni Enterprise di SQL Server. Funziona anche per Azure SQL Database, Azure SQL Data Warehouse e Parallel Data Warehouse.

La crittografia TDE ha una struttura gerarchica, con Windows Data Protection API (DPAPI) che si trova in cima alla gerarchia e viene utilizzata per crittografare la chiave master del servizio (SMK). È possibile utilizzare SMK per crittografare le credenziali, le password dei server collegati e le chiavi master del database (DMK) che risiedono in diversi database. Un DMK SQL è una chiave simmetrica che protegge le chiavi private dei certificati e le chiavi asimmetriche memorizzate nei database.

SQL Server può generare certificati autofirmati da utilizzare con TDE oppure è possibile richiedere un certificato da una CA (che è l’approccio più comune). Se si decide di abilitare TDE, è necessario eseguire il backup del certificato e della chiave privata associati al certificato. Sarà necessario ripristinare o collegare il database su un server SQL diverso. Se si abilita TDE su qualsiasi altro database SQL Server, anche il database di sistema tempdb viene crittografato. Se si disattiva TDE, è necessario mantenere il certificato e la chiave privata perché parti del log delle transazioni potrebbero rimanere crittografate fino a quando non si esegue un backup completo.

TDE richiede anche una chiave di crittografia del database (DEK), che è una chiave simmetrica protetta utilizzando un certificato memorizzato nel database master, o una chiave asimmetrica protetta da un servizio che utilizza EKM (Extensible Key Management), come Microsoft Azure Key Vault. I file di backup dei database abilitati TDE vengono crittografati utilizzando il DEK, quindi durante le operazioni di ripristino, il certificato che protegge il DEK deve essere disponibile.

Le chiavi simmetriche utilizzano la stessa password per crittografare e decrittografare i dati. Le chiavi asimmetriche utilizzano una password per crittografare i dati (chiave pubblica) e una password diversa per decrittografare i dati (chiave privata). È possibile utilizzare il comando CREA CERTIFICATO per creare certificati e i comandi CREA CHIAVE SIMMETRICA e CREA CHIAVE ASIMMETRICA Transact-SQL per creare chiavi di crittografia del database.

Crittografia di backup

La crittografia di backup funziona come TDE ma crittografa i backup SQL invece dei dati attivi e dei file di registro. La crittografia di backup è disponibile in SQL Server 2014 e versioni successive. È possibile specificare la crittografia AES 128, AES 192, AES 256 o Triple DES e utilizzare un certificato o una chiave asimmetrica memorizzata in EKM. Inoltre, è possibile abilitare TDE e la crittografia di backup contemporaneamente, anche se è necessario utilizzare diversi certificati o chiavi.

Proprio come con TDE, se si abilita la crittografia di backup, è necessario eseguire il backup del certificato o della chiave. Senza la chiave o il certificato, il file di backup non può essere utilizzato per ripristinare i dati. I backup possono anche essere crittografati quando si utilizza SQL Server Managed Backup in Microsoft Azure.

Vale la pena notare che se si utilizza un certificato per crittografare i backup, è necessario disporre del certificato originale durante il ripristino dei dati. Ciò significa che il certificato deve avere la stessa impronta digitale di quando è stato creato il backup. Rinnovare i certificati o modificarli in qualsiasi modo può causare la modifica dell’impronta digitale.

Crittografia a livello di colonna/cella

Disponibile in tutte le edizioni di SQL Server, la crittografia a livello di cella può essere abilitata su colonne che contengono dati sensibili. I dati vengono crittografati su disco e rimangono crittografati in memoria fino a quando non viene utilizzata la funzione DECRYPTBYKEY per decrittografarli. Pertanto, anche se i dati SQL sono crittografati, non è sicuro al di là semplicemente utilizzando una funzione nel contesto utente per decifrare esso. Inoltre, poiché è necessaria una funzione per decrittografare i dati, le applicazioni client devono essere modificate per funzionare con la crittografia a livello di cella.

Gestione delle chiavi di crittografia

Come con TDE, è necessario creare una chiave master (DMK) prima di utilizzare la crittografia a livello di cella. Esistono quattro opzioni per crittografare le informazioni utilizzando la crittografia a livello di cella:

• È possibile utilizzare una passphrase per crittografare e decrittografare i dati, ma è necessario crittografare le stored procedure e le funzioni; in caso contrario, è possibile accedere alla passphrase nei metadati.
• Le chiavi asimmetriche forniscono una forte sicurezza ma possono avere un impatto sulle prestazioni.
• Le chiavi simmetriche sono di solito abbastanza forti e forniscono un buon equilibrio tra sicurezza e prestazioni.
• I certificati forniscono anche un buon equilibrio tra sicurezza e prestazioni e possono essere associati a un utente di database.

Always Encrypted

Always Encrypted Crittografa i dati sensibili nelle applicazioni client senza rivelare le chiavi di crittografia al motore di database, fornendo la separazione tra proprietari di dati e gestori di dati. Ad esempio, con Sempre crittografato abilitato, si può essere sicuri che gli amministratori di database non saranno in grado di leggere i dati sensibili. Come suggerisce il nome, i dati vengono crittografati a riposo e se utilizzati in un sistema di terze parti, come Azure.

Always Encrypted può essere configurato per singole colonne di database. Vengono utilizzati due tipi di chiavi: chiavi di crittografia a colonna e chiavi master a colonna. Le chiavi di crittografia delle colonne proteggono i dati in una colonna e le chiavi master delle colonne sono “chiavi di protezione delle chiavi” che crittografano una o più chiavi di crittografia delle colonne. Le chiavi master delle colonne vengono memorizzate in archivi di chiavi attendibili esterni, come Azure Key Vault.

Il processo di crittografia è trasparente per le applicazioni client ma richiede un driver speciale sui computer client. Always Encrypted è disponibile in SQL Server 2016 e versioni successive, ma solo nelle edizioni Enterprise. A causa dei requisiti extra lato client, Always Encrypted è più adatto alle situazioni in cui la separazione dei proprietari e dei gestori dei dati è un requisito primario.

Consulente informatico e autore specializzato in tecnologie di gestione e sicurezza. Russell ha più di 15 anni di esperienza nel settore IT, ha scritto un libro sulla sicurezza di Windows, e ha coautore di un testo per Microsoft Official Academic Course (MOAC) serie.