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, qui la seconda parte.

Scheda 8: gestire i profili utenti

Qui la scheda originale

La maniera di gestire i profili dei collaboratori e degli utenti finali va deciso a monte dello sviluppo. Consiste nel definire profili di accesso e autorizzazione differenziati, di modo tale che ognuno possa accedere solo ai dati di cui ha effettivamente bisogno. Il primo passo è, ovviamente, l'uso di un identificatore unico ed individuale sia per i collaboratori in fase di sviluppo dell'applicazione sia per gli utenti finali. La conseguenza? L'imposizione di un meccanismo di autenticazione prima dell'accesso a qualsiasi tipo di dato.

Inoltre, per garantire l'accesso solo ai dati strettamente necessari, il sistema deve prevedere policy differenziate di lettura, scrittura, cancellazione ecc.. secondo le esigenze. I profili sono così organizzati secondo il ruolo dell'utente. Il vantaggio ulteriore di tale meccanismo è che garantisce la possibilità, insieme ai sistemi di logging, di tracciare le attività e rilevare anomalie. Un modo che aiuta anche a individuare più facilmente accessi fraudolenti e utilizzo illegittimo dei dati.

E' utile prestare attenzione a:

• favorire l'uso di un password manager nel progetto e solidi meccanismi di autenticazione;
• evitare account generici condivisi da più persone;
• rivedere regolarmente le permissioni degli utenti;
• evitare di usare l'account amministratore / root per eseguire operazioni convenzionali.

Scheda 9: controlla le librerie e i SDK

Qui la scheda originale

Questa scheda è importante per coloro che utilizzano librerie, kit di sviluppo e altre componenti software scritte da terze parti. I consigli del garante francese sono: 

1. fai una scelta consapevole:

• è importante valutare attentamente il valore aggiunto da ciascuna dependency. Ogni elemento aggiunto infatti aumenta la superficie di attacco. In pratica: se una singola libreria offre più funzioni, scegli e integra solo quelle di cui c'è effettivamente bisogno. Si ridurrà così il numero di potenziali falle;
  
  

2. scegli software, librerie e SDK mantenute:

• in caso di scelta di software open o free source, sono preferibili quelli con una community attiva, aggiornati regolarmente e con una buona e esauriente documentazione tecnica;
• in caso di scelta di soluzioni commerciali invece, è importante stabilire fin dal contratto che il codice sarà mantenuto ed aggiornato per l'intera vita del progetto;
• alcune librerie e SDK "ripagano sé stesse" utilizzano i dat raccolti dai siti o app dove sono integrati. E' fondamentale verificare che ciò avvenga in conformità al GDPR, a partire dalla racolta del consenso degli utenti.
• in caso di uso della criptazione, il Garante francese sconsiglia fortemente di implementare autonomamente algoritmi o protocolli crittografici. E' consigliato invece scegliere librerie che siano mantenute, aggiornate e facilmente integrabili.
  
  

3. mantieni librerie e SDK:

• usa un sistema di gestione delle dependency (yum, apt, maven, pip ecc…) per mantenere aggiornato l'elenco delle dipendenze;
• gestisci gli aggiornamenti delle tue dependency, sopratutto in caso di fix di vulnerabilità a fini di sicurezza;
• presta attenzione ed evita le versioni di librerie e SDK prossimi all'end of life (EOL), quindi vicine alla fine del supporto;
• verifica lo stato dei progetti open source, specialmente in caso di cambio della proprietà del dominio o del pacchetto. Alcuni attacchi avvengono usando gli aggiornamenti di dependency molto popolari.

Scheda 10: assicura la qualità del codice e della documentazione

Qui la scheda originale

La documentazione relativa all'applicativo viene molto spesso tralasciata durante lo sviluppo, perchè manca sempre tempo. Tuttavia è fondamentale per la manutenzione dell'applicativo stesso. Tale documentazione infatti deve consentire di capire il funzionamento globale del codice e quale parti di questo sono soggette a modifica. Non basta però documentare il codice: la documentazione deve illustrare anche l'architettura dell'applicazione. Questo sarà di grande aiuto anche per gli sviluppatori per capire come le varie parti devono lavorare insieme. Ovviamente, se evolve il codice la documentazione deve andare di pari passo. Infine, la documentazione deve dettagliare la sicurezza. E' utile indicare varie posture di sicurezza per l'applicativo, indicando quelle che offrono maggiore protezione.

Adottare buone pratiche di programmazione è in questo caso molto utile. Il Garante francese consiglia questa guida su GitHub, che elenca le convenzioni esistenti. In ogni caso è utile:

• usare vriabili e nomi funzioni espliciti, per rendere più semplice comprendere il funzionamento fin da un primo sguardo al codice;
• usare correttamente l'indentazione, per rendere immediata la comprensione della struttura del codice;
• evitare la ridondanza del codice perchè, in caso di necessità di modifiche, queste andranno fatte da più parti;
• usare tool che possono aiutare a verificare la qualità del codice. Ad esempio un IDE (Integrated development environments), possibimente con uso di plugins, può essere configurato per rispettare le regole di indentazione del codice, le linee di separazione tra diverse porzioni del codice ecc…

La leggibilità del codice riduce lo sforzo per il mantentimento e la correzione di bug nel tempo.

Scheda 11: testare l'applicativo

Qui la scheda originale

L'ulteriore passo prevede di testare l'applicazione per verificare che svolga correttamente le operazioni, che garantisca una buona user experience e per individuare e risolvere problemi prima dell'utilizzo. Il Garante francese identifica 3 fasi di test:

• sviluppo, per la verifica del funzionamento dell'applicativo e la sua adeguatezza rispetto alle finalità richieste;
• sicurezza come il fuzzing o la scansione di vulnerabilità per verificare che il prodotto funzioni anche discostandosi dal suo normale utilizzo e per rintracciare e risolvere eventuali falle;
• test automatici: un sistema di integrazione continua per seguire test automaticamente permetterà di verificare la qualità ad ogni modifica del codice sorgente.

Una indicazione specifica: per i test il Garante francese consiglia l'uso di un database di dati fittizi simile a quelli reali. L'uso di dati personali reali comporterebbe infatti una violazione delle finalità del trattamento dei dati nonchè un aumento del loro rischio di esposizione. In caso sia necessario importare configurazioni esistenti dalla produzione ai casi di test, si consiglia di rendere anonimi i dati personali.

Nella prossima puntata della guida al GDPR per sviluppatori software tutto quanto riguarderà gli utenti dell'applicativo: informative, meccanismi di esercizio dei diritti degli interessati, il periodo di conservazione dei dati, l'uso di analytics ecc...