Opzioni di crittografia sui database

I database mantengono i principali dati aziendali e debbono essere adeguatamente protetti. Tutti gli attuali database forniscono strumenti per proteggere i dati basati su algoritmi di crittografazione. Non e' pero' sempre chiaro a quale livello agiscono e qual e' il grado di sicurezza fornito.
Questa breve pagina cerca di presentare i livelli su cui e' possibile agire riportando quali soluzioni sono disponibili su alcuni database [NdA ho dovuto limitare tale panoramica ai DB che conosco meglio: Oracle, MySQL, PostgreSQL].

Nel seguito sono riportate le informazioni di interesse organizzate in paragrafi specifici: Introduzione, Livelli di applicazione della crittografia, Algoritmi, ...

Introduzione

Le piu' recenti normative per la sicurezza dei dati hanno posto l'attenzione di tutte le aziende sulla protezione dei dati: GDPR (General Data Protection Regulation, per la protezione dei dati personali), SOX (Sarbanes-Oxley Act of 2002, per la protezione dei dati finanziari), PCI-DSS (Payment Card Industry Data Security Standard, standard internazionale a protezione dei dati delle carte di credito), HIPAA (Health Insurance Portability and Accountability Act, legge USA a protezione dei dati personali e sanitari), UK Data Protection Act (per la protezione dei dati personali), FERPA NASD CA SB1386 e AB 1950 Basel II (per la protezione dei dati degli studenti e delle amministrazioni), ...

I database mantengono i principali dati aziendali e debbono essere adeguatamente protetti. Questo documento riporta quali sono i diversi livelli in cui e' possibile crittografare i dati e quali tecniche sono disponibili su principali DB relazionali.

Livelli di applicazione della crittografia

La tabella seguente riporta i diversi livelli su cui e' possibile applicare la crittografia e quali tecnologie vengono utilizzate da database diversi.

Livello Descrizione Oracle MySQL PostgreSQL Note
Password Encryption Trattamento della password di accesso alla base dati SHA-2 SHA-2 MD5 La password e' tipicamente memorizzata in modo crittografato sul DB. L'accesso alle tabelle che la contengono e' generalmente riservato ai soli DBA. Vi sono significative differenze tra i DB ed anche tra versioni differenti dello stesso DB: Oracle, MySQL, PostgreSQL.
Data Encryption Funzioni di crittografia disponibili DBMS_CRYPTO Package Encryption Functions pgcrypto Module L'applicazione utilizza funzioni del database per crittografare i dati, tipicamente per le sole colonne con dati sensibili/personali/critici.
Data at rest Encryption I dati vengono crittografati quando scritti su disco Transparent Data Encryption InnoDB Tablespace Encryption LUKS Impedisce l'accesso ai dati a chi e' connesso sul sistema operativo ospite. Si tratta di una funzionalita' importante sopratutto quando si ospitano database in cloud.
Encrypting Passwords across a Network Scambio della password in rete SHA-2 SHA-2 MD5 E' opportuno che la password sia ulteriormente crittografata quando transita in rete per evitare che lo sniffing dei pacchetti consenta di raccogliere i dati necessari per accedere al DB.
Encrypting Data across a Network Scambio crittografato dei dati in rete TLS/SSL TLS/SSL TLS/SSL Se la rete non e' protetta e' necessario crittografare tutto il traffico tra applicazioni e DB Server. Una soluzione alternativa esterna al DB e' l'utilizzo di VPN.
SSL Host Authentication Strong authentication TLS/SSL Auth. TLS/SSL Auth. TLS/SSL Auth. Fornisce una maggiore sicurezza evitando attacchi di tipo "man in the middle" sul DB. Richiede una maggiore gestione per definire e mantenere i certificati rispetto alla semplice crittografia.
Client-Side Encryption Crittografia a livello applicativo       Funzionalita' esterna all'RDBMS: l'applicazione effettua la crittografazione internamente e memorizza sul DB dati crittografati (possono essere crittografati tutti i dati o solo i campi ritenuti critici).
Backup Encryption Crittografia applicata ai backup RMAN datapump mysqldump pgdump Crittografazione dei backup.

La tabella e' necessariamente sintetica: vi sarebbero centinaia di ulteriori informazioni da fornire... seguendo i link si trovano documenti con ulteriori dettagli.
Le soluzioni tecniche utilizzate dai diversi DB presentano notevoli differenze: in alcuni casi alcune soluzioni sono nettamente piu' sicure, in altri casi e' molto difficile distinguerle. Nella scelta dei colori utilizzato nella tabella abbiamo semplicemente indicato la presenza o meno di una specifica opzione di crittografia a livello di database.

Ogni database ha versioni differenti e sono molto significative le differenze tra versioni (eg. PostgreSQL supporta nel TLS l'ECDH dalla 9.4, Oracle utilizza lo SHA-1 dalla versione 11g e lo SHA-256 dalla versione 12 per l'encrytion delle password, MySQL fornisce molte piu' funzionalita' sulla sicurezza dalla versione 5.7, ...). Nella compilazione abbiamo fatto riferimento all'ultima versione dei database disponibile in produzione il 31/12/2017. L'utilizzo della versione piu' recente di un database non solo consente di utilizzare gli algoritmi di sicurezza piu' aggiornati ma anche di disporre di tutti i fix di sicurezza

Oracle e' disponibile i piu' Edition (eg. Standard) e nell'Enterprise Edition sono disponibili parecchie Option, alcune delle quali molto importanti dal punto di vista delle funzionalita' di sicurezza (eg. Advanced Security Option che comprende il TDE citato in tabella, Oracle DB Vault, ...).
MySQL e' disponibile almeno su tre fork [NdA il termine e' improprio ma rende l'idea: per essere esatti due edition ed un fork] che si differenziano sopratutto per le componenti di sicurezza (MySQL Community, MySQL Enterprise Edition, MariaDB).. Nella compilazione della tabella abbiamo fatto riferimento a MySQL Community perche' molto diffusa. Ma e' importante sottolineare che l'Enterprise Edition fornisce funzionalita' aggiuntive (eg. MySQL Enterprise Encryption), che MariaDB dalla 10.0 implementa i ruoli e l'Audit plugin e dalla 10.1 la tablespace e log encryption.
EDB fornisce la versione PostgreSQL Plus che presente diverse funzionalita' aggiuntive dal punto di vista della sicurezza.

Sono molteplici le funzionalita' di sicurezza e di crittografia non riportate in tabella fornite da terze parti che si integrano ai database o sono richiamabili come tool esterni (eg. miXen).

Il fatto che un DB supporti una certa modalita' di crittografia non implica affatto che questa venga utilizzata o, peggio, che venga utilizzata correttamente!

Algoritmi utilizzati (TL;DR)

La teoria degli algoritmi di crittografia e' complessa e richiede basi matematiche appropriate... quindi non e' il caso di approfondirla!
La tabella seguente riassume gli algoritmi di hash delle password utilizzati per i database descritti in questa pagina: Curva ellittica

Algoritmo Bit HEX Database Note
DES 56 14
custom 64 16 MySQL < 4.1 old_password()
MD5 128 32 PostgreSQL
MongoDB
Triple DES fino a 168 Oracle
SHA-1 160 40 MySQL
Oracle >= 11
SQL Server
CouchDB
password() Memorizza il dato con un '*' iniziale (41 HEX)
 
 
 
SHA-2 da 224 a 512 MySQL >= 5.6
MongoDB >= 2.4
Oracle>=12
AES-128 128 32 Oracle TDE tablespace encryption default
AES-192 192 48 Oracle TDE column encryption default
AES-256 256 64 MySQL TDE, Oracle TDE

Oltre agli algoritmi di crittografazione e' altrettanto importante la generazione di numeri casuali. Gli ambienti virtualizzati e su container soffrono spesso di mancanza di entropia, cosa che causa problemi nella generazione dei numeri casuali [NdA basterebbe un'occhiata alla mia scrivania per risolvere il problema ;-]. Le funzioni random sono tipicamente legate a quelle di crittografia e disponibili negli stessi moduli/package...

La ricerca in questi campi e' continua non solo perche' l'HW e' sempre piu' performante (eg. Moore, grid computing), ma c'e' un continuo rincorrersi tra spie e hacker (eg. Snowden) e ci sono anche molti molti soldi in gioco (eg. le criptovalute basate su blockchain utilizzano i piu' recenti algoritmi di crittografia basati sulle curve ellittiche).

Gli algoritmi di crittografia vengono utilizzati dai protocolli di comunicazione come il famoso SSL.
Per essere precisi l'SSL (Secure Sockets Layer) e' il predecessore dell'attuale TLS (Transport Layer Security) e sono entrambe protocolli crittografici utilizzati per le comunicazioni sopra il livello di trasporto TCP (Transmission Control Protocol). L'utilizzo piu' comune e noto del TLS/SSL e' su web per garantire la sicurezza delle comunicazioni verso i siti (con il protocollo HTTPS), altrettanto importante e significativo e' l'uso del TLS/SSL nelle connessioni VPN, ... Per l'accesso alle basi dati e' molto meno utilizzato poiche' solitamente queste vengono poste su reti interne e protette.

TLS/SSL forniscono meccanismi per l'autenticazione, l'integrita' dei dati e la cifratura operando al di sopra del livello di trasporto [NdE il livello di trasporto e' il TCP]. Nella fase di avvio della comunicazione tra due nodi viene prima negoziato l'algoritmo da utilizzare, quindi vengono scambiate le chiavi di cifratura ed eseguita l'autenticazione. La fase di autenticazione avviene con lo scambio di chiavi asimmetriche (ovviamente viene inviata solo la chiave pubblica) e la verifica di certificati emessi da certificate authority (CA). Una volta instaurata la comunicazione i messaggi vengono cifrati con chiavi simmetriche ed verificati singolarmente con un checksum.

Per ogni fase vengono utilizzati protocolli diversi ed in ogni versione vengono aggiornati gli algoritmi (eliminando quelli che sono stati ricosciuti come meno sicuri). Attualmente con il TLS sono utilizzati per lo scambio di chiavi: RSA, Diffie-Hellman, ECDH, ... per l'autenticazione: RSA, DSA, ECDSA, ... per la cifratura simmetrica: RC4, DES, Triple DES, AES, ... per la verifica d'integrita': HMAC-MD5, HMAC-SHA, ... In precedenza con l'SSL per la verifica di integrita' venivano utilizzati anche: MD2, MD4, MD5 e SHA ma ora non sono ritenuti sufficientemente sicuri.

Tutto chiaro? Probabilmente no... ma non importa! E' piu' semplice di quanto sembri: con il corretto utilizzo di TLS/SSL si e' certi dell'identita' del chiamato/chiamante, ogni messaggio viene verificato (e quindi non puo' essere modificato), ogni messaggio viene cifrato (e quindi non puo' essere letto da altri).

Varie ed eventuali

La crittografia non esaurisce affatto le esigenze di sicurezza di una base dati (eg. Oracle, MySQL, PostgreSQL).


Titolo: Opzioni di crittografia sui database
Livello: Medio (2/5)
Data: 1 Gennaio 2018
Versione: 1.0.0 - 1 Gennaio 2018
Autori: mail [AT] meo.bogliolo.name