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. Qui la prima parte.

Scheda 5: scegliere consapevolmente l’architettura

Qui la scheda originale

Al momento di pensare l’architettura del futuro applicativo, sarà fondamentale per prima cosa identificare quali dati personali saranno raccolti e, di conseguenza, stabilire il loro ciclo vitale e i meccanismi per gestirli. La scelta degli asset di supporto sarà fondamentale (server, servizi cloud, storage ecc…), assieme alla consapevolezza tecnica. Sarà fondamentale domandarsi come funzionerà il software, tracciando un diagramma che rappresenti il flusso dei dati e, in dettaglio, come si svolgeranno questi processi.

Un punto essenziale sarà domandarsi se i dati saranno stoccati nel terminale dell’utente o comunque rimarrano confinati alle comunicazioni di rete sotto controllo degli utenti, oppure se ci sarà bisogno di ricorrere ad hosting esterni.

Nel primo caso lo sviluppatore potrà limitarsi essenzialmente a garantire la massima sicurezza possibile dei dati. Se si decide invece di affidarsi a terzi, è bene tenere a mente due punti per orientarsi nella scelta:

• la qualità del servizio offerto dal provider;
• gli standard di sicurezza offerti;
  nella consapevolezza che il cloud genera ulteriori e peculiari rischi ai dati.

Scheda 6: mettere in sicurezza siti web, applicativi e server

Qui la scheda originale

Siti web, applicativi e server devono essere messi in sicurezza: non solo per quanto riguarda le comunicazioni di rete, ma anche l’intera infrastruttura. Con un’attenzione particolare al meccanismo di autenticazione.

1. Sicurezza delle comunicazioni di rete
   • Implementare la versione 1.2 o 1.3 su tutti i siti web sostituendo l’SSL;
   • rendere il TLS obbligatorio per tutte le pagine del sito web e per tutte le applicazioni mobile;
   • limitare le comunicazioni a quelle strettamente necessarie. Se l’accesso a un server è possibile solo tramite il protocollo HTTPS, solo le porte 443 e 80 di questo server dovranno essere accessibili. Sarà buona prassi di igiene informatica bloccare col firewall le altre porte.
     
     
2. Sicurezza delle autenticazioni

• scegliere password solidissime. Sul punto non ci dilunghiamo oltre;
• non salvare mai le passwor in chiaro. Le password devono essere mantenute in formato hash, sfruttando apposite librerie di criptazione;
• nel caso in cui sono usati cookie per l’autenticazione
• forzare all’uso del HTTPS via HSTS;
• usare il flag HttpOnly;
• usare il flag Secure;
• testare le suite di criptazione installate sui sistemi. Privilegiare l’uso di AES 256;
• adottare specifiche password policy per gli amministratori (password solide, da cambiare spesso ecc…)
• limitare l’accesso ai tool di amministrazione solo allo staff qualificato, privilegiando account con privilegi più bassi per le operazioni quotidiane;
• l’accesso da remoto all’interfaccia di amministrazione dovrebbe avvenire solo tramite misure di sicurezza maggiori.

3. Sicurezza dell’infrastruttura

• sono fondamentali i backup, possibilmente a cadenza regolare e criptati;
• installare gli aggiornamenti critici e monitorare costantemente le vulnerabilità;
• restringere o vietare gli accessi fisici e software alle porte di accesso diagnostico e di configurazione remota (consigliato l’uso di netstat)
• proteggere i database se si è obbligati a renderli disponibili in Internet e proteggerli contro attacchi SQL injection o script injection ecc…

Scheda 7: minimizzare la raccolta dati

Qui la scheda originale

La minimizzazione è uno dei principi essenziali del GDPR. I dati raccolti dovranno essere soltanto quelli rilevanti e necessari in relazione agli scopi che si prefigge il software.

Si deve quindi valutare la tipologia di dati che dovranno essere raccolti PRIMA di implementare l’applicazione. Ad esempio, se per certe categorie di persone non serve raccogliere uno specifico dato, semplicemente è meglio non raccoglierlo. Limitare i dati raccolti è fondamentale sopratutto in caso di informazioni estremamente sensibili, come dati sanitari o relativi alla fedina penale ecc… I vincoli legali sul punto sono così stringenti che, a meno che non sia necessario, è preferibile non raccoglierli. La minimizzazione vale anche per i dati raccolti nel log data.

Se proprio sono necessari dati sensibili, pseudonimizzazione e anonimizzazione possono ridurre rischi ed esposizione.

Spesso si può avere la tentazione di raccogliere dati aggiuntivi non necessari per gli scopi del sowftare, ma per migliorare l’esperienza dell’utente. Un esempio: usare dati di geolocalizzazione per indicazioni geografiche. In questi casi la scelta deve essere lasciata all’utente, che deciderà se prestare o rifiutare il consenso.

Infine: i dati non possono essere conservati senza scadenza. Quindi sono fondamentali meccanismi automatici che procedano ad eliminare completamente i dati che non sono più necessari. Per farlo esistono si possono usare sia tool specializzati che procedere alla distruzione fisica del disco.

Qui la prima parte > Garante francese: guida al GDPR per sviluppatori software (parte 2)

ALLA PROSSIMA PUNTATA !