Nonostante la piena operatività del GDPR ormai da alcuni mesi, alcune aziende stanno ancora cercando di gestire i processi per rendere il proprio IT conforme alle nuove normative. Dato che il GDPR copre molti aspetti della sicurezza dei dati oltre alle questioni di perdita dei dati, non esiste quasi un singolo processo IT che non sia interessato dalla nuova legge europea. Mentre è ovvio che la maggior parte dei processi deve cambiare, per altri è meno scontato.
Una delle modifiche richieste consiste nella necessità di crittografare le e-mail che contengono informazioni personali di clienti, dipendenti e chiunque altro. Dato che l'articolo 25 del GDPR richiede la protezione dei dati "fin dalla progettazione e per impostazione predefinita" per tutti i processi (IT) di business per prodotti e servizi e l'intero regolamento dovrebbe rendere più sicuri i dati personali e meno probabili le perdite di dati, molti legali sostengono che questa nuova legge imponga la crittografia di tutte le e-mail per impostazione predefinita. Anche se non è chiaro al momento se questo sia vero o meno, vale la pena pensare alle conseguenze di questa attività, se non lo avete già fatto.
Importante: un'e-mail è come una cartolina!
Quando si invia un'e-mail, alcune persone come, per esempio, l'amministratore IT dell'azienda o l'Internet service provider, possono leggerne il contenuto se lo desiderano. Pertanto, l'invio di una normale e-mail che includa informazioni personali o sensibili senza crittografia è considerato una pratica illegale ai sensi del GDPR.
La crittografia delle e-mail non è una pratica comune come dovrebbe. Questo per il fatto che l'implementazione di questa funzionalità non è semplice. Ci sono attualmente due metodi differenti tra cui scegliere:
Crittografia del trasporto
Crittografia del trasporto significa che le e-mail sono criptate quando vengono inviate (trasferite) da un server a un altro. Quando si utilizza questo metodo le e-mail sono inviate attraverso un tunnel crittografato. Le e-mail sono crittografate alla partenza da un server e decrittografate quando arrivano sull'altro server. Tutte le e-mail sul server non sono crittografate quando sono archiviate sul server. Per inviare e-mail crittografate tramite Internet usereste per esempio il protocollo di trasferimento e-mail POP3S con il protocollo di rete Transport Layer Security (TLS) (il nuovo nome del protocollo Secure Sockets Layer (SSL) utilizzato per alcuni anni).
TLS si combina con POP3S creando così un tunnel di crittografia, noto anche come site-to-site-encryption o end-to-end-encryption, che rappresenta un'ottima soluzione quando si collegano direttamente due server. Tuttavia, molte aziende non hanno relazioni così strette da collegare direttamente i propri server e-mail. È più probabile che ci siano altri server in mezzo, attraverso i quali devono passare le e-mail. Quindi è necessaria un'altra soluzione… come…
Crittografia dei contenuti
Quando si utilizza la crittografia dei contenuti, vengono criptate le e-mail e non il tunnel di rete attraverso il quale vengono trasferite. Oggi gli standard più comuni per la crittografia dei contenuti e-mail sono lo standard S/MIME (Secure/Multipurpose Internet Mail Extensions) o l'utilizzo di OpenPGP.
Lo standard S/MIME può essere, per esempio, implementato nel vostro MS Exchange Server. Lo standard S/MIME si basa su crittografia asimmetrica e utilizza una coppia di chiavi correlate matematicamente. Si tratta della chiave pubblica e di quella privata. Un messaggio viene crittografato con la chiave pubblica del destinatario (non del mittente), mentre viene decrittografato con la vostra chiave privata.
Anche se la tecnologia del protocollo S/MIME non è facile da spiegare, cercheremo di farlo in maniera semplice. Quando si implementa il protocollo S/MIME in un MS Exchange Server viene prodotto un certificato che contiene la firma dell'utente e la sua chiave pubblica. Quando egli invia a un altro utente (utente "B") la propria firma, dimostra di essere la persona che dice di essere e fornisce al destinatario della propria e-mail la sua chiave pubblica, concedendogli pertanto il diritto di inviargli e-mail crittografate. Quando poi l'utente B invia un'e-mail crittografata all'utente A, il client e-mail dell'utente A "riconosce" che il messaggio proviene da un mittente sicuro e conosciuto, cerca la sua chiave privata all'interno del client e-mail e decripta il messaggio.
La stessa procedura si applica a OpenPGP. Anch'esso si basa sullo scambio di chiavi private e pubbliche per la crittografia e la decrittografia delle e-mail. Generate una coppia di chiavi, una che cripta l'e-mail (la chiave pubblica) e l'altra che decripta il messaggio criptato (la chiave privata). Condividete la vostra chiave pubblica con tutte le persone da cui volete ricevere e-mail crittografate. Quando ricevete un'e-mail crittografata da una fonte nota il vostro client e-mail decripta il messaggio. Ecco come funziona. Tuttavia, l'implementazione di una soluzione OpenPGP può essere abbastanza difficile e dispendiosa in termini di tempo.
Oggigiorno, quando le aziende utilizzano la crittografia per le e-mail, implementano lo standard S/MIME nel proprio MS Exchange o in un altro e-mail exchange server, mentre gli individui utilizzano soluzioni di crittografia basate su OpenPGP come per esempio GnuPG o altre varianti open source.
I pericoli della crittografia e-mail
Come abbiamo visto, l'utilizzo della crittografia del trasporto come TLS implica che sia sul server del mittente sia sul server e-mail del destinatario (sia sui client e-mail) i messaggi e gli allegati non sono crittografati. Pertanto, quando un server di posta elettronica non funziona (per esempio in caso di guasto di un disco rigido interno o quando l'intero sistema si ferma a causa di errori del software) gli esperti di recupero dati come i tecnici di Ontrack Data Recovery sono in grado di riassemblare i file system così come di recuperare i messaggi senza troppi sforzi.
Tuttavia, quando si utilizza la crittografia dei contenuti, a prescindere che si tratti di una soluzione S/MIME, OpenPGP o gateway, possono verificarsi casi in cui il recupero delle e-mail crittografate è complesso.
In ogni caso le cosiddette chiavi pubbliche e private devono essere messe a disposizione degli esperti di recupero dati perché possano iniziare o cercare di recuperare le e-mail. Se tali chiavi, o per esempio la chiave privata, che è in effetti un certificato, non sono disponibili, allora non c'è la minima possibilità di recuperare il contenuto originale all'interno delle e-mail.
Dato che, per esempio, la lunghezza minima della chiave simmetrica (o key size) di OpenPGP è di 128 Bit, ci vorrebbero 1,44 miliardi di anni per individuare quella chiave di crittografia simmetrica. Inoltre, con le chiavi a 256 Bit, la maggior parte degli esperti di crittografia afferma che è impossibile anche per le agenzie di sicurezza governative e i loro supercomputer decrittografare quella chiave.
Pertanto, è opportuno conservare e archiviare sempre le proprie chiavi di crittografia, i certificati o le password di decrittografia, tenendoli separati dal server e-mail originale o dal computer desktop così che, quando si verifica una perdita di dati, gli esperti di recupero dati possono utilizzarle per recuperare i dati originari crittografati.