Spiegazione della crittografia di SQL Server: TDE, crittografia a livello di colonna e altro

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 data breach possono comportare pesanti multe, 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.

Crittografia del trasporto SSL

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 i dati solo mentre viaggiano attraverso la rete, ma, a differenza della maggior parte delle altre forme di crittografia di SQL Server, SSL è disponibile in tutte le versioni supportate di SQL Server e in tutte le edizioni.

Prima di abilitare SSL, sarà necessario installare un certificato sul SQL Server. Il modo migliore per farlo è richiedere un certificato dalla propria autorità di certificazione aziendale (CA). Windows Server può essere configurato come una CA e si possono impostare i client in modo che si fidino dei certificati che emette. In alternativa, è possibile utilizzare certificati autofirmati, anche se questa soluzione è più adatta agli ambienti di test.

SQL Server Transparent Data Encryption (TDE)

La Transparent Data Encryption (TDE) in SQL Server protegge i dati inattivi criptando i dati del database e i file di log su disco. Funziona in modo trasparente con le applicazioni client esistenti, quindi non necessitano di essere modificate quando TDE è abilitata. TDE utilizza una crittografia in tempo reale a livello di pagina. Le pagine vengono criptate prima di essere scritte su disco, senza aumentare la dimensione dei dati e dei file di log, e vengono decriptate quando 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 principale del servizio (SMK). Puoi utilizzare la SMK per crittografare le credenziali, le password dei server collegati e le chiavi principali del database (DMK) residenti in diversi database. Una DMK SQL è una chiave simmetrica che protegge le chiavi private dei certificati e delle chiavi asimmetriche memorizzate nei database.

SQL Server può generare certificati autofirmati per l'uso con TDE oppure è possibile richiedere un certificato da un'autorità di certificazione (che è l'approccio più comune). Se si decide di abilitare TDE, è necessario eseguire il backup del certificato e della chiave privata associata al certificato. Sarà necessario ripristinare o collegare il database su un diverso SQL Server. Se si abilita TDE su qualsiasi altro database SQL Server, anche il database di sistema tempdb viene criptato. Se si disabilita TDE, si dovrebbe mantenere il certificato e la chiave privata perché parti del log delle transazioni potrebbero rimanere criptate fino a quando non si esegue un backup completo.

TDE richiede anche una chiave di crittografia del database (DEK), che è una chiave simmetrica protetta tramite un certificato memorizzato nel database master, oppure una chiave asimmetrica protetta da un servizio che utilizza la Gestione Estensibile delle Chiavi (EKM), come ad esempio Microsoft Azure Key Vault. I file di backup dei database abilitati TDE sono criptati utilizzando la DEK, quindi durante le operazioni di ripristino, il certificato che protegge la DEK deve essere disponibile.

Le chiavi simmetriche utilizzano la stessa password per criptare e decriptare i dati. Le chiavi asimmetriche usano una password per criptare i dati (chiave pubblica) e una password diversa per decriptare i dati (chiave privata). Puoi utilizzare il comando CREATE CERTIFICATE per creare certificati, e i comandi Transact-SQL CREATE SYMMETRIC KEY e CREATE ASYMMETRIC KEY per creare chiavi di cifratura del database.

Crittografia del backup

La crittografia dei backup funziona come TDE ma cripta i backup di SQL invece dei file di dati attivi e dei log. La crittografia dei 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 contemporaneamente TDE e la crittografia dei backup, anche se si dovrebbero utilizzare certificati o chiavi differenti.

Proprio come con TDE, se si abilita la Backup Encryption, è necessario eseguire anche 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 essere criptati anche quando si utilizza SQL Server Managed Backup su Microsoft Azure.

È importante notare che se si utilizza un certificato per crittografare i backup, è necessario disporre del certificato originale quando si ripristinano i 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 variazione 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 sono criptati su disco e rimangono criptati in memoria fino a quando la funzione DECRYPTBYKEY viene utilizzata per decriptarli. Pertanto, sebbene i dati SQL siano criptati, non sono sicuri oltre il semplice utilizzo di una funzione nel contesto utente per decriptarli. Inoltre, poiché è necessaria una funzione per decriptare i dati, le applicazioni client devono essere modificate per lavorare con la crittografia a livello di cella.

Gestione delle chiavi di crittografia

Come per TDE, è necessario creare una chiave principale (DMK) prima di utilizzare la crittografia a livello di cella. Ci sono quattro opzioni per criptare le informazioni utilizzando la crittografia a livello di cella:

• È possibile utilizzare una passphrase per criptare e decriptare i dati, ma è necessario criptare le procedure e le funzioni memorizzate; altrimenti, la passphrase può essere accessibile nei metadati.
• Le chiavi asimmetriche offrono una forte sicurezza ma possono avere un impatto sulle prestazioni.
• Le chiavi simmetriche sono generalmente abbastanza robuste e offrono un buon equilibrio tra sicurezza e prestazioni.
• I certificati offrono anche un buon equilibrio tra sicurezza e prestazioni, e possono essere associati a un utente del database.

Always Encrypted

Always Encrypted cripta i dati sensibili nelle applicazioni client senza rivelare le chiavi di crittografia al motore del database, garantendo una separazione tra i proprietari dei dati e i gestori dei dati. Ad esempio, con Always Encrypted abilitato, puoi essere sicuro che gli amministratori del database non saranno in grado di leggere dati sensibili. Come suggerisce il nome, i dati sono criptati a riposo e se utilizzati in un sistema di terze parti, come Azure.

Always Encrypted può essere configurato per singole colonne del database. Si utilizzano due tipi di chiavi: le chiavi di crittografia delle colonne e le chiavi principali delle colonne. Le chiavi di crittografia delle colonne proteggono i dati in una colonna e le chiavi principali delle colonne sono ‘chiavi che proteggono le chiavi’ che criptano una o più chiavi di crittografia delle colonne. Le chiavi principali delle colonne sono memorizzate in archivi chiavi esterni affidabili, 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 aggiuntivi lato client, Always Encrypted è più adatto a situazioni in cui la separazione tra proprietari e gestori dei dati è un requisito primario.