La tabella seguente riassume gli algoritmi di hash delle password utilizzati per i database descritti in questa pagina:
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, ...
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.
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 EDB Postgres Advanced Server (EPAS) che presente diverse
funzionalita' aggiuntive dal punto di vista della sicurezza tra cui, dalla versione 15, anche il TDE.
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.
Il fatto che un DB supporti una certa modalita' di crittografia non implica affatto che questa venga utilizzata o, peggio, che venga utilizzata correttamente!
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:
| 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).
La crittografia non esaurisce affatto le esigenze di sicurezza di una base dati; vi sono molti altri aspetti da valutare su: Oracle, MySQL, PostgreSQL.
Titolo: Opzioni di crittografia sui database
Livello: Medio
Data:
1 Gennaio 2018
Versione: 1.0.1 - 14 Febbraio 2023
Autori: mail [AT] meo.bogliolo.name