Note sulla crittografia nei database: i dati in transito

Non sono sparito... In questo periodo sto trascurando il blog perché sono assorbito da un progetto decisamente interessante, di cui forse parlerò in futuro. Nel frattempo, pubblico qualche nota su un argomento centrale per la sicurezza: la cifratura dei dati.

Nonostante tutte le precauzioni messe in atto per proteggere i sistemi informatici e i dati custoditi, è sempre possibile che un aggressore riesca a penetrare le difese e raggiungere il cuore del sistema, la base dati. Quando l’attacco ha successo, l’estrema difesa è rappresentata dall’uso della crittografia, che rende illeggibili i dati a chi non possiede le chiavi per decodificarli.

Un ottimo libro sulla crittografia per chi volesse approfondire l'argomento è Practical Cryptography di Niels Ferguson and Bruce Schneier, che in qualche modo segue il precedente Applied Cryptography, ancora di Schneier.

Nel settore delle basi dati si sono affermati due approcci alle tecniche crittografiche, nati da esigenze diverse: la cifratura dei dati in transito e la cifratura dei dati memorizzati (o data-at-rest). Nel primo caso, che vedremo oggi, si intende proteggere le comunicazioni, perché la minaccia di furto dei dati si manifesta a livello del canale; nel secondo caso si vuole proteggere (almeno) una parte dei dati perché particolarmente riservata - come nel classico esempio dei numeri di carte di credito - dall’accesso sia di persone esterne che degli utenti interni del database.

Cifratura dei dati in transito

Tutti i DBMS all’installazione aprono delle porte di default per le loro comunicazioni, che gli amministratori meno accorti tendono a non cambiare. Gli hacker conoscono queste porte, e quasi sempre sono esperti di reti. Riescono a intercettare facilmente le trasmissioni, che generalmente avvengono in chiaro (o quasi). Se il canale di comunicazione è considerato a rischio, è opportuno cifrare/decifrare la trasmissione ai suoi estremi, ovvero all’ingresso e all’uscita del canale - avendo tuttavia ben presente che la cifratura delle trasmissioni ha un impatto considerevole sulle prestazioni. Se si sceglie questo approccio, ovvero si considera prioritaria la minaccia sul canale, i dati contenuti nelle tabelle possono rimanere non criptati (ma nulla vieta di ricorrere a entrambe le soluzioni).

Per intercettare le comunicazioni, un attaccante deve avere accesso alla rete e sapere interpretare il flusso delle comunicazioni. L’accesso alla rete è certamente semplificato se si usa una macchina facente parte della rete-bersaglio, o se si ha accesso fisico a uno dei suoi switch (magari attraverso una porta SPAN *): è sufficiente configurare la scheda di rete in modalità promiscua per intercettare tutte le trasmissioni che avvengono all’interno della rete. Per interpretare il flusso delle comunicazioni, oltre ad avere una minima conoscenza dei protocolli di rete - in pratica del TCP/IP - e dei protocolli dei DBMS che si appoggiano su di essi, basta l’uso di uno dei tanti strumenti disponibili in internet come Tcpdump o Ethereal per intercettare i pacchetti e acquisirne i payload, al cui interno sono veicolati i payload del database. Usando questa tecnica, l’attaccante sarà in grado di intercettare il processo di autenticazione (il login al database), i comandi SQL (dai quali può estrapolare la struttura della base dati), e i dati restituiti dalle query.

[* Switch Port Analyzer. Molti switch evoluti sono dotati di una porta SPAN a scopi amministrativi, sulla quale (e solo su di essa) viene trasmessa copia di tutti i dati inviati alle altre.]

Per proteggere la trasmissione si possono adottare approcci diversi. Nello specifico:

• Funzionalità dedicate interne al database: alcuni DMBS offrono dei package per il supporto e la gestione della cifratura delle trasmissioni, come nel caso del pacchetto Oracle Advanced Security incluso nella versione Enterprise di Oracle (può essere utile consultare a questo scopo il volume Oracle security handbook di Theriault, Newman e Vandivier). Quando un client tenta di aprire una connessione col server, il listener di Oracle avvia una sequenza di negoziazione sul sistema di cifratura, mediante la quale comunica al server i metodi crittografici che supporta. Il server li confronta con quelli che ha a sua disposizione, e se trova delle corrispondenze attiva quello a cui è data la priorità nei suoi file di configurazione; in caso contrario, rifiuta la connessione. Poiché solitamente questo genere di soluzioni è costoso (per l’acquisto delle versioni più care o di pacchetti aggiuntivi), la loro diffusione è limitata rispetto alle altre.

• Connessioni speciali: in sostanza si riducono tutte all’uso di SSL (Secure Socket Layer), che è adottato praticamente da tutti i DBMS sul mercato. Il protocollo SSL utilizza metodi di cifratura a chiave pubblica e richiede l’uso di certificati a chiave pubblica per verificare l’identità del DB server e della macchina su cui è in esecuzione l’applicazione.

• Tunneling: in questo caso si sfrutta il protocollo SSH, che è diventato uno standard di fatto per l’amministrazione remota di sistemi Unix e di dispositivi di rete, in sostituzione del protocollo Telnet, privo di protezione contro le intercettazioni. Questa tecnica è implementata in modo trasparente rispetto al database, perché i dati sono cifrati direttamente nel tunnel. Per cifrare il traffico del database si stabilisce un tunnel SSH mediante il port forwarding: si specifica una porta A sul client che fungerà da accesso al tunnel, il quale consegnerà i pacchetti sulla porta specificata B del server.
  

  Esempio: ssh -L 9999:localhost:4304 192.168.0.1
  

  Con questo comando si genera un tunnel tra la porta 9999 del client (localhost) e la porta 4304 del server (192.168.0.1). Ogni trasmissione che abbia luogo attraverso la porta A del client passerà automaticamente attraverso il tunnel SSH, cifrata, fino alla porta B sul server.
  

• Demandare al sistema operativo: anche in questo caso, come nel precedente, la cifratura avviene in modo trasparente per il database, ma l’operazione è direttamente a carico del sistema operativo. Si usa lo standard IPSec, che a sua volta crea una sorta di tunnel cifrato, che però ha effetto su tutto lo stack TCP/IP. È fondamentale che il servizio di cifratura di IPSec sia attivo su tutte le macchine che devono essere coinvolte.
  

Queste le soluzioni più comuni per la cifratura dei dati in transito. Nel prossimo post completeremo la panoramica vedendo quelle per i dati memorizzati. Stay tuned!