Dati cifrati nel DB: come gestirli?

La protezione di dati sensibili è cosa assai seria e gestirla in modo adeguato non è per nulla semplice. Si potrebbe pensare di cifrare semplicemente il dato dentro al DBMS aziendale. Ma basta?

No. Purtroppo no. Cifrare il dato nel DB, e dipende anche come, ci preserva da tutta una serie di minacce ma di certo non ci mette al riparo da altre.

Iniziamo col dire che se abbiamo la necessità di proteggere i nostri dati sensibili, o meglio alcuni dati sensibili, è perché probabilmente esiste anche uno strato applicativo che utilizza e gestisce tali dati.

Analizzando le possibili minacce a cui il nostro sistema applicativo può essere soggetto, possiamo ravvisare le seguenti:

1. DB Admin malizioso che fa un export dei dati sensibili: direttamente dal DB o utilizzando le diverse console tipo PHPMyAdmin;
2. rottura dei dischi rigidi del DB e società deputata all'assistenza che interviene sul guasto, avendo accesso ai dati in forma nativa;
3. connessioni di rete non protette tra il DBMS e i layer applicativi soprastanti;
4. layer applicativo di business logic accessibile per manutenzione ad operatori "maliziosi";
5. sviluppatori "maliziosi" o non formati dal punto di vista della sicurezza applicativa che possono introdurre le seguenti vulnerabilità:
• sessioni dalla durata troppo ampia;
• dato sensibile e dato non sensibile gestito secondo la stessa politica di visualizzazione sul client (fat o web);
• reportistica che non distingue dato sensibile da dato non sensibile;
• reportistica senza l'indicazione dell'utente che ha effettuato la stampa;
6. attribuzioni delle responsabilità agli operatori che utilizzano il sistema applicativo insufficienti;

Per ognuna di queste minacce e relative possibili vulnerabilità introdotte, serve una contromisura di sicurezza. Già da qui si capisce che la sola cifratura del DB non è sufficiente a garantire la riservatezza del dato sensibile in tutto il sistema.

Innanzitutto, prima di scendere nel dettaglio delle possibili contromisure, è necessario mettere in evidenza che per proteggere il dato sensibile non possiamo solo pensare alla "confidenzialità", intesa come mera cifratura del dato. E' molto comune confondere la confidenzialità del dato con la cifratura dello stesso. Garantire la confidenzialità implica invece meccanismi di identificazione, autenticazione e autorizzazione, prerequisiti per la decifratura e quindi la visualizzazione del dato in chiaro.

Una buona definizione di "confidenzialità" o "riservatezza" è la seguente:

"preservare le restrizioni all'accesso e alla visualizzazione di informazioni riservate, includendo anche la protezione delle informazioni personali e proprietarie…" La perdita di riservatezza consiste nella possibilità di visionare informazioni riservate senza le opportune autorizzazioni.

Da nessuna parte si dice che il dato deve essere cifrato! Basterebbero addirittura delle buone misure di autenticazione e autorizzazione per rispondere a questo requisito. Da qui si capisce che per garantire la confidenzialità dei nostri dati sensibili dobbiamo soprattutto pensare ai meccanismi di autenticazione e autorizzazione che ci permettono di profilare chi e come i dati vengono visualizzati. Poi l'autorizzazione può essere data su delle chiavi di cifratura (simmetriche o asimmetriche) oppure sul dato vero e proprio. Nel secondo caso però non ci protegeremmo da eventuali minacce quali il furto dei dischi del DBMS.

Tornando quindi alla nostra ipotesi di minacce, e dopo la doverosa precisazione di approccio generale, proviamo ad ipotizzare le relative contromisure:

1. DB Admin malizioso che fa un export dei dati sensibili: cifratura del dato con chiavi di cifratura non accessibili ai DB Admin - cifratura con chiavi asimmetriche di chiavi simmetriche per permettere l'accesso a più utenti dello stesso dato cifrato;
2. rottura dei dischi rigidi del DB e società deputata all'assistenza che interviene sul guasto, avendo accesso ai dati in forma nativa: cifratura del dato;
3. connessioni di rete non protette tra il DBMS e i layer applicativi soprastanti: cifratura del canale con protocolli come SSL/TLS - autenticazione del server sul client e, in casi molto particolari, anche dei client sul server (mutua autenticazione);
4. layer applicativo di business logic accessibile per manutenzione ad operatori maliziosi: la cifratura del dato con chiavi degli utenti risponde anche a questa minaccia - politiche di logging delle attività degli operatori;
5. sviluppatori maliziosi o non formati dal punto di vista della sicurezza applicativa che possono introdurre le seguenti vulnerabilità:
• sessioni troppo lunghe: specializzare le sessioni nel caso riguardino dati sensibili e limitarne la durata preservando comunque l'usabilità dell'applicazione;
• dato sensibile e dato non sensibile gestito secondo la stessa politica di visualizzazione sul client (fat o web): sviluppare meccanismi di ulteriore autenticazione nel caso di visualizzazione del dato sensibile - autenticazione a due fattori per il dato sensibile;
• reportistica che non distingue dato sensibile da dato non sensibile: specializzare i report a seconda della tipologia di dato che contengono; limitare la reportistica di dati sensibili e, nel caso, indicare l'utente che ha stampato il dato e il timestamp dell'operazione; in casi limite utilizzare materiali cartacei anti-fotocopia (ma nessuno vi protegge dalla macchina fotografica!);
• reportistica senza l'indicazione dell'utente che ha effettuato la stampa: come sopra;
6. attribuzioni delle responsabilità agli operatori che utilizzano il sistema applicativo insufficienti: comunicazioni formali agli operatori sulle politiche da seguire nell'utilizzo e/o manutenzione di un particolare sistema applicativo; indicazioni delle responsabilità, sanzioni e attività di monitoraggio delle operazioni;

E' chiaro che non a tutto c'è soluzione. Parlare con l'operatore infedele che ha "visto" il dato sensibile e ce lo "spiffera" non può essere gestito dal punto di vista tecnico e tecnologico, ma attraverso la responsabilizzazione degli stessi sì.

Diverso è invece l'attacco di tipo "tempest" (passatemi l'associazione poco ortodossa) con la famigerata "macchina fotografica"! Per quanto sia corta la sessione applicativa o del lock del desktop, esiste sempre un intervallo di tempo in cui l'utente malevolo può fotografare la schermata...

Parliamo invece di come realizzare la cifratura del dato. A chi non piace mettersi a giocherellare con le funzioni crittografiche esposte dallo strato applicativo o del DB? Si sa, noi informatici amiamo particolarmente smanettare con queste cose...

Ma le procedure che sviluppiamo devono essere a prova di bomba! E' sì importante cifrare il dato, ma è molto più importante leggerlo! Quindi piuttosto che cimentarsi in procedure complesse che potrebbero lasciar spazio a errori di progettazione o di implementazione, sarebbe meglio affidarsi alle prerogative del DBMS. Molti di questi infatti, oltre ad esporre le primitive crittografiche (AES, Triple DES, etc.) permettono di gestire tabelle in cui alcune o tutte le colonne vengono cifrate automaticamente dal DBMS stesso. Oracle e PostgreSQL sono due DBMS che mettono a disposizione questi meccanismi.

Magari la chiave di cifratura è stata generata direttamente in un HSM e l'accesso all'HSM viene gestito con delle credenziali cifrate con chiavi pubbliche di più utenti. Invece che cifrare la stessa chiave simmetrica N volte con tutte le chiavi pubbliche degli utenti che la devono utilizzare (possibilità comunque valida, date un'occhiata a questo post), cifro N volte la password di accesso alla chiave simmetrica generata nell'HSM. Equivalente, tranne il fatto che la vera chiave simmetrica è nata e morirà dentro l'HSM.

Capisco che tutto questo può sembrare una inutile complicazione: perché impazzire per capire se il mio DBMS ha tabelle cifrate o comprare un HSM?

Perché nel caso di contestazione un conto è dimostrare che la propria procedura di gestione della cifratura è "corretta e completa" (direbbe qualcuno), un altro è dire "la cifratura la fa Oracle (per esempio) mentre la chiave simmetrica è in un HSM". Si chiama "Responsibility Shifting" e viene applicato molto di più di quello che si potrebbe pensare. In questo caso però ha un senso.

Non ha senso inventare di nuovo la ruota, tanto vale usarne una già esistente e magari ben gommata!