Il GDPR con gli occhi aperti

da https://www.linkedin.com/pulse/il-gdpr-con-gli-occhi-aperti-andrea-cristaldi/

A pochi giorni dall’entrata in vigore del Regolamento Europeo sulla protezione dei dati GDPR, mi sembra doveroso scrivere giusto un paio di righe a riguardo. Per mesi si è sentito parlare di GDPR, ma pochi ne conoscono veramente i contenuti e in pochissimi sanno cosa si nasconde tra le righe. Questo perchè a mio avviso si è dato troppo spazio alla parte giuridica e poco alla parte tecnico-informatica.

Le basi

A livello normativo è un Regolamento Europeo, un atto giuridico vincolante che tutti gli Stati membri UE devono applicare senza battere ciglio. Per questo non potrà esistere alcuna proroga, il 25 Maggio si parte (questo Venerdì, per essere chiari). L’obiettivo è quello di ridare il controllo dei dati personali ai diretti Interessati, dopo anni in cui i governi hanno letteralmente dormito consentendo a 4/5 player internazionali di impossessarsi di tutto. Adesso è un pò come cercare di chiudere il recinto dopo che i buoi migliori sono scappati, ma meglio tardi che mai. Il GDPR di per se non è nulla di complicato, sono 90 e passa articoli che chiunque con un pò di buona volontà può leggere. Sul modo in cui applicarlo invece, si possono scrivere trattati.

Cosa cambia per l’Interessato

L’interessato è maggiormente tutelato, sia direttamente che indirettamente. E’ tutelato direttamente dai maggiori diritti, tra cui la trasparenza richiesta nelle comunicazioni, i consensi specifici che non possono prevedere limitazioni in caso di mancata sottoscrizione, la riduzione al minimo possibile dei dati richiesti per ottenere un servizio, il diritto di accesso, di rettifica e cancellazione dei dati, il diritto di opporsi alla profilazione e di proporre reclamo al Garante. L’interessato può sempre tutelarsi autonomamente, facendo causa al titolare del trattamento, cosa molto importante perchè espone il Titolare del trattamento non solo al controllo e alle sanzioni dell’Autorità Garante, ma anche alla giustizia ordinaria. (Quindi, cari dirigenti delle PA, non dovreste pensare di essere al sicuro, per l’assunto che il Garante essendo PA non imporrà sanzioni ad un’altra PA, perchè l’interessato può agire direttamente e richiedere l’intervento del Garante che sarà obbligato a muoversi.) L’interessato viene anche protetto indirettamente da tutte quelle prassi che il Titolare del trattamento “dovrebbe” essere obbligato a redigere, e quindi a mettere nero su bianco assumendosi la responsabilità di quanto scritto. Ed è qui che è importante il GDPR: è lo strumento con cui si vuole assegnare le responsabilità all’interno di processi che, tra aziende ed enti diversi, sarebbe impossibile da standardizzare perchè eterogenei. L’interessato comunque può sempre complicarsi la vita, esattamente come faceva prima dell’entrata in vigore del GDPR: accettando ad occhi chiusi le clausole di contratti e gridando ai quattro venti i propri dati personali, infatti i dati resi pubblici dall’interessato potranno essere utilizzati da chiunque senza consenso. Postare su Facebook di trovarsi in Ospedale per un controllo o altro, non significa non avere nulla da nascondere. Significa non essere consapevoli delle innumerevoli modalità in cui pochi dati possono diventare molti e dei modi in cui possono essere utilizzati contro di noi.

 

Cosa cambia per Enti ed Aziende

Tutto. Considerando il modo in cui gli enti pubblici e le aziende da sempre gestiscono i dati personali e particolari (ex sensibili) degli utenti, cambia veramente tutto. Non sono quei pochi documenti obbligatori esplicitamente menzionati nel GDPR a fare la differenza, ma il modo in cui questi vengono redatti oltre a tutti i documenti di appoggio, ma non citati direttamente nel GDPR, necessari a dimostrare quanto dichiarato e quanto messo in atto per proteggere i dati degli interessati. Infatti, tra i principi fondamentali del GDPR troviamo l’Accountability, cioè l’onere per il Titolare del trattamento di dimostrare l’adozione, senza convenzionalismi, di tutte le misure tecniche e organizzative adeguate per garantire che il trattamento sia effettuato conformemente al Regolamento. Quindi bisogna dimostrare, carte alla mano. Prendiamo il DPIA, il documento di valutazione di impatto. Redigere un documento di questo tipo è abbastanza semplice, ma tutto quello messo nero su bianco deve corrispondere alle buone prassi e agli standard di sicurezza informatica, ma non solo, in vigore. Basta un software non licenziato ad esempio, o in end of life, o per cui non abbiamo pagato il supporto, a mettere oggettivamente a rischio i dati trattati perchè non potranno più essere installati gli update di sicurezza. Questo ovviamente non c’è scritto sul GDPR, ma a cosa pensate che possa servire dichiarare l’elenco dei software utilizzati per trattare i dati? Ed è solo uno dei tanti campi da riempire nel DPIA e una delle tante problematiche che ne possono scaturire.

Tra le righe del GDPR troviamo una serie di concetti chiave, noti agli esperti di sicurezza informatica, meno noti ai giuristi (ad ognuno il suo lavoro). Ad esempio:

Crittografia
Ovvero, come rendere illeggibili i dati a terze persone non interessate al trattamento. Si parla di valutare l’adozione di algoritmi e tecnologie che hanno scopi e utilizzi diversi tra loro, di VPN, HTTPS, PGP, certificati, sicurezza dei database, sicurezza delle reti, ecc.

Privacy by design e by default
Un approccio concettuale innovativo che impone alle aziende l’obbligo di avviare un progetto prevedendo, fin da subito, gli strumenti a tutela dei dati personali. Insomma, bisogna prevenire piuttosto che curare. l’Autorità di controllo Norvegese ha fornito una guida a tal proposito in cui si parla ad esempio, del processo di revisione di un software: sette attività a ciclo continuo che si basano su standard esistenti che i programmatori, quelli preparati, dovrebbero conoscere, ma che dovrebbero anche applicare. Si parla di formazione mirata, di test a cui sottoporre il software e le piattaforme, tutte cose che sul GDPR non trovate (esplicitamente). Ed il Privacy by design e by default non si limita al software…

Data Breach
Sono eventi quali la distruzione, la perdita, l’alterazione e la divulgazione non autorizzata o accesso ai dati personali avvenuti sia in maniera involontaria che illegale. Non si parla solo di hacker, non si parla solo di informatica. Sono eventi che non solo si devono evitare, ma che in alcuni casi fanno scattare l’obbligo di inviare una comunicazione di violazione al Garante e, nei casi più rilevanti, a tutti gli Interessati. In questa comunicazione si deve far presente il problema, i dati interessati alla violazione, il modo in cui si cerca di contenere il problema, come e quando agiremo per ripristinare il tutto. Questa comunicazione deve essere inviata entro 72 ore da quando abbiamo scoperto la violazione. Bene. Già per accorgersi della violazione bisogna avere delle competenze di un certo livello. Ricordando che la responsabilità ultima di tutto è sempre del Titolare del trattamento (che può demandare alcuni compiti, ma è sempre lui che rischia), scrivere una comunicazione di violazione in 72 ore senza avere pronto un piano di recupero standardizzato, un piano di policy che assegni compiti e responsabilità, non è cosa semplice, perchè significa mettere nero su bianco qualcosa che non è stato testato nella pratica e “misurato nelle parole”. Il limite tra inviare una comunicazione di violazione o una confessione firmata con il sangue è sottilissimo.

Misure tecniche e organizzative
“Il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio”. Per gli addetti informatici, parole come “misure tecniche e organizzative” suonano come Policy. Il GDPR ci chiede quindi di applicare Policy ai nostri flussi di lavoro. Come dimostrare questa applicazione, considerando che il GDPR impone l’onere della prova al Titolare? Bisognerebbe redigere un piano di policy, dei regolamenti interni di buone prassi e altri documenti in base ai flussi di lavoro aziendali. Ma di questi documenti sul GDPR non se ne trova traccia, se qualcuno conosce un altro modo per dimostrare l’applicazione di Policy me lo faccia sapere.

Triade CIA
“Assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento”. Gli esperti di sicurezza informatica troveranno in queste parole uno dei concetti di base della sicurezza informatica, ovvero la triade CIA (che nulla ha a che fare con la CIA americana). Come dimostrare di aver messo in atto delle misure tali da garantire questi requisiti, se non con un piano di controllo degli accessi, un piano sulla sicurezza IT, sui device BYOD, e un piano di manutenzione?

Disaster recovery
“Ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico”. Come dimostrare di aver messo in atto quanto richiesto senza un piano manutenzione preventiva e un piano di disaster recovery?

Testing
“Testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento”, anche qui gli esperti di sicurezza informatica leggeranno tra le righe: penetration testing, stress test per software e servizi, stress test per il personale (es. phishing).

Tutte queste carte dovranno descrivere quello che, anche tecnicamente, verrà messo in atto, e quindi qualche euro in attrezzature e licenze dovrà pur uscire.

In tutto questo c’è chi ancora è convinto che un’azienda o un ente possa applicare il GDPR con la tecnica del CTRL-c CTRL-v, ovvero copiando e incollando testi presi qua e la su internet, cambiando i riferimenti e le intestazioni o che possa dare l’incarico di consulenza a chi ha appena frequentato un corsetto di 3 ore per sentirsi DPO.

Buon GDPR a tutti.

Andrea Cristaldi

Unire i file multipli VDMK in un unico file

VMware ha un’utile funzione, quella di dividere un hd virtuale in tanti file più piccoli per consentire di spostarli e copiarli più facilmente. Mai avuto problemi, fino a qualche giorno fa, quando alcuni degli ultimi file in ordine cronologico non li ha più caricati, portando la macchina virtuale a non funzionare correttamente. Spero di aver risolto unendo i file in uno unico. Per farlo è possibile utilizzare un comando di Vmware:

vmware-vdiskmanager.exe –r "C:\percorso\file.vmdk" –t 0 singlolofile.vmdk