Privacy per informatici: qualche applicazione
A cura di Lisa Frassinelli
1. Approfondire la privacy con gli studenti di informatica
Nell’articolo introduttivo abbiamo sottolineato l’importanza di sensibilizzare verso la tematica privacy chi si occupa di Informatica, quindi, in ottica di orientamento, gli studenti di questa specializzazione tecnica. Abbiamo quindi introdotto i concetti di base del GDPR, accennato ad alcuni aspetti particolarmente importanti per gli informatici e svolto due attività pratiche “introduttive” per avvicinare gli studenti al tema della privacy facendo riferimento alla loro quotidianità.
In questo secondo articolo ci spingeremo un po’ più in là. Innanzitutto, approfondiremo il concetto di accountability, già introdotto, cercando di comprenderne meglio il significato e gli impatti che esso ha, per un’azienda, sul piano organizzativo e tecnico: in particolare, esamineremo le misure di sicurezza e i concetti di privacy by design e privacy by default. Dopodiché, su questi aspetti fondamentali della privacy a livello aziendale, presenteremo un Compito di realtà suddiviso in quattro attività pratiche da proporre in classe: seguiremo il filo conduttore dell’applicazione della privacy ai database, considerando che nel corso del quinto anno di specializzazione, questo argomento è affrontato nella disciplina di Informatica e spesso si ritrova anche nella seconda prova scritta di esame.
Come nel primo articolo, cercheremo inoltre di offrire degli spunti interdisciplinari che portino al coinvolgimento dei diversi docenti delle materie di indirizzo e, talvolta, anche di altre discipline. Infine, anche in questo caso, gli argomenti trattati si prestano a essere inseriti nell’ambito di Educazione Civica, ma anche a essere considerati come strumento per l’orientamento e di rafforzamento del legame con il mondo del lavoro.
In questo secondo articolo ci spingeremo un po’ più in là. Innanzitutto, approfondiremo il concetto di accountability, già introdotto, cercando di comprenderne meglio il significato e gli impatti che esso ha, per un’azienda, sul piano organizzativo e tecnico: in particolare, esamineremo le misure di sicurezza e i concetti di privacy by design e privacy by default. Dopodiché, su questi aspetti fondamentali della privacy a livello aziendale, presenteremo un Compito di realtà suddiviso in quattro attività pratiche da proporre in classe: seguiremo il filo conduttore dell’applicazione della privacy ai database, considerando che nel corso del quinto anno di specializzazione, questo argomento è affrontato nella disciplina di Informatica e spesso si ritrova anche nella seconda prova scritta di esame.
Come nel primo articolo, cercheremo inoltre di offrire degli spunti interdisciplinari che portino al coinvolgimento dei diversi docenti delle materie di indirizzo e, talvolta, anche di altre discipline. Infine, anche in questo caso, gli argomenti trattati si prestano a essere inseriti nell’ambito di Educazione Civica, ma anche a essere considerati come strumento per l’orientamento e di rafforzamento del legame con il mondo del lavoro.
2. Il principio di accountability e le sue applicazioni
Il principio di accountability, ossia “responsabilizzazione”, è uno dei concetti fondamentali del GDPR (al quale di seguito ci riferiremo anche col nome di Regolamento): introdotto proprio con questa normativa, ne permea tutta la struttura, responsabilizzando il titolare del trattamento. Richiede che le organizzazioni non solo rispettino il Regolamento (in particolare i principi e diritti dell’interessato, sui quali è costruita la normativa stessa), ma che siano anche in grado di dimostrare concretamente di aver adottato tutte le misure necessarie per garantire la protezione dei dati personali che trattano.
Nel GDPR il concetto di accountability emerge in molti punti, fra cui il seguente, in cui vengono specificate le responsabilità del titolare del trattamento:
“Tenuto conto della natura, dell'ambito di applicazione, del contesto e delle finalità del trattamento, nonché dei rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche, il titolare del trattamento mette in atto misure tecniche e organizzative adeguate per garantire, ed essere in grado di dimostrare, che il trattamento è effettuato conformemente al presente regolamento. Dette misure sono riesaminate e aggiornate qualora necessario. […]”
(art. 24 del GDPR).
È chiaro che il titolare ha la responsabilità di dimostrare la consapevolezza rispetto al recepimento del GDPR, cioè come materialmente lo cala all’interno del proprio contesto da un punto di vista documentale, procedurale e delle misure di sicurezza, con adeguato aggiornamento. La corretta applicazione dell’accountability porta ad affrontare la protezione dei dati personali con un approccio proattivo e sostanziale, indirizzando verso una vera e propria cultura della privacy che permea la realtà dell’organizzazione.
In definitiva, esaminando il testo del Regolamento, emergono gli elementi principali con cui si attua il principio di accountability, che si possono sintetizzare in:
Di seguito analizzeremo alcuni di questi elementi, tramite i quali il principio di accountability viene concretizzato, considerando che sul sito del Garante per la protezione dei dati personali sono disponibili spiegazioni dettagliate su tutti.
In ottica di interdisciplinarità, l’accountability si presta a diversi approfondimenti: per esempio, se ne potrebbe analizzare il significato in inglese o si potrebbe considerare come questo termine viene utilizzato nel project management tramite la matrice RACI (Responsible, Accountable, Consulted, Informed).
Nel GDPR il concetto di accountability emerge in molti punti, fra cui il seguente, in cui vengono specificate le responsabilità del titolare del trattamento:
“Tenuto conto della natura, dell'ambito di applicazione, del contesto e delle finalità del trattamento, nonché dei rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche, il titolare del trattamento mette in atto misure tecniche e organizzative adeguate per garantire, ed essere in grado di dimostrare, che il trattamento è effettuato conformemente al presente regolamento. Dette misure sono riesaminate e aggiornate qualora necessario. […]”
(art. 24 del GDPR).
È chiaro che il titolare ha la responsabilità di dimostrare la consapevolezza rispetto al recepimento del GDPR, cioè come materialmente lo cala all’interno del proprio contesto da un punto di vista documentale, procedurale e delle misure di sicurezza, con adeguato aggiornamento. La corretta applicazione dell’accountability porta ad affrontare la protezione dei dati personali con un approccio proattivo e sostanziale, indirizzando verso una vera e propria cultura della privacy che permea la realtà dell’organizzazione.
In definitiva, esaminando il testo del Regolamento, emergono gli elementi principali con cui si attua il principio di accountability, che si possono sintetizzare in:
- privacy by design e by default;
- registro dei trattamenti (accennato nell’articolo introduttivo);
- misure di sicurezza;
- notifica delle violazioni (i data breach visti nell’articolo introduttivo);
- analisi dei rischi e Valutazione d’impatto della protezione dei dati (DPIA, dall’inglese Data Protection Impact Assessment);
- nomina del Responsabile per la Protezione dei Dati (RPD o, in inglese, DPO – Data Protection Officer, uno dei ruoli visti nell’articolo introduttivo).
Di seguito analizzeremo alcuni di questi elementi, tramite i quali il principio di accountability viene concretizzato, considerando che sul sito del Garante per la protezione dei dati personali sono disponibili spiegazioni dettagliate su tutti.
In ottica di interdisciplinarità, l’accountability si presta a diversi approfondimenti: per esempio, se ne potrebbe analizzare il significato in inglese o si potrebbe considerare come questo termine viene utilizzato nel project management tramite la matrice RACI (Responsible, Accountable, Consulted, Informed).
3. Misure di sicurezza
Il GDPR tratta le misure di sicurezza in vari punti, evidenziando la necessità di adottare misure tecniche e organizzative adeguate e di dimostrare l'efficacia di tali misure in caso di verifica da parte dell'autorità di controllo. In particolare:
“Tenendo conto dello stato dell'arte e dei costi di attuazione, nonché della natura, dell'oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio, che comprendono, tra le altre, se del caso:
(art. 32 del GDPR).
Come si può notare, non sono indicate misure minime, come avveniva invece nella normativa italiana precedente, ma è richiesto un livello di sicurezza adeguato al rischio e al contesto, applicando in pieno il principio di accountability. Inoltre, nel Regolamento non si parla solo di misure tecniche, ma anche organizzative, legate cioè alla parte gestionale dell’azienda più che a quella tecnologica, cosa che riporta all’idea di una “cultura” della privacy, sempre in ottica di accountability.
Le misure di sicurezza sono trattate abitualmente in varie materie di indirizzo e questo apre a possibili spunti interdisciplinari sia per quanto riguarda gli aspetti tecnici, evidenti in materie come Informatica e Sistemi e Reti, sia per quelli organizzativi, con la gestione di processi e procedure, che si avvicinano all’ambito della disciplina Gestione Progetto e Organizzazione di Impresa.
Per questo, inoltre, si omette in questa sede di fornire ulteriori descrizioni delle misure di sicurezza, concentrandoci piuttosto sulla relazione fra queste e il concetto di accountability, come vedremo più avanti nel Compito di realtà.
“Tenendo conto dello stato dell'arte e dei costi di attuazione, nonché della natura, dell'oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio, che comprendono, tra le altre, se del caso:
- a) la pseudonimizzazione e la cifratura dei dati personali;
- b) la capacità di assicurare su base permanente la riservatezza, l'integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento; […]”
(art. 32 del GDPR).
Come si può notare, non sono indicate misure minime, come avveniva invece nella normativa italiana precedente, ma è richiesto un livello di sicurezza adeguato al rischio e al contesto, applicando in pieno il principio di accountability. Inoltre, nel Regolamento non si parla solo di misure tecniche, ma anche organizzative, legate cioè alla parte gestionale dell’azienda più che a quella tecnologica, cosa che riporta all’idea di una “cultura” della privacy, sempre in ottica di accountability.
Le misure di sicurezza sono trattate abitualmente in varie materie di indirizzo e questo apre a possibili spunti interdisciplinari sia per quanto riguarda gli aspetti tecnici, evidenti in materie come Informatica e Sistemi e Reti, sia per quelli organizzativi, con la gestione di processi e procedure, che si avvicinano all’ambito della disciplina Gestione Progetto e Organizzazione di Impresa.
Per questo, inoltre, si omette in questa sede di fornire ulteriori descrizioni delle misure di sicurezza, concentrandoci piuttosto sulla relazione fra queste e il concetto di accountability, come vedremo più avanti nel Compito di realtà.
4. Privacy by design e by default
I concetti di privacy by design (“protezione dei dati fin dalla progettazione”) e privacy by default (“protezione dei dati per impostazione predefinita”) sono stati introdotti con il GDPR. Risultano molto importanti nell’ottica di affrontare la protezione dei dati personali con un approccio proattivo e sono uno degli elementi principali con cui si applica l’accountability.
Entrando nello specifico, dal Regolamento si può evincere il significato dei due concetti, come segue.
Privacy by default
La privacy by default (chiamata anche data protection by default) richiede che le impostazioni predefinite di qualsiasi sistema debbano garantire il massimo livello di privacy per gli utenti, senza che questi debbano intervenire. In particolare, l’articolo 25 del GDPR afferma che il titolare del trattamento è tenuto a mettere in atto misure tecniche e organizzative adeguate per “[…] garantire che siano trattati, per impostazione predefinita, solo i dati personali necessari per ogni specifica finalità del trattamento […]”. Questo vale per la quantità di dati raccolti, l’estensione del trattamento, il periodo di conservazione e l’accessibilità dei dati (cioè chi può accedere a tali dati, quindi trattarli).
Privacy by design
La privacy by design (chiamata anche data protection by design) richiede che la tutela dei diritti dell’interessato sia prevista già a partire dalle prime fasi di ideazione e progettazione di un prodotto, servizio o processo e per l’intera gestione del ciclo di vita dei dati, attraverso adeguate misure tecniche e organizzative. In pratica, la privacy non deve essere un'aggiunta o una correzione a posteriori, ma deve essere integrata fino dalle fasi iniziali del progetto di qualsiasi sistema che tratti dati personali, sia nel caso di nuova implementazione, sia nel caso di modifica evolutiva di una esistente. Le modalità con cui si applica il concetto di privacy by design sono molteplici e riguardano tutti gli aspetti che impattano sul trattamento di dati personali, comprese le misure di sicurezza.
Si può osservare che i due concetti di privacy by design e by default sono in parte collegati fra loro: è possibile garantire la seconda, quindi la protezione dei dati personali per impostazione predefinita, se i sistemi con cui si trattano tali dati sono stati progettati in modo da consentirlo (“by design”).
Entrando nello specifico, dal Regolamento si può evincere il significato dei due concetti, come segue.
Privacy by default
La privacy by default (chiamata anche data protection by default) richiede che le impostazioni predefinite di qualsiasi sistema debbano garantire il massimo livello di privacy per gli utenti, senza che questi debbano intervenire. In particolare, l’articolo 25 del GDPR afferma che il titolare del trattamento è tenuto a mettere in atto misure tecniche e organizzative adeguate per “[…] garantire che siano trattati, per impostazione predefinita, solo i dati personali necessari per ogni specifica finalità del trattamento […]”. Questo vale per la quantità di dati raccolti, l’estensione del trattamento, il periodo di conservazione e l’accessibilità dei dati (cioè chi può accedere a tali dati, quindi trattarli).
Privacy by design
La privacy by design (chiamata anche data protection by design) richiede che la tutela dei diritti dell’interessato sia prevista già a partire dalle prime fasi di ideazione e progettazione di un prodotto, servizio o processo e per l’intera gestione del ciclo di vita dei dati, attraverso adeguate misure tecniche e organizzative. In pratica, la privacy non deve essere un'aggiunta o una correzione a posteriori, ma deve essere integrata fino dalle fasi iniziali del progetto di qualsiasi sistema che tratti dati personali, sia nel caso di nuova implementazione, sia nel caso di modifica evolutiva di una esistente. Le modalità con cui si applica il concetto di privacy by design sono molteplici e riguardano tutti gli aspetti che impattano sul trattamento di dati personali, comprese le misure di sicurezza.
Si può osservare che i due concetti di privacy by design e by default sono in parte collegati fra loro: è possibile garantire la seconda, quindi la protezione dei dati personali per impostazione predefinita, se i sistemi con cui si trattano tali dati sono stati progettati in modo da consentirlo (“by design”).
5. Compito di realtà: la privacy in un database
L’applicazione in informatica di quanto esposto è estremamente ampia e spazia dall’ambito sistemistico al networking, dalla cybersecurity al software e molto altro, con evidenti spunti di attività che si possono proporre in classe e forti rimandi a quanto normalmente viene affrontato in varie materie di indirizzo.
Cercando di evitare sovrapposizioni con quanto già svolto nelle discipline tecniche, ma mantenendo comunque un aggancio a queste, proponiamo una sorta di percorso nei database che consenta di mettere in pratica i quattro concetti che abbiamo affrontato in questo articolo: accountability, misure di sicurezza, privacy by design e privacy by default.
Lavoreremo su database MySQL, ma quanto proposto è facilmente riutilizzabile anche su altri DBMS. Per svolgere al meglio l’attività, è richiesto che gli studenti abbiano già acquisito conoscenze di SQL.
Il Compito di realtà che proponiamo è suddiviso in quattro attività, ciascuna delle quali rappresenta la specifica applicazione di uno dei quattro concetti da affrontare.
Per tutte le attività proposte, lavoreremo nel database db_privacy:
Di seguito riportiamo gli spunti di lavoro specifici per la quattro parti del Compito di realtà.
5.1 Accountability -> Pseudonimizzazione
Come applicazione del principio di accountability, lavoreremo su uno dei criteri che è spesso riportato in modo esplicito nel GDPR, la “«pseudonimizzazione»: il trattamento dei dati personali in modo tale che […] non possano più essere attribuiti a un interessato specifico senza l'utilizzo di informazioni aggiuntive, […] conservate separatamente e soggette a misure tecniche e organizzative intese a garantire che tali dati personali non siano attribuiti a una persona fisica identificata o identificabile;” (art. 4 del GDPR).
Progetteremo un semplice database per la gestione di clienti, ordini, prodotti e dettagli degli ordini. Faremo quindi un esempio di come si possa applicare la pseudonimizzazione ai dati personali dei clienti, verificando infine il risultato.
Di seguito, si riportano direttamente le istruzioni SQL per i vari step di svolgimento.
Creazione delle tabelle
Nella tabella clienti, l’attributo stato_cliente indica se il cliente è in uso (valore ‘U’) o pseudonimizzato (valore ‘P’).
Inserimento dei dati
Come si può notare, l’unica tabella che contiene effettivamente dati personali è clienti.
Estrazione dei dati
Il risultato di questa estrazione è riportato alla fine dell’attività per il confronto finale.
Pseudonimizzazione di un cliente
Dato che solo la tabella clienti contiene dati personali, aggiornando questa è possibile effettuare la pseudonimizzazione.
Nuova estrazione dei dati dopo la pseudonimizzazione (verifica finale)
Dopo la pseudonimizzazione si esegue nuovamente la query riportata sopra e si confrontano i risultati con la precedente esecuzione: ora è impossibile risalire al ‘vero’ cliente.
È bene fare presente che quello appena svolto è un esempio molto semplice. Nella realtà potrebbe non essere sufficiente ad avere la certezza che i dati personali non siano più individuabili: potrebbe esserci una qualche corrispondenza fra dati originali e pseudonimizzati mantenuta e che rende questo procedimento inutile! Insomma, nella realtà le operazioni sono molto più complesse di così.
5.2 Misure di sicurezza software -> Password protette con funzioni di hash
Per quanto riguarda le misure di sicurezza, considerando l’ambito database, proponiamo alcuni spunti per la protezione delle password con funzioni di hash, utili per la gestione del controllo degli accessi di utenti ad un’applicazione (individuando un algoritmo adeguato per la sicurezza necessaria nel caso specifico).
Si fa riferimento alla tabella utenti creata nel database db_privacy:
In questa tabella si possono fare prove di inserimento di dati verificando il funzionamento di diversi algoritmi di hash, per esempio:
Con una semplice estrazione di tutta la tabella (SELECT * FROM utenti;), si possono controllare le caratteristiche delle password cifrate con le tre diverse funzioni di hash.
Come si può notare, le password registrate hanno le lunghezze indicate per i tre algoritmi (rispettivamente 40, 32 e 64 cifre esadecimali) e risultano effettivamente ‘illeggibili’.
5.3 Privacy by Default -> Default in un database
Rimanendo nell’ambito database, proviamo ora a individuare alcuni semplici accorgimenti di progettazione, abitualmente utilizzati, che possono portare all’applicazione del criterio di privacy by default, secondo il quale chi tratta dati personali deve essere guidato nel farlo in modo corretto ai fini privacy.
Considerando per esempio un’applicazione web, si potrebbero evidenziare alcuni aspetti che delineano il “default”, ossia campi obbligatori o meno, campi preimpostati, eccetera. Per sviluppare questi punti è molto utile che il database su cui si appoggia l’applicazione sia strutturato in modo tale da facilitare questi aspetti.
In particolare, consideriamo la seguente porzione del database db_privacy:
Si hanno le tabelle titoli, che serve come archivio dei titoli di studio, e utenti_pbdef, nella quale si inseriscono i dati personali che saranno trattati attraverso una specifica applicazione.
Per quanto riguarda il criterio privacy by default, si può osservare che la tabella utenti_pbdef ha la chiave primaria auto-incrementante, ha alcuni campi obbligatori e altri opzionali (questo guida chi inserisce i dati ad aver chiari quali sono quelli che deve o che può inserire) ed è presente il vincolo di integrità referenziale per il titolo di studio, che di fatto risulta limitato nei possibili valori ammessi, riducendo così la possibilità di inserimento di dati errati.
In pratica, l’utente che gestisce i dati è così guidato nel farlo secondo i principi del GDPR, e ciò rappresenta un’applicazione del criterio di privacy by default.
5.4 Privacy by Design -> ruoli in un database
Il criterio privacy by design richiede che fino dalla fase di progettazione di un sistema si tenga conto degli aspetti privacy.
Nell’attività che proponiamo ci si potrebbe quindi concentrare sull’aspetto iniziale di un progetto che, trattandosi di un database, si realizzerebbe portando avanti le varie fasi dall’analisi fino ad arrivare un modello concettuale, tenendo conto anche di quanto viene studiato nel corso di Tecnologie e Progettazione di Sistemi Informatici e di Telecomunicazioni, oltre che a Informatica.
Considerando che quanto progettato deve poi effettivamente essere realizzato e cercando di rendere l’attività da proporre in classe quanto più possibile coinvolgente verso la tematica privacy, optiamo per un taglio più pratico, andando direttamente a lavorare sul database, tenendo presente però che l’attività completa dovrebbe partire, come detto, dalle prime fasi del progetto.
Proponiamo di lavorare sulle abilitazioni di utenti all’utilizzo di applicativi e relative funzionalità all’interno di un database, nel nostro caso db_privacy, che potrebbe essere utilizzato per le fasi di accesso ad applicazioni aziendali, tipo un ERP, opportunamente affinato con ulteriori specifici permessi.
Di seguito, si riportano direttamente le istruzioni SQL per i vari step di svolgimento.
Creazione di database e tabelle
In particolare:
Inserimento dei dati
Inseriamo alcuni dati per poter fare delle prove in modo da chiarire bene come si è strutturato il db e il risultato che si ottiene.
Estrazione dei dati e verifica conclusiva
Eseguendo la query, si ottiene il seguente risultato:
In conclusione, ogni utente può accedere esclusivamente alle applicazioni e funzionalità ammesse per il proprio ruolo: abbiamo progettato una struttura abilitativa in cui i trattamenti di dati personali sono consentiti solo a chi è autorizzato, cosa che peraltro si collega alle nomine specifiche previste dal GDPR.
Cercando di evitare sovrapposizioni con quanto già svolto nelle discipline tecniche, ma mantenendo comunque un aggancio a queste, proponiamo una sorta di percorso nei database che consenta di mettere in pratica i quattro concetti che abbiamo affrontato in questo articolo: accountability, misure di sicurezza, privacy by design e privacy by default.
Lavoreremo su database MySQL, ma quanto proposto è facilmente riutilizzabile anche su altri DBMS. Per svolgere al meglio l’attività, è richiesto che gli studenti abbiano già acquisito conoscenze di SQL.
Il Compito di realtà che proponiamo è suddiviso in quattro attività, ciascuna delle quali rappresenta la specifica applicazione di uno dei quattro concetti da affrontare.
Per tutte le attività proposte, lavoreremo nel database db_privacy:
CREATE DATABASE IF NOT EXISTS db_privacy;
USE db_privacy;
Di seguito riportiamo gli spunti di lavoro specifici per la quattro parti del Compito di realtà.
5.1 Accountability -> Pseudonimizzazione
Come applicazione del principio di accountability, lavoreremo su uno dei criteri che è spesso riportato in modo esplicito nel GDPR, la “«pseudonimizzazione»: il trattamento dei dati personali in modo tale che […] non possano più essere attribuiti a un interessato specifico senza l'utilizzo di informazioni aggiuntive, […] conservate separatamente e soggette a misure tecniche e organizzative intese a garantire che tali dati personali non siano attribuiti a una persona fisica identificata o identificabile;” (art. 4 del GDPR).
Progetteremo un semplice database per la gestione di clienti, ordini, prodotti e dettagli degli ordini. Faremo quindi un esempio di come si possa applicare la pseudonimizzazione ai dati personali dei clienti, verificando infine il risultato.
Di seguito, si riportano direttamente le istruzioni SQL per i vari step di svolgimento.
Creazione delle tabelle
CREATE TABLE clienti(
id_cliente INT AUTO_INCREMENT PRIMARY KEY,
cognome VARCHAR(50) NOT NULL,
nome VARCHAR(50) NOT NULL,
stato_cliente ENUM ('U', 'P') NOT NULL,
UNIQUE (cognome, nome));
CREATE TABLE ordini(
id_ordine INT AUTO_INCREMENT PRIMARY KEY,
id_cliente INT NOT NULL,
data_ordine DATE NOT NULL,
FOREIGN KEY (id_cliente) REFERENCES clienti (id_cliente));
CREATE TABLE prodotti(
id_prodotto INT AUTO_INCREMENT PRIMARY KEY,
descrizione VARCHAR(100) NOT NULL,
prezzo DECIMAL(6,2));
CREATE TABLE dettagli_ordine(
id_ordine INT NOT NULL,
id_prodotto INT NOT NULL,
quantita INT NOT NULL,
PRIMARY KEY (id_ordine, id_prodotto),
FOREIGN KEY (id_ordine) REFERENCES ordini (id_ordine),
FOREIGN KEY (id_prodotto) REFERENCES prodotti (id_prodotto));
Nella tabella clienti, l’attributo stato_cliente indica se il cliente è in uso (valore ‘U’) o pseudonimizzato (valore ‘P’).
Inserimento dei dati
INSERT INTO clienti VALUES
(NULL, 'Rossi', 'Mario', 'U'),
(NULL, 'Verdi', 'Luisa', 'U'),
(NULL, 'Bianchi', 'Carlo', 'U');
INSERT INTO ordini VALUES
(NULL, 1, '2025-01-30'),
(NULL, 3, '2025-03-02'),
(NULL, 1, '2025-04-30'),
(NULL, 2, '2025-06-12'),
(NULL, 2, '2025-07-20');
INSERT INTO prodotti VALUES
(NULL, 'Quaderno a righe', 2.10),
(NULL, 'Quaderno a quadretti', 2.10),
(NULL, 'Penna rossa', 1.50),
(NULL, 'Penna blu', 1.50),
(NULL, 'Evidenziatori', 5.30),
(NULL, 'Penna nera', 1.50),
(NULL, 'Pennarelli', 6.50);
INSERT INTO dettagli_ordine VALUES
(1, 1, 2), (1, 4, 1), (1, 6, 3), (4, 5, 1),
(2, 2, 4), (2, 7, 2), (3, 3, 3), (5, 1, 6);
Come si può notare, l’unica tabella che contiene effettivamente dati personali è clienti.
Estrazione dei dati
SELECT c.cognome as cognome, c.nome as nome, o.id_ordine as ordine,
o.data_ordine as data, p.descrizione as prodotto, p.prezzo as prezzo,
d.quantita as quantita, p.prezzo * d.quantita as totale
FROM clienti c, ordini o, dettagli_ordine d, prodotti p
WHERE c.id_cliente = o.id_cliente AND
d.id_ordine = o.id_ordine AND
d.id_prodotto = p.id_prodotto
ORDER BY 1, 2, 4;
Il risultato di questa estrazione è riportato alla fine dell’attività per il confronto finale.
Pseudonimizzazione di un cliente
UPDATE clienti
SET cognome = 'Duck', nome = 'Donald', stato_cliente = 'P'
WHERE id_cliente = 1;
Dato che solo la tabella clienti contiene dati personali, aggiornando questa è possibile effettuare la pseudonimizzazione.
Nuova estrazione dei dati dopo la pseudonimizzazione (verifica finale)
Dopo la pseudonimizzazione si esegue nuovamente la query riportata sopra e si confrontano i risultati con la precedente esecuzione: ora è impossibile risalire al ‘vero’ cliente.
È bene fare presente che quello appena svolto è un esempio molto semplice. Nella realtà potrebbe non essere sufficiente ad avere la certezza che i dati personali non siano più individuabili: potrebbe esserci una qualche corrispondenza fra dati originali e pseudonimizzati mantenuta e che rende questo procedimento inutile! Insomma, nella realtà le operazioni sono molto più complesse di così.
5.2 Misure di sicurezza software -> Password protette con funzioni di hash
Per quanto riguarda le misure di sicurezza, considerando l’ambito database, proponiamo alcuni spunti per la protezione delle password con funzioni di hash, utili per la gestione del controllo degli accessi di utenti ad un’applicazione (individuando un algoritmo adeguato per la sicurezza necessaria nel caso specifico).
Si fa riferimento alla tabella utenti creata nel database db_privacy:
CREATE TABLE utenti(
id_utente INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(30) NOT NULL,
pwd VARCHAR(255) NOT NULL);
In questa tabella si possono fare prove di inserimento di dati verificando il funzionamento di diversi algoritmi di hash, per esempio:
- SHA1 (Secure Hash Algorithm), che dà come risultato un codice esadecimale di 40 caratteri,
- MD5, che fornisce in output un codice esadecimale di 32 caratteri,
- SHA2, che si basa su un algoritmo più sicuro rispetto agli altri due e può essere utilizzato in diverse versioni. La funzione richiede in input due parametri: la stringa da cifrare e la lunghezza in bit del codice hash risultante: nel nostro caso indichiamo256, ottenendo una stringa di 64 caratteri esadecimali.
INSERT INTO utenti VALUES
(NULL, 'Marco', sha1('292mr9j!fJR'));
INSERT INTO utenti VALUES
(NULL, 'Anna', md5 ('NKJ45jkk*+i'));
INSERT INTO utenti VALUES
(NULL, 'Luigi', sha2 (('oiu19?34IhS'), 256));
Con una semplice estrazione di tutta la tabella (SELECT * FROM utenti;), si possono controllare le caratteristiche delle password cifrate con le tre diverse funzioni di hash.
Come si può notare, le password registrate hanno le lunghezze indicate per i tre algoritmi (rispettivamente 40, 32 e 64 cifre esadecimali) e risultano effettivamente ‘illeggibili’.
5.3 Privacy by Default -> Default in un database
Rimanendo nell’ambito database, proviamo ora a individuare alcuni semplici accorgimenti di progettazione, abitualmente utilizzati, che possono portare all’applicazione del criterio di privacy by default, secondo il quale chi tratta dati personali deve essere guidato nel farlo in modo corretto ai fini privacy.
Considerando per esempio un’applicazione web, si potrebbero evidenziare alcuni aspetti che delineano il “default”, ossia campi obbligatori o meno, campi preimpostati, eccetera. Per sviluppare questi punti è molto utile che il database su cui si appoggia l’applicazione sia strutturato in modo tale da facilitare questi aspetti.
In particolare, consideriamo la seguente porzione del database db_privacy:
CREATE TABLE titoli (
id_titolo INT PRIMARY KEY AUTO_INCREMENT,
descrizione VARCHAR(100) NOT NULL);
CREATE TABLE utenti_pbdef (
id_utente INT PRIMARY KEY AUTO_INCREMENT,
nome VARCHAR(50) NOT NULL,
cognome VARCHAR(50) NOT NULL,
sport VARCHAR(50),
titolo_studio INT,
UNIQUE (nome, cognome),
FOREIGN KEY (titolo_studio) REFERENCES titoli(id_titolo));
INSERT INTO titoli VALUES
(NULL, 'Licenza media'),
(NULL, 'Diploma superiore'),
(NULL, 'Laurea triennale'),
(NULL, 'Laurea magistrale'),
(NULL, 'Altro');
Si hanno le tabelle titoli, che serve come archivio dei titoli di studio, e utenti_pbdef, nella quale si inseriscono i dati personali che saranno trattati attraverso una specifica applicazione.
Per quanto riguarda il criterio privacy by default, si può osservare che la tabella utenti_pbdef ha la chiave primaria auto-incrementante, ha alcuni campi obbligatori e altri opzionali (questo guida chi inserisce i dati ad aver chiari quali sono quelli che deve o che può inserire) ed è presente il vincolo di integrità referenziale per il titolo di studio, che di fatto risulta limitato nei possibili valori ammessi, riducendo così la possibilità di inserimento di dati errati.
In pratica, l’utente che gestisce i dati è così guidato nel farlo secondo i principi del GDPR, e ciò rappresenta un’applicazione del criterio di privacy by default.
5.4 Privacy by Design -> ruoli in un database
Il criterio privacy by design richiede che fino dalla fase di progettazione di un sistema si tenga conto degli aspetti privacy.
Nell’attività che proponiamo ci si potrebbe quindi concentrare sull’aspetto iniziale di un progetto che, trattandosi di un database, si realizzerebbe portando avanti le varie fasi dall’analisi fino ad arrivare un modello concettuale, tenendo conto anche di quanto viene studiato nel corso di Tecnologie e Progettazione di Sistemi Informatici e di Telecomunicazioni, oltre che a Informatica.
Considerando che quanto progettato deve poi effettivamente essere realizzato e cercando di rendere l’attività da proporre in classe quanto più possibile coinvolgente verso la tematica privacy, optiamo per un taglio più pratico, andando direttamente a lavorare sul database, tenendo presente però che l’attività completa dovrebbe partire, come detto, dalle prime fasi del progetto.
Proponiamo di lavorare sulle abilitazioni di utenti all’utilizzo di applicativi e relative funzionalità all’interno di un database, nel nostro caso db_privacy, che potrebbe essere utilizzato per le fasi di accesso ad applicazioni aziendali, tipo un ERP, opportunamente affinato con ulteriori specifici permessi.
Di seguito, si riportano direttamente le istruzioni SQL per i vari step di svolgimento.
Creazione di database e tabelle
CREATE TABLE utenti_pbdes(
id_utente INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(30) NOT NULL,
pwd VARCHAR(255) NOT NULL);
CREATE TABLE ruoli(
id_ruolo INT AUTO_INCREMENT PRIMARY KEY,
descrizione VARCHAR(100) UNIQUE NOT NULL);
CREATE TABLE utenti_ruoli(
id_utente INT NOT NULL,
id_ruolo INT NOT NULL,
PRIMARY KEY (id_utente, id_ruolo),
FOREIGN KEY (id_utente) REFERENCES utenti_pbdes(id_utente),
FOREIGN KEY (id_ruolo) REFERENCES ruoli(id_ruolo));
CREATE TABLE applicazioni(
id_applicazione INT AUTO_INCREMENT PRIMARY KEY,
descrizione VARCHAR(100) NOT NULL);
CREATE TABLE funzioni(
id_funzione INT AUTO_INCREMENT PRIMARY KEY,
descrizione VARCHAR(100) NOT NULL,
applicazione INT NOT NULL,
FOREIGN KEY (applicazione) REFERENCES applicazioni(id_applicazione));
CREATE TABLE ruoli_funzioni(
id_ruolo INT NOT NULL,
id_funzione INT NOT NULL,
PRIMARY KEY (id_ruolo, id_funzione),
FOREIGN KEY (id_ruolo) REFERENCES ruoli(id_ruolo),
FOREIGN KEY (id_funzione) REFERENCES funzioni(id_funzione));
In particolare:
- utenti_pbdes: contiene gli utenti che sono registrati per accedere agli applicativi;
- ruoli: contiene i ruoli che sono poi associati da una parte agli utenti (tabella utenti_ruoli) e dall’altra alle funzionalità degli applicativi (tabella ruoli_funzioni); è uno degli elementi più importanti della struttura autorizzativa che andiamo a creare;
- utenti_ruoli: lega utenti e ruoli, come traduzione di un’associazione n:m;
- applicazioni: contiene l’elenco degli applicativi in esame;
- funzioni: contiene le funzionalità disponibili per ogni applicativo;
- ruoli_funzioni: è la tabella chiave che consente di associare ai ruoli le funzionalità disponibili, quindi, in pratica, tutti gli utenti associati ad uno specifico ruolo sono abilitati a lavorare su tutte le funzionalità che sono collegate a quel ruolo in questa tabella.
Inserimento dei dati
Inseriamo alcuni dati per poter fare delle prove in modo da chiarire bene come si è strutturato il db e il risultato che si ottiene.
INSERT INTO utenti_pbdes VALUES
(NULL, 'Pippo', 'pwdPippo'),
(NULL, 'Pluto', 'pwdPluto'),
(NULL, 'Minnie', 'pwdMinnie'),
(NULL, 'Topolino', 'pwdTopolino'),
(NULL, 'Paperino', 'pwdPaperino');
INSERT INTO ruoli VALUES
(NULL, 'Dipendente Ufficio Personale'),
(NULL, 'Dipendente Ufficio Acquisti'),
(NULL, 'Responsabile Ufficio Acquisti');
INSERT INTO utenti_ruoli VALUES
(1, 1), (2, 2), (3, 3), (4, 1), (5, 2);
INSERT INTO applicazioni VALUES
(NULL, 'Gestione del personale'),
(NULL, 'Gestione acquisti');
INSERT INTO funzioni VALUES
(NULL, 'Gestione anagrafico dipendenti', 1),
(NULL, 'Gestione stipendi', 1),
(NULL, 'Gestione presenze aziendali', 1),
(NULL, 'Gestione presenze ufficio', 1),
(NULL, 'Richiesta ferie personali', 1),
(NULL, 'Gestione anagrafico fornitori', 2),
(NULL, 'Gestione ordini', 2);
INSERT INTO ruoli_funzioni VALUES
(1, 1), (1, 2), (1, 3), (1, 5),
(2, 5), (2, 6), (2, 7), (3, 4),
(3, 5), (3, 6), (3, 7);
Estrazione dei dati e verifica conclusiva
SELECT u.username as utente, r.descrizione as ruolo,
a.descrizione as applicazione, f.descrizione as funzione
FROM utenti_pbdes u, ruoli r , utenti_ruoli ur, funzioni f,
ruoli_funzioni rf, applicazioni a
WHERE u.id_utente = ur.id_utente AND r.id_ruolo = ur.id_ruolo AND
r.id_ruolo = rf.id_ruolo AND f.id_funzione = rf.id_funzione AND
a.id_applicazione = f.applicazione
ORDER BY 1, 3, 4;
Eseguendo la query, si ottiene il seguente risultato:
In conclusione, ogni utente può accedere esclusivamente alle applicazioni e funzionalità ammesse per il proprio ruolo: abbiamo progettato una struttura abilitativa in cui i trattamenti di dati personali sono consentiti solo a chi è autorizzato, cosa che peraltro si collega alle nomine specifiche previste dal GDPR.
6. Conclusioni
In sintesi, l’accountability e le sue applicazioni fanno sì che la protezione dei dati venga vista non più solo come un obbligo burocratico, ma come un elemento imprescindibile nelle organizzazioni: se ne deve tenere conto in ogni aspetto, compresi quelli tecnici. In questo rientra l’applicazione dei criteri privacy by design e by default o la gestione di misure di sicurezza adeguate ai trattamenti che vengono effettuati, come abbiamo visto nelle attività del Compito di realtà proposto.
Considerata l’importanza di queste tematiche, è fondamentale che gli informatici, attuali e futuri, siano consapevoli e adeguatamente formati su questi aspetti e possano raggiungere un grado di competenza, consapevolezza e sensibilità adeguato a considerare con il giusto peso la protezione dei dati personali in ogni aspetto del loro lavoro.
Considerata l’importanza di queste tematiche, è fondamentale che gli informatici, attuali e futuri, siano consapevoli e adeguatamente formati su questi aspetti e possano raggiungere un grado di competenza, consapevolezza e sensibilità adeguato a considerare con il giusto peso la protezione dei dati personali in ogni aspetto del loro lavoro.
Strumenti e programmi utilizzati
Oracle MySQL
Softaculous AMPPS
Visual Studio Code
Softaculous AMPPS
Visual Studio Code
