Encryption in SQL Server 2022

23.05.24 03:34 PM Comment(s)

Cos’è l’Encryption

La crittografia (Encryption) è il processo di oscuramento dei dati mediante l'uso di una chiave o di una password. Questo processo può rendere i dati inutilizzabili senza la chiave di decrittazione o la password corrispondente. La crittografia non risolve i problemi di controllo degli accessi. Tuttavia, migliora la sicurezza limitando la perdita di dati anche se i controlli di accesso vengono aggirati. Ad esempio, se il computer host del database è configurato in modo errato e un hacker ottiene dati sensibili, le informazioni rubate potrebbero essere inutili se crittografate.

Sebbene la crittografia sia uno strumento prezioso per garantire la sicurezza, non dovrebbe essere presa in considerazione per tutti i dati o le connessioni. Quando decidi se implementare la crittografia, considera il modo in cui gli utenti accedono ai dati. Se gli utenti accedono ai dati su una rete pubblica, potrebbe essere necessaria la crittografia dei dati per aumentare la sicurezza. Tuttavia, se tutti gli accessi implicano una configurazione Intranet sicura, la crittografia potrebbe non essere necessaria. Qualsiasi utilizzo della crittografia dovrebbe includere anche una strategia di manutenzione di password, chiavi e certificati.

Encryption e metodi disponibili

SQL Server comprende la capacità nativa di crittografare i dati a partire dalla versione 2005. Quella versione includeva funzionalità che potevano essere utilizzate per crittografare singoli elementi e colonne di dati, nonché la funzionalità TDE (Transparent Data Encryption) che era disponibile con l'edizione Enterprise di SQL Server e poteva essere utilizzata per crittografare tutti i dati archiviati su disco.

Non ci sono state aggiunte significative alle funzionalità disponibili per la crittografia fino al 2016, quando Microsoft ha aggiunto Always Encrypted per la crittografia delle colonne.

Con SQL Server 2019 Microsoft ha reso disponibile TDE per l’edizione standard, ed oltre a questo in SQL Server 2019 è stata aggiunta la possibilità di utilizzare Always Encrypted con enclavi sicure per migliorare le funzionalità disponibili per l'interazione con i dati crittografati.

Infine, con SQL Server 2022 sono stati apportati ulteriori miglioramenti all'insieme di funzionalità disponibili quando si lavora con Always Encrypted con enclavi.

Scopo dell’Encryption

Lo scopo dell’Encryption è semplice da individuare: si vuole evitare che i dati cadano nelle mani sbagliate.

La pratica è un po' più complessa: esattamente da quali tipi di attacchi si desidera essere protetti? Assicurare che i dati siano crittografati nel punto in cui sono archiviati sul disco non aiuta se un utente malintenzionato ottiene l'accesso diretto per eseguire query sul database.

Si potrebbero crittografare i dati contenuti in colonne, ma ciò consentirà di essere protetti comunque se i dati non crittografati saranno ritrasmessi attraverso la rete alla nostra applicazione ed un utente malintenzionato intercetterà il nostro traffico di rete?

Un’altra domanda utile da porsi è: perché si sta considerando la crittografia in primo luogo?

Spesso i progetti prendono in considerazione la crittografia perché le normative pertinenti o i requisiti del cliente lo richiedono. Troppo spesso in questi casi la crittografia è considerata un'opzione binaria, i dati sono crittografati o meno.

Capita sovente che venga fatto il minimo indispensabile per attivare la crittografia ed andare avanti. I dati potrebbero essere crittografati, ma la protezione offerta sarà utile solo in casi limitati.

Quando pensiamo agli scenari nei quali desideriamo proteggerci, è opportuno considerare dove sono presenti i dati che quindi potrebbero essere vulnerabili. Con questo non ci riferiamo a dove sono archiviati dati specifici, ma piuttosto al tipo di posizione:

Su disco, principalmente in file di dati e file di backup.
In memoria sul server del database.
In transito attraverso la rete.
Nelle applicazioni.
File archiviati all'esterno del database, magari su una condivisione di rete.

La crittografia è solo una linea di difesa e dovrebbe andare di pari passo con un approccio alla sicurezza ben definito e implementato. La prima linea di difesa sarà sempre il controllo degli accessi, assicurando in primo luogo che solo gli utenti e le applicazioni corretti possano accedere a server e dati.

Allora perché utilizzare la crittografia?

La risposta è: esiste sempre la possibilità che i controlli sugli accessi vengano violati. I migliori approcci alla sicurezza sono sempre a più livelli e, oltre al controllo degli accessi e alla crittografia, è bene disporre di controlli in modo da poter vedere chi accede ai sistemi e sapere cosa sta facendo, oltre a disporre di avvisi per attività sospette.

Nota: la crittografia e la decrittografia dei dati richiedono un dispendio di CPU e quindi comportano un sovraccarico delle prestazioni. Inoltre in genere si avrà un aumento dei costi di gestione, ad esempio dove si dovranno gestire le chiavi di crittografia.

