Note sulla crittografia nei database: i data-at-rest

Dopo avere visto gli approcci alla cifratura dei dati in transito, vediamo ora quelli rivolti ai dati memorizzati (e archiviati). La cifratura dei dati su disco è da preferire quando si conservano dati che non dovrebbero essere visibili se non ai legittimi proprietari. È il caso dei numeri delle carte di credito, a cui non dovrebbero accedere neppure i DBA; ma va contemplata anche l’eventualità di una copia illegale dei file del database, o del furto del server o dei dischi su cui risiedono i dati.

Le strategie seguite sono tipicamente tre:

• Cifratura a livello applicazione: tutta la gestione è demandata ad apposite librerie crittografiche del linguaggio di programmazione usato nello sviluppo dell’applicazione per la gestione della base dati (come le Java Cryptographic Extensions). Questo approccio è completamente trasparente al database. Se questa soluzione è utile nei casi in cui le norme di sicurezza sono molto stringenti (è impossibile usare i dati all’infuori dell’applicazione che li ha cifrati), è però poco pratico perché limita l’utilizzo di stored procedure e appesantisce lo sviluppo dell’applicazione.
  

• Cifratura a livello del file system: sfrutta le capacità dei sistemi operativi più evoluti di gestire i file in forma cifrata. Anche in questo caso, l’operazione è trasparente al database. Ha un grosso limite nel decadimento delle prestazioni, perché ogni accesso ai file deve passare attraverso la fase di cifratura/decifratura.
  

• Cifratura a livello del database: si usano le funzionalità offerte dal DBMS o da estensioni sviluppate da terzi. Risulta essere la soluzione più pratica, e infatti è la più utilizzata. Tuttavia “pratica” non va intesa come semplice: a questo approccio è legata la gestione di un insieme di chiavi che non è affatto banale. Tipicamente, a ogni attributo che si intende cifrare è associata una chiave simmetrica. Gli utenti del database sono forniti di una chiave pubblica e di una privata personali. Quando a uno di questi utenti viene assegnato il permesso di accedere a un attributo cifrato, la relativa chiave simmetrica viene cifrata con la chiave pubblica dell’utente e posizionata in una locazione accessibile. Ad essa l’utente potrà accedere mediante la sua chiave privata, che gli consentirà di operare sull’attributo.
  

Comunque, quale che sia la strategia adottata, la prima considerazione da fare riguarda quali dati nascondere. Gli algoritmi crittografici consumano risorse sul server, con il conseguente decadimento delle prestazioni. Per questo motivo è necessario individuare quali attributi siano assolutamente da mascherare, evitando dove possibile gli attributi usati come chiavi o associati a indici, perché genererebbero un sovraccarico dovuto alla decifrazione ad ogni scansione della tabella a cui appartengono.

Un’altra questione riguarda le funzionalità di backup e ripristino. I backup vanno cifrati al pari dei dati in linea, altrimenti all’aggressore basterà procurarsi i file di backup per aggirare il problema (operazione anche meno rischiosa se non è previsto un auditing sugli accessi ai dati archiviati). Inoltre, bisogna tenere presente che, se la politica di sicurezza aziendale prevede il cambiamento periodico delle chiavi, bisognerà gestire e conservare (in maniera sicura) quelle usate per generare i backup.

Vista la complessità e la difficoltà implementativa di queste scelte, è indispensabile documentarsi approfonditamente prima di adottarle per i propri sistemi, studiando in particolare le funzionalità messe a disposizione dai singoli DBMS. Esse tuttavia - al momento - non affrontano ancora in modo integrato questioni complesse come per esempio la gestione della cifratura in presenza di clustering, di repliche del database, dell’auditing. In questo settore specifico si potrà scegliere di usare prodotti di terze parti, che generalmente offrono soluzioni più complete e più semplici da utilizzare.