Oggi scrivo da hacker.
Vi sto dicendo che bisogna cifrare i dati. Qualcuno si meraviglierà, qualcun altro dirà che sono impazzito, ma confermo tutto. Bisogna cifrare dei dati.
Già il fatto che scriva “dei dati”, vuol dire che non dobbiamo cifrare tutto. Partiamo però sempre da alcuni assunti, che guidano queste mie riflessioni e che spero vi aiutino nella riflessione.
Perché implementare una cifratura dati
In primo luogo, i dati sono il nostro patrimonio, il vero capitale delle nostre organizzazioni. In ragione di ciò vanno difesi.
Secondariamente i rischi che corrono i nostri dati sono conosciuti, tutti pensiamo agli attacchi informatici, ma in realtà ce ne sono altri, meno considerati, come il furto interno e l’errore umano. Ricordo comunque che l’atto finale di ogni attacco informatico è la cosiddetta “esfiltrazione”, ovvero il “portare fuori” i dati dalla nostra organizzazione, al fine di venderli nel darkweb o di usarli per ricatti o scopi malavitosi.
Prevenire danni con la cifratura dei dati sensibili
Ora come possiamo prevenire tutto ciò?
Predico sempre due macro-azioni, ovvero:
- Alzare l’asticella della sicurezza
- Avere un piano B
Premesso quindi che le azioni sono diverse, ogni azienda ha dei dati particolari che vuole proteggere. Ho usato volutamente il termine particolari, che nella giurisprudenza GDPR ha sostituito il termine sensibili, allargandolo non di poco. Infatti, ci sono dei dati che sono relativi al business, o a personale che hanno un valore indiscusso.
Implementare una cifratura dati coerente con il GDPR porta quindi alla necessità di rendere tutti questi dati inintelligibili. Ciò comporta che un loro eventuale furto li riduca a bit e non a dati. La mia azienda ha un servizio di cifratura dati aziendali orientato proprio verso questo scopo, servizio che ho sempre pensato di vendere in prima istanza agli enti pubblici, molto più attenti alle volte a queste problematiche: la storia dice che il primo cliente al quale l’ho venduto sia stata una grossa azienda privata, di oltre 10.000 dipendenti, i cui auditor per la quotazione in borsa hanno richiesto la cifratura del database del personale.
Ci sono quindi aspetti legali ed aspetti di opportunità. Poi ricordiamo tutti, come i progetti della Ferrari furono rubati, avvenuta nel 2007, facendo le fotocopie… La sicurezza va vista a tutto tondo.
Cifratura dei dati aziendali: soluzioni possibili
Intanto dobbiamo distinguere fra dati di applicazioni, normalmente memorizzati in database, e dati destrutturati, tipicamente residenti nel file server.
Per proteggere e cifrare i dati nei DBMS, i più difficili da gestire, si può:
- Riscrivere le applicazioni, facendo sì che la cifratura e la decifratura in lettura siano gestite dall’applicazione stessa: bello ma difficile da realizzare.
- Comprare uno storage sul quale attivare la cifratura: molti storage vendor raccontano questa funzionalità come se fosse “la soluzione”; in realtà cautela solo dal furto dello storage fisico, eventualità per la verità piuttosto rara per un datacenter strutturato. Infatti, una volta che lo storage è acceso, i dati sono in chiaro! Proprio come avviene nei portatili, strumenti nei quali questa feature ha successo.
- Attivare la chiave di cifratura su di una colonna o riga del database: Oracle, Microsoft, ecc. hanno questa funzionalità. La prima critica che si può fare è che l’attivazione del servizio porta immediatamente ad un rallentamento delle prestazioni dell’applicazione stessa; infatti, ad ogni richiesta bisogna decifrare la riga o la colonna, fornire il dato in chiaro all’applicazione, attendere l’elaborazione ed il commitment e provvedere a cifrare di nuovo riga e colonna. Gli utenti vi chiamano immediatamente per domandare: com’è che l’applicazione va piano? Inoltre, sia Oracle che Microsoft, al di là del costo significativo della feature, hanno il difetto di mettere la chiave di cifratura/decifratura dentro il data base, cosicché chi ruba il DB, si porta a casa anche la chiave… Insomma, non proprio furbo.
- La soluzione più percorribile a mio parere, valida tra l’altro anche per i dati destrutturati, è quella di cifrare il file di database: alla fine Oracle, Microsoft SQL Server, Postgres, sono tutti dei file. È come mettere un involucro intorno al DB, lasciamo aperta la parte superiore per fare entrare le query; se qualcuno ruba il file di database, porta fuori dei bit e non dei dati. Ed è proprio il caso di esfiltrazione, quello da cui vogliamo, in primis, difenderci.
Conclusione: cifrare dati personali, sensibili e “particolari”
Nell’approccio olistico alla gestione e difesa dei dati dobbiamo considerare anche la cifratura degli stessi. Di tutto? Assolutamente no, ma di quello che riteniamo significativo, pericoloso se in mani altrui e, come detto in premessa, particolare. Pensiamo ai disastri che si possono prevenire cifrando dati relativi a progetti oggetto di brevetto, alle classifiche dei servizi sociali negli enti comunali, spesso archiviate in file di excel, ai database del personale con tante informazioni delicate, ai riassunti delle banche (una volta facendo un assessment in una banca, ho trovato su Alfresco un file xls in chiaro contenente i campi “correntista”, “giacenza attuale”, “giacenza media”, insomma un file non proprio carino se finito in mani esterne).
Giuseppe Mazzoli
Amministratore Unico di 3CiME Technology