Uno degli scenari peggiori che si possono incontrare è quando una persona operativa configura la crittografia senza dire a nessun altro dove viene eseguito il backup delle chiavi, poi quell'individuo lascia l'organizzazione e, se per esempio si dovesse verificare un guasto del server, si potrebbe non essere mai in grado di ripristinare i dati crittografati.

Una parte importante della strategia di crittografia sarà decidere quali dati crittografare e come lavorare con essi una volta crittografati.

Gli strumenti di encryption disponibili su SQL Server

Feature	Cosa protegge
Transparent Data Encryption (TDE)	Dati salvati su disco. Ciò include file di dati, file di transaction log, file di backup e snapshot del database.
Backup Encryption	File di backup.
Always Encrypted	Dati archiviati in colonne. Con Always Encrypted, i dati sono protetti su disco, in memoria e in transito attraverso la rete.
Transport Layer Security (TLS)	Traffico di rete. TLS protegge i dati in transito attraverso la rete nonché i comandi eseguiti sul server del database.
Hashing & Salting	Questa non è strettamente crittografia, ma generalmente si può utilizzare per proteggere le password.
Encryption Functions	Dati archiviati in colonne. Sono le funzioni di crittografia introdotte in SQL 2005 che precedono Always Encrypted.
Extensible Key Management (EKM)	Fornisce ulteriore protezione e facilità di gestione per le chiavi di crittografia consentendone l'archiviazione presso un provider esterno.

TDE

TDE protegge i nostri dati archiviati su disco, quelli che spesso chiamiamo dati a riposo. Offre una buona protezione nello scenario in cui un utente malintenzionato accede al file system e potrebbe tentare di recuperare i dati direttamente dai file di database stessi o copiare i file di backup in modo che possano essere ripristinati su un altro SQL Server per accedervi.

Tuttavia, non ci protegge dal fatto che un utente malintenzionato possa avere accesso per interrogare direttamente il database. La parte “transparent” del nome si riferisce al fatto che TDE funziona in modo trasparente in background senza alcun impatto sulle nostre query o altre funzionalità dell'applicazione. TDE protegge tutti i dati in un database, a differenza dei metodi di crittografia delle colonne che solitamente mirano a tipi specifici di informazioni da crittografare.

Backup Encryption

La crittografia di backup crittografa semplicemente i nostri file di backup. Sono inclusi backup completi, backup differenziali e backup del log. Ciò è particolarmente utile laddove potremmo archiviare i backup, possibilmente su nastro, fuori sede e vogliamo assicurarci che siano inaccessibili in caso di furto. Anche TDE crittografa i backup, quindi va considerato l'utilizzo della crittografia di backup solo laddove non possiamo utilizzare TDE per qualche motivo.

Always Encrypted

Always Encrypted è una forma di crittografia delle colonne. Funziona di pari passo con il driver del client utilizzato dall'applicazione per connettersi ed eseguire query sul database per garantire che i dati rimangano crittografati fino al punto in cui raggiungono l'applicazione.

Questo è ciò a cui si riferisce la parte “always” del nome. I dati sono protetti a riposo, in memoria e in transito attraverso la rete. La crittografia e la decrittografia vengono effettivamente eseguite all'interno del driver client anziché in SQL Server.

Esiste la versione base introdotta in SQL Server 2016 e Always Encrypted with Secure Enclaves aggiunta in SQL Server 2019.

La cosa interessante di Always Encrypted è che la crittografia e la decrittografia vengono eseguite automaticamente dal driver del client, quindi in molti casi non è nemmeno necessario apportare modifiche al codice.

Esistono tuttavia limitazioni su come interagire con i dati crittografati. La versione con enclave rimuove alcune di queste restrizioni consentendo a determinate attività di essere collocate in una porzione sicura di memoria (chiamata enclave) sul server del database. L’uso delle enclavi comporta tuttavia un sovraccarico aggiuntivo in termini di installazione e gestione.

TLS

TLS viene utilizzato per crittografare il traffico di rete. Ciò significa che i dati e le query inviati tra l'applicazione e il database server sono completamente crittografati. Simile ad SSL, noto per essere utilizzato per crittografare il traffico Internet (SSL nella maggior parte dei casi utilizza effettivamente il protocollo TLS).

Hashing & Salting

L'hashing e il salting non sono crittografia vera e propria, in quanto si tratta di processi unidirezionali. L'hashing è il modo in cui viene convertito un valore attraverso una funzione che produce un output apparentemente casuale. L'output sarà sempre lo stesso per lo stesso valore di input ma non può esserlo decodificato per trovare il valore originale.

Il salting è un metodo per fornire ulteriore sicurezza per i valori a cui è stato applicato l’hashing. L'hashing e il salting sono considerati la migliore pratica per archiviare le password poiché significa che non abbiamo nemmeno bisogno di archiviare le password effettive, quindi non dovrebbe esserci modo per un utente malintenzionato di accedervi.

Encryption Functions

