Nei precedenti articoli abbiamo visto alcune delle problematiche di sicurezza, diretta ed indiretta, legate agli strumenti IT e introdotto il regolamento europeo GDPR (General Data Protection Regulation), soprannominato anche “Gran Decreto Privacy”.
In questo articolo concentriamo l’attenzione su alcune delle richieste che il GDPR pone per i nuovi trattamenti di dati successivi alla sua definitiva entrata in vigore: la privacy e la data protection by design e by default.
La privacy e la protezione dei dati diventano parte integrante di ogni trattamento sin dalla progettazione e per impostazione predefinita. E deve essere svolta una adeguata analisi dei rischi. Ciò è conforme pienamente ai principi espressi da normative internazionali come ISO27001 (la sicurezza informatica) e ISO31000 (la gestione del rischio) e, in generale, ai temi della qualità espressi dalla normativa ISO9001 nella nuova versione del 2015. E rientra nelle buone pratiche suggerite dai framework come ITIL e COBIT e dai principi degli standard di Project Management come PMBoK, Prince2, ISO21500 etc.
Le conseguenze e i vincoli introdotti
In un progetto di servizio IT che automatizza un trattamento di dati e considerando anche eventuali fasi manuali al suo interno occorre inserire fra i requisiti essenziali la data protection e la privacy.
Per capire meglio cosa questo significa partiamo dalle premesse: un progetto IT, in questo caso di nuovo trattamento dei dati, parte necessariamente da una serie di requisiti da soddisfare, legati alle ragioni di business aziendale cui è associato l’obiettivo del processo. Questi requisiti, integrando quanto il GDPR chiede negli standard di Business Analysis, possono essere suddivisi nelle seguenti categorie:
Requisiti funzionali espliciti: sono le esigenze funzionali che il servizio IT deve soddisfare per generare valore per chi lo usa; un esempio, in un servizio web e-commerce, è descrizione della form di iscrizione al sito stesso.
Requisiti funzionali impliciti: sono esigenze funzionali che tendiamo spesso a dare per scontate, ma che sono comunque molto importanti; un esempio sono le regole di profilazione degli utenti che accedono ad un sistema, che definiscono i diritti di accesso alle varie categorie di dati per i singoli profili degli utenti.
Requisiti non-funzionali: sono caratteristiche tecniche ed organizzative che il servizio IT dovrà rispettare; un esempio sono le piattaforme su cui una app deve operare (iOS, Android, Windows Phone…).
Requisiti di qualità, fra cui includere anche quelli di sicurezza: sono la parte che ITIL definisce come “garanzia” di un servizio e rappresentano la qualità del servizio stesso. Tra questi i più importanti sono:
– la disponibilità (availability) di un servizio, ossia l’intervallo in cui il servizio è disponibile per gli utenti, che può essere, per esempio, orario di ufficio oppure 24x7x365 (tutto il tempo dell’anno);
– la capacità (capacity) di un servizio, ad esempio il numero massimo di utenti che possono collegarsi simultaneamente, il numero massimo di documenti memorizzabili etc.;
– l’affidabilità (reliability), ossia la capacità di un servizio di funzionare rispettando tutte le specifiche che lo definiscono in modo costante nel tempo (ad esempio, il tempo di esecuzione di una data funzione dovrebbe mantenersi ragionevolmente costante anche al crescere del numero di utenti collegati);
– la sicurezza (security) del servizio, sia rispetto ad eventi accidentali (ad esempio, guasti di componenti hardware) ed attacchi deliberati (azione di pirati informatici, virus etc).
Affidabilità e sicurezza sono in sostanza quanto richiesto dal privacy e data protection by default. In particolare queste due caratteristiche si traducono nelle seguenti qualità da mantenere per i dati:
disponibilità del dato: il dato è fruibile per gli utenti attraverso il servizio IT che lo tratta, se questo non sta funzionando, il dato è inaccessibile; anche se il dato è salvato nel backup, occorre tempo per ripristinare il funzionamento del servizio IT e ri-immettervi il dato rendendolo nuovamente disponibile per gli utenti; si pensi, ad esempio, ad un contesto sanitario dove la cartella clinica di un paziente deve essere disponibile per tutti quanti sono coinvolti nella cura del paziente stesso;
riservatezza del dato: il dato deve essere accessibile solo alle persone il cui ruolo prevede l’accesso al dato stesso; ovviamente possono esistere ruoli abilitati ad accedere a una quantità maggiore di dati rispetto ad altri; ad esempio, in un archivio del personale l’ufficio HR ha accesso a tutti i dati delle persone memorizzate, mentre altre funzioni non possono vedere indirizzi e stipendi;
integrità del dato: il dato deve essere protetto rispetto a modifiche del contenuto, accidentali (involontarie) oppure effettuate volontariamente in modo non autorizzato (ad esempio, si pensi all’azione di virus, dai cripto-locker come WannaCry ai virus subdoli che scambiano tra loro in modo casuale le righe di testo dei documenti che attaccano, oppure all’azione di un pirata informatico che modifica i voti di un concorso pubblico);
esattezza del dato: il dato deve essere esatto (ossia contenere dati personali corretti) ed aggiornato; pensiamo per esempio a tutte le problematiche legate alle utenze di servizi come gas ed elettricità quando il nominativo del titolare non è riportato correttamente dentro i sistemi che elaborano i dati;
conformità del dato: il dato deve essere espresso in una forma conforme alle leggi ed ai regolamenti; ad esempio, nell’ambito di alcune transazioni finanziarie la precisione dei numeri con la virgola deve essere di almeno 6 cifre decimali.
A tali requisiti si aggiungono due ulteriori qualità per la salvaguardia dei dati:
– RTO: tempo totale necessario per il ripristino della piena funzionalità di un servizio IT, comprensivo dei dati in esso contenuti, in caso di incidente; è composto da varie fasi, dall’individuazione dell’incidente o malfunzionamento a tutto quanto serve per ripristinare la piena funzionalità del servizio che tratta i dati e quindi la piena disponibilità di ogni dato in esso memorizzato.
– RPO: tempo nel passato cui è possibile tornare con il ripristino dei dati, significa che in caso di incidente grave che comporta la distruzione di un archivio dati, il backup periodico deve garantire la possibilità di ritornare ad un dato momento nel passato.
Se, ad esempio, salviamo il contenuto di un disco di un PC a mezzanotte e poi un guasto cancella tutti i dati alle 10 del giorno dopo, sarà possibile ripristinare solo i dati come erano a mezzanotte; esistono sistemi (costosi) in cui l’RPO è meno di un minuto, il che significa praticamente che non si possono perdere dati.
Andiamo oltre: analisi del rischio.
Le qualità definite nel paragrafo precedente sono ciò cui è necessario tendere. Questo significa che dobbiamo da un lato definire quali valori per ciascuna delle qualità sopra definite sono necessari per ogni trattamento dei dati e dall’altro valutare il rischio di uscire da valori, a causa di eventi accidentali come, ad esempio, i guasti software e hardware o di eventi deliberati come i virus o gli attacchi informatici.
Questo si può attuare con un processo standardizzato chiamato gestione del rischio (Risk Management), definito nello standard ISO 31000. Possiamo definire in breve l’analisi, gestione e prevenzione/riduzione del rischio (Risk Assessment, Management e Treatment) con un proverbio: “Prevedere il peggio per gioire del meglio”.
Infatti la gestione del rischio prevede di:
individuare, basandosi su esperienza, buone pratiche e altre metodologie codificate, tutti i rischi, ossia gli eventi (casuali e non) che possono alterare il risultato atteso;
quantificare l’impatto, ossia l’effetto dannoso di tali eventi sulle qualità del servizio sopra descritte;
quantificare la probabilità del verificarsi di tali eventi;
attribuire un peso al rischio combinando insieme probabilità ed impatto (esistono varie formule standard per questo);
individuare i rischi con peso più alto, definendo quindi quali sono i rischi “importanti” che richiedono contromisure e quali invece i rischi “accettabili”;
stabilire quali azioni possono ridurre la probabilità o l’impatto o entrambi per questi rischi, ed il loro costo;
applicare queste contromisure e stabilire il nuovo peso del rischio.
Il GDPR prevede che queste analisi del rischio debbano essere fatte prima di ogni progetto di nuovo trattamento. In realtà poi l’analisi del rischio viene ripetuta periodicamente, all’interno di un processo di miglioramento continuo.
Applichiamo ora il GDPR
Tutti i requisiti di sicurezza del dato, seguendo il GDPR, vanno affrontati in modo completo e organico fin dall’inizio.
Vediamo ora insieme una possibile sequenza di passaggi con un esempio legato all’azione di un ufficio clienti presso un’azienda che si rivolge a clienti finali e che vende ad essi.
Supponiamo dunque che il trattamento da progettare ex novo sia l’archivio clienti di un particolare prodotto con una garanzia di assistenza gratuita di 24 mesi dopo l’acquisto, e focalizziamo l’attenzione sui requisiti richiesti dal GDPR, in particolare per security e privacy.
Anzitutto circoscriviamo il perimetro, partendo dallo scopo del trattamento che è legato ad un particolare contratto (“liceità”) e che prevede che i dati saranno conservati per 12 mesi dopo la cessazione del rapporto commerciale. I dati sono personali (relativi a persone fisiche), quindi soggetti a tutte le regole del GDPR.
I dati devono essere raccolti all’atto della stipula del contratto, corredato del consenso informato con tutte le specificazioni richieste dal GDPR. La firma del contratto è completata con la firma specifica del consenso informato. La copia di contratto e consenso informato firmata dal cliente è raccolta, scansionata e poi depositata in archivio cartaceo a parte, mantenuto sotto chiave.
Le copie dei contratti raccolti devono essere tenute in contenitori chiusi durante il trasporto verso i sistemi dove avviene la scansione, onde evitare che persone non autorizzate vedano i dati personali in essi scritti.
I dati vengono inseriti da persone autorizzate che ricevono la trasmissione della scansione. La copia della scansione ricevuta dagli addetti, ultimata l’operazione di inserimento, viene cancellata.
A questo punto occorre applicare tutti i principi ai dati: l’archivio dei dati, costruito ad hoc, deve applicare i principi di pseudonimizzazione e minimizzazione dei dati stessi. Il servizio IT e le sue componenti devono essere protetti da guasti accidentali e da attacchi informatici.
Occorre ora un’analisi del rischio, tesa a stabilire le conseguenze rispetto ai principi del GDPR di eventi infausti:
a. una eventuale corruzione o perdita dei dati impedirebbe la godibilità della garanzia e quindi la violazione degli accordi contrattuali, violando anche il GDPR,
b. un eventuale trafugamento di dati violerebbe la privacy dei clienti e costringerebbe l’azienda alla comunicazione esplicita a tutti i propri clienti ed al garante di quanto avvenuto, con la conseguente perdita di reputazione.
Con i risultati del punto precedente diventa necessario inserire tra i vari requisiti tutti quelli funzionali, non funzionali e di qualità tesi ad applicare una sicurezza adeguata. Potremo quindi prevedere:
a. Firewall a protezione dei sistemi che contengono i dati.
b. Crittografia applicata sulle connessioni di accesso ai sistemi.
c. Eventuale crittografia applicata entro il database per evitare che accessi non autorizzati ad esso possano portare a trafugamento o modifiche di dati.
d. Regole di accesso ferree per l’applicativo: gli addetti al trattamento dati possono vedere solo i dati specifici necessari per svolgere la loro funzione aziendale.
e. Controlli di qualità sul sistema con vulnerability assessment da realizzare periodicamente e processi di aggiornamento e gestione delle non conformità riscontrate.
f. Politiche di backup e ripristino opportune, tese a minimizzare la probabilità di perdita di dati e, allo stesso tempo, a migliorare i valori di RPO e RTO.
g. Politiche opportune di scelta e gestione delle password.
Infine, i ruoli di accesso dovranno essere distribuiti opportunamente rispetto alla privacy.
Per concludere:
L’esempio pratico appena esposto rende manifesto come – introducendo le buone pratiche di analisi del rischio, rispetto dei requisiti di sicurezza e privacy fin dall’inizio del progetto, ed applicandovi opportunamente le regole metodologiche e tecniche – si è in regola anche rispetto al GDPR, oltre a costruire servizi IT di trattamento dati di qualità e funzionamento migliore.
Tutto questo – concludiamo – ha un costo superiore rispetto alla disattesa di tali prassi? Sicuramente sì, ma è necessario considerare il rapporto costi/benefici non soltanto all’inizio, ma durante tutto il ciclo di vita del servizio IT.
NB: nel prossimo articolo tratteremo le conseguenze del GDPR sull’IT Service Management ossia sulla gestione dell’esercizio dei servizi IT. Stay tuned!
– Sitografia –
Il testo del GDPR in Italiano
Il portale EUROPRIVACY
Il portale del Garante Italiano della Privacy
