Dall’entrata in vigore del GDPR, concetti come privacy by design e by default hanno assunto un ruolo centrale nell’implementazione della protezione dei dati personali nelle aziende e nelle amministrazioni, imponendo un approccio circolare sul tema, che si curi degli aspetti privacy fin dalla progettazione iniziale.
In questo contesto l’idea di dover “adattare” un software affinché tratti i dati in conformità con il GDPR è già un fallimento.
Gli sviluppatori dovrebbero infatti proporre soluzioni che non trattano più dati di quanto necessario e legittimo, mentre le aziende, dal canto loro, dovrebbero premiare unicamente quei software che rispettano la normativa in tema di protezione dei dati personali.
Per far chiarezza, la CNIL (Commission Nationale de l’Informatique et des Libertés) ha emanato delle linee guida per aiutare gli sviluppatori a creare soluzioni software che siano in linea con i principi del GDPR.
Indice degli argomenti
GDPR per sviluppatori: l’obiettivo della CNIL
Un esempio di soluzione software che non è progettata secondo i principi di privacy by design e default è Google Analytics. Il servizio di web analytics di Google ha dovuto infatti correre ai ripari quando la normativa GDPR è entrata in vigore, rendendo disponibile agli utenti un tool (la funzionalità ga(‘set’, ‘anonymizeIp’, true) nella libreria analytics.js) per anonimizzare gli IP, che altrimenti venivano raccolti di default dal sistema e analizzati per fornire un’analisi più dettagliata del traffico sul sito web.
L’obiettivo del GDPR è che in futuro non siano necessari simili “escamotage” per evitare un trattamento di dati nemmeno utili per la stragrande maggioranza degli utenti, spingendo gli sviluppatori a programmare soluzioni in linea con la normativa in tema di protezione dei dati personali nella maggioranza dei casi d’uso, e rendendo invece necessaria l’attivazione esplicita di funzionalità ulteriori nel caso di trattamenti dati più incisivi.
La guida, che è disponibile a questo link (in lingua inglese), si apre quindi con una serie di suggerimenti di carattere generale per poi dettagliare utili consigli operativi.
Va segnalato che della guida è stata approntata una traduzione in italiano, disponibile su GitHub a questo link, anche se la traduzione contiene ancora diverse imprecisioni.
GDPR per sviluppatori: l’attività di pianificazione
Nel momento in cui si decide di sviluppare un software è importante innanzitutto verificare se attraverso di esso potrebbero essere trattati dati personali e a chi questi dati verranno comunicati e come.
Affrontare a ritroso questo problema (ovvero individuare i trattamenti di dati una volta che il software è stato oramai sviluppato) può infatti rivelarsi complesso, inefficiente e incompleto (essendo possibile che ad un soggetto che interviene a monte sfuggano alcuni processi interni che però possono costituire un trattamento di dati “nascosto” ad occhio esterno).
La guida della CNIL suggerisce quindi di soffermarsi innanzitutto su una mappatura del trattamento dati.
Per fare questo è però necessario che lo sviluppatore (o chi lo supporta) abbia a mente i principi base della normativa privacy europea (e non solo, a seconda dei mercati di destinazione del prodotto). Prerequisito essenziale per sviluppare software nel 2020 è quindi un’infarinatura generale in tema di diritto della protezione dei dati personali.
Comprendere i concetti chiave di questa disciplina sarà utilissimo per evitare, durante la fase di sviluppo, problemi che potrebbero arrivare a condizionare la commerciabilità del prodotto finale.
Con queste conoscenze sarà quindi possibile mappare il trattamento dei dati e individuare le categorie di dati che la soluzione software andrà a trattare.
Utile strumento di supporto, in questo frangente, può essere il registro dei trattamenti, strumento nel quale, tra le altre cose, vanno registrate le categorie di dati trattati, le finalità del trattamento, nonché le categorie dei destinatari e degli interessati, indicando anche se i dati verranno trasferiti in paesi terzi.
Sebbene il suggerimento della CNIL si limiti ad un generico richiamo al registro dei trattamenti, è evidente che nel caso di software venduto a terzi professionisti (che a loro volta diverranno titolari del trattamento nel servirsene) l’utilità di creare, oltre al registro dei trattamenti dell’azienda (che guarderà quindi ai dati trattati dall’azienda dello sviluppatore) un vero e proprio registro ad hoc per il programma o applicazione realizzato dallo sviluppatore, immedesimandosi nell’utente professionale del software, così da valutare (nei vari possibili scenari di utilizzo) i rischi privacy connessi ed eventualmente così da supportare l’utente nel momento in cui questi adotterà il software sviluppato.
La necessità di una DPIA
Nel caso in cui ci si renda conto che la soluzione sviluppata potrebbe presentare “un rischio elevato per i diritti e le libertà delle persone fisiche” coinvolte (ad esempio quando l’applicativo potrebbe trattare dati appartenenti a categorie particolari, o quando potrebbe coinvolgere minori, in particolare quando i loro dati potrebbero essere diffusi, ad esempio all’interno di una piattaforma social) è necessario fare un’ulteriore step e orientarsi verso una valutazione d’impatto, che può essere condotta internamente (ad esempio seguendo le linee guida del Garante Privacy, che peraltro consigliano l’utilizzo di un pratico software realizzato sempre dal CNIL) o avvalendosi di consulenti esterni e che sarà utile per seguire con la dovuta attenzione gli aspetti privacy durante le fasi di sviluppo.
L’ultimo suggerimento di apertura della CNIL è quello di documentare tutti questi processi, al fine di poter dimostrare, un domani, il processo di compliance.
GDPR per sviluppatori: le scelte di sviluppo
La guida del Garante francese consiglia quindi di introdurre i profili privacy sin dalla fase iniziale del progetto di sviluppo di un software.
Questi profili avranno un peso in numerose scelte di sviluppo (es. scegliere un sistema centralizzato o decentralizzato, o scegliere un linguaggio di programmazione più veloce o invece uno orientato alla sicurezza o più consolidato e solido) e imporranno alcuni accorgimenti (es. In tema di sicurezza delle credenziali). In generale la CNIL suggerisce di non affidarsi ad una sola linea di difesa, progettando soluzioni che garantiscano una protezione profonda e completa del sistema.
Il Garante francese fa l’esempio del controllo dei dati inseriti in un modulo online, che va integrato, per maggior sicurezza, con sistemi di protezione delle query del database, così da evitare attacchi di tipo SQL Injection.
La CNIL suggerisce inoltre di integrare nel proprio IDE (Integrated Development Environment) con tool che verifichino la conformità del codice a standard di settore in tema di sicurezza (es. quelli pubblicati dalla fondazione OWASP).
I dati personali nel software
Quindi la guida ricorda che incontrare dati personali nello sviluppo di un software è più frequente di quanto si possa pensare, sono infatti dati personali anche l’indirizzo IP, l’ID del dispositivo dell’utente e il cookie ID. E non è solo l’acquisizione diretta di questi elementi che costituisce un trattamento di dati personali, ma anche la semplice possibilità, incrociando più dati, di risalire a un dato personale comporta un trattamento rilevante ai fini della normativa privacy.
La CNIL, sul punto, si sofferma quindi sui processi di pseudonimizzazione e anonimizzazione dei dati, procedimenti che possono alleggerire il trattamento posto in essere da un software.
Mentre l’anonimizzazione del dato personale è un processo che rende impossibile individuare il soggetto (si tratta quindi di un processo irreversibile), la pseudonimizzazione è invece un procedimento reversibile, che si occupa unicamente di “sostituire” il dato personale con un dato non personale (es. non individuo più l’utente con il proprio nome e cognome ma unicamente con un identificativo numerico).
Secondo quanto appena detto, mentre l’anonimizzazione genera dati non personali (e quindi esclusi dall’applicazione della disciplina privacy), la pseudonimizzazione genera comunque dati personali (perché è possibile ottenere nuovamente i dati incrociando il dato pseudonimo con la chiave che riconduce al dato personale originale).
È quindi essenziale che la chiave che consente di riottenere il dato personale dal dato pseudonimo sia tenuta separata dal dato pseudonimo e sia protetta con misure tecniche adeguate.
Attenzione, però: la CNIL raccomanda in ogni caso di non considerare mai anonimi i database “grezzi” (non elaborati).
L’anonimizzazione è sempre il risultato di un processo che rende irreversibilmente non identificabile un soggetto e che deve consentire di evitare l’individuazione (possibilità di isolare alcuni o tutti i dati che identificano una persona nel dataset), la correlabilità (possibilità di correlare fra loro almeno due dati nel dataset relativi alla medesima persona o gruppo di persone), e la deduzione (possibilità di desumere, con elevato grado di probabilità, il valore di un attributo dai valori di un insieme di attributi).
Non si può quindi presupporre, senza dar corso a questo processo, che un database sia in partenza anonimo.
Mettere in sicurezza l’ambiente di sviluppo
La guida della CNIL affronta a questo punto il tema, centrale, della sicurezza dei server e delle stazioni di lavoro, riprendendo una serie di suggerimenti di base sul tema (come ad esempio installare ed aggiornare firewall e antivirus, evitare l’utilizzo di periferiche esterne come chiavette USB per quanto possibile, evitare di utilizzare Wi-Fi con crittografia WEP, accedere da remoto unicamente tramite VPN, implementare il protocollo TLS sul server ecc.) per poi dettagliare alcune interessanti considerazioni.
Il Garante si sofferma infatti sulla necessità di analizzare i rischi, specie nel caso in cui, per comodità e semplicità di gestione, si faccia affidamento a cloud services collaborativi (es. Trello, Slack ecc.) e di documentare le scelte fatte e le misure di sicurezza adottate, anche attraverso strumenti di automatizzazione delle procedure come Ansible, Puppet o Chef.
La CNIL consiglia poi di monitorare con costanza le vulnerabilità che tempo per tempo emergono nel settore, riferendosi ad esempio al NVD (National Vulnerability Database) Data Feeds statunitense.
Sarà poi importante che dei dati sul server siano fatti backup (possibilmente crittografati) e che l’accesso al server venga controllato, sia per quanto riguarda l’accesso fisico, che per quanto riguarda l’accesso eventualmente consentito via web (ad esempio filtrando gli IP a cui è consentito accesso).
La CNIL chiude questo paragrafo con una raccomandazione (davvero essenziale) in tema di tracciabilità.
Deve essere possibile individuare chi ha avuto accesso all’ambiente di sviluppo, utilizzando strumenti e tecnologie che garantiscano da un lato la sicurezza delle credenziali, documentando la gestione delle chiavi SSH (Secure Shell), e dall’altro la possibilità di individuare il soggetto che ha operato sul server (la sanzione comminata dal Garante privacy in relazione alla piattaforma Rousseau, infatti, si basava, tra le altre cose, sulla “condivisione” delle credenziali di amministrazione da parte di più soggetti, rendendo così impossibile risalire, a ritroso, a chi aveva posto in essere determinate operazioni) evitando di utilizzare account “generici” e conservando i log di accesso (anche con strumenti automatici di analisi).
Il Garante privacy italiano, sul punto, ha più volte esplicitato la necessità di conservare i dati di log per almeno sei mesi.
La CNIL consiglia poi di adottare per il software sviluppato un sistema di controllo versione, così da conservare tutte le varie versioni del codice sorgente (senza però le credenziali, che andranno conservate a parte) e da annotare una cronologia dei cambiamenti via via intervenuti.
In tale sistema potranno essere versate anche le opportune metriche per il controllo della qualità del codice.
Attenzione, infine, a pubblicare il codice online: sebbene questo sia un ottimo metodo di diffusione della conoscenza, non si tratta di un passo da fare a cuor leggero e necessita di una verifica preliminare per assicurarsi che non siano presenti dati personali o credenziali nel codice o nei commenti.
Quindi la CNIL suggerisce di creare livelli differenziati di accesso al software (a cui corrispondano determinati permessi) basati su strumenti di autenticazione forti e di effettuare regolari backup del codice sorgente.
L’architettura del software
Altro momento cruciale è quello della scelta degli asset a supporto del progetto. La decisione su quali servizi cloud utilizzare, o sul server (o dispositivo) dove memorizzare i dati può avere un rilevante impatto sugli aspetti privacy, semplificando o complicando, a seconda delle decisioni, la compliance privacy del software.
Nel caso in cui il software o l’applicazione gestiscano i dati a livello centralizzato e su software di terze parti, sarà importante individuare un partner affidabile e che dia garanzie (e se possibile certificazioni) in tema di sicurezza dei dati, sarà anche importante verificare in quale luogo fisico sia situato il server, se in Unione Europea o al di fuori, circostanza di importanza ancora maggiore in questo momento di incertezza sulle condizioni per il legittimo trasferimento di dati al di fuori dell’Unione (oltre ad un contratto fondato su clausole standard, sarà importante adottare misure tecnologiche di protezione, quali crittografia o pseudonimizzazione, nel caso in cui ci si voglia affidare ad un partner oltreoceano).
Nel caso in cui si utilizzino librerie o SDK (software development kits), sarà altresì importante scegliere progetti aggiornati di frequente e con una community attiva, evitando però progetti che si mantengono utilizzando i dati ricavati dai siti o applicazioni in cui sono integrati.
Andranno poi mappate le dipendenze, per conoscere e verificare tali strumenti (prestando attenzione a possibili rischi come typosquatting e altri tipi di attacchi) e utilizzato un dependency management systems (come yum, apt, maven, pip ecc.).
Proteggere i siti web
Il primo suggerimento della CNIL per i siti web è quello di implementare i protocolli TLS nelle versioni 1.2 o 1.3, ad esempio facendo riferimento al progetto Letsencript, creato da una Certification Authority non profit, la Internet Security Research Group (ISRG).
Il secondo consiglio è quello di limitare le porte di comunicazione a quanto strettamente necessario per il corretto funzionamento del sito.
Se l’accesso a un server web è possibile solo utilizzando il protocollo HTTPS, devono essere accessibili solo le porte 443 e 80 di questo server, mentre tutte le altre porte possono essere bloccate dal firewall.
Le password
La CNIL suggerisce innanzitutto di non memorizzare mai le password in chiaro, ma di conservarle come hash utilizzando una libreria collaudata, come ad esempio bcrypt (le conseguenze nefaste della mancata implementazione di una simile procedura si sono viste ad esempio nell’attacco hacker che ha colpito le PEC degli avvocati romani, a quanto pare compromesse proprio perché gli hacker sono entrati in possesso di un elenco delle password di default in chiaro).
Nel caso di autenticazione tramite cookie, la CNIL consiglia di:
- forzare l’uso di HTTPS tramite HSTS;
- utilizzare il secure flag (che consente la trasmissione del cookie solo su connessione https);
- utilizzare il flag HttpOnly (un flag addizionale che impedisce l’accesso “client side” ai cookie).
Infine, la guida consiglia di testare le suite crittografiche installate sui sistemi, disabilitando quelle obsolete (RC4, MD4, MD5 ecc.) e comunque incoraggiando l’uso dello standard AES256.
GDPR per sviluppatori: la minimizzazione dei dati
Compiute le scelte di architettura, messo in sicurezza il sistema, e individuati i flussi di dati, è il momento di evitare trattamenti di dati superflui, nel rispetto del principio di data minimisation contenuto nel GDPR.
La minimizzazione deve riguardare anche i dati di log. Chiaramente il processo di minimizzazione deve avere massimo rilievo nel caso in cui il software o l’applicazione possano trattare dati personali appartenenti a categorie particolari.
È inoltre opportuno prevedere sistemi per la cancellazione automatica dei dati obsoleti (ovvero per la loro anonimizzazione automatica), così da alleggerire il procedimento di compliance e di non rischiare di effettuare trattamenti di dati illegittimi perché troppo prolungati nel tempo.
Sarà importante, a questo punto, anche acquisire una prova dell’avvenuta cancellazione, così da poter dimostrare la compliance rispetto alla disciplina privacy.
L’informativa
Una volta sviluppato il software e minimizzato il trattamento dei dati, è venuto il momento di pensare a come informare i clienti riguardo alla loro privacy e a quello che farà il software con i loro dati o quelli dei loro clienti. L’informativa, che deve contenere gli elementi di cui agli artt. 13 o 14 del GDPR, deve essere facilmente disponibile per l’utente ed essere chiara e completa.
Nel caso in cui il trattamento sia basato sul consenso dell’interessato (es. per comunicazioni marketing), sarà importante acquisire il consenso (es. tramite flag) in un modo che consenta di documentare, in seguito, il consenso prestato. La prova del consenso andrà conservata per tutto il periodo in cui verrà conservato il dato.
A questo punto non resta, per lo sviluppatore, che preparare la propria struttura per reagire alle eventuali istanze in forza della normativa privacy da parte degli interessati (che inoltreranno tali istanze con le modalità indicate nell’informativa).
In questo senso è utile predisporre metodi e procedure che consentano con pochi clic di adempiere a possibili istanze a tema privacy, ad esempio prevedendo sistemi che consentano l’eliminazione integrale dei dati di un utente, o la loro agevole modifica, o ancora la possibilità di “mettere in quarantena” i dati trattati in caso di istanza tesa alla limitazione del trattamento.
Altro tema importante è la portabilità dei dati; per soddisfare tale requisito è utile predisporre il software di modo che i dati possano essere comodamente estratti in un formato strutturato, comune e interoperabile, come ad esempio CSV, XML, JSON o altri.
La cancellazione dei dati
Come anticipato la CNIL suggerisce la predisposizione di strumenti che diano corso alla cancellazione automatica dei dati una volta spirato il periodo di conservazione degli stessi (anch’esso indicato nell’informativa).
La guida suggerisce, poi, che l’archiviazione del dato (fase intermedia che precede la cancellazione definitiva del dato personale) sia accompagnata da modalità di accesso differenti rispetto a quelle previste per il dato presente sul database attivo.
Conclusione
La guida della CNIL è un interessante strumento di supporto per gli sviluppatori che intendono fare della compliance privacy un punto di forza del proprio software.
Questo è importante sia per la tutela diretta degli sviluppatori, al fine di effettuare un trattamento legittimo, sia per sviluppare un mercato in cui i prodotti software utilizzati da clienti business si presentino, di default, in compliance con il trattamento che tali clienti intendono effettuare.
In questo senso l’esperimento della CNIL è particolarmente interessante anche per la sua natura collaborativa, infatti è possibile, per chi fosse interessato, contribuire a sviluppare e ampliare i temi della guida della CNIL direttamente via GitHub a questo link. (versione inglese) o a questo link (versione italiana).
Non resta che augurarsi che a questo tema, finora poco esplorato, venga ora dedicata la giusta attenzione, viste le particolarità che caratterizzano il processo di sviluppo di un software e il fitto intrecciarsi di ogni piccola parte di questo processo con aspetti relativi alla protezione dei dati personali.