Un insieme di funzioni di crittografia utilizzabili all’interno di SQL Server per consentire di crittografare i propri dati. Always Encrypted dovrebbe essere il successore di queste funzioni e sarebbe consigliabile utilizzarlo ove possibile. La crittografia tramite queste funzioni è un po' più limitante, meno sicura e un po' più difficile da implementare rispetto a Always Encrypted. Tuttavia potrebbero esserci alcuni scenari in cui si possono sfruttare queste funzioni.

EKM

La maggior parte dei sistemi di crittografia si basano su chiavi: si dovrebbe pensare a come e dove gestirle nel tempo. EKM è una funzionalità che consente di archiviarle all'esterno del server, su un dispositivo informatico fisico chiamato Hardware Security Module (HSM) o, più comunemente al giorno d'oggi, utilizzando un servizio cloud come Azure Key Vault. Non è necessario utilizzare EKM per implementare una strategia di crittografia sicura, ma vale la pena considerarlo per la facilità di gestione che deriva dall'avere tutte le chiavi in un unico posto. È anche più semplice gestire policy come il controllo degli accessi quando si adotta un approccio centralizzato nell'archiviazione delle chiavi.

Approccio consigliato per l’Encryption

In precedenza sono stati analizzati i posizionamenti dove risiedono i dati.

Una buona strategia proteggerà tutte le posizioni analizzate, a volte con vari livelli.

Finché si utilizza SQL Server dalla versione 2016 e successive, esiste una strategia predefinita che è consigliabile considerare e che combina una serie di funzionalità elencate sopra:

TDE. Per la protezione a riposo di tutti i dati, tuttavia se si utilizza una versione di SQL Server precedente alla 2019 sarà necessario avere l'edizione Enterprise per utilizzare TDE.
Always Encrypted. Per crittografare tutte (o la maggior parte) le colonne che contengono informazioni personali identificabili o sensibili.
TLS. Per garantire che le comunicazioni di rete tra l'applicazione e il server siano crittografate.
Hashing e salting delle password. Per garantire che le password siano sicure e non abbiamo mai bisogno di memorizzare la password effettiva nel database.

La crittografia è più semplice da integrare quando si sviluppano nuove applicazioni, ma il più delle volte deve essere implementata nell’ambito di applicazioni esistenti. In questo secondo caso spesso però si hanno vincoli di tempo e di budget o il tutto deve essere realizzato in modo incrementale.

Dovrà allora essere valutato se l'implementazione di una qualsiasi delle funzionalità precedenti avrà un impatto sulle prestazioni che potrebbe sollevare dubbi, una volta affrontato questo si potrebbero analizzare le cose in questo ordine:

Hashing e salting delle password. Messo in primo piano in quanto non dovrebbero mai essere salvate le password in chiaro nei database.
TLS. Dovrebbe essere attivato per tutte le connessioni tra gli applicativi e Sql Server. Semplice e rapido da configurare.
TDE. Anche TDE è molto semplice da configurare e viene fornito gratuitamente con l'edizione standard di SQL Server dalla versione 2019 in avanti. Protegge da un numero limitato di scenari ma è molto veloce da implementare.
Always Encrypted. La crittografia delle colonne con Always Encrypted è un po' più difficile da comprendere e sono presenti limitazioni sulle modalità con cui è possibile lavorare con i dati crittografati. È tuttavia lo strumento migliore per proteggere i tuoi dati personali e sensibili. Se il progetto di encryption ha risorse limitate, è consigliabile concentrarsi prima sulla crittografia degli elementi più sensibili e di quelli per cui non sarà necessario apportare modifiche al codice per aggirare il fatto che i dati sono crittografati.

Encryption nel cloud

Spostandosi in ambienti cloud è normale che lo sviluppo di nuove applicazioni adotti un approccio di tipo cloud first. La questione principale da tenere in considerazione è che SQL Server nel cloud ha, per lo più, gli stessi concetti di SQL Server on premises e la maggior parte delle stesse funzionalità che vengono utilizzato più o meno allo stesso modo.

I concetti espressi nell’articolo sono validi anche utilizzando SQL Server tramite un prodotto Software as a Service (SaaS) come il database SQL di Azure, Istanza gestita SQL di Azure o Amazon Web Services Relational Database Service (AWS RDS).

Ci saranno tuttavia alcune differenze o cose che non si possono fare. Non si può, ad esempio, utilizzare Always Encrypted con enclavi sicure su AWS RDS, anche se si può utilizzare la versione base di Always Encrypted. Utilizzando sempre Always Encrypted con enclavi sicure come esempio, è possibile utilizzarlo con il database SQL di Azure, ma probabilmente si utilizzerà un provider di attestazione diverso rispetto ad una situazione di istanza classica su virtual machine

Le considerazioni sopra sono valide per i seguenti ambienti in cloud:

SQL Server su Azure all’interno di una macchina virtuale
Azure SQL Database
Azure SQL Managed Instance
SQL Server in AWS all’interno di una macchina virtuale (EC2)
SQL Server su AWS RDS

di Alice Sella, pubblicato il 23 maggio 2024