lunedì 14 febbraio 2022
di GDPRlab.it
Il Garante francese ha pubblicato la “Guida al GDPR per sviluppatori”: in 16 punti i principi del GDPR che questi devono rispettare nello sviluppo di applicazioni e software conformi alle previsioni di legge in fatto di privacy e protezione dati.
Introduzione alla programmazione “GDPR friendly”
Privacy by design e by default sono due principi cardine nella protezione dei dati personali per aziende e pubbliche amministrazioni. Questi due concetti sono opposti, negano l’idea, che si possa adattare a posteriori un software al GDPR. Il Garante francese ha pubblicato una lunga e articolata guida con tanti consigli pratici, best practices, strumenti per supportare gli sviluppatori nel programmare software e applicativi conformi al GDPR. In questa prima parte trattiamo il lavoro preparatorio allo sviluppo del software.
Scheda 0: per sviluppare in conformità al GDPR occorre pianificare in anticipo (non riadattare)
Non c’è niente di più sbagliato di pensare di poter adattare una applicazione al GDPR: un software va pensato perché possa trattare i dati in conformità. Per questo è utile individuare una persona che conosca i principi del GDPR e ne monitori la conformità. Questa persona è il DPO, se l’azienda ne ha uno. Il DPO ha le conoscenze necessarie per mappare e classificare i dati che l’applicazione dovrà trattare, come li elaborerà e la conformità di questi al GDPR.
Il registro dei trattamenti consente una visione complessiva e facilita l’individuazione dei rischi correlati secondo priorità: sarà un valido aiuto. Permette di individuare in anticipo azioni e meccanismi per ottemperare alle previsioni del GDPR, ma indica anche quali rischi sono da tenere in particolare considerazione. Diviene così un passo obbligato quello di valutare attentamente le basi legali che legittimano la raccolta e il trattamento dei dati processati dall’applicazione.
Infine il Garante francese sottolinea come la conformità vada garantità in tutte le fasi di sviluppo: anche le procedure interne devono garantire la protezione dei dati in tutti gli aspetti e in tutti gli eventi che potrebbero occorrere (da un breach alla semplice richiesta di accesso ai dati dell’Interessato).
Scheda 1: identificare i dati personali, anonimizzarli e pseudonimizzarli
Qui la scheda originale
Lo sviluppatore deve avere chiara la definizione di dati personali. Per il GDPR è un dato personale:
“qualsiasi informazione relativa a una persona fisica identificata o identificabile (ovvero l’interessato)”.
Qualsiasi operazione su questa tipologia di dati rientra nell’ambito di applicazione del GDPR: raccolta, registrazione, trasmissione, modifica, diffusione, trasferimento ecc… sono operazioni che devono essere conformi al GDPR. Il trattamento dati dovrà avvenire nella stretta osservazione del principio di minimizzazione: l’applicazione dovrà raccogliere e trattare solo e soltanto i dati necessari alla precisa finalità del software.
I dati personali raccolti dovranno essere mantenuti:
- in forma anonima, ovvero in maniera tale che sia impossibile individuare la persona alla quale quei dati appartengono;
- in forma pseudonimizzata, ovvero in una forma a metà strada tra la conservazione di un dataset di dati “grezzi” e un dataset di dati anonimi.
Questi dati vanno conservati in luoghi separati. I dati anonimi non dovranno essere riconducibili ad una persona, mentre la pseduonimizzazione è un processo reversibile.
Per approfondire > Dati anonimi e dati pseudonimizzati – L’apertura del Considerando 26 del GDPR
Scheda 2: prepara lo sviluppo del software
Siamo alle scelte metodologiche. Il primo punto è quello di adottare un approccio “privacy by design”: la protezione dei dati deve cioè essere il punto centrale del funzionamento del software e deve essere integrata per l’intero ciclo di vita della tecnologia. E’ un principio che deve essere incorporato fin dalla fase di progettazione. Sarà utile a stabilire quali impostazioni dovranno essere predefinite per l’utente, in massima tutela della privacy.
Infine condurre un Privacy Impact Assessment (PIA): qui la pagina tematica del Garante Italiano
Lo sviluppatore che mette al centro la protezione dei dati, svilupperà in conseguenza architettura e funzionalità, sceglierà tool e pratiche di sviluppo sicure: sono molteplici le liste di standard, le best practices e le guide alla programmazione che migliorano soprattutto la sicurezza. Ci sono anche vari tool che possono essere integrati nell’IDE (integrated develomement enviroments) per verifiche automatiche sulla conformità del codice al GDPR. Così come ci sono centinaia di “best practices” per i singoli linguaggi di programmazione: un esempio qui per C, C++ e Java.
Scheda 3: mettere in sicurezza l’ambiente di sviluppo
L’intero ambiente di sviluppo dovrà essere messo in sicurezza: qui sarà centralizzata una grande mole di dati. Server e workstation dovranno essere sicuri, protetti in modo omogeneo e riproducibile. Dovranno essere elencate in dettaglio le misure di sicurezza previste per server e postazioni di lavoro e la loro configurazione, così da avere certezza di una implementazione uniforme della sicurezza (dall’uso della VPN, all’implementazione del protocollo TLS sul server, passando per l’installazione e aggiornamento di firewall e antivirus ecc…)
Le misure di sicurezza dovranno tenere di conto e svilupparsi secondo la valutazione dei rischi: è utile anche definire un piano che migliori la copertura dei rischi, nominando anche un responsabile che si occupi della sua attuazione. Tra i rischi sono da considerare anche quelli derivanti dall’uso di software as a service e di strumenti di collaborazione cloud come GitHub, Slack, Trello ecc… Infine è fondamentale tenere traccia degli accessi e di tutte le operazioni.
Implementare la crittografia e documentare la gestione delle chiavi SSH è un altro punto essenziale di sicurezza.
Per approfondire > (Open)SSH secure use recommendations
Scheda 4: gestione del codice sorgente
Il garante francese consiglia anche l’adozione di un sistema di controllo versione per il software sviluppato: dovrà conservare le versioni del codice sorgente e tenere traccia e cronologia dei cambiamenti effettuati. Il sistema di controllo non dovrà invece conservare le credenziali, che vanno stoccate a parte per motivi di sicurezza.
Curiosità per approfondire > Cybersecurity e attacchi 0day: le minacce più insidiose non inserite nei contratti
CONDIVIDI QUESTA PAGINA!