Articolo Pubblicazioni

Privacy by design e by default: come applicare l’art. 25 del GDPR ai sistemi informativi

di · Pubblicato il 19 settembre 2017 - Aggiornato il 14 novembre 2026 · Tratto da «Privacy by design e by default»

Abstract

L’articolo riprende il seminario «Privacy by design e by default» del 19 settembre 2017. Spiega che cosa chiede l’art. 25 del GDPR, come impostare la valutazione dei rischi in fase di progettazione e come scegliere le impostazioni predefinite secondo i quattro criteri della quantità, della portata, della conservazione e dell’accessibilità dei dati. Presenta i report di progettazione come strumento di accountability e i modelli di sviluppo sicuro, da OpenSAMM al Security Development Lifecycle, con la modellazione delle minacce.

Vincenzo Calabrò | Privacy by design e by default: come applicare l’art. 25 del GDPR ai sistemi informativi
SCARICA LE SLIDE: «Privacy by design e by default» Calabrò V., 2017, PDF di 86 pagine
 

Protezione dei dati e sicurezza

La protezione dei dati viene spesso confusa con la sicurezza, ma ha un’estensione maggiore. Comprende la liceità del trattamento, la trasparenza, i diritti degli interessati e la limitazione dei dati, oltre alla loro protezione tecnica.
L’articolo 25 del GDPR chiede al titolare di mettere in atto misure tecniche e organizzative adeguate sia quando determina i mezzi del trattamento, cioè in fase di progettazione, sia durante il trattamento stesso. Le misure citate dall’articolo, come la pseudonimizzazione e la minimizzazione, sono lo standard minimo. Per scegliere le misure, e per giustificare l’eventuale esclusione di una di esse, si tiene conto dello stato dell’arte, dei costi, della natura, dell’ambito, del contesto e delle finalità del trattamento e dei rischi per i diritti e le libertà delle persone, con le loro diverse probabilità e gravità.

La valutazione dei rischi in progettazione

I rischi vanno valutati in modo oggettivo, per stabilire se il trattamento comporta un rischio o un rischio elevato, prendendo come riferimento i possibili impatti negativi su una persona concreta, come un cliente, un paziente o un utente web. Contano le operazioni che possono causare un danno fisico, materiale o immateriale. Le politiche interne dovrebbero garantire per impostazione predefinita:
  • la riduzione al minimo dei dati personali trattati;
  • la pseudonimizzazione il prima possibile;
  • un alto livello di trasparenza sulle funzioni e sul trattamento, perché l’interessato possa controllarlo;
  • il miglioramento continuo delle caratteristiche di sicurezza delle soluzioni.
Il GDPR impone la privacy by design ai titolari. Per i produttori di prodotti, servizi e applicazioni non esiste un obbligo diretto. Dovrebbero comunque aiutare i titolari a essere conformi progettando correttamente le impostazioni predefinite.

Le impostazioni predefinite

Le impostazioni che contano sono quelle attive al primo utilizzo, senza che l’utente faccia alcuna scelta. Determinano come un’applicazione o un dispositivo tratta i dati personali, per esempio l’accesso ai contatti, alla videocamera e al microfono o alla posizione. Le impostazioni predefinite servono a far funzionare il servizio senza sommergere l’utente di domande e a ridurre gli errori di chi non sa configurarlo. L’utente però deve sempre poterle modificare, come avviene con la password predefinita da cambiare al primo accesso.
Per ogni funzione configurabile lo sviluppatore decide se prevedere un valore predefinito e verifica che ogni valore rispetti l’articolo 25. Anche il titolare che usa la soluzione deve conoscerne le impostazioni e le possibilità di configurazione, in base al principio di responsabilizzazione. I criteri sono quattro:
  • quantità minima di dati. Meno dati personali si raccolgono, meglio è, anche con una raccolta granulare per sotto-finalità. La posizione, per esempio, serve al navigatore e va disattivata per le altre funzioni. Conta anche la qualità dei dati, evitando categorie particolari quando bastano dati comuni;
  • portata minima del trattamento. L’obiettivo è ridurre il rischio delle operazioni, senza necessariamente ridurne il numero, per esempio con pannelli che permettano di esercitare i diritti in modo semplice, con scelte di consenso e disattivazione dei cookie;
  • periodo di conservazione minimo. Il limite vale anche per copie e log, e scaduto il periodo i dati vanno cancellati o anonimizzati;
  • accessibilità controllata. L’accesso ai dati si limita in base alla necessità, controllando anche condivisioni, trasferimenti e pubblicazioni.

I report di progettazione come strumento di accountability

Spesso si perde traccia delle ragioni per cui un’organizzazione ha scelto una misura al posto di un’altra. Nei grandi progetti, dalle architetture software alle migrazioni in cloud, i report di solution design descrivono metodologia, prototipazione e messa in produzione. Il seminario proponeva di integrarli con le valutazioni normative, le analisi dei rischi, le valutazioni d’impatto (DPIA), le verifiche privacy prima dei rilasci e le raccomandazioni del responsabile della protezione dei dati, così da documentare la conformità delle scelte di progetto.

Lo sviluppo sicuro del software

La privacy by design si realizza dentro un ciclo di sviluppo sicuro. Il seminario presentava quattro riferimenti:
  • OpenSAMM, il modello di maturità sostenuto da OWASP, organizzato in quattro funzioni, governance, costruzione, verifica e distribuzione, ciascuna con tre pratiche su tre livelli di maturità;
  • BSIMM, che misura le pratiche reali di decine di iniziative di sicurezza del software in grandi aziende;
  • CLASP, un insieme di pratiche formalizzate donato a OWASP e oggi poco aggiornato;
  • Security Development Lifecycle di Microsoft, con sette fasi, cioè formazione, requisiti, progettazione, implementazione, verifica, rilascio e risposta.
In tutti la modellazione delle minacce sta nella fase di progettazione. Si definiscono ambito e vincoli, si elencano gli asset e i punti di ingresso e uscita, si disegnano i diagrammi di flusso dei dati e i livelli di fiducia, si classificano le minacce con un modello come STRIDE, si individuano le vulnerabilità e si valuta il rischio, per esempio con DREAD, per decidere le priorità. È lo stesso ragionamento che l’articolo 25 chiede per i dati personali, applicato fin dal primo disegno della soluzione.
 
 
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.
Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn