Il presente è il primo di una serie di cinque articoli che saranno pubblicati nelle prossime settimane.

Sommario

Dopo aver introdotto gli elementi indispensabili per comprendere quale sia lo scopo della valutazione d’impatto sulla protezione dei dati, come prospettata dalla normativa vigente nell’ambito della privacy, viene presentata una Guida utile per poter svolgere in modo strutturato la DPIA (Data Protection Impact Assessment).

Nella Guida si dettagliano in modo puntuale le varie fasi necessarie per arrivare a una valutazione ragionata e specifica del rischio dei processi legati al trattamento di dati personali. La Guida proposta può risultare utilmente applicata nelle strutture della Pubblica Amministrazione centrale e locale che, spesso, svolgono con personale proprio le azioni di analisi dei processi e di valutazione dell’impatto.
Viene anche proposto un metodo speditivo semplificato per la quantificazione del rischio del processo analizzato. A completamento dell’analisi vengono fornite delle schede operative di riferimento per svolgere in modo guidato e, al contempo, adeguatamente rigoroso tutte le fasi della valutazione d’impatto sulla protezione dei dati.

1. La finalità della Guida sulla DPIA

1.1. Finalità

Questo articolo si propone di fornire una Guida ai Titolari di trattamenti di dati personali e ai loro collaboratori, al fine di svolgere la valutazione d’impatto sulla protezione dei dati (Data Protection Impact Assessment = DPIA) richiesta dal Regolamento UE 679/2016 (GDPR).

Nel seguito del lavoro indicheremo con la sola parola Regolamento il riferimento al Regolamento UE 679/2016 (GDPR) e utilizzeremo Art.x per indicare l’articolo x di tale Regolamento.

La DPIA costituisce il momento più complesso nel ciclo di protezione dei dati personali perché, proprio con la DPIA, si valutano i rischi che possono essere indotti da un cattivo o non sufficientemente protetto trattamento dei dati.

Va subito precisato che non esiste un metodo univoco per svolgere la DPIA; ma le indicazioni fornite dal Regolamento, l’esperienza del Data Protection Working Party UE – noto come WP Art.29 a livello Europeo – ereditata dall’EDPB (European Data Protection Board) – le indicazioni del Garante nazionale per la protezione dei dati personali e delle principali Autorità di Controllo Nazionali in Europa (in particolare in Gran Bretagna con l’Information Commissioner’s Officer – ICO – e in Francia con il CNIL – Commission Nationale de l’Informatique et des Libertés) consentono di individuare possibili percorsi preferenziali per condurre la valutazione DPIA.

Nel seguito di questa Guida viene delineato un percorso che si ritiene efficace ed efficiente, sia nella PA sia in ambiente privato, per svolgere questa valutazione. Tale percorso recepisce, oltre che i dettami del Regolamento, le indicazioni del Garante nazionale al momento disponibili [Gar1], integrandole con i suggerimenti forniti dal WP Art.29 a livello europeo [UE1] e con l’esperienza internazionale proposta dall’ICO UK [ICO1] e, per alcuni ambiti, dal CNIL francese [CNI1]. Il percorso è strutturato su otto fasi puntuali che, in assenza di altri modelli di riferimento preferiti dal Titolare, possono costituire un riferimento adeguato per lo svolgimento della DPIA.

Entrando nello specifico, nel Cap.2 si presentano le informazioni di base indispensabili per poter iniziare il lavoro di valutazione, rispondendo a dodici domande propedeutiche alle analisi del percorso successivo.

Nel Cap.3 si analizza in dettaglio la fase iniziale della DPIA: questa coincide con un’analisi preliminare che conduce alla decisione del Titolare a riguardo della necessità, o meno, di svolgere una DPIA completa per il trattamento considerato.

Nel Cap.4, una volta deciso che è necessaria per un trattamento una DPIA completa, si entra nel vivo della valutazione e vengono descritte in dettaglio le azioni da svolgere e come costruire, con delle schede proposte nelle Appendici del documento, la relazione tecnica di valutazione che accompagna ogni DPIA. In questo capitolo viene anche proposto il metodo per la valutazione del rischio, un metodo speditivo semplificato e progettato ad hoc, tenendo in considerazione le esperienze del Regno Unito e della Francia in questo ambito.

2. L’essenziale da conoscere prima di affrontare una DPIA

In questo capitolo vengono date 12 dettagliate risposte a 12 quesiti che si pongono in modo naturale quando si affronta lo svolgimento di una DPIA.

2.1 Cosa è una DPIA?

L’articolo 35 del Regolamento introduce il concetto di valutazione d’impatto sulla protezione dei dati (Data Protection Impact Assessment = DPIA) e stabilisce che “quando un tipo di trattamento, allorché prevede in particolare l’uso di nuove tecnologie, considerati la natura, l’oggetto, il contesto e le finalità del trattamento, può presentare un rischio elevato per i diritti e le libertà delle persone fisiche, il Titolare del trattamento effettua, prima di procedere al trattamento, una valutazione dell’impatto dei trattamenti previsti sulla protezione dei dati personali. Una singola valutazione può esaminare un insieme di trattamenti simili che presentano rischi elevati analoghi”.

In altre parole, quando un trattamento può comportare un rischio elevato per i diritti e le libertà delle persone interessate – a causa del monitoraggio sistematico dei loro comportamenti, o per il gran numero dei soggetti interessati di cui sono trattati, ad esempio, dati di categorie particolari (Art.9), o anche per una combinazione di questi e altri fattori-, il Regolamento obbliga i Titolari a svolgere una valutazione di impatto prima di darvi inizio, consultando l´autorità di controllo in caso le misure tecniche e organizzative da loro stessi individuate per mitigare l´impatto del trattamento non siano ritenute sufficienti – cioè, quando il rischio residuo per i diritti e le libertà degli interessati resti elevato.

In estrema sintesi, la DPIA è un processo di analisi finalizzato a supportare il Titolare di un trattamento al fine di identificare e minimizzare i rischi relativi alla protezione dei dati.

La finalità della DPIA non è quella di eliminare tutti i rischi, ma quella di aiutare il Titolare a minimizzarli, determinando se il livello di rischio residuo risulti accettabile o meno.

Riferimenti al Regolamento per approfondimenti

Art.35 (punto1) e Considerando n. 84 e 90

2.2. Esiste un unico metodo per svolgere la DPIA?

Non esiste un unico metodo o modello di riferimento per lo svolgimento della DPIA.

Il Regolamento stabilisce all’Art.35 punto 7 gli elementi di analisi minimale che debbono essere considerati nella valutazione. Tali elementi sono qui di seguito riportati.

Regolamento – Art.35 punto 7

La valutazione (DPIA) contiene almeno:

a) una descrizione sistematica dei trattamenti previsti e delle finalità del trattamento, compreso, ove applicabile, l’interesse legittimo perseguito dal Titolare del trattamento;
b) una valutazione della necessità e proporzionalità dei trattamenti in relazione alle finalità;
c) una valutazione dei rischi per i diritti e le libertà degli interessati di cui al paragrafo 1; e
d) le misure previste per affrontare i rischi, includendo le garanzie, le misure di sicurezza e i meccanismi per garantire la protezione dei dati personali e dimostrare la conformità al presente regolamento, tenuto conto dei diritti e degli interessi legittimi degli interessati e delle altre persone in questione.

A partire dal cap.3 di questa Guida viene illustrato un percorso logico strutturato su otto Fasi che, in assenza di altri modelli di riferimento preferiti dal Titolare, può costituire un punto di partenza adeguato e comune per lo svolgimento della DPIA.

2.3 Chi ha la responsabilità di svolgere la DPIA?

La responsabilità della DPIA spetta al Titolare del trattamento (in inglese Data Controller), anche se la conduzione materiale della valutazione di impatto può essere affidata, in linea generale, a un altro soggetto interno o esterno alla sua organizzazione. Il Titolare ne monitora lo svolgimento consultandosi con il Responsabile della Protezione dei Dati (RPD, in inglese Data Protection Officer – DPO) e acquisendo – se i trattamenti lo richiedono – il parere di esperti di settore, del responsabile della sicurezza dei sistemi informativi (Chief Information Security Officer, CISO) e del responsabile IT.

2.4 Perché la DPIA è così importante?

Lo svolgimento della DPIA offre importanti vantaggi ai fini della dimostrazione di conformità alla norma, in quanto questa valutazione risulta essere una modalità di analisi efficace per verificare tutti i principi di protezione e gli obblighi introdotti dal Regolamento.

Tuttavia, lo svolgimento della DPIA non risponde solo ad una esigenza di conformità: una DPIA efficace, infatti, consente di identificare e risolvere i problemi connessi alla protezione dei dati in una fase precoce, prima dell’avvio del processo di trattamento, portando evidenti benefici in termini di garanzie sia per i soggetti interessati dal trattamento sia all’organizzazione (si pensi agli aspetti connessi con la trasparenza, la reputazione e l’immagine dell’organizzazione stessa).

Lo svolgimento della DPIA costituisce, tra l’altro, una parte essenziale degli obblighi di un Titolare: la mancata conduzione della DPIA o un suo svolgimento superficiale può essere sanzionato dall’Autorità competente con ammende amministrative estremamente onerose, fino a € 10 milioni di euro (Art.83 punto 4).

Riferimenti al Regolamento per approfondimenti

Artt. 5 (punto 2), 24, 25, 35, 83

2.5 Come può essere usata una DPIA già svolta?

Una DPIA può concentrarsi su un singolo trattamento o su un gruppo di trattamenti simili: in caso di DPIA già esistente, si può fare riferimento a questa per ogni trattamento di natura similare che presenta rischi analoghi.

In caso di introduzione di nuove tecnologie, si può fare riferimento, se la valutazione è ritenuta adeguata, alla DPIA eseguita dallo sviluppatore del prodotto.

Per nuovi progetti di trattamento, le DPIA sono una parte vitale della protezione dei dati by design (quindi fin dal progetto iniziale). Un’analisi in questa fase progettuale consente di influenzare lo sviluppo, portando all’attuazione della proposta nel modo più ottimizzato.

Tuttavia, è importante ricordare che le DPIA sono rilevanti anche per i casi di pianificazione di modifiche a un trattamento esistente. In questo caso è necessario che il Titolare conduca la DPIA in un momento precedente all’implementazione della modifica.

In altre parole, una DPIA non è semplicemente un timbro di conformità, un tecnicismo da realizzare come parte di un processo di approvazione.

La DPIA è una valutazione fondamentale che va integrata nel piano di progetto del nuovo trattamento e mantenuta nel tempo. Quindi, non si deve immaginare una DPIA come un esercizio da svolgere una tantum per archiviare poi la pratica. Una DPIA è un processo vivo e continuativo nel tempo, introdotto dal Regolamento per aiutare il Titolare a gestire e rivedere periodicamente i rischi del trattamento e le misure che sono state messe in atto per mitigarlo.

Riferimenti al Regolamento per approfondimenti

Art.35 (punti 1 e 11) e Considerando n. 84 e 92

2.6 Quale genere di ‘rischio’ deve essere valutato nella DPIA?

Non esiste una definizione esplicita di “rischio” nel Regolamento, ma le varie disposizioni sulla DPIA chiariscono che si tratta di rischi riferiti agli interessi dei singoli individui.

L’Art. 35 afferma che un DPIA deve considerare i “rischi per i diritti e le libertà delle persone fisiche“. Ciò include i rischi per la privacy e i diritti di protezione dei dati, ma anche su altri diritti e interessi fondamentali.

La disposizione chiave della norma su questo tema è espressa nel Considerando 75 presente nel regolamento [GDP1], che collega il rischio al concetto di danno materiale o immateriale, declinato nella forma di danno fisico, danno economico e danno sociale.

Regolamento – Considerando 75

I rischi per i diritti e le libertà delle persone fisiche, aventi probabilità e gravità diverse, possono derivare da trattamenti di dati personali suscettibili di cagionare un danno fisico, materiale o immateriale, in particolare: se il trattamento può comportare discriminazioni, furto o usurpazione d’identità, perdite finanziarie, pregiudizio alla reputazione, perdita di riservatezza dei dati personali protetti da segreto professionale, decifratura non autorizzata della pseudonimizzazione, o qualsiasi altro danno economico o sociale significativo; se gli interessati rischiano di essere privati dei loro diritti e delle loro libertà o venga loro impedito l’esercizio del controllo sui dati personali che li riguardano; se sono trattati dati personali che rivelano l’origine razziale o etnica, le opinioni politiche, le convinzioni religiose o filosofiche, l’appartenenza sindacale, nonché dati genetici, dati relativi alla salute o i dati relativi alla vita sessuale o a condanne penali e a reati o alle relative misure di sicurezza; in caso di valutazione di aspetti personali, in particolare mediante l’analisi o la previsione di aspetti riguardanti il rendimento professionale, la situazione economica, la salute, le preferenze o gli interessi personali, l’affidabilità o il comportamento, l’ubicazione o gli spostamenti, al fine di creare o utilizzare profili personali; se sono trattati dati personali di persone fisiche vulnerabili, in particolare minori; se il trattamento riguarda una notevole quantità di dati personali e un vasto numero di interessati.

Una DPIA deve valutare, dunque, questo tipo di rischio, e in particolare se esso si manifesta come ‘rischio elevato’. Il Regolamento indica che la valutazione del rischio deve essere condotta analizzando la probabilità (likelihood) di accadimento dell’evento e la gravità (severity) del danno (o impatto) potenziale che ne consegue.

È importante specificare che, nella Guida che segue, caratterizzeremo con la variabile probabilità non il semplice ‘tentativo’ non autorizzato di accedere ai dati da proteggere (senza dunque interessarsi all’esito del tentativo), ma, per fare l’esempio di un attacco malevolo, la probabilità dell’evento completo in cui sfruttando una possibile vulnerabilità si riesca ad accedere effettivamente ai dati da parte di un soggetto non autorizzato. Questo approccio che indicheremo come ‘completo’, con riferimento all’esempio ora fatto, è da considerare per tutte le casistiche che si presenteranno nell’analisi, in cui varrà sempre il criterio di valutare, al contempo, sia la minaccia (cioè il tentativo da parte di qualcuno, dove realizzabile) sia la vulnerabilità (cioè la debolezza sfruttata nel sistema di misure messo a difesa dei dati personali).

Riferimenti al Regolamento per approfondimenti

Art.35 (punto 1) e Considerando n. 4, 75, 76, 84 e 90

2.7 Cosa vuol dire ‘rischio elevato’ e come si può predire questa situazione?

Come detto in precedenza, il rischio in questo contesto riguarda i possibili danni materiali o non materiali agli individui, con un rischio declinato nella forma di danno fisico, danno economico e danno sociale.

Per valutare se un trattamento è a “rischio elevato”, il Regolamento indica che è necessario considerare sia la probabilità sia la gravità negli effetti di un determinato evento.

Un “rischio elevato” implica, evidentemente, una soglia (quantitativa o qualitativa) più elevata in termini di livello, sia, ad esempio, perché il danno potenziale è più probabile, sia perché il danno potenziale è più grave (nel senso di più ampio), o anche perché la combinazione dei due valori (probabilità e gravità) indica un livello elevato di rischio per quel particolare tipo di evento analizzato.

La valutazione dettagliata e affidabile del livello di rischio, inteso in questo senso, è uno degli obiettivi fondamentali della DPIA.

Ma in una fase preliminare di analisi, indicata nel seguito come Fase 0 della valutazione, la domanda a cui si deve rispondere non è tanto ‘quanto vale in modo puntuale il rischio per un certo trattamento’ ma, piuttosto, se ‘il trattamento possa essere caratterizzato da un rischio elevato’.

Questa sottile, ma sostanziale, differenza è ben indicata nella versione inglese del Regolamento, Art.35 che definisce la DPIA con la frase “… a processing … is likely to result in a high risk”, con likely che assume il significato di probabile/verosimile.

Per svolgere questa analisi preliminare di Fase 0 ci si potrà servire, se si intenderà seguire le indicazioni di questa Guida, di un questionario di screening proposto nel prossimo capitolo, in modo da decidere con un approccio sufficientemente analitico ma al contempo rapido, se sia necessaria o meno la DPIA completa per quel trattamento.

Per operare con un questionario di screening si cercherà di evidenziare, attraverso le domande poste, se esistono delle “caratteristiche critiche” del trattamento, delle red flags, come indicano ad esempio le norme del Garante UK, cioè delle condizioni oggettive, che la norma e la letteratura tecnica disponibile evidenziano in modo puntuale, alla presenza delle quali è molto probabile, seppur non certo al 100%, che ci si possa trovare di fronte ad un trattamento a rischio elevato.

Importante – Resta comunque valida l’affermazione generale riportata in varie sedi nazionali ed internazionali che, in caso di dubbio da parte del Titolare sul livello di rischio da assegnare in fase di analisi preliminare, venga deciso di svolgere comunque la DPIA nella sua interezza.

[Segue nel prossimo articolo]

Articolo a cura di Marco Carbonelli

https://www.ictsecuritymagazine.com/articoli/guida-per-lo-svolgimento-della-valutazione-dimpatto-sulla-protezione-dei-dati-dpia-parte-i/

Cominciamo dal principio: la self-sovereign identity è un principio, prima che una tecnologia. Un principio basato sul concetto di identità digitale.
L’identità digitale, che dovrebbe essere parte della cultura comune nel mondo odierno, ci rappresenta in tutti i possibili contesti pubblici, privati e ricreativi.

Recentemente si vedono molti articoli tecnologici legati alla “self-sovereign identity” ma purtroppo sfugge ai più, che traducono troppo frettolosamente gli articoli anglo-americani, il concetto filosofico che sta alla base.

Il ragionamento tecnologico dietro al tema mainstream è di solito la Blockchain, ma già nel 2017, molte organizzazioni e associazioni[1] ne parlavano come estensione e attuazione del principio sotteso al dover controllare molteplici identità digitali.

Già più di dieci anni prima, Kaliya Hamlin e altri autori si ponevano il problema della multi-identità su Internet. Ma perché solo oggi la gestione delle multi-identità online è così difficile da affrontare?

La risposta è: perché continuiamo a ragionare come nel mondo fisico.

Qui nascono i primi problemi, come posso gestire la multi identità se non l’ho compresa? Come posso dire subito che la Blockchain è la soluzione senza analizzare il contesto?

Partiamo già dall’assunto che non vogliamo semplificare il problema, ma gestirlo as-is, con la migliore tecnologia disponibile sul mercato. La verità è che abbiamo fatto molti progressi sui sistemi di identità online, ma abbiamo peggiorato la complessità e specialmente peggiorato la percezione degli utenti.

Le persone in generale, le aziende, le scuole, le istituzioni, trattano l’identità digitale come un account.

La prima considerazione è che tradizionalmente viene confusa l’identità digitale con l’account, che possiamo considerare invece un semplice schema utente / password per accedere – tipicamente – a un servizio.

Oggi il paradigma è un po’ più complesso perché si aggiungono, allo schema dell’account, i dati degli utenti.
Dati che cambiano la loro dimensione e funzione nel tempo; e questo non è poco.

Costruire l’identità digitale, per la maggior parte delle aziende, si è tradotto nel creare gli account con vecchie concezioni su nuovi servizi, tra tutti il telelavoro e la telescuola post emergenza. Dispositivi mobili e nuovi servizi dei social media ci hanno fornito sistemi di identità molto più sofisticati, flessibili, che non sempre proteggono la privacy e non sempre sono compresi dall’utente. Eppure siamo ancora molto lontani da un sistema di identità per Internet, che funziona ancora in una modalità diversa e non deve essere confuso con la logica della Blockchain.

Internet è stato progettato per consentire a qualsiasi macchina di inviare messaggi a qualsiasi altra macchina senza il permesso dell’autorità amministrativa.
E questo non lo dobbiamo dimenticare.

Se genero dati che non controllo, e qualcuno comincia a comunicarli, in base alla programmazione ricevuta, allora debbo pormi domande non solo tecnologiche ma culturali.

La self-sovereign identity gestisce un sistema di identità simile a Internet ma dovrebbe consentire a qualsiasi persona di organizzare e gestire le relazioni di identità reclamando, cancellando e gestendo i dati senza necessità di autorizzazione da parte di qualcun altro. Capiamo fin da subito che se i dati sono posseduti dalle aziende o dai privati le cose cambiano. Non comprendere le clausole o i dati coinvolti da parte dell’utente appare un problema evidente.

Andiamo per gradi. Prima degli utenti è importante che istituzioni e aziende capiscano il concetto, perché i Major Brand lo hanno capito benissimo. Internet è stato costruito senza un modo standard ed esplicito per identificare persone o organizzazioni, quindi i siti web hanno semplicemente iniziato a offrire i propri account locali con nomi utente e password, e questa è stata la soluzione predominante. Le aziende hanno fatto lo stesso. Internet, la scuola, le aziende, le società sportive, si sono espansi enormemente e le persone hanno iniziato a usare sempre più servizi integrati ogni giorno. Questo approccio basato su silos, in cui gli utenti devono mantenere le identità per ogni sito con cui interagiscono, è diventato insostenibile. Non è solo un disastro di usabilità per gli individui, ma crea anche una moltitudine di honeypot di dati per gli hacker, la cui violazione compromette la fiducia in tutti. La cultura sarà la chiave.

Le aziende hanno cercato di collegare diversi silos di identità in vari modi e li hanno federati con utenti inconsapevoli (o quasi) della gestione dei propri dati e soprattutto dei termini e condizioni di utilizzo degli account (es. Facebook).

Questa mancanza di cultura ha prodotto effetti collaterali involontari, concentrando il controllo su un numero limitato di fornitori, aumentando la perdita di dati e soprattutto la condivisione involontaria.

Ovviamente andrebbero sviluppate anche tutte le tematiche sulla privacy ma la considerazione certa è che, ad oggi, l’utente non ha la percezione del vero controllo.

Allo stesso tempo si aggiunga l’inefficienza economica delle organizzazioni e delle istituzioni che devono raccogliere, archiviare e proteggere i dati personali nei propri silos, andando avanti così sarà possibile raggiungere un punto di non ritorno, pensando per esempio al diritto all’oblio o al collasso delle risorse tecnologiche.

Senza porre condizioni minime di sostenibilità digitale delle soluzioni proposte non si coglie il vero senso della sovranità dei dati da parte dell’utente. La politica, le aziende e le istituzioni come anche la scuola non devono abdicare alle proprie responsabilità delegando questioni strategiche ad un’armata di tecnici o commerciali con la soluzione tecnologica salvifica, ma collaborare con essi per trovare il giusto equilibrio.

Lo sforzo per comprenderci è imprescindibile, compreso quello di capire intimamente la Blockchain, non proclamandola come una sorta di panacea tecnologica. Altrimenti il risultato sarà che il dibattito, partendo da domande sbagliate, finirà con il produrre risposte sbagliate. Comprendere l’intimo legame  che intercorre tra dati dell’utente, privacy e tecnologia è diventato urgente, irrinunciabile.

Diverso sarebbe stato chiedersi come evitare la diffusione incontrollata dei dati, agevolando comunque il telelavoro senza delegare la responsabilità all’utente, ma piuttosto coinvolgendolo.

Non è socialmente sostenibile una compressione dei diritti fondamentali dell’individuo che arrivi a concepire un sistema atto a restituire all’utente la sovranità dei propri dati, senza una seria differenza ontologica tra enti tecnologici ed Essere, senza determinare l’«oblio» dell’Essere.
Essere i nostri dati è il punto focale, non scegliere una tecnologia.
Come ci ricorda Heidegger[2]:

«L’essenza più profonda della tecnica non è nulla di tecnico».

Se ci si fosse fatti la domanda corretta, sarebbe emerso già da tempo che la soluzione per tutelare la l’identità dell’utenti e i loro relativi dati esiste, ma non può basarsi solamente sulla centralizzazione dei dati.
La Blockchain aiuta ma il concetto di self sovereign identity non è da confondersi con la tecnologia stessa, e la tecnologia non è la soluzione ai problemi etici.

Il concetto che le informazioni del cittadino sono e restano nelle mani del cittadino è chiaro. Per le aziende ed i dati dei dipendenti il problema è evidentemente più complesso. Account privati (es. Google e WhatsApp) usati nelle aziende complicano, in maniera esponenziale, il problema.

Quindi, se ad un problema complesso aggiungo l’eterogeneità degli account, ottengo un grande pasticcio se gli utenti non fanno la loro parte. Ecco perché tutti dovrebbero interessarsi al concetto di self sovereign identity.

Le tecnologie esistono già. Ma per usarle bene è necessario porsi la domanda giusta.

La creazione di identità dei 7.599.259[3] studenti, di diversi milioni di lavoratori, associazioni sportive, enti di formazione che hanno creato identità digitali con account Google, Microsoft, Zoom, Cisco etc. durante l’emergenza sanitaria dovranno essere gestite o cancellate nei prossimi anni.

La mente è uno strumento prezioso ma è, per sua natura, “separatista”; analizziamo il particolare e non teniamo presente il tutto.

Questo è il centro del problema: siamo a un punto molto interessanrte della storia ed è necessario trovare nuove vie per aprirsi a un pensiero di più ampio respiro. La rivoluzione digitale è una cosa meravigliosa anche perché ci pone delle domande difficili, inaspettate. Le aziende tecnologiche ci aiutano ma dobbiamo prendere coscienza del tutto, senza dimenticarci anche della sicurezza informatica.

Capito cosa dobbiamo diventare, poi sarà più facile farlo con la tecnologia giusta.
Queste suggestioni servono per focalizzare un punto di analisi e alimentare il relativo dibattito. Le risorse delle aziende vanno indirizzate a proteggere le identità digitali degli utenti, guardando più in là. Cosa succederebbe se le identità digitali venissero gestite da uno Stato straniero o da un’azienda concorrente? Coinvolgere l’utente è la chiave, con la cultura. C’è bisogno della collaborazione di tutti.

Non esiste democrazia senza un demos e un demos non esiste senza un’aggregazione di senso, che deve essere chiaro, comune e condiviso; e in questo caso si tratta di un demos di identità digitali.

In conclusione, con i dati self-sovereign, i vostri dati digitali saranno, in linea teorica, di vostra proprietà e controllati da voi. Le piattaforme non controlleranno i vostri dati, ma dovrete imparare a leggere i contratti. Le aziende dovranno capire i concetti degli oggetti descrittori DID (DDO) e quello delle chiavi pubbliche e private, nonché del funzionamento del registro condiviso. La condivisione degli identificatori digitali sarà possibile attraverso l’infrastruttura a chiave pubblica e l’archiviazione attraverso il ledger distribuito. Ma le aziende saranno pronte ad integrarlo nei propri sistemi di autenticazione? Da DPO dico anche che la cancellazione dei dati sarà a carico del titolare se l’utente capisse di avere un diritto. Più semplice sarebbe avere un approccio privacy-oriented – by design e by default – risolvendo la tematica chiedendosi di chi sia la titolarità sui dati. Porsi queste domande dovrà diventare una prassi, una pratica quotidiana che l’utente e le aziende dovranno apprendere. E per questo servirà Cultura.

Note

[1] https://sovrin.org/wp-content/uploads/2017/06/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf

[2] M. Heidegger, La questione della tecnica, trad. it. in Saggi e discorsi, Mursia, 1976

[3] https://bit.ly/2nLNHgI

Articolo a cura di Efrem Zugnaz

https://www.ictsecuritymagazine.com/articoli/perche-dovrei-preoccuparmi-della-self-sovereign-identity-se-sono-unazienda-o-un-cittadino/

Dal 15 giugno l’App Immuni è utilizzabile in tutta Italia e ci si augura che presto venga scaricata dal maggior numero possibile di persone, in quanto strumento prezioso nella strategia globale di lotta alla pandemia.

Per attuare gli strumenti di contact tracing[1] secondo le indicazioni fornite dal nostro Garante per la Privacy e dalle Autorità europee, in un continuum ideale e valoriale, un requisito fondamentale era rappresentato da una fonte normativa che ne sancisse l’assoluta necessità, sicché in data 30 aprile 2020, sono state approvate[2] le “misure urgenti per l’introduzione del sistema di allerta Covid-19″, in particolare al Capo II,  art. 6, dove viene descritto il “Sistema di allerta Covid-19”.

Il comma 1 stabilisce che “al solo fine di allertare le persone che siano entrate in contatto stretto con soggetti risultati positivi e tutelarne la salute attraverso le previste misure di prevenzione nell’ambito delle misure di sanità pubblica legate all’emergenza COVID-19, é istituita una piattaforma unica nazionale per la gestione del sistema di allerta dei soggetti che, a tal fine, hanno installato, su base volontaria, un’apposita applicazione sui dispositivi di telefonia mobile”.

Il titolare del trattamento è il Ministero della Salute, che si coordina, sentito il Ministro per gli affari regionali e le autonomie, anche ai sensi dell’articolo 28 del Regolamento (UE) 2016/679 (GDPR), con i soggetti operanti nel Servizio nazionale della protezione civile, nonché con l’Istituto superiore di sanità e, anche per il tramite del Sistema Tessera Sanitaria, con le strutture pubbliche e private accreditate del Servizio sanitario nazionale, “nel rispetto delle relative competenze istituzionali in materia sanitaria connessa all’emergenza epidemiologica da COVID 19, per gli ulteriori adempimenti necessari alla gestione del sistema di allerta e per l’adozione di correlate misure di sanità pubblica e di cura”.
Le modalità operative del sistema di allerta tramite la piattaforma informatica sono complementari alle ordinarie modalità in uso nell’ambito del Servizio sanitario nazionale (cd. ‘tracciamento manuale dei contatti’).

In ottemperanza alle prescrizioni del Regolamento (UE) 2016/679, il Ministero della salute:

• dopo una valutazione di impatto, effettuata ai sensi dell’art.35,
• ha adottato misure tecniche e organizzative idonee a garantire un livello di sicurezza adeguato ai rischi elevati per i diritti e le libertà’ degli interessati,
• sentito il Garante per la protezione dei dati personali ai sensi dell’art.36, par. 5, e dell’articolo 2-quinquiesdecies del ‘Codice in materia di protezione dei dati personali’[3].

Era infatti necessario assicurare, in particolare, che:

a) gli utenti ricevessero, prima dell’attivazione dell’app, informazioni chiare e trasparenti, ai sensi degli artt.13 e 14, al fine di raggiungere una piena consapevolezza, in particolare, sulle finalità e sulle operazioni di trattamento, sulle tecniche di pseudonimizzazione utilizzate e sui tempi di conservazione dei dati;
b) per impostazione predefinita, in conformità all’art.25, i dati personali raccolti fossero esclusivamente quelli necessari ad avvisare gli utenti dell’applicazione di rientrare tra i contatti stretti di altri utenti accertati positivi al COVID-19 (individuati secondo criteri stabiliti dal Ministero della salute), nonché ad agevolare l’eventuale assistenza sanitaria in loro favore;
c) il trattamento effettuato per allertare i contatti fosse basato sul trattamento di dati di prossimità dei dispositivi, resi anonimi oppure, ove ciò non sia possibile, pseudonimizzati; “è esclusa in ogni caso la geo-localizzazione dei singoli utenti”;
d) fossero garantite su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento nonché misure adeguate ad evitare il rischio di reidentificazione degli interessati cui si riferiscono i dati pseudonimizzati oggetto di trattamento;
e) i dati relativi ai contatti stretti fossero conservati, anche nei dispositivi mobili degli utenti, per il periodo strettamente necessario al trattamento, la cui durata é stabilita dal Ministero della salute e specificata nell’ambito delle presenti misure; i dati fossero infine cancellati in modo automatico alla scadenza del termine;
f) i diritti degli interessati (artt. 15- 22) potessero venire esercitati anche con modalità semplificate.

I dati raccolti attraverso l’app non possono essere trattati per finalità diverse da quelle sopra indicate, salva la possibilità di utilizzo in forma aggregata o comunque anonima, per soli fini di sanità pubblica, profilassi, statistici o di ricerca scientifica, ai sensi degli artt. 5, paragrafo 1, lettera a) e 9, paragrafo 2, lettere i) e j), del Regolamento (UE) 2016/679.

Viene espressamente ribadita la volontarietà dell’utilizzo: “il mancato utilizzo dell’applicazione non comporta alcuna conseguenza pregiudizievole ed é assicurato il rispetto del principio di parità di trattamento”.

La piattaforma informatica “è di titolarità pubblica ed è realizzata dal Commissario Straordinario per l’attuazione e il coordinamento delle misure di contenimento e contrasto dell’emergenza epidemiologica Covid-19”. Utilizza solo infrastrutture pubbliche situate all’interno dei confini nazionali ed è gestita esclusivamente dalla società pubblica Sogei SpA. Il codice sorgente è stato sviluppato per la presidenza del Consiglio dei ministri da Bending Spoons SpA ed è rilasciato sotto licenza GNU Affero General Public License (versione 3). L’utilizzo dell’App e della piattaforma, nonché ogni trattamento di dati personali dovranno essere interrotti alla data di cessazione dello stato di emergenza disposto con delibera del Consiglio dei ministri del 31 gennaio 2020, e comunque non oltre il 31 dicembre 2020, ed entro la medesima data tutti i dati personali trattati dovranno essere cancellati o resi definitivamente anonimi.

In data 1 giugno 2020, il Garante per la protezione dei dati personali ha autorizzato il Ministero della salute ad avviare il trattamento relativo al “Sistema di allerta Covid-19” (app “Immuni”)[4], sicché da pari data l’app è disponibile sugli store digitali di Apple e Google.

Come si legge nel Provvedimento, sulla base della valutazione d’impatto effettuata dal Ministero, il trattamento di dati personali effettuato nell’ambito del Sistema “può essere considerato proporzionato, essendo state previste misure volte a garantire in misura sufficiente il rispetto dei diritti e le libertà degli interessati, che attenuano i rischi che potrebbero derivare da trattamento”.

Tuttavia, anche a causa della complessità del sistema e del numero dei soggetti coinvolti, il Garante ha voluto indicare una serie di misure, volte a rafforzare la sicurezza dei dati degli utenti dell’app; in particolare, l’Autorità ha disposto che, utilizzando anche il periodo di test che dall’8 giugno ha riguardato quattro regioni (Abruzzo, Liguria, Marche e Puglia):

• gli utenti fossero informati adeguatamente in ordine al funzionamento dell’algoritmo di calcolo utilizzato per la valutazione del rischio di esposizione al contagio;
• fossero portati a conoscenza del fatto che il sistema potrebbe generare notifiche di esposizione che non sempre riflettono un’effettiva condizione di rischio;
• avessero inoltre la possibilità di disattivare temporaneamente l’App, attraverso una funzione facilmente accessibile nella schermata principale;
• fosse anche garantita la trasparenza del trattamento a fini statistico-epidemiologici dei dati raccolti e individuate modalità adeguate a proteggerli, evitando ogni forma di riassociazione a soggetti identificabili e adottando idonee misure di sicurezza e tecniche di anonimizzazione;
• venissero introdotte misure volte ad assicurare il tracciamento delle operazioni compiute dagli amministratori di sistema sui sistemi operativi, sulla rete e sulle basi dati;
• la conservazione degli indirizzi Ip dei cellulari venisse commisurata ai tempi strettamente necessari per il rilevamento di anomalie e di attacchi;
• venissero adottate misure tecniche e organizzative per mitigare i rischi derivanti da “falsi positivi”;
• particolare attenzione fosse dedicata all’informativa e al messaggio di allerta, tenendo altresì conto del fatto che è previsto l’uso del Sistema anche da parte di minori ultra quattordicenni.

Il Garante ha sottolineato infine che il trattamento di dati personali raccolti attraverso l’app “da parte di soggetti non autorizzati può determinare un trattamento di dati personali illecito, eventualmente anche sotto il profilo penale”.

Dal canto suo, il 3 giugno 2020 il Ministero dell’Economia e delle Finanze è intervenuto a indicare le “modalità tecniche per il coinvolgimento del ‘Sistema Tessera Sanitaria’ ai fini dell’attuazione delle misure di prevenzione nell’ambito delle misure di sanità’ pubblica legate all’emergenza COVID-19”[5].

Il Sistema TS (di cui è titolare il Ministero dell’economia e delle finanze) rende disponibili all’operatore sanitario (l’operatore del Dipartimento di prevenzione della ASL autorizzato ad accedere al Sistema TS per la trasmissione al Sistema di allerta Covid-19 dei dati raccolti mediante l’app), anche tramite «SAR» (il Sistema di accoglienza regionale), le funzionalità per la trasmissione dei dati[6], secondo le seguenti modalità.

In caso di esito positivo di un tampone, l’operatore sanitario contatta il paziente per effettuare l’indagine epidemiologica, che prevede anche la verifica dell’installazione dell’App Immuni: se il paziente l’ha installata, gli sarà richiesto di aprirla e di utilizzare la funzione di generazione del codice OTP (One time password di durata temporale limitata). Il paziente comunica i 10 caratteri del codice OTP all’operatore sanitario  e attende l’autorizzazione a procedere con l’upload delle proprie TEK (Temporary exposure key, chiave crittografica casuale generata da un telefono cellulare o altro dispositivo «mobile» dotato dell’App).

L’operatore sanitario, secondo le modalità descritte nell’Allegato A del decreto, accede al Sistema TS e, in virtù del particolare profilo attribuito, inserisce i dati forniti dal paziente concernenti:

Il Sistema TS invia i dati al server di backend del Sistema di allerta Covid-19:

Di seguito evidenzio alcuni dei punti di maggiore interesse – in ottica data protection & privacy – relativi alle modalità tecniche di trasmissione da parte degli operatori sanitari dei dati alla componente di backend, descritte appunto nell’Allegato A del decreto MEF.

Accesso al servizio

Le possibilità di accesso al servizio da parte dell’operatore sanitario sono riassunte nella seguente tabella, che indica gli utenti che possono accedere al sistema TS attraverso sistemi software con interfacce web o web services, oppure per il tramite di sistemi regionali (SAR):

Registrazione degli accessi applicativi e tempi di conservazione

Il servizio non costituisce né alimenta alcuna banca dati contenuta nel Sistema TS, in quanto la sua finalità é la trasmissione dei dati al backend dall’app. Il sistema registra unicamente gli accessi all’applicazione e l’esito dell’operazione, e inserisce i dati dell’accesso in un archivio dedicato. In nessun caso sono tracciati i dati applicativi (OTP, data inizio sintomi), né su banca dati né su file di log. I log degli accessi così descritti sono conservati per dodici mesi.

Misure di sicurezza

Infrastruttura fisica

L’infrastruttura fisica é realizzata dal Ministero dell’economia e delle finanze attraverso l’utilizzo dell’infrastruttura del Sistema tessera sanitaria. I locali sono sottoposti a videosorveglianza continua e sono protetti da qualsiasi intervento di personale esterno. L’accesso ai locali avviene secondo una documentata procedura, prestabilita dal titolare del trattamento, che prevede l’identificazione delle persone che accedono e la registrazione degli orari di ingresso e di uscita di tali persone.

Registrazione degli utenti ed assegnazione degli strumenti di sicurezza

L’infrastruttura di Identity e Access Management censisce direttamente le utenze, accogliendo flussi di autenticazione e di autorizzazione, per l’assegnazione dei certificati client di autenticazione, delle credenziali di autenticazione e delle risorse autorizzative. Il certificato viene emesso con un sistema di crittografia asimmetrica a chiave pubblica/privata. Il sistema effettua la gestione completa del certificato di autenticazione: assegnazione, ri-emissione alla scadenza, revoca.

La gestione dei profili di autorizzazione é effettuata sempre dagli amministratori di sicurezza delle ASL: “a tutti gli operatori sanitari che devono essere autorizzati viene assegnata una risorsa di autorizzazione creata e dedicata appositamente al servizio descritto dal presente decreto. Gli amministratori di sicurezza si autenticano con le credenziali in basic authentication. Entro sessanta giorni dalla data di adozione del decreto saranno dotati di strumenti di autenticazione forte. La gestione degli amministratori di sicurezza delle ASL é effettuata dall’Amministratore centrale della sicurezza. L’Amministratore centrale della sicurezza é nominato tra gli incaricati del trattamento”.

Sistemi e servizi di backup e disaster recovery

Non sono previsti sistemi e servizi di backup e disaster recovery per i log di accesso in quanto non necessari per le finalità di trattamento dei dati del servizio. Tali sistemi non sono previsti nemmeno per i dati: infatti, poiché il sistema non prevede una banca dati e registra unicamente gli accessi al servizio, l’eventuale perdita delle informazioni registrate non pregiudicherebbe l’utilizzo né l’efficienza del servizio, in quanto il codice OTP ha durata limitata, non è in alcun modo riconducibile all’interessato, e comunque può essere rigenerato in qualunque momento dal dispositivo «mobile». È unicamente previsto il backup dei sistemi.

Accesso ai sistemi

L’infrastruttura dispone di sistemi di tracciamento degli accessi ai sistemi informatici di supporto come base dati, server web e infrastrutture a supporto del servizio.

L’accesso alla base dati avviene tramite utenze nominali e il sistema di tracciamento registra (su appositi log) le seguenti informazioni: identificativo univoco dell’utenza che accede, data e ora di login, logout e login falliti, postazione di lavoro utilizzata per l’accesso (IP client), tipo di operazione eseguita sui dati (ad esclusione delle risposte alle query).

Per ogni accesso ai sistemi operativi, ai sistemi di rete, al software di base e ai sistemi complessi (anche da parte degli amministratori di sistema), il sistema di tracciamento registra (su appositi log) le seguenti informazioni: identificativo univoco dell’utenza che accede, data e ora di login, logout e login falliti, postazione di lavoro utilizzata per l’accesso (IP client).

I log prodotti dai sistemi di tracciamento infrastrutturali sono soggetti a monitoraggio costante allo scopo di individuare eventuali anomalie inerenti alla sicurezza (accessi anomali, operazioni anomale, ecc.) e di valutare l’efficacia delle misure implementate.

I log di accesso degli amministratori di sistema e degli incaricati sono protetti da eventuali tentativi di alterazione e dispongono di un sistema di verifica della loro integrità. I log relativi agli accessi e alle operazioni effettuate sui sistemi operativi, sulla rete, sul software di base e sui sistemi complessi sono conservati per dodici mesi.

Sin dalla sua attivazione, secondo gli ultimi aggiornamenti, l’app Immuni è stata scaricata da 2,5 milioni di persone. Se ne auspica la sua più ampia diffusione, in quanto è uno strumento fondamentale nella lotta alla pandemia, non solo perché consente di affinare sempre più i dati epidemiologici, statistici e di ricerca scientifica, ma soprattutto per prevenire ‘attivamente’ il contagio massivo: in definitiva, “più persone la scaricano, maggiore sarà la sua efficacia”, come è stato detto e ripetuto da più parti.

Note

[1] Per ampi dettagli scientifici, tecnici e giuridici, si rinvia al White Paper a cura di Sergio Guida “Un Framework per il Contact Tracing in Italia tra esigenze scientifiche, possibilità tecnologiche e rispetto di Diritti e Liberta’ Individuali in termini di Data Protection”, in corso di pubblicazione.

[2] Con il Decreto Legge n. 28 “Misure urgenti per la funzionalità’ dei sistemi di intercettazioni di conversazioni e comunicazioni, ulteriori misure urgenti in materia di ordinamento penitenziario, nonché disposizioni integrative e di coordinamento in materia di giustizia civile, amministrativa e  contabile e misure urgenti per l’introduzione del sistema di allerta Covid-19”, (GU n.111 del 30-4-2020).

[3] È il “Codice Privacy”, di cui al decreto legislativo 30 giugno 2003, n. 196 integrato con le modifiche introdotte dal Decreto Legislativo 10 agosto 2018, n.101, 2018 n. 101, concernente «Disposizioni per l’adeguamento della normativa nazionale alle disposizioni del regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché’ alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (Regolamento generale sulla protezione dei dati».

[4] Con il Provvedimento di autorizzazione al trattamento dei dati personali effettuato attraverso il Sistema di allerta Covid-19 – App Immuni [doc. web n. 9356568], GARANTE PER LA PROTEZIONE DEI DATI PERSONALI, Registro dei provvedimenti, n. 95 del 1° giugno 2020.

[5] È il decreto ministeriale  3 giugno 2020, Modalità tecniche per il coinvolgimento del Sistema tessera sanitaria ai fini dell’attuazione delle misure di prevenzione nell’ambito delle misure di sanità pubblica legate all’emergenza COVID-19 (20A03083) (GU n.144 del 8-6-2020).

[6] Cfr. “Il Ministero della salute, in qualità di titolare del trattamento ai sensi dell’art. 6, comma 1 del decreto-legge 30 aprile 2020, n. 28, ha designato il Ministero dell’economia e delle finanze quale responsabile esterno del trattamento dei dati di cui al presente decreto. La valutazione di impatto dei trattamenti effettuati nell’ambito del Sistema tessera sanitaria di cui al presente decreto è riportata nel documento di valutazione di impatto di cui all’art. 6, comma 2 del decreto-legge 30 aprile 2020, n. 28”.

Articolo a cura di Sergio Guida

https://www.ictsecuritymagazine.com/articoli/il-sistema-di-allerta-covid-19-nazionale-e-partito-con-lapp-immuni-dopo-lautorizzazione-del-garante-privacy/

Pubblicazioni ed efficacia

In linea generale, sui termini di pubblicazione all’albo pretorio on line è necessario verificare la fonte normativa di riferimento, sia per la pubblicazione e sia per l’efficacia del provvedimento.

Le deliberazioni degli Enti locali[1]:

• pubblicità – vengono pubblicate all’albo pretorio per giorni 15 ai fini di dare corso agli effetti: «tutte le deliberazioni del comune e della provincia sono pubblicate mediante pubblicazione all’albo pretorio, nella sede dell’ente, per quindici giorni consecutivi, salvo specifiche disposizioni di legge» (ex 124, comma 1 del D.lgs. n. 267/2000)[2];
• efficacia – diventano esecutive dopo il decimo giorno dalla loro pubblicazione, mentre nel caso di urgenza possono essere dichiarate immediatamente eseguibili con il voto espresso dalla maggioranza dei componenti (ex 134, commi 3 e 4 del TUEL)[3].

Gli altri provvedimenti, quali ad es. le determinazioni dirigenziali, hanno termini di pubblicazione ed efficacia che possono essere diversi in relazione alle discipline di riferimento.

Ne consegue che l’efficacia dei provvedimenti, per il principio di legalità, non segue le regole per gli atti emanati dagli organi individuati dall’art. 134 del D.lgs. n. 267/2000; di conseguenza, gli atti degli organi di governo sono subordinati ai tempi della loro pubblicazione, dato l’interesse collettivo che rivestono, mentre all’opposto, le determinazioni dirigenziali (costituendo provvedimenti volti a realizzare gli interessi specifici affidati alle cure dell’Amministrazione e consistenti in decisioni destinate a generare, modificare o distinguere situazioni giuridiche specifiche o quanto meno a negarne la nascita, la modificazione o l’estinzione) devono anch’esse essere pubblicate per soddisfare le esigenze di trasparenza dell’attività amministrativa (secondo il modello FOIA, ex del D.lgs. n. 33/2013), ma non vi è alcuna regola legislativa che ne comporti l’inefficacia in pendenza di pubblicazione, ben potendosi stabilire, a livello regolamentare (fonte secondaria), dei termini minimi, mutuando quelli sopra indicati[4].

A corredo di tale orientamento occorre ricordare che, in relazione alle regole dell’art. 10 disp.prel.cc., si individua un termine generale iniziale di obbligatorietà di pubblicazione delle leggi e dei regolamenti nel giorno decimoquinto (15) successivo alla loro pubblicazione, ossia acquistano efficacia solo quindici giorni dopo l’esecutività della deliberazione: l’art. 10 «Inizio dell’obbligatorietà delle leggi e dei regolamenti», dispone «Le leggi e i regolamenti divengono obbligatori nel decimoquinto giorno successivo a quello della loro pubblicazione, salvo che sia altrimenti disposto».

In effetti, i provvedimenti che incidono la sfera giuridica dei destinatari se, per una parte, vanno notificati all’interessato (ex art. 21 bis della legge n. 241/1990, con valore precettivo), dall’altra, i provvedimenti generali devono pur acquisire efficacia a seguito di un periodo minimo di pubblicazione, secondo la regola generale dell’art. 10 delle Preleggi.

Un parere del Ministero dell’interno del 13 settembre 2006 rileva che il procedimento di pubblicazione può considerarsi perfezionato solo al termine di quindici giorni previsti dall’art. 124 TUEL ed è da tale termine finale che decorrono i dieci giorni previsti dall’art. 134 TUEL (ovvero, 15 giorni di pubblicazione + 10 giorni di efficacia)[5]; rispetto alla previsione dell’art. 134 del TUEL, dove si dispone che le deliberazioni non soggette a controllo necessario o non sottoposte a controllo eventuale, diventano esecutive dopo il decimo giorno (10) dalla loro pubblicazione.

Dunque, la disposizione di cui all’art. 10 cit., nella sua inequivoca redazione testuale, «è applicabile a tutti i regolamenti degli Enti locali, essendo questi ultimi pienamente inseriti nel contesto delle fonti del diritto e non distinguendo il predetto art. 10 in ordine alla natura governativa o meno dei regolamenti»[6].

Inoltre l’art. 3 comma 2 delle preleggi, a norma del quale il potere regolamentare di altre autorità è esercitato nei limiti delle rispettive competenze, «in conformità delle leggi particolari» va coordinato con l’art. 10, che riserva alla legislazione speciale i presupposti di esercizio del potere regolamentare (condizioni, modalità e soprattutto ambiti e materie di disciplina), sempre fermo restando il regime generale di entrata in vigore delle norme che è sanzionato dall’art. 10.

Per definire i termini di pubblicazione in assenza di una fonte di riferimento, tale fonte potrebbe rinvenirsi nello Statuto; e nel silenzio dello stesso, non essendo prevista una speciale normativa in ordine all’entrata in vigore degli atti, da ricomprendersi anche i regolamenti o provvedimenti, dovrà applicarsi la regola generale dell’art. 10 delle Preleggi.

Distinzioni tra esecutività ed efficacia

Sulla distinzione tra esecutività e efficacia della deliberazione, si annota che:

• la fase di “pubblicazione” di una deliberazione all’albo pretorio è istituto diverso da quello disciplinato dall’art. 10, sebbene entrambi condividano la finalità di rendere legalmente conoscibile il contenuto di atti e provvedimenti autoritativi;
• la fase di “vacatio legis”, di cui all’art. 10 delle preleggi, assolve esclusivamente alla funzione di rendere conoscibile (e far presumere conosciuto) un testo normativo che concorre ad integrare le fonti del diritto, nel suo testo già definitivo e non suscettibile di ulteriori modifiche;
• la fase di “pubblicazione” della deliberazione/determinazioni è un istituto di partecipazione popolare (di antichissima origine) che, insieme alla necessità di apprestare un meccanismo legale di presunzione di conoscenza nei confronti dei terzi (non direttamente incisi dai provvedimenti, mentre ai destinatari l’atto va comunque notificato), è volto anche a rendere possibile la presentazione di osservazioni, oppure opposizioni da parte di chiunque vi abbia interesse, per consentire all’organo emanante di provvedere su di esse e che dunque potrebbero condurre anche a una modifica della deliberazione stessa prima della sua entrata in vigore[7].

Chiarito la ratio della pubblicazione e dei suoi effetti, l’”esecutività” della delibera, data dalla quale quest’ultima acquista efficacia e può essere portata ad esecuzione, decorre dal decimo giorno dall’inizio della pubblicazione, oppure data di adozione nel caso di delibere dichiarate immediatamente eseguibili, ex art. 134 TUEL.

In termini diversi, la data di esecutività decorre:

• dopo 10 giorni dalla pubblicazione;
• dall’adozione (immediata) della deliberazione dichiarata immediatamente eseguibile.

Tuttavia, nel caso di una deliberazione approvativa di un regolamento, l’esecuzione della deliberazione implica:

• l’affissione del regolamento al pubblico;
• e la relativa decorrenza della “vacatio legis”, di cui all’art. 10 delle Preleggi (15 giorni di pubblicazione), perché tale adempimento scaturisce dal regime in sé dell’atto approvato di cui è parte integrante (nell’assenza di una diversa previsione dello Statuto) che va tenuto distinto dal regime dell’atto di approvazione.

In mancanza di una norma statutaria (o di una norma di legge) laddove il provvedimento indichi decorrenze “dalla sua approvazione” o rechi altre indicazioni di tipo generico, i termini fissati per gli adempimenti disposti (salve norme transitorie) dovranno intendersi di norma come correlati alla sua entrata in vigore: decimoquinto giorno successivo a quello della loro pubblicazione.

Va aggiunto, con riferimento ai quindici giorni della pubblicazione, ex art. 10 Preleggi, decorrano:

• dal compimento integrale della pubblicazione della delibera all’albo pretorio (ex 124 TUEL, ovvero, dopo i 15 di pubblicazione + 15 di vacatio legis) che implica la decorrenza dei termini di impugnazione[8];
• oppure, come sembrerebbe più corretto, dal giorno di esecutività della stessa (dieci giorni dall’inizio della pubblicazione, ex 134 TUEL).

Alla luce delle considerazioni che precedono, in mancanza di termini diversi stabiliti da norme di natura statutaria o di legge, l’efficacia decorre dopo 15 giorni dalla pubblicazione all’albo pretorio, ai sensi dell’art. 10 delle Preleggi, con l’avvertenza di stabilire – nel testo deliberativo – in modo inequivocabile il termine del periodo di vacatio legis; meglio sarebbe, allora, inserire direttamente nello Statuto, o nella disciplina regolamentare, una norma che definisse in modo certo l’efficacia delle deliberazioni (di tutte le deliberazioni/determinazioni, comprese quelle di approvazione dei regolamenti, se non si vuole estendere espressamente i 15 giorni dell’art. 10 prel.) scaduto il termine di dieci (10) giorni dalla pubblicazione (ovvero, all’undicesimo dall’inizio della pubblicazione), piuttosto che incorrere nel dubbio che l’efficacia decorra dopo i dieci giorni del termine di pubblicazione (15 + 10, il computo iniziale dei dieci giorni debba compiersi con riferimento al termine della pubblicazione da effettuarsi per 15 giorni)[9]: in claris non fit interpretatio.

Pubblicità legale e trasparenza

Distinto il perimetro delle pubblicazioni da quello dell’efficacia degli atti, si deve chiarire la distinzione tra pubblicazione all’albo pretorio, con valore di pubblicità legale, dalla pubblicazione al sito istituzionale, sez. “Amministrazione trasparente”, con funzione di pubblicità conoscitiva, alias trasparenza, ex d.lgs. n. 33/2013 (c.d. Decreto Trasparenza, di cui al riferimento Freedom of Information Act, FOIA).

Sul punto, le Linee Guida n. 15/2014 del Garante privacy al punto «3.a. Albo pretorio online degli enti locali», si affronta:

• sia la pubblicazione per “ragioni di trasparenza”, sul modello FOIA;
• sia per ragioni di “efficacia legale”[10] della pubblicazione, che si intendono assolti con la pubblicazione nei propri siti informatici da parte delle Amministrazioni e degli Enti pubblici obbligati (ai sensi della Legge 18 giugno 2009, n. 69, recante «Disposizioni per lo sviluppo economico, la semplificazione, la competitività nonché in materia di processo civile»).

Si annota che i documenti oggetto di pubblicazione obbligatoria, ex D.lgs. n. 33/2013, vanno ordinariamente pubblicati nei termini indicati dal cit. decreto, osservando che l’art. 8 «Decorrenza e durata dell’obbligo di pubblicazione» che detta le regole generali: «i dati, le informazioni e i documenti oggetto di pubblicazione obbligatoria ai sensi della normativa vigente sono pubblicati per un periodo di 5 anni, decorrenti dal 1° gennaio dell’anno successivo a quello da cui decorre l’obbligo di pubblicazione, e comunque fino a che gli atti pubblicati producono i loro effetti, fatti salvi i diversi termini previsti dalla normativa in materia di trattamento dei dati personali e quanto previsto dagli articoli 14, comma 2, e 15, comma 4. Decorsi detti termini, i relativi dati e documenti sono accessibili ai sensi dell’articolo 5».

La norma, nelle Linee Guida cit., intende esprimere un concetto di pubblicazione legato ai termini individuati puntualmente ai fini della trasparenza, mentre in presenza di altre forme di trasparenza, quella legale, i termini sono individuati dalla fonte di riferimento speciale o specifica (la c.d. base giuridica).
Ciò posto, le pubblicazioni delle deliberazioni di giunta o consiglio comunale, volendo anche assimilare le determinazioni (che seguirebbero l’art. 23 del D.lgs. n. 33/2013 in elenco)[11], trovano la loro fonte nel TUEL, ex art. 124 «Pubblicazione delle deliberazioni», con una pubblicazione limitata «per quindici giorni consecutivi».

La pubblicazione conferisce efficacia legale al provvedimento: più puntualmente l’art. 134 del D.lgs. n. 267/2000, «Esecutività delle deliberazioni», prescrive che «Le deliberazioni non soggette a controllo necessario o non sottoposte a controllo eventuale diventano esecutive dopo il decimo giorno dalla loro pubblicazione».

Giova rammentare che la giurisprudenza precisa che se la necessaria pubblicità dell’azione degli Enti locali richiede di applicare ai provvedimenti monocratici le stesse fondamentali regole di pubblicità degli atti degli organi collegiali, ciò non vuol dire che per gli stessi valgano anche le disposizioni che riguardano il conseguimento dell’efficacia dei provvedimenti (ex art. 191 TUEL)[12]: per il principio di legalità, infatti, soltanto agli atti emanati dagli organi individuati dall’art. 134 del D.lgs. 267 del 2000, si applicano le sue relative disposizioni e non anche agli atti disciplinati dal precedente art. 124[13].

Il combinato disposto prevede una forma specifica di pubblicità legale dei provvedimenti deliberativi e un termine (quindici giorni) per la loro pubblicazione, mancando una fonte normativa che disciplina una durata ulteriore dei provvedimenti per intero (compresi gli allegati) ai fini della trasparenza.

Il Garante privacy, al cit. punto «3.a. Albo pretorio online degli enti locali» delle Linee Guida, dispone che l’Amministrazione Locale che ha intenzione di pubblicare sull’albo pretorio on line un atto contenente dati personali è tenuta:

• a verificare, preliminarmente, per i dati comuni, l’esistenza di una norma di legge o di regolamento, oppure, per i dati “sensibili e giudiziari”, di una norma di legge che le prescriva l’affissione di quell’atto all’albo pretorio;
• sussiste il divieto di diffusione di dati idonei a rivelare lo stato di salute e cautele per gli altri dati “sensibili e giudiziari”, nonché divieto di diffondere dati personali non necessari, non pertinenti o eccedenti;
• trascorso il periodo temporale previsto dalle singole discipline per la pubblicazione degli atti e documenti nell’albo pretorio, «gli enti locali non possono continuare a diffondere i dati personali in essi contenuti. In caso contrario, si determinerebbe, per il periodo eccedente la durata prevista dalla normativa di riferimento, una diffusione dei dati personali illecita perché non supportata da idonei presupposti normativi»;
• le pubblicazioni, ai sensi del D.lgs. n. 33/2013, seguono le regole ivi previste.

Con riferimento alla permanenza nel web di dati personali contenuti nelle deliberazioni degli Enti locali, oltre il termine di quindici giorni, previsto dall’art. 124 del citato D.lgs. n. 267/2000, si è in presenza di una violazione degli obblighi di pubblicazione laddove non esista un diverso parametro legislativo o regolamentare che preveda la relativa diffusione.

A sostenere tale dovere di durata limitata «di quindici giorni», l’inciso secondo il quale:

• ove «la normativa di riferimento non indichi la durata temporale dell’affissione all’albo, l’amministrazione deve comunque individuare un congruo periodo di tempo – non superiore al periodo ritenuto, caso per caso, necessario al raggiungimento dello scopo per il quale l’atto è stato adottato e i dati stessi sono stati resi pubblici – entro il quale i dati personali devono rimanere disponibili»;
• alle pubblicazioni all’albo pretorio on line «non si applica l’arco temporale dei cinque anni previsto per la pubblicità di dati e informazioni sui siti web istituzionali per finalità di trasparenza di cui all’art. 8 del D.lgs. n. 33/2013».

Diritto all’oblio

Si perviene alla logica e conseguente conclusione che «una volta trascorso il periodo di pubblicazione previsto dalle singole discipline di riferimento oppure, in mancanza, decorso il periodo di tempo individuato dalla stessa amministrazione – se gli enti locali vogliono continuare a mantenere nel proprio sito web istituzionale gli atti e i documenti pubblicati, ad esempio nelle sezioni dedicate agli archivi degli atti e/o della normativa dell´ente, devono apportare gli opportuni accorgimenti per la tutela dei dati personali. In tali casi, quindi, è necessario provvedere a oscurare nella documentazione pubblicata i dati e le informazioni idonei a identificare, anche in maniera indiretta, i soggetti interessati».

Il Garante privacy osserva al termine del ragionamento che risulta sproporzionato rispetto alla finalità di pubblicità, consentire l’indiscriminata reperibilità in rete dei dati personali contenuti in atti e provvedimenti amministrativi tramite i comuni motori di ricerca generalisti, anzi si «consiglia alle amministrazioni pubbliche… di adottare gli opportuni accorgimenti tecnici per evitare l’indicizzazione nei motori di ricerca generalisti della documentazione contenente dati personali e pubblicata sull’albo pretorio online dei siti istituzionali degli enti locali».

Il precipitato dell’analisi giuridica postula che la diffusione (pubblicazione) on line degli atti deve essere coerente con la base giuridica di riferimento (15 giorni per le deliberazioni) insita nel diritto all’oblio, quel diritto alla riservatezza in relazione alla narrazione di fatti risalenti nel tempo[14], mentre qualora l’Amministrazione intenda estendere tale durata (pubblicazione ulteriore) dovrà omettere ogni dato personale presente nel testo deliberativo in assenza di una fonte primaria di riferimento (si dovrebbe escludere una fonte regolamentare interna)[15].

Osservare le regole dei termini di pubblicazione degli atti e documenti costituisce un’estensione del diritto all’oblio, quel diritto preteso da coloro che desiderano non vedere continuamente pubblicati i propri dati personali, ovvero quelle notizie relative a vicende passate, legittimamente diffuse, quando è trascorso un certo tempo dalla prima pubblicazione.

Il diritto all’oblio si riconnette anche all’uso di internet e alla reperibilità dei documenti e informazioni nella rete, consistente nell’esigenza di collocare nel tempo la pubblicazione[16], avvenuta lecitamente magari anni prima; ovvero, contestualizzare nell’attualità l’interesse alla permanenza della diffusione, correlato al diritto alla cancellazione dei propri dati personali non più corrispondenti all’interesse generale e al ruolo rivestito dall’interessato (ex art. 21 Cost.), minando (con la reperibilità dei motori di ricerca e la permanenza on line) inevitabilmente la dignità e il decoro individuale (ex art. 3 Cost.)[17].

Il permanere dei provvedimenti deliberativi, comprese le determinazioni, oltre i termini previsti dalla legge, non può che integrare la violazione del fondamentale diritto all’oblio[18], esponendo, peraltro, l’Amministrazione al permanere dei rischi in materia di sicurezza dei dati trattati e delle piattaforme on line (c.d. sicurezza cibernetica al fine di assicurare un livello elevato di sicurezza delle reti e dei sistemi informatici).

Accesso dopo la pubblicazione

Dunque, dopo la pubblicazione degli atti nei termini stabiliti dalle fonti di riferimento, gli stessi possono essere accessibili mediante il c.d. diritto di accesso civico generalizzato[19], secondo quanto previsto al comma 2 dell’art. 5, «Accesso civico a dati e documenti» del d.lgs. n. 33/2013, che dispone «Allo scopo di favorire forme diffuse di controllo sul perseguimento delle funzioni istituzionali e sull’utilizzo delle risorse pubbliche e di promuovere la partecipazione al dibattito pubblico, chiunque ha diritto di accedere ai dati e ai documenti detenuti dalle pubbliche amministrazioni, ulteriori rispetto a quelli oggetto di pubblicazione ai sensi del presente decreto, nel rispetto dei limiti relativi alla tutela di interessi giuridicamente rilevanti secondo quanto previsto dall’articolo 5-bis».

Giova rammentare che, all’esito di un’istanza di accesso generalizzato, il cittadino può ottenere la documentazione, i dati e le informazioni che gli fanno comprendere la scelta amministrativa effettuata e che rappresentano la decisione dell’Amministrazione, con la conseguenza che in linea di massima con l’accesso generalizzato si potrà avere una documentazione che consente una conoscenza meno “profonda” rispetto all’accesso documentale, ex art. 22 della Legge n. 241/1990, ma più estesa a tutta l’attività amministrativa e alle decisioni sulla spesa pubblica[20].

I costi dell’accesso

Per quanto concerne i costi dell’accesso, i commi 1 e 6 dell’art. 7 del d.P.R. 12 aprile 2006, n. 184 (regolamento recante la disciplina in materia di accesso) prevedono che «l’atto di accoglimento della richiesta di accesso contiene l’indicazione dell’ufficio, completa della sede, presso cui rivolgersi, nonché di un congruo periodo di tempo, comunque non inferiore a quindici giorni, per prendere visione dei documenti o per ottenerne copia» e che «in ogni caso, la copia dei documenti è rilasciata subordinatamente al pagamento degli importi dovuti ai sensi dell’articolo 25 della legge secondo le modalità determinate dalle singole amministrazioni. Su richiesta dell’interessato, le copie possono essere autenticate»[21].

In presenza di tale contesto normativo non risulta corretto ricavare implicitamente il principio che, qualora si tratti di atti reperibili nel sito web dell’Amministrazione, o di atti che l’Amministrazione è disposta a trasmettere per posta elettronica, venga meno l’obbligo di rilasciare la copia cartacea, ove motivatamente richiesta: il rilascio di documenti in formato digitale può avvenire mediante invio per posta elettronica o link, senza oneri e costi; mentre, quando si richiede la copia analogica, sono dovuti i costi di riproduzione e visura.

La Circolare n. 1 del 2019 «Attuazione delle norme sull’accesso civico generalizzato (c.d. FOIA)» della Funzione Pubblica, sul punto riferisce che «chiunque ha diritto di fruire “gratuitamente” di tutti i documenti, le informazioni e i dati oggetto di accesso civico, compresi quelli oggetto di pubblicazione obbligatoria (art. 3, comma 1), e che “il rilascio di dati o documenti in formato elettronico o cartaceo è gratuito, salvo il rimborso del costo effettivamente sostenuto e documentato dall’amministrazione per la riproduzione su supporti materiali” (art. 5, comma 4)».

Tuttavia, viene precisato che «è possibile addebitare al richiedente i soli costi di riproduzione e di spedizione dei documenti (se superiori a 20 pagine), mentre la consultazione in loco e l’accesso elettronico o tramite i registri è gratuita. La natura fondamentale del diritto di accesso civico generalizzato esclude che il rimborso possa costituire una barriera economica in grado di ostacolare l’esercizio del diritto… Innanzitutto, a fronte di una istanza di accesso civico generalizzato possono essere addebitati solo i costi strettamente necessari per la riproduzione di dati e documenti richiesti, ad esclusione di qualsiasi altro onere a carico del cittadino. In particolare, il costo rimborsabile, corrispondente a quello “effettivamente sostenuto e documentato dall’amministrazione per la riproduzione”, non include il costo per il personale impiegato nella trattazione delle richieste di accesso, essendo quest’ultimo un onere che, in linea di principio, grava sulla collettività che intenda dotarsi di un’amministrazione moderna e trasparente».

Viene, altresì, definito il costo per singola voce: «Nel costo di riproduzione del quale l’amministrazione può chiedere il rimborso rientrano le seguenti voci: – il costo per la fotoriproduzione su supporto cartaceo; – il costo per la copia o la riproduzione su supporti materiali (ad es. CD-rom); – il costo per la scansione di documenti disponibili esclusivamente in formato cartaceo, in quanto attività assimilabile alla fotoriproduzione e comunque utile alla più ampia fruizione favorita dalla dematerializzazione dei documenti (art. 42, d.lgs. n. 82 del 2005); – il costo di spedizione dei documenti, qualora espressamente richiesta in luogo dell’invio tramite posta elettronica o posta certificata e sempre che ciò non determini un onere eccessivo per la pubblica amministrazione».

A chiusura, si occupa di disporre che in assenza di discipline speciali di settore che stabiliscano specifiche modalità di accesso, «l’applicazione della disciplina generale in tema di accesso civico generalizzato non esclude che ai costi addebitabili al richiedente possano cumularsi – come avviene per l’accesso procedimentale alla documentazione urbanistica e/o edilizia – gli oneri in materia di bollo e i diritti di ricerca e visura… I costi di cui si chiede il rimborso devono essere predeterminati mediante un tariffario e comunque prospettati al richiedente prima delle attività di riproduzione. Le tariffe possono coincidere con quelle già adottate per l’accesso procedimentale, ferma restando la proporzionalità e la corrispondenza delle stesse al costo effettivamente sostenuto e documentato dalla pubblica amministrazione. Nel caso in cui un’amministrazione non si sia dotata di un tariffario in materia di accesso, occorre far riferimento ai prezzi medi praticati nel mercato di riferimento».

Note

[1] La durata dell’affissione è fissata in quindici giorni dall’art. 124 del D.lgs. n. 267 del 2000, norma che vale anche per le determinazioni dirigenziali comunali, Cons. Stato, sez. V, 18 giugno 2018, n. 3719.

[2] È noto che il termine per la proposizione del ricorso decorre per gli atti di cui non sia richiesta la notifica individuale, dal giorno in cui sia scaduto il termine della pubblicazione, se questa sia prevista da disposizioni di legge o di regolamento, Cons. Stato, sez. V, 8 luglio 2019, n. 4774. Tale pubblicazione implica, altresì, per i soggetti non contemplati nell’atto o ai quali l’atto stesso sia, in ogni caso, riferibile, presunzione di conoscenza, con la conseguenza che è dall’ultimo giorno di pubblicazione che decorre il termine decadenziale di sessanta giorni per proporre impugnazione avverso detto atto per i terzi interessati, T.A.R. Lazio, Latina, sez. I, 21 giugno 2018, n. 353.

[3] Nel caso di urgenza le deliberazioni possono essere dichiarate immediatamente eseguibili con lo scopo di salvaguardare l’effettività di quanto deciso dall’organo politico nelle more della pubblicazione dell’atto, al fine di evitare uno spazio temporale (dal giorno della deliberazione a quello dell’effettiva pubblicazione) che potrebbe tradire l’obiettivo della delibera medesima in modo deleterio per il pubblico interesse di volta in volta perseguito, così eliminando l’effetto annuncio connaturato all’ordinaria regola, di cui al terzo comma dell’art. 134 (in base alla quale la delibera diventa ordinariamente esecutiva solo trascorsi dieci giorni dalla sua pubblicazione), T.A.R. Piemonte, Torino sez. I, 6 febbraio 2015, n. 258.

[4] Cons. Stato, sez. V, 3 febbraio 2015, n. 515.

[5] Tale orientamento si fonda sull’interpretazione dell’allora art. 47 della Legge n. 142/1990, in sostanza coincidente con gli articoli 124 e 134 del TUEL, Cass. Civ., sez. I, 3 maggio 1999, n. 4397, idem T.A.R. Sardegna, 17 giugno 2002, n. 709.

[6] T.A.R. Lazio, Roma, sez. II ter, 11 marzo 2020, n. 3179.

[7] Per un’applicazione del principio, si rinvia a T.A.R. Calabria, Reggio Calabria, 5 aprile 2012, n. 269, secondo il quale «Nell’istituzione dell’Albo Pretorio si concretizza… quella più lata e risalente funzione partecipativa che è insita nella pubblicità degli atti e che ha costituito uno storico antesignano del sistema che poi è stato nel tempo costruito fino ad essere consacrato nella l. 241/90: essa risponde ad una delle più antiche forme di diffusione e conoscenza legale degli atti rivolti alla collettività, che, traendo le origini dalle istituzioni romane, ha trovato ininterrotta disciplina, nell’ordinamento nazionale, sin dall’ articolo 62 del Testo unico della legge comunale e provinciale approvato con R.D. 3 marzo 1934, n. 383, poi confluito con varie modifiche di regime nell’odierno art. 124 del D.lgs. 267/2000 e che ha ricevuto nuovo vigore dall’evoluzione della tecnologia che ne ha consentito una importante riedizione ed attualizzazione nella nuova veste dell’Albo Pretorio informatico (art. 32, L. nr. 69/2009). Nella prassi e nella giurisprudenza formatesi nel vigore delle normative poi susseguitesi, la pubblicazione all’Albo della deliberazione è stata sempre intesa come una fase integrativa dell’efficacia, che non incide sulla validità dell’atto, bensì solo sulla presunzione della sua conoscenza in capo ai terzi, tanto che la decorrenza dei termini dell’impugnazione dell’atto si computa a far data dalla scadenza dei termini di pubblicazione (si veda ex multis TAR Lazio, II, 4 febbraio 1985, nr. 141, TAR Palermo, 22 dicembre 1982, n. 877, Cons. Stato, Sez. V, 4 febbraio 1998. n. 127), senza che rilevi l’eventuale dichiarazione di immediata esecutività, che soltanto anticipa – in via provvisoria e condizionata all’avvenuta pubblicazione – l’efficacia dell’atto”)».

[8] T.A.R. Basilicata, Potenza, sez. I, 10 luglio 2014, n. 452; T.A.R. Puglia, Lecce, sez. I, 29 aprile 2014, n. 1128.

[9] Cfr. Corte Conti, sez. contr. Campania, 5 settembre 2018, n. 104.

[10] Si tratta di una previsione legale secondo cui, nel caso di atti non assoggettati a notifica individuale, il terminus a quo per l’impugnativa decorre dall’ultimo giorno della pubblicazione, se questa sia prevista da disposizioni di legge o di regolamento, Cons. Stato, sez. V, 27 settembre 2018, n. 5567.

[11] Le deliberazioni degli organi di governo, consiglio e giunta comunale, comprende anche le determinazioni dirigenziali, esprimendo la parola “deliberazione” ab antiquo sia risoluzioni adottate da organi collegiali che da organi monocratici ed essendo l’intento quello di rendere pubblici tutti gli atti degli Enti locali di esercizio del potere deliberativo, indipendentemente dalla natura collegiale o meno dell’organo emanante, Cons. Stato, sez. V, 15 marzo 2006, n. 1370.

[12] I provvedimenti, alias determinazioni, che non comportano impegni di spesa sono esecutivi dal momento della loro adozione, Cons. Stato, sez. V, 3 febbraio 2015, n. 515.

[13] Cons. Stato, sez. V, 11 maggio 2017, n. 2195.

[14] Il diritto all’oblio è legato anche all’eventuale richiesta del risarcimento del danno da illecito trattamento di dati personali, ravvisabile non già nel contenuto e nelle originarie modalità di pubblicazione e diffusione on line delle notizie (di cronaca) e nemmeno nella conservazione e archiviazione informatica di esso, ma nel mantenimento del diretto e agevole accesso a quell’informazione (servizio giornalistico) pubblicata diverso tempo addietro e della sua diffusione sul web oltre un termine ragionevole all’attualità del dato conoscitivo, con conseguente pregiudizio per i soggetti coinvolti, Cass. civ., sez. I, 24 giugno 2016, n. 13161.

[15] I Comuni non hanno alcun potere legislativo. Il potere regolamentare costituzionalmente previsto di loro pertinenza attiene alla disciplina dell’organizzazione e dello svolgimento delle funzioni loro attribuite, rilevando che il potere normativo attribuisce ai Comuni un potere regolamentare di carattere normativo nei limiti delle competenze che sono loro proprie (organizzazione e funzionamento delle istituzioni e degli organismi di partecipazione, oltre che degli organi e uffici e per l’esercizio delle funzioni proprie), T.A.R. Piemonte, Torino, sez. II, 17 ottobre 2017, n. 1125.

[16] Il diritto all’oblio non costituisce un annientamento della memoria storica, ma una corretta indicizzazione delle informazioni o notizie che vengono immesse in rete, RAZZANTE, Informazione: istruzioni per l’uso, Padova, 2014.

[17] Cass. Civ., sez. Unite, 22 luglio 2019, n. 19681.

[18] Cfr. Cass. Civ., sez. I, 20 marzo 2018, n. 6919.

[19] In materia di accesso agli atti, laddove l’Amministrazione, con riferimento agli stessi dati, documenti e informazioni, neghi il diritto di accesso ex legge n. 241/1990, motivando nel merito, cioè con la necessità di tutelare un interesse pubblico o privato prevalente, e quindi nonostante l’esistenza di una posizione soggettiva legittimante ai sensi della n. 241/1990, per ragioni di coerenza sistematica e a garanzia di posizioni individuali specificamente riconosciute dall’ordinamento, si deve ritenere che le stesse esigenze di tutela dell’interesse pubblico o privato sussistano anche in presenza di una richiesta di accesso generalizzato, anche presentata da altri soggetti, Cons. Stato (Ad. Plen.), 2 aprile 2020, n. 10.

[20] T.A.R. Campania, Napoli, sez. VI, 25 febbraio 2020, n. 857. Cfr. ANAC, «Linee guida recanti indicazioni operative ai fini della definizione delle esclusioni e dei limiti all’accesso civico di cui all’art.5 co.2 del d.lgs.33/2013. Art. 5-bis, comma 6, del d.lgs. n. 33 del 14/03/2013 recante «Riordino della disciplina riguardante il diritto di accesso civico e gli obblighi di pubblicità, trasparenza e diffusione di informazioni da parte delle pubbliche amministrazioni»», delibera n. 1309 del 28 dicembre 2016.

[21] Cfr. l’art. 25, comma 1, secondo periodo, della Legge n. 241/199, «L’esame dei documenti è gratuito. Il rilascio di copia è subordinato soltanto al rimborso del costo di riproduzione, salve le disposizioni vigenti in materia di bollo, nonché i diritti di ricerca e di visura».

Articolo a cura di Maurizio Lucca

https://www.ictsecuritymagazine.com/articoli/i-termini-di-pubblicazione-il-diritto-alloblio-e-i-costi-dellaccesso/

Da alcuni anni ho il privilegio di scrivere su questa rivista e durante l’emergenza COVID, che ci ha costretto a modificare diverse nostre abitudini, ho riletto i miei articoli pubblicati dal 2017 al mese di febbraio u.s.[1]. Tra questi mi hanno sollecitato nuove riflessioni e considerazioni – guarda caso – il primo e l’ultimo.

Nel primo del 2017[2] concludevo così: ”…auspico che il raggiunto traguardo dei dieci anni della Legge 18 marzo 2008, n. 48, non sopisca gli animi degli addetti ai lavori, ma anzi, serva come rinnovato impegno a continuare nella formazione di personale tra le forze di polizia. La speranza è quella di poter vedere uscire dalle scuole di formazione di polizia un “ufficiale di polizia giudiziaria 4.0”, pronto e preparato ad affrontare le sfide future di un inarrestabile e velocissimo progresso tecnologico che vedrà sempre di più presenti sulla scena del crimine dispositivi digitali prova dei delitti o elementi utili al prosieguo delle indagini e all’accertamento dei fatti”.

Mentre nell’ultimo del 2020[3] concludevo considerando che: “le FF.PP. devono essere adeguatamente “formate” a ogni livello per saper affrontare “i nuovi spazi” del crimine. È impensabile non dotare chi si trova in prima linea (come gli uffici denunce) degli strumenti culturali (corsi) e tecnologici (hardware e software) che possano aiutarli a ricevere, in modo adeguato ed efficace, una denuncia per fatti criminosi commessi attraverso una chat”.

Se sarebbe ingeneroso non evidenziare i lodevoli sforzi compiuti dalle FF.PP a soluzione delle problematiche sopra tratteggiate, e i passi finora brillantemente compiuti, il tema della formazione e della dotazione di strumenti adeguati ad affrontare le nuove “frontiere” del crimine è tema “caldo” e sempre più all’attenzione[4] nell’evidenza – ormai innegabile, come ho ribadito più volte che al di là delle classificazioni dottrinali tra crimini informatici e no – che oggi sia sempre più raro, se non impossibile, sviluppare indagini in contesti avulsi dal “digitale”; per dirla più brevemente, oggi potremo dire che non esiste “caso” che non veda per la sua soluzione, prova o documentazione la necessità di dover “trattare” dati digitali.

Con trattare mi riferisco genericamente a tutte quelle best practices, ormai internazionalmente riconosciute, che permettono alla prova digitale di essere considerata genuina, autentica e affidabile fin da quella fase embrionale del procedimento, rappresentata dalla denuncia di un fatto di reato che le FF.PP. sono obbligate a ricevere. Ho già avuto modo più volte di segnalare esempi concreti e casi specifici, che evidenziavano come le “tradizionali” modalità di acquisizione di una notizia di reato da parte della polizia giudiziaria richiedano alcune rivisitazioni, allorquando l’allegato alla denuncia è ormai, quasi sempre, rappresentato da un elemento “digitale” (un file). Ritengo che l’articolo richiamato in nota 2 possa essere ampliamente esplicativo ed esaustivo rispetto a queste criticità.

Nonostante i tratteggiati sforzi posti in essere dalle FF.PP., il personale “qualificato”/”specializzato” in digital forensics, o per dirla in altri modi “capace” di gestire fin dalla denuncia una “evidence digitale” non ha ancora raggiunto una così capillare diffusione da poter assicurare in ogni ufficio denunce la presenza di una di queste figure. Anzi, la loro fisiologica scarsità destina tale personale esperto verso reparti e attività maggiormente impegnati nel contrasto al crimine informatico, lasciando così “scoperto” quell’ambito – delicatissimo – rappresentato dalla denuncia: e si sa, come si dice in gergo, che “chi nasce male…” L’assenza di tale personale fin da quella fase embrionale riverbera, spesso, “errori” che si ripercuotono nella fase dibattimentale, ove magari dopo mesi di indagini, ci si può ritrovare con la cd. “prova regina” invalidata perché non acquisita, gestita e trattata nel rispetto di poche regole che ormai dovrebbero essere state “standardizzate” da ogni ufficiale di polizia giudiziaria.

Proprio su questa criticità rappresentata dall’assenza di personale “esperto” proprio laddove può nascere la notitia criminis (l’ufficio denunce di qualsiasi posto di polizia) mi sono giunte richieste su quali siano gli strumenti (magari open-source o comunque gratuiti) di cui l’U.P.G. 4.0. potrebbe dotarsi per raccogliere al meglio una denuncia ed evitare, così, di veder andare in “fumo” mesi di indagini. In merito, se da un lato è vero che molti avvocati ed esperti del settore prestano le propri capacità professionali anche nella redazione di notizie di reato indenni da queste problematiche, è altrettanto vero che l’ignaro cittadino comune è tutt’oggi convinto che la “stampa” del file dell’email o della chat siano di per sé abbondantemente sufficienti a supportare le loro ragioni in denuncia. Ma di questo abbiamo già ampiamente dibattuto in altri articoli.

Tornando alla domanda, la risposta non è così scontata e semplice e rivolta a più specialisti della materia si risolverebbe – e sono sicuro di non sbagliarmi – nella segnalazione di decine di prodotti diversi (anche se, in definitiva, fanno la stessa cosa) che spesso ottengono la preferenza rispetto ad altri sulla scorta di diverse ragioni:

• “è il primo che ho utilizzato e lo conosco meglio”;
• “lo usano tutti quelli di…”;
• “ho sempre avuto solo questo”;
• “quell’altro non funzionava, mi dava sempre errore”;
• …e tante altre che abbiamo sentito molte volte (“non gira su… io uso solo Linux… non digerisco MacOs”).

Penso che la scelta, per quanto legata a preferenze personali che possono essere le più diverse, richieda per una risposta esauriente un approfondito collaudo dei diversi tool e programmi, volto a testare:

• il rispetto delle best practices e della disciplina codicistica in materia;
• la loro efficacia ed efficienza rispetto il “fine” per cui vengono utilizzate;
• la loro facilità di apprendimento e utilizzo rispetto a una platea di utilizzatori che, sulle premesse fatte sopra, va allargata ben oltre quella più limitata e preparata dei cd. First Responder e Digital Evidence Specialist cui siamo soliti riferirci, dovendo ricomprendere quella che vorremo chiamare U.P.G. 4.0. e che dovrebbe quindi rivolgersi a tutti gli ufficiali di P.G. (quand’anche a quelli che lo sono solo nell’esercizio di determinate funzioni) e che non hanno particolari “cognizioni” in materia di digital forensics.

È evidente, come ho già avuto di evidenziare, che solo la “scuola” di formazione delle FF.PP. potrà in futuro colmare questo gap introducendo, tra le discipline del corso di formazione, anche corsi di digital forensics capaci di fornire a ciascun operatore le conoscenze minime per poter operare in un campo che ormai ha pervaso ogni ambito investigativo.

Nel panorama digital forensics esistono diverse suite del tipo “digital-forensics-oriented” quali BENTO, DART, TSURUGI, DEFT, KALI: tutte danno la possibilità in diversi contesti – live, post-mortem, laboratorio – di fare digital forensics a “costo-zero”, con eccellenti risultati, anche rispetto più rinomate e titolate suite commerciali; tuttavia il loro utilizzo richiede solide cognizioni e buone capacità e conoscenza anche della riga di comando (CLI), requisiti che, se patrimonio del personale First Responder e Digital Evidence Specialist delle varie specialità di polizia, si riscontrano più raramente nella “generalità” degli U.P.G. che, nella migliore delle ipotesi, hanno “minime”, se non “alquanto modeste”, cognizioni in materia.

Si è tentato più volte e in diversi modi di istruire tutto il personale sull’utilizzo di queste suite, quanto meno nell’uso dei tool cd. “essenziali”, ma la vastità degli strumenti a disposizione, anziché rassicurare, tende spesso a spaventare il profano che si orienta verso prodotti singoli che conosce meglio e sui quali si addestra più facilmente all’uso. Non è un caso, del resto, che le stesse suite abbiano delle versioni “acquire” destinate solo a questo scopo, “sfoltite” di quei tool che risulterebbero meno necessari in tale fase; e penso di non essere smentito nel considerare come il loro utilizzo sia “riservato” a personale esperto, in quanto solo un’approfondita conoscenza dei diversi tool di queste suite permette di riscontrarne appieno l’elevata efficacia e di apprezzarne gli effetti, essendo spesso costituite da un insieme di tool molto efficaci in singole attività e che, se sapientemente combinati tra loro, possono davvero competere – e talvolta superare – tool commerciali di più facile approccio.

Altrettanto evidente è considerare che chi non ha conoscenze “approfondite” è alla ricerca di soluzioni “one-click” che, seppur criticabili sul piano dell’efficienza ed efficacia, risultano comunque apprezzate per la loro facilità di utilizzo da chi non ha competenze specialistiche e non ha alcuna intenzione di acquisirle, ma è tuttavia disposto a seguire poche, semplici istruzioni.

Prendiamo per esempio un’operazione che potrebbe sembrare banale: come quella del calcolo di un hash su di un file operazione che, se affidata ad un “esperto” della materia, può vedere il ricorso a decine di tool e tecniche (da CLI è abbastanza semplice per l’esperto calcolare l’hash di un file).

Tutti ormai dovrebbero sapere cosa sia un “hash” ma, soprattutto, dovremmo aver raggiunto un grado di cultura informatica che ci permetta di dire che non dovrebbe esistere l’indicazione di un file priva del suo hash che lo “identifichi” compiutamente. Purtroppo non sempre è così e ancora pervengono notizie di reato e denunce corredate da files privi di qualsivoglia hash con la pericolosa conseguenza che, anche involontariamente, nei vari passaggi di mano della stesse può capitare che quei files vengano “modificati”, quant’anche involontariamente, con tutti gli “imbarazzanti” effetti che possono derivarne.

Non dovrebbe allora essere così complicato imporre a ogni UPG, qualora si ritrovi dinanzi a un elemento digitale (foto, file, video), di dover procedere al calcolo dell’hash e verbalizzarlo nell’atto della denuncia.

La già ricordata circolare della GDF, a pagina 31 del Volume 2, recita testualmente: “In ogni caso, e quale regola generale cui conformarsi anche in assenza dei militari CFDA, anche per l’acquisizione di singoli documenti informatici, è opportuno, ove tecnicamente possibile in relazione alle competenze degli operanti, calcolare un’impronta logico-matematica detta hash. La determinazione dell’impronta (rectius valore di hash e funzione di verifica) del documento informatico attraverso gli algoritmi di hash consente, infatti, unitamente alla documentazione delle attività svolte, di ricostruire le azioni svolte sui documenti informatici di interesse”.

Sottolineo “ove tecnicamente possibile in relazione alle competenze degli operanti”, vi è quindi consapevolezza che non tutto il personale abbia quelle competenze così minime.

Da tempo, quindi, occupandomi anche di formazione dei cd. First Responder – che, ribadisco, in quest’ottica rappresentano già un livello più avanzato rispetto all’ordinario U.P.G. – mi sono posto la domanda di come si possa, anche a livello di qualsiasi ufficio periferico di polizia, standardizzare procedure di acquisizione di denunce corredate da allegati digitali.

Inizialmente l’attenzione è caduta su singoli tool (per esempio HASH MY FILE[5], peraltro presente in diverse delle suite sopra citate) che, se contraddistinte da un’elementare facilità  d’uso (basta trascinare il file di cui si vuole calacolare l’hash all’interno della finestra), presentano un certo grado di complessità in ordine alla scelta dell’algoritmo, esportazione del report e tutta una serie di operazioni di copia/incolla, ridimensione della finestra per essere incollata in un file word, etc. non sempre di così facile e immediata realizzazione per un profano. Qui sento già qualcuno dire“basta allegare il report”: verissimo, tuttavia, per esperienza, spesso l’allegato si stacca dal verbale e si perde magari nel corso di fotocopie e quindi consiglio sempre di integrare gli hash direttamente nel verbale che non si perde (quasi) mai… sarò paranoico, ma preferisco così.

Sempre alla ricerca di soluzioni più facili per tutti (anche per i profani), l’attenzione è caduta su HashGen All in One [6]. A scapito dell’etimologia (che lo farebbe apparire, a prima vista, un software dedicato solo all’hash), quand’anche non corredato delle centinaia di tool delle più blasonate suite già sopra citate, capaci di assicurare con strumenti open-source una digital forensics a 360°, questo software presenta alcune “novità” e features meritevoli di particolare apprezzamento da parte degli operatori di P.G.

Ciò che mi ha positivamente colpito rispetto al caso che stiamo trattando – calcolo dell’hash – è la possibilità di generazione automatica del verbale di operazioni tecniche originato sulla base dei dati forniti di volta in volta dall’operatore che di fatto elimina quelle operazioni di copia/incolla dal programma o CLI di calcolo dell’hash al verbale che potrebbero ingenerare errori. Una procedura in pratica “automatizzata” attraverso la quale, con alcuni “pulsanti” di inequivocabile interpretazione, chiunque è in grado di poter generare l’hash di un file e redigere un adeguato “verbale” delle operazioni compiute.

Lo stesso, ovvero la generazione di un verbale, avviene in maniera semplificata anche con riferimento al cd. interprete di conversazioni whatsapp che permette, in maniera alquanto intuitiva, di redigere una verbalizzazione delle conversazioni di una chat whatsapp corredata di testo e immagini.

Molto utile anche l’acquisizione di riproduzioni fotografiche e l’estrazione automatica di tabulati telefonici che, unite a una funzione write-blocker altrettanto intuitiva e di facile attivazione, permettono di avere una “piccola” casetta di attrezzi essenziali per le più comuni attività di ricezione di denuncia (e non solo) che un comune U.P.G. 4.0 può trovarsi ad affrontare.

Conclusioni

Occorre sempre più cultura e formazione digitale per saper affrontare le nuove sfide tecnologiche: i reati sono sempre gli stessi, anche se sono profondamente cambiate le “dinamiche” e gli “oggetti” coinvolti, tanto da costringere gli U.P.G. 4.0 ad avvalersi di nuovi strumenti e tecniche fin dalla ricezione della denuncia. L’acquisizione, in sede di denuncia, di un file (magari prova regina!) non effettuata correttamente potrebbe solo, in sede dibattimentale e magari dopo mesi di impegnative indagini, venire “censurata” perché non “affidabile”, “genuina”, “garantita”.

Ben vengano allora, al fianco delle più blasonate suite forensi dedicate a personale maggiormente formato ed esperto, anche software come quello qui sopra citato che permettono anche al personale meno esperto di corredare correttamente una denuncia, acquisire un piccolo device e svolgere, in modo più agevole e sicuro, le “operazioni” più comuni che oggi l’U.P.G. 4.0 si trova ad affrontare fin da quella fase “embrionale” che è la denuncia.

Note

[1] https://www.ictsecuritymagazine.com/author/pier-luca-toselli/

[2] https://www.ictsecuritymagazine.com/articoli/legge-18-marzo-2008-n-48-lufficiale-polizia-giudiziaria-dieci-anni/

[3] https://www.ictsecuritymagazine.com/articoli/giovani-e-whatsapp-come-introdurre-una-chat-nel-processo/

[4] La Guardia di Finanza, con la circolare 1/2018, ha dimostrato grande sensibilità su questi temi, in considerazione di un rinnovato panorama operativo connaturato sempre più dalla dimensione digitale bisognoso di nuove “regole” e “procedure” per una corretta “gestione” dei dati. Ma anche le altre FF.PP. sono continuamente impegnate nella formazione di personale capace, fin dalle fasi preliminari, di gestire correttamente “l’evidence digitale”, nella consapevolezza che ormai “tutto è digitale”.

[5] https://www.nirsoft.net/utils/hash_my_files.html

[6] https://www.hashgen.it

Articolo a cura di Pier Luca Toselli

https://www.ictsecuritymagazine.com/articoli/lufficiale-di-p-g-4-0-quali-strumenti-per-le-operazioni-piu-comuni-che-coinvolgono-dati-digitali/

1. Breve premessa: sottoscrizione dei documenti informatici

La determinazione AGID n. 157/2020, «Emanazione delle Linee Guida per la sottoscrizione elettronica di documenti ai sensi dell’art. 20 del CAD», fornisce le indicazioni operative per firmare il documento informatico e attribuire una paternità certa all’atto (profili che possono essere traslati anche nei documenti amministrativi)

L’art. 20, «Validità ed efficacia probatoria dei documenti informatici», del d.lgs. n. 82/2005 stabilisce che il documento informativo firmato con firma digitale, o altro tipo di firma elettronica qualificata o una firma elettronica avanzata o, comunque, formato, previa identificazione informatica del suo autore:

• «soddisfa il requisito della forma scritta»;
• «ha l’efficacia prevista dall’articolo 2702 del Codice civile».

Le Linee guida, aventi carattere vincolante e valenza erga omnes (quale atto di regolamentazione di natura tecnica), disciplinano le modalità atte a garantire la sicurezza, integrità e immodificabilità del documento e, in maniera manifesta e inequivoca, la sua riconducibilità all’autore (osservazioni estensibili a tutti gli atti formati digitalmente).

Destinatari delle Linee guida sono:

• i fornitori di servizi e i gestori dell’identità (SP);
• gli utenti in qualità di fruitori del servizio.

L’utilizzo del dispositivo di firma elettronica qualificata o digitale si presume riconducibile al titolare di firma elettronica, salvo che questi dia prova contraria, con l’evidente intento di formulare la piena identità digitale (SPID, della persona fisica e per uso professionale), con il pieno diritto di accedere ai servizi on line offerti dai soggetti pubblici (P.A. e gestori di pubblici servizi)[1].

Viene indicata concretamente la procedura di sottoscrizione da parte del gestore e di riflesso dell’utente con le proprie credenziali, indicando il processo di generazione del file, e relative regole tecniche di sicurezza (c.d. sigillo elettronico qualificato e il suo formato, specifiche PDF versione 1.7 o successive, profilo PDF/A-2a, secondo lo standard ISO/IEC 32000)[2].

2. Formato aperto

Il comma 1 dell’art. 40, «formazione di documenti informatici», del d.lgs. n. 82/2005 stabilisce che «le pubbliche amministrazioni formano gli originali dei propri documenti, inclusi quelli inerenti ad albi, elenchi e pubblici registri, con mezzi informatici secondo le disposizioni di cui al presente codice e le Linee guida», con uno scopo di digitalizzare l’intera attività (inclusa la dematerializzazione, con conseguenti piani di sostituzione degli archivi cartacei con archivi informatici), che, associato al “protocollo informatico”, completa la tracciatura dei documenti ricevuti o spediti dalle Pubbliche Amministrazioni, ex art. 53 del decreto del Presidente della Repubblica 28 dicembre 2000, n. 445, ovvero le comunicazioni che provengono da o sono inviate a domicili digitali eletti, nonché le istanze e le dichiarazioni presentate per via telematica.

A ben vedere, se l’accesso ai servizi on line è la regola, questa visione prospettica impone la riorganizzazione strutturale e gestionale delle P.A., volta al perseguimento dell’utilizzo delle tecnologie dell’informazione e della comunicazione per la realizzazione degli obiettivi di efficienza, efficacia, economicità, imparzialità, trasparenza, semplificazione e partecipazione nel rispetto dei principi di uguaglianza e di non discriminazione, nonché per l’effettivo riconoscimento dei diritti dei cittadini e delle imprese alla cittadinanza digitale, in conformità agli obiettivi indicati nei Piani triennali per l’informatica.

Questo processo di trasformazione (con l’affidamento al Responsabile per la transizione digitale) impone alle Pubbliche Amministrazioni in particolare a razionalizzare e semplificare i procedimenti amministrativi, le attività gestionali, i documenti, la modulistica, le modalità di accesso e di presentazione delle istanze da parte dei cittadini e delle imprese mediante documenti digitali.

Di converso, la Pubblica Amministrazione dovrà estendere le forme di trasparenza (secondo il modello FOIA) con la pubblicità dei documenti nei portali, nell’albo pretorio on line, nella sez. «Amministrazione Trasparente» dei propri siti istituzionali.

I documenti amministrativi (compresi i provvedimenti) devono, quindi, essere redatti in formato digitale (ex art. 20 del CAD), con l’esigenza di distinguere (secondo le definizioni dell’art. 1 del CAD):

– FORMATO APERTO (comma 1, lettera l bis): un formato di dati reso pubblico, documentato esaustivamente e neutro rispetto agli strumenti tecnologici necessari per la fruizione dei dati stessi;

– DATI DI TIPO APERTO (comma 1, lettera l ter): i dati che presentano le seguenti caratteristiche:

• sono disponibili secondo i termini di una licenza o di una previsione normativa che ne permetta l’utilizzo da parte di chiunque, anche per finalità commerciali, in formato disaggregato;
• sono accessibili attraverso le tecnologie dell’informazione e della comunicazione, ivi comprese le reti telematiche pubbliche e private, in formati aperti ai sensi della lettera l bis), sono adatti all’utilizzo automatico da parte di programmi per elaboratori e sono provvisti dei relativi metadati;
• sono resi disponibili gratuitamente attraverso le tecnologie dell’informazione e della comunicazione, ivi comprese le reti telematiche pubbliche e private, oppure sono resi disponibili ai costi marginali sostenuti per la loro riproduzione e divulgazione salvo quanto previsto dall’articolo 7 del decreto legislativo 24 gennaio 2006, n. 36 (dove si precisa che i dati sono resi disponibili gratuitamente oppure, qualora per il riutilizzo di documenti sia richiesto un corrispettivo, quest’ultimo è limitato ai costi effettivi sostenuti per la loro riproduzione, messa a disposizione e divulgazione).

L’art. 68 del CAD, nel riferire sull’utilizzo di dati aperti, precisa: «le pubbliche amministrazioni acquisiscono programmi informatici o parti di essi nel rispetto dei princìpi di economicità e di efficienza, tutela degli investimenti, riuso e neutralità tecnologica, a seguito di una valutazione comparativa di tipo tecnico ed economico tra le seguenti soluzioni disponibili sul mercato: a) software sviluppato per conto della pubblica amministrazione; b) riutilizzo di software o parti di esso sviluppati per conto della pubblica amministrazione; c) software libero o a codice sorgente aperto; d) software fruibile in modalità cloud computing; e) software di tipo proprietario mediante ricorso a licenza d’uso; f) software combinazione delle precedenti soluzioni».

Inoltre, l’art. 23 ter, «Documenti amministrativi informatici», del d.lgs. n. 82/2005 dispone che «gli atti formati dalle pubbliche amministrazioni con strumenti informatici, nonché i dati e i documenti informatici detenuti dalle stesse, costituiscono informazione primaria ed originale da cui è possibile effettuare, su diversi o identici tipi di supporto, duplicazioni e copie per gli usi consentiti dalla legge».

Il primo comma dell’art. citato esprime una evidente esigenza di passare al digitale di tutti i documenti, rilevando al comma 1 bis che «la copia su supporto informatico di documenti formati dalle pubbliche amministrazioni in origine su supporto analogico è prodotta mediante processi e strumenti che assicurano che il documento informatico abbia contenuto identico a quello del documento analogico da cui è tratto, previo raffronto dei documenti o attraverso certificazione di processo nei casi in cui siano adottate tecniche in grado di garantire la corrispondenza del contenuto dell’originale e della copia».

Dunque, i documenti informatici (anche da copie analogiche), quando sono sottoscritti con firma digitale o di altra firma elettronica qualificata (nel rispetto delle Linee guida AGID), assolvono la loro funzione di autenticità, con l’obbligo di conservazione dell’originale del documento soddisfatto con la conservazione della copia su supporto informatico.

3. Pubblicazione dei documenti e dati aperti

Chiarito, nei passi precedenti, la stesura del documento digitale si tratta di verificare le modalità della pubblicazione partendo dall’art. 52, «Accesso telematico e riutilizzo dei dati» del CAD dove si chiarisce che i dati e i documenti soggetti a pubblicazione, con qualsiasi modalità, senza l’espressa adozione di una licenza si «intendono rilasciati come dati di tipo aperto ai sensi all’articolo 1, comma 1, lettere l bis) e l ter), del presente Codice, ad eccezione dei casi in cui la pubblicazione riguardi dati personali».

A rafforzare tale obbligo di pubblicazione digitale, con dati di tipo aperto, il comma 4 dell’art. 52 cit. stabilisce che «le attività volte a garantire l’accesso telematico e il riutilizzo dei dati delle pubbliche amministrazioni rientrano tra i parametri di valutazione della performance dirigenziale», segnando un evidente raffronto in termini di capacità di assolvere concretamente le funzioni assegnate, dove la digitalizzazione del procedimento amministrativo ricopre un obiettivo fondamentale per il singolo dirigente.

Questo ultimo aspetto è ancorato ad un ulteriore obbligo di trasparenza in capo ai dirigenti, segnato dal comma 1 quater dell’art. 14 del d.lgs. n. 33/2013, quando si richiede che «negli atti di conferimento di incarichi dirigenziali e nei relativi contratti sono riportati gli obiettivi di trasparenza, finalizzati a rendere i dati pubblicati di immediata comprensione e consultazione per il cittadino, con particolare riferimento ai dati di bilancio sulle spese e ai costi del personale, da indicare sia in modo aggregato che analitico. Il mancato raggiungimento dei suddetti obiettivi determina responsabilità dirigenziale ai sensi dell’articolo 21 del decreto legislativo 30 marzo 2001, n. 165», rafforzando l’obbligo con il dovere di verificare il raggiungimento dei suddetti obiettivi per un successivo conferimento di incarico dirigenziale.

Le due norme citate, con l’ulteriore apparato sanzionatorio previsto dagli artt. 46 e 47 del decreto Trasparenza (ex d.lgs. n. 33/2013)[3], impongono precisi obblighi di pubblicazione in capo alla dirigenza; obblighi di pubblicazione secondo il formato aperto, con le precisazioni che seguono.

In effetti l’art. 53, «Siti Internet delle pubbliche amministrazioni», del CAD a livello generale chiariscono gli obblighi di pubblicazione dei documenti, rispettosi dei principi di accessibilità, nonché di elevata usabilità e reperibilità, anche da parte delle persone disabili, completezza di informazione, chiarezza di linguaggio, affidabilità, semplicità dì consultazione, qualità, omogeneità e interoperabilità.

L’art. 53 CAD dispone, altresì, che le P.A. nei siti istituzionali devono:

• rendere facilmente reperibili e consultabili i dati, gli atti e i documenti di cui al decreto legislativo 14 marzo 2013, n. 33, nell’apposita sez. «Amministrazione trasparente»;
• pubblicare, ai sensi dell’articolo 9 del decreto legislativo 14 marzo 2013, n. 33, anche il catalogo dei dati e dei metadati, nonché delle relative banche dati in loro possesso e i regolamenti che disciplinano l’esercizio della facoltà di accesso telematico e il riutilizzo di tali dati e metadati, fatti salvi i dati presenti in Anagrafe tributaria.

Giova rammentare per gli atti da pubblicare in «Amministrazione trasparente» rispetto al c.d. albo pretorio on line che nelle Linee Guida n. 15/2014 del Garante privacy al punto «3.a. Albo pretorio online degli enti locali» (ma estensibile a tutte le P.A.), si affronta sia la pubblicazione per “ragioni di trasparenza”, sul modello FOIA (rectius quello del d.lgs. n. 33/2013) che per ragioni di “efficacia legale”[4] della pubblicazione che si intendono assolti con la pubblicazione nei propri siti informatici da parte delle Amministrazioni e degli Enti pubblici obbligati (ai sensi della Legge 18 giugno 2009, n. 69, recante «Disposizioni per lo sviluppo economico, la semplificazione, la competitività nonché in materia di processo civile»): aspetti diversi.

Si afferma che i documenti oggetto di pubblicazione obbligatoria, ex d.lgs. n. 33/2013, vanno ordinariamente pubblicati nei termini indicati dal cit. decreto Trasparenza, osservando che l’art. 8 «Decorrenza e durata dell’obbligo di pubblicazione» detta le regole generali: «i dati, le informazioni e i documenti oggetto di pubblicazione obbligatoria ai sensi della normativa vigente sono pubblicati per un periodo di 5 anni, decorrenti dal 1° gennaio dell’anno successivo a quello da cui decorre l’obbligo di pubblicazione, e comunque fino a che gli atti pubblicati producono i loro effetti, fatti salvi i diversi termini previsti dalla normativa in materia di trattamento dei dati personali e quanto previsto dagli articoli 14, comma 2, e 15, comma 4. Decorsi detti termini, i relativi dati e documenti sono accessibili ai sensi dell’articolo 5».

Si comprende che la norma indicata intende esprimere un concetto di pubblicazione legato ai termini individuati puntualmente ai fini della trasparenza, mentre in presenza di altre forme di trasparenza, quella legale, i termini sono individuati dalla fonte di riferimento speciale o specifica, come del resto per le pubblicazioni in generale dove bisogno individuare la base giuridica di legittimazione (c.d. base giuridica), specie quando sono presenti dati personali (identificativi).

Ad esempio, i provvedimenti amministrativi (quali le determinazioni/deliberazioni) per la loro pubblicazione (e la relativa durata in relazione al c.d. diritto all’oblio) devono trovare la propria fonte nella norma di riferimento, avendo cura di rilevare che l’art. 23  – «Obblighi di pubblicazione concernenti i provvedimenti amministrativi» – del d.lgs. n. 33/2013 dispone che tali determinazioni (i provvedimenti adottati dagli organi di indirizzo politico e dai dirigenti) sono pubblicate e aggiornate ogni sei mesi, in distinte partizioni della sezione «Amministrazione trasparente», non in forma integrale ma «in elenchi», con particolare riferimento ai provvedimenti finali dei procedimenti di:

• scelta del contraente per l’affidamento di lavori, forniture e servizi, anche con riferimento alla modalità di selezione prescelta ai sensi del codice dei contratti pubblici, relativi a lavori, servizi e forniture, di cui al decreto legislativo 18 aprile 2016, n. 50, fermo restando quanto previsto dall’articolo 9 bis;
• accordi stipulati dall’Amministrazione con soggetti privati o con altre amministrazioni pubbliche, ai sensi degli articoli 11 e 15 della legge 7 agosto 1990, n. 241.

Per gli altri atti, documenti e provvedimenti è necessario riferirsi alle diverse forme di pubblicità individuate dal d.lgs. n. 33/2013, meglio descritte nei singoli adempimenti nella determinazione ANAC n. 1310 del 28 dicembre 2016, «Prime linee guida recanti indicazioni sull’attuazione degli obblighi di pubblicità, trasparenza e diffusione di informazioni contenute nel d.lgs. 33/2013 come modificato dal d.lgs. 97/2016».

Occorre rammentare, in termini di trasparenza e formato aperto, che il comma 35, lettera f) dell’art. 1 della legge n. 190/2012, obbligava «di pubblicare tutti gli atti, i documenti e le informazioni di cui al presente comma anche in formato elettronico elaborabile e in formati di dati aperti. Per formati di dati aperti si devono intendere almeno i dati resi disponibili e fruibili on line in formati non proprietari, a condizioni tali da permetterne il più ampio riutilizzo anche a fini statistici e la ridistribuzione senza ulteriori restrizioni d’uso, di riuso o di diffusione diverse dall’obbligo di citare la fonte e di rispettarne l’integrità».

4. Pubblicazione dei dati, delle informazioni e dei documenti

Il Capo I ter «Pubblicazione dei dati, delle informazioni e dei documenti» del d.lgs. n. 33/2013 si occupa di stabilire come vanno pubblicati tutti i documenti:

Art. 6 – QUALITÀ DELLE INFORMAZIONI: le informazioni riportate nei siti istituzionali devono rispettare gli obblighi di pubblicazione previsti dalla legge, assicurandone l’integrità, il costante aggiornamento, la completezza, la tempestività, la semplicità di consultazione, la comprensibilità, l’omogeneità, la facile accessibilità, nonché la conformità ai documenti originali in possesso dell’Amministrazione, l’indicazione della loro provenienza e la riutilizzabilità: la pubblicazione deve rispettare i termini previsti nel decreto Trasparenza: la qualità delle informazioni diffuse non può, in ogni caso, costituire motivo per l’omessa o ritardata pubblicazione dei dati, delle informazioni e dei documenti.

Art. 7 – DATI APERTI E RIUTILIZZO (c.d. open data): i documenti, le informazioni e i dati oggetto di pubblicazione obbligatoria, resi disponibili anche a seguito dell’accesso civico sono pubblicati:

• in formato di tipo aperto, ai sensi dell’68 del CAD[5];
• e riutilizzabili ai sensi del decreto legislativo 24 gennaio 2006, n. 36, del decreto legislativo 7 marzo 2005, n. 82, e del decreto legislativo 30 giugno 2003, n. 196, senza ulteriori restrizioni diverse dall’obbligo di citare la fonte e di rispettarne l’integrità.

Il Garante privacy[6] annota, sul punto, che il riutilizzo di tali documenti non deve pregiudicare il livello di tutela delle persone fisiche con riguardo al trattamento dei dati personali fissato dalle disposizioni di diritto europeo e nazionale in materia: le nuove disposizioni introducono specifiche eccezioni al riutilizzo fondate sui principi di protezione dei dati, prevedendo che una serie di documenti del settore pubblico contenenti tale tipologia di informazioni siano sottratti al riuso anche qualora siano liberamente accessibili online.

Si ricava che il principio generale del libero riutilizzo di documenti contenenti dati pubblici, stabilito dalla disciplina nazionale ed europea, riguarda essenzialmente documenti che non contengono dati personali oppure riguarda dati personali opportunamente aggregati e resi anonimi.

Conclude il Garante privacy che il semplice fatto che informazioni personali siano rese pubblicamente conoscibili on line per finalità di trasparenza questo non significa che le stesse siano liberamente riutilizzabili da chiunque e per qualsiasi scopo, bensì impone al soggetto chiamato a dare attuazione agli obblighi di pubblicazione sul proprio sito web istituzionale di determinare – qualora intenda rendere i dati riutilizzabili – se, per quali finalità e secondo quali limiti e condizioni eventuali utilizzi ulteriori dei dati personali resi pubblici possano ritenersi leciti alla luce del “principio di finalità” e degli altri principi di matrice europea in materia di protezione dei dati personali.

Art. 7 bis – RIUTILIZZO DEI DATI PUBBLICATI: dove si distinguono le pubblicazioni contenenti dati personali, diversi dai dati sensibili e dai dati giudiziari, che comportano la possibilità di una diffusione dei dati medesimi attraverso siti istituzionali, nonché il loro trattamento secondo modalità che ne consentono la indicizzazione e la rintracciabilità tramite i motori di ricerca web e il loro riutilizzo, ai sensi dell’articolo 7, nel rispetto dei principi sul trattamento dei dati personali.

Le pubblicazioni ulteriori, ovvero quello che non sussiste un obbligo di pubblicazione ai sensi del decreto Trasparenza o sulla base di specifica previsione di legge o regolamento, nel rispetto dei limiti indicati dall’articolo 5 bis, devono avvenire in forma anonima per i dati personali eventualmente presenti, con evidenti limitazioni in presenza di dati riferiti a determinate situazioni, rendendo non intelligibili i dati personali non pertinenti o, se sensibili o giudiziari, non indispensabili rispetto alle specifiche finalità di trasparenza della pubblicazione.

ART. 8 DECORRENZA E DURATA DELL’OBBLIGO DI PUBBLICAZIONE: vengono previsti i termini ordinatori di pubblicazione (salvo i casi specifici) il c.d. diritto all’oblio (cancellazione)[7]:

• i dati, le informazioni e i documenti oggetto di pubblicazione obbligatoria ai sensi della normativa vigente sono pubblicati per un periodo di 5 anni, decorrenti dal 1° gennaio dell’anno successivo a quello da cui decorre l’obbligo di pubblicazione, e comunque fino a che gli atti pubblicati producono i loro effetti, fatti salvi i diversi termini previsti dalla normativa in materia di trattamento dei dati personali e quanto previsto dagli articoli 14, comma 2, e 15, comma 4;
• decorsi detti termini, i relativi dati e documenti sono accessibili ai sensi dell’articolo 5 (accesso civico).

ART. 9 ACCESSO ALLE INFORMAZIONI PUBBLICATE NEI SITI: indica l’obbligo di inserire nella home page dei siti istituzionali un’apposita sezione denominata «Amministrazione trasparente», al cui interno sono contenuti i dati, le informazioni e i documenti pubblicati ai sensi della normativa vigente.

Per evitare eventuali duplicazioni, la suddetta pubblicazione può essere sostituita da un collegamento ipertestuale alla sezione del sito in cui sono presenti i relativi dati, informazioni o documenti, assicurando la qualità delle informazioni di cui all’articolo 6, chiarendo un dovere di natura cogente che impedisce alle P.A. di disporre filtri e altre soluzioni tecniche atte ad impedire ai motori di ricerca web di indicizzare ed effettuare ricerche all’interno della sezione «Amministrazione trasparente», salvo ovviamente i casi in cui siano presenti dati personali (particolari, i c.d. “ex sensibili” e giudiziari, o che creino disagio).

In effetti, la presenza di documenti, caso di specie, graduatorie, visibili e liberamente scaricabili, con la presenza di dati personali (indirizzo di residenza ed e-mail, codice fiscale, numero di telefono, dati riferiti all’invalidità) non è coerente con le regole sulla pubblicazione degli atti nel sito web istituzionale, atteso che le ulteriori informazioni di carattere personale relative ai soggetti inseriti nei testi documentali non risultano necessarie rispetto alla finalità perseguite con la pubblicazione.

Il Garante per la protezione dei dati personali conferma che la pubblicazione in chiaro, anche di informazioni non necessarie rispetto alle finalità perseguite con la pubblicazione, nonché dati relativi alla salute di taluni docenti, risulta un trattamento non conforme alla disciplina rilevante in materia di protezione dei dati personali, in violazione (oltre all’applicazione di una sanzione):

• dei principi di “liceità, correttezza e trasparenza” e di “minimizzazione dei dati”, di cui all’art. 5, par. 1, (par. 1, lett. a) e c) del Regolamento UE 679/2016;
• in assenza di un presupposto normativo per la pubblicazione, di cui all’art. 6, par. 1, lett. c) ed e), par. 2 e par. 3, lett. b), del Regolamento e 2 ter, commi 1 e 3, del Codice in materia di protezione dei dati personali;
• del divieto di diffusione di dati relativi alla salute, di cui all’art. 9, parr. 1, 2, 4, del Regolamento e art. 2 septies, comma 8, del Codice[8].

Note

[1] La firma digitale in formato CAdES dà luogo un file con estensione finale <*.p7m> e può essere apposta a qualsiasi tipo di file, ma per visualizzare il documento oggetto della sottoscrizione è necessario utilizzare un’applicazione specifica. Invece, la firma digitale in formato PAdES, più nota come «firma PDF», è un file con normale estensione <*.pdf>, leggibile con i comuni readers disponibili per questo formato, sicché sussiste la piena equivalenza, riconosciuta a livello europeo, delle firme digitali nei formati CAdES e PAdES:, secondo la normativa nazionale, la struttura del documento firmato può essere indifferentemente PAdES o CAdES, Cass. civ, sezioni Unite, 27 aprile 2018, n. 10266.

[2] La c.d. “marcatura temporale” è il processo con cui un certificatore accreditato crea e appone su un documento informatico, digitale o elettronico una “firma digitale del documento” alla quale sono associate le informazioni relative alla data e all’ora di creazione che, ove siano state seguite le regole tecniche sulla validazione temporale, sono così opponibili ai terzi, Cass. civ., sez. I, ord., 13 febbraio 2019, n. 4251.

[3] Vedi il comma 7 dell’art. 1, del D.L. n. 162/2019, «Disposizioni urgenti in materia di proroga di termini legislativi, di organizzazione delle pubbliche amministrazioni, nonché di innovazione tecnologica».

[4] Si tratta di una previsione legale secondo cui, nel caso di atti non assoggettati a notifica individuale, il terminus a quo per l’impugnativa decorre dall’ultimo giorno della pubblicazione, se questa sia prevista da disposizioni di legge o di regolamento, Cons. Stato, sez. V, 27 settembre 2018, n. 5567.

[5] Sulla tipologia del formato si vedano DPCM 10 dicembre 2008, «Specifiche tecniche del formato elettronico elaborabile (XBRL) per la presentazione dei bilanci di esercizio e consolidati e di altri atti al registro delle imprese»; DPCM 13 novembre 2014, «Regole tecniche in materia di formazione, trasmissione, copia, duplicazione, riproduzione e validazione temporale dei documenti informatici nonché di formazione e conservazione dei documenti informatici delle pubbliche amministrazioni ai sensi degli articoli 20, 22, 23 -bis, 23 -ter, 40, comma 1, 41, e 71, comma 1, del Codice dell’amministrazione digitale di cui al decreto legislativo n. 82 del 2005»; Direttiva 2013/37/UE che modifica la direttiva 2003/98/CE relativa al riutilizzo dell’informazione del settore pubblico. Secondo le indicazioni AGID, i “Formati aperti” sono: «il formato dei dati digitali si definisce “aperto” quando ne viene resa pubblica, mediante esaustiva documentazione, la sintassi, la semantica, il contesto operativo e le modalità di utilizzo. Tali informazioni, unitamente ad una guida all’uso del formato, orientata alla lettura da parte dell’utilizzatore, devono essere presenti in uno o più documenti rilasciati dall’ente proponente lo standard».

[6] Garante per la protezione dei dati personali, «Linee guida in materia di trattamento di dati personali, contenuti anche in atti e documenti amministrativi, effettuato per finalità di pubblicità e trasparenza sul web da soggetti pubblici e da altri enti obbligati», Reg. provvedimenti n. 243 del 15 maggio 2014.

[7] La pubblicazione di un’informazione concernente una persona determinata, a distanza di tempo da fatti e avvenimenti che la riguardano, non può che integrare la violazione del fondamentale diritto all’oblio; Cass., sez. I, 20 marzo 2018, n. 6919.

[8] Garante per la protezione dei dati personali, doc. web n. 9283014, «Ordinanza ingiunzione nei confronti di …», Registro dei provvedimenti n. 21 del 30 gennaio 2020.

Articolo a cura di Maurizio Lucca

https://www.ictsecuritymagazine.com/articoli/pubblicazione-e-formato-aperto-dei-documenti-amministrativi/

Incipit

L’articolo tratta la terza e ultima parte della CTF Necromancer, tenuta come lezione all’Università di Perugia in occasione dell’evento CyberChallenge.

Prima Parte:  https://www.ictsecuritymagazine.com/articoli/a-case-history-ctf-necromancer-parte-1/.
Seconda Parte:  https://www.ictsecuritymagazine.com/articoli/a-case-history-ctf-necromancer-parte-2/

Nella tetra penombra della grotta, con il nostro talismano al collo ed uno sciame di pipistrelli, ormai riverso e orrendamente mutilato sul freddo pavimento, avevamo volto lo sguardo verso il soffitto della grotta, scorgendo la scritta impressa col sangue: thenecromancerwillabsorbyoursoul/.

FLAG – 06.

Probabilmente si trattava di un’altra pagina URL, come ne avevo già trovate in precedenza. Un altro percorso all’interno dell’URL.

Quindi, aprii il mio browser ed inserii il percorso nella barra degli indirizzi, per rivelare la FLAG 06:

192.168.178.37/thenecromancerwillabsorbyoursoul/

Continui ad attraversare la caverna. In lontananza puoi vedere un familiare tremolio di luce che si muove dentro e fuori dall’ombra. Mentre ti avvicini alla luce, puoi sentire dei deboli passi, seguiti dal suono di una pesante apertura della porta. Ti avvicini e poi ti fermi impietrito dalla paura. È il negromante! Ancora una volta ti fissa con occhi mortalmente vuoti. È in piedi sulla soglia; uno staffa in una mano e un oggetto nell’altra. Sorridendo, il negromante tiene in aria il bastone e l’oggetto. Punta il suo bastone nella tua direzione e la puzza di morte e decadenza inizia a riempire l’aria. Lo guardi negli occhi e poi ……. …… buio. Apri gli occhi e ti ritrovi sdraiato sul pavimento umido della grotta. L’amuleto deve averti salvato dall’ incantesimo lanciato dal negromante. Ti alzi in piedi. Dietro di te, solo l’oscurità. Davanti a te, una grande porta con il simbolo di un teschio inciso sulla superficie. Guardando più da vicino il cranio, puoi vedere u161 inciso sulla fronte.

FLAG – 07.

Ancora una porta: u161 . La “u”, come già era accaduto, identificava lo User Datagram Protocol (UDP), che avevamo trovato per la prima volta durante la FLAG 02, nella prima parte del Necromancer.

Una delle caratteristiche delle porte di rete è che convenzionalmente indentificano una particolare connessione attiva sulla macchina. Così, ad esempio, la porta 25 viene utilizzata per i servizi di posta SMTP, la porta 80 per l’http, 22 l’ SSH , la 21 per l’FTP e così via.

La nostra porta 161 / UDP, viene utilizzata per il protocollo noto come Simple Network Management Protocol (SNMP). Si tratta di un protocollo studiato per la gestione elementare di un determinato dispositivo di rete, come ad esempio un telefono, una stampante, un router, un PC, etc.

L’architettura del SNMP è basata su un modello client-server: i server vengono chiamati manager; gli altri dispositivi o componenti che si possono interfacciare con la rete, sono gli agent.

L’ SNMP utilizza un modello “ad albero” per lo scambio di dati: i “rami” dell’ “albero” sono delle tabelle che prendono il nome di Management Information Bases (MIB). All’interno di ogni MIB si trovano le “foglie”, chiamate nodi, che rappresentano i dispositivi o i componenti connessi alla rete.

Per identificare univocamente un nodo e quindi un dispositivo connesso, si utilizza un Object Identifier (OID).

L’OID è composto da: il numero (o la stringa) che identifica il MIB + un numero (o una stringa) che identifica un dato device (ad esempio: 1.3.6.1.4.234.2.4.1.2.1.1.1.3.1234.3).

Gli agent che ricevono la richiesta di fornire informazioni, prima di rispondere, si assicurano che il richiedente abbia i permessi per effettuare tale richiesta. Nelle versioni SNMP 1 e 2, la prassi è che il manager si presenta all’agent, specificando un “nome della comunità”, ovvero il “community name”.

Ciò che mi mancava era proprio il community name, il mio tesserino d’identificazione per presentarmi via SNMP al mio agent e dirgli: “Eccomi! Sono autorizzato a ricevere o inviare informazioni!”

Accantonai quindi per un attimo la mia porta 161 e tornai a dedicarmi alla pagina web che stavo esplorando. La scritta “necromancer!”, così sottolineata [Figura 36], era un chiaro richiamo. Quindi, decisi di cliccarla. Apparve una finestra che mi chiedeva di scaricare un file d’archivio denominato: “necromancer”. [Figura 37].

Utilizzai il comando tar per estrarre l’archivio:

• tar: comando
• x : per estrarre i file da un archivio
• j : compressione attraverso bzip2
• v  : verbose (per aggiungere più informazioni all’output del comando, mostrando l’elaborazione)
• f :nome del file archivio
• necromancer : il nome d’archivio da cui volevamo procedere all’estrazione

Il risultato dell’estrazione fu un file Packet Capture (cap file) [Figura 38], denominato necromancer. Uno dei modi in cui è possibile aprire questo tipo di file, è utilizzando Wireshark.

Digitando wireshark necromancer.cap [Figura 39] mi apparve il risultato dello sniffing del traffico Wireless 802.11.

Solitamente, uno dei modi per craccare una rete WiFi protetta con il protocollo WPA/WPA2, è quello di mettersi in “modalità ascolto” attraverso la scheda wireless per individuare la rete bersaglio, quindi il MAC del router e il canale radio utilizzato. A questo punto, si monitora la rete target sino a quando un dispositivo non si connette ad essa ed esegue l’“handshake”. Dopodiché sarà sufficiente salvare il file .cap, convertirlo e craccarlo (utilizzando hashcat, ad esempio).

Il file necromancer.cap trovato, doveva essere il risultato di un’ultima fase di cattura dell’handshake di un’ipotetica rete wireless. Non dovevo far altro che convertirlo nel formato hccapx e successivamente craccarlo.

hccapx è un particolare formato di file sviluppato appositamente per il programma hashcat e utilizzato per hash di tipologia WPA/WPA2. Al fine di generare il file con la data estensione, si utilizza il tool cap2hccapx, scaricabile al seguente indirizzo: https://hashcat.net/wiki/doku.php?id=hashcat_utils

Per la conversione fu sufficiente eseguire il comando:

• cap2hccapx : utility di conversione
• cap  : file .cap da convertire
• hccapx  : risultato della conversione desiderato (nomefile.hccapx)

Non rimaneva altro da fare che trovare la nostra chiave, utilizzando hashcat. Per farlo, bastò procedere come avevo fatto per l’hash trovato alla FLAG02 [Figura 9]. L’unica differenza, era rappresentata dal parametro d’identificazione del hash –m . Poiché non avrei craccato un hash MD5 ma una chiave WPA, il parametro da specificare sarebbe stato –m 2500.

Dato invio, furono sufficienti pochi secondi per decriptare la chiave: death2all

Nota: Un altro modo per estrarre la chiave, sarebbe stato quello di utilizzare: aicrack-ng

• aircrack-ng : comando
• cap  : file .cap da craccare
• -w : parametro per specificare lawordlist
• /usr/share/wordlist/rockyou.txt : wordlist utilizzata

Finalmente, avevo il nostro community name. Ora avrei potuto utilizzare metasploit per l’enumeration e vedere cosa sarebbe accaduto.

La prima cosa che feci fu avviare la metasploit tramite il comando msfconsole:

Selezionai il modulo da lanciare:

• use : comando di selezione del modulo
• auxiliary/scanner/snmp/snmp_enum : percorso del modulo

Per utilizzare il modulo, adattandolo ai miei scopi, avrei dovuto settare esattamente due opzioni prima di lanciarlo:

1. I’IP bersaglio
2. Il Community Name

1° Opzione:

• set : inserisci
• RHOSTS : parametro per specificare l’host remoto (la macchina bersaglio)
• 168.178.37 : IP bersaglio (la macchina Virtuale della CTF Necromancer)

2° Opzione:

• set : inserisci
• COMMUNITY: il parametro per il community name
• death2all : il Community Name che avevo appena trovato.

Infine, lo lanciai: run

Temi il Necromante! Ti trovi dinanzi alla porta. La porta è chiusa. Se vuoi sconfiggermi, dovrai aprire la porta. Locked – death2allrw!

C’ero quasi, il community name trovato (death2all) mi aveva permesso di autenticarmi nella procedura prevista dal protocollo SNMP. Ora, dovevo aprire la porta. Ciò che non sapevo era “dove” si trovasse questa porta. Lasciai in standby il terminale di metasploit e ne aprii un altro.

Abbiamo detto che all’interno della struttura SNMP ogni OID è composto da: il numero (o la stringa) che identifica il MIB + un numero (o una stringa) che identifica un dato device. (Ad esempio: 1.3.6.1.4.234.2.4.1.2.1.1.1.3.1234.3). La domanda da porsi era quindi: qual è l’OID della porta di “death2allrw!”?

Il tool snmpwalk faceva al caso mio. Esso, infatti, permette di enumerare tutti i device SNMP.

• snmpwalk : comando
• -c : opzioni per specificare la Community String
• death2allrw : il nome della community string che avevo trovato [Figura 40]
• -v : opzione per specificare la versione del SNMP in uso
• 1 : versione in uso
• 168.178.37 : IP della VM Necromante
• | : operatore pipe
• grep: estrai solo…
• death2all : la riga che contiene

Avevo così ottenuto il mio OID: iso.3.6.1.2.1.1.6.0. Ed il valore della stringa era: STRING: “Locked – death2allrw!”

Adesso, non dovevo far altro che aprire la porta. Per farlo, mi servii di un altro tool: snmpset

• snmpset : comando utilizzato per modificare le informazioni nell’host remoto
• -v : opzione per specificare la versione del SNMP in uso
• 2c : versione SNMP in uso
• -c : community string
• death2allrw : la mia community string
• 168.178.37 : IP della VM Necromante
• 3.6.1.2.1.1.6.0 : Primo Valore dell’OID, più…
• string: opzione per specificare la stringa
• “Unlocked – death2allrw!”: …il nuovo valore della stringa da sostituire al vecchio

Questa volta, quando tornai sul terminale di metasploit e rilanciai il modulo di snmp_enum, il risultato fu la FLAG07! [Figura 41]

Temi il Necromante! Ti trovi dinanzi alla porta. La Porta è aperta! Ora puoi entrare nel nascondiglio del Necromante! flag7{9e5494108d10bbd5f9e7ae52239546c4} – t22

Craccai l’hash, come fatto sino ad ora, e il risultato fu: demonslayer

FLAG – 08.

Come accaduto in precedenza, assieme all’hash della flag ottenni anche un altro indizio: t22 [Figura 41]. La porta 22 è “celebre” per il suo protocollo di Secure SHell (SSH) che permette di stabilire una sessione remota, cifrata, con un altro host.

Provai quindi a connettermi al Necromante via ssh, utilizzando il risultato dell’hash craccato (della FLAG07) come username:

Il primo impulso fu quello di provare a inserire come password “Necromancer”, ma fu tentativo a vuoto. Dovevo brut-forzare il protocollo ssh. Decisi quindi di utilizzare hydra, un tool che permette di effettuare attacchi brute-force a vari servizi, come: ftp, ssh, MY-SQL, etc…

• hydra : comando utilizzato per richiamare il tool
• -s : porta
• 22 : il numero della porta ssh
• -l : username con il quale si tenta il login
• demonslayer : il mio username, ottenuto dall’hash della FLAG07
• -P : parametro per specificare la wordlist
• /usr/share/wordlists/rockyou.txt : percorso della mia wordlist “rockyou.txt”
• 168.178.37: l’host target (l’indirizzo IP del Necromancer)
• “ssh”: il protocollo da attaccare

Ci vollero circa dieci secondi prima che hydra trovasse la password: 12345678. [Figura 42]

Nota: sarebbe stato possibile eseguire lo stesso attacco utilizzando metasploit:
auxiliary/scanner/ssh/ssh_login

Ora, non mi rimaneva che addentrami nel covo del Necromante per fronteggiarlo.

• ssh : richiesta di connessione al protocollo
• demonslayer : nome utente
• @192.168.178.37 : connessione verso l’indirizzo IP della macchina

Alla richiesta della password per l’utente demonslayer, digitai quella che avevo appena trovato: 12345678. [Figura 42]

Ero dentro! Mi trovavo sulla directory home dell’utente demonslayer. Diedi subito un’occhiata, listando il contenuto della folder con il comando ls. Apparve un file di testo: flag8.txt . Il comando cat mi rivelò il contenuto:

Entri nella caverna del Negromante! Una puzza di decomposizione riempie questo posto. Barattoli pieni di parti di diverse creature, sporcano gli scaffali. Un fuoco con fiamme verdi brucia freddamente in lontananza. In piedi nel mezzo della stanza, con le spalle rivolte verso di te, c’è il Negromante. Di fronte a lui, giace un cadavere indistinguibile di una creatura vivente ma vista prima. Tiene un bastone in una mano e l’oggetto tremolante nell’altra. “Sei un pazzo a seguirmi qui! Non sai chi sono!” Il negromante si gira verso di te. Parole oscure riempiono l’aria! “Sei già dannato, amico mio. Adesso preparati alla tua morte!” Difenditi! Contrattacca gli incantesimi del Negromante su u777!

Eravamo giunti alla resa dei conti.
Un’altra porta UDP, la 777. Questa volta non sarebbe servito l’IP della macchina remota, poiché eravamo già connessi tramite SSH alla macchina target. Il parametro fu localhost ed il numero della porta.

** Ti rimangono solo 3 punti ferita! **  Difenditi dagli incantesimi del Negromante!  Where do the Black Robes practice magic of the Greater Path?

 L’ultima frase suonava come un indovinello: “Where do the Black Robes practice magic of the Greater Path?”. Ottenni la riposta da Google: “Kelewan”. E con essa, la flag numero 8.

FLAG – 09, 10

Le FLAG 09 e 10, richiesero anch’esse svariati minuti di ricerca attraverso Google. Ma, alla fine, ottenni le risposte alle due domande [Figura 43]:

“Who did Johann Faust VIII make a deal with?” “Mephistopheles”

“Who is tricked into passing the Ninth Gate?”  “Hedge”

FLAG – 11

Non appena ottenni la FLAG10 [Figura 43], rispondendo all’ultima delle tre domande, apparve il seguito:

Un grande lampo di luce ti fa cadere a terra, accecandoti momentaneamente! Mentre la vista comincia a tornare, puoi vedere una densa nera nuvola di fumo indugiare dove un tempo stava il Negromante. Una risata diabolica echeggia nella stanza e la nuvola nera inizia a scomparire nelle fessure del pavimento. La stanza è silenziosa Cammini verso il punto dove si trovava il Negromante. Sul terreno c’è una piccola fiala.

Diedi qualche invio e il cursore tornò a lampeggiare sullo schermo. Decisi di cercare la “piccola fiala sul terreno”, come riportava l’indizio. Utilizzai il comando ls –ll per listare a video tutti i file, ma il risultato fu analogo a quello già ottenuto: mi apparve il file flag8.txt.

La fiala doveva essere proprio lì sotto i miei occhi, ma nascosta. Provai con ls –al e questa volta la vidi!

La chiave era il parametro del comando –a. Convenzionalmente, quando si lista il contenuto di una directory, i file e le directory che iniziano con “.” non vengono mostrati, a meno che non si utilizzi il parametro –a .

• ls : lista il contenuto
• -a : visualizza anche i file o le directory che iniziano con “.”
• l : visualizzazione come elenco, indicando anche altri parametri (permessi, gruppi, proprietario, etc…)

“Raccolsi” quindi la fiala, utilizzando il comando cat.

Raccogli la piccola fiala. Al suo interno puoi vedere un liquido verde. L’apertura del vile rilascia un piacevole odore nell’aria. Bevi l’elisir e senti un grande potere nelle tue vene.

Quale privilegio più alto, se non quello di avere permessi sudo?

Utilizzando sudo –l listai i privilegi che avevo come utente. Ergo, verificai dove avevo i permessi “sudo”.

I permessi “sudo”, e quindi di livello più alto (solitamente appartenenti all’utente “root”), mi erano concessi solamente sul comando “cat” al fine di listare il contenuto dell’ultima flag11.txt, locata al percorso /root/flag11.txt .

Così, “trattenni il fiato”, utilizzai il comando sudo per l’ultima “invocazione”: sudo cat /root/flag11.txt

Improvvisamente ti gira la testa e cadi a terra! Quando apri gli occhi ti ritrovi a fissare lo schermo di un computer. Congratulazioni!!! Hai conquistato… THE NECROMANCER! by @xerubus

 Lascio a voi il cracking della FLAG11…

 

Colgo l’occasione per ringraziare i Proff. Stefano Bistarelli e Francesco Santini dell’Università di Perugia, per aver organizzato e reso possibile questa giornata, lo sponsor DiGiOne per la disponibilità e aver fornito gli strumenti necessari e naturalmente tutto il mio team di Cyber Division per la collaborazione e il supporto.

Articolo a cura di Vincenzo Digilio

https://www.ictsecuritymagazine.com/articoli/a-case-history-ctf-necromancer-parte-3/

Introduzione

Gli ultimi anni hanno visto una crescita esponenziale dell’utilizzo di TLS (Transport Layer Security) per la messa in sicurezza di servizi ed applicazioni on-line. Nonostante questa popolarità, molti amministratori di sistema non riescono a gestire correttamente i problemi di sicurezza che derivano da configurazioni errate (ad esempio, l’utilizzo di cifrari deboli). Per questo motivo, sono stati sviluppati molti strumenti automatici per l’identificazione di vulnerabilità nelle implementazioni di TLS. Nonostante la semplicità di utilizzo, tali strumenti non assistono gli amministratori nel difficile compito di applicare le adeguate misure per mitigare i problemi riscontrati. Di conseguenza, agli amministratori viene richiesto di investire una grande quantità di tempo, che di solito non hanno a disposizione, per trovare, comprendere e tradurre in azioni concrete che portano alle opportune modifiche della configurazione di TLS. Per ovviare a questi problemi, descriviamo TLSAssistant, uno strumento capace di individuare non solo i potenziali problemi di sicurezza in una configurazione di TLS ma anche di generare un rapporto che indichi quali sono le mitigazioni da adottare.

Strumenti disponibili

La maggior parte degli strumenti disponibili per analizzare la sicurezza di TLS, una volta invocati, inviano ripetutamente messaggi di tipo ClientHello (il primo messaggio di un handshake TLS) e analizzano il contenuto del ServerHello (la risposta) da cui è possibile risalire alla configurazione e, di conseguenza, ricercare indicatori di vulnerabilità.

Alcuni di questi strumenti sono liberamente scaricabili mentre altri possono essere utilizzati direttamente da browser. Nell’ambito webapp troviamo aziende come Qualys che offrono sia una piattaforma a pagamento che un servizio di scansione gratuito in grado di rilevare vulnerabilità. Lo strumento di Qualys esegue un gran numero di analisi e valuta sistematicamente il livello di sicurezza assegnando un voto (da A+ a F) al sito analizzato. Il report finale riassume inoltre la totalità dei test eseguiti ed evidenzia le anomalie rilevate utilizzando una scala di colori per caratterizzarne la gravità.

Un altro strumento online accessibile gratuitamente è Discovery. Il servizio viene fornito da Cryptosense, una startup attiva nell’ambito della sicurezza in ambito crittografico, e sembra essere lo strumento più simile a TLSAssistant. Oltre ad un sistema di valutazione simile al precedente, Cryptosense Discovery offre inoltre una descrizione su come migliorare la sicurezza del sistema analizzato, ad esempio suggerendo di aumentare la lunghezza delle chiavi crittografiche in casi si usino alcuni cifrari.

A titolo di esempio descriviamo brevemente tre strumenti che richiedono l’installazione in locale:

• ssl-enum-ciphers: script sviluppato per il noto strumento di port scanning nmap. Lo script è in grado di elencare tutti i cifrari supportati da un dato server, l’eventuale supporto alla compressione dei pacchetti ed una piccola serie di errori di configurazione noti. Il report da esso generato mostrerà inoltre un livello di sicurezza calcolato utilizzando lo stesso metodo offerto dal servizio online di Qualys (già menzionato);
• TLS-Attacker: framework sviluppato allo scopo di analizzare le librerie TLS. È completamente personalizzabile e permette, tra le altre caratteristiche, di simulare un qualsiasi tipo di messaggio TLS per testare il comportamento dei server in analisi. Il progetto è corredato di una serie di flussi predefiniti in grado di simulare alcuni degli attacchi a TLS;
• testssl.sh: è forse il più potente tool open-source (per analisi TLS) disponibile sul web. Il tool è infatti in grado di estrarre informazioni utili a partire dell’header di risposta del server, di verificare i certificati offerti (e la relativa catena di fiducia), di simulare una moltitudine di handshake e, soprattutto, di segnalare esplicitamente le vulnerabilità delle quali il server potrebbe essere affetto. Nonostante la presenza di un report molto verboso, lo strumento rende espliciti i problemi riscontrati permettendo quindi una rapida valutazione del server analizzato.

La quasi totalità degli strumenti disponibili sono sì in grado di rilevare possibili falle ma non offrono suggerimenti sul come risolvere i problemi riscontrati.

TLSAssistant

TLSAssistant combina diversi strumenti di analisi allo stato dell’arte con un sistema di report che suggerisce le mitigazioni appropriate. TLSAssistant è open source, rilasciato sotto licenza Apache-2.0 e disponibile online al seguente repository. Lo strumento è stato sviluppato all’interno di Digimat, un laboratorio congiunto tra FBK e Poligrafico e Zecca dello Stato.

TLSAssistant è scritto in Bash e può quindi essere richiamato dalla riga di comando. Lo strumento prende come input il target da valutare (ad es. l’indirizzo IP di un server) e genera un file di report, il cui contenuto dipende dalle vulnerabilità rilevate e dal livello di verbosità scelto dall’utente. Figura 1 mostra i due componenti principali: Analyzer e Evaluator.

L’Analyzer integra i migliori strumenti disponibili per l’individuazione dei problemi di sicurezza di TLS tra i quali testssl.sh (descritto in precedenza).

L’Evaluator è il contributo principale di TLSAssistant e si occupa della generazione del report che contiene le vulnerabilità rilevate dall’Analyzer e relative misure di mitigazione a vari livelli di astrazione:

1. Descrizione testuale (in linguaggio naturale) della vulnerabilità TLS, individuazione del rispettivo CVE, CVSS e relative mitigazioni.Ad esempio, se viene rilevata la vulnerabilità CRIME, questo è l’output testuale:
   

   Compression Ratio Info-leak Mass Exploitation Description: By exploiting the information leakage provided by DEFLATE (compression algorithm), an attacker is able to retrieve the session cookie. In particular, the attacker guesses parts of the cookie, injects them in a valid client packet and analyzes the server’s response. Thanks to the properties of a DEFLATE output, if the server’s response is bigger than an untouched packet, then the guess is wrong. Mitigation: Disable the TLS compression mechanism. CVE: 2012-4929 CVSS3: 2.6 (Low)

2. Code snippet: frammento di codice che può essere copiato e incollato all’interno della configurazione del server web per correggere la vulnerabilità; il report dettaglia come individuare il file / la riga corretti da modificare. TLSAssistant è in grado di rilevare qualsiasi server web ma al momento è in grado di fornire istruzioni dettagliate solo per server HTTP Apache e nginx.Considerando la vulnerabilità CRIME e un server Apache, il report conterrà il seguente code snippet:
   

   1.    open your Apache configuration file (default: /etc/apache2/sites-available/default-ssl.conf); 2.     search for the line starting with: SSLCompression –       if found, change the value to off; –       if not, add the line SSLCompression off within the file. N.B. restart the server by typing: sudo service apache2 restart.

A breve, TLSAssistant sarà in grado di esportare il risultato dell’analisi in linguaggio STIX (Structured Threat Information eXpression), che supporta attività di cyber threat intelligence e facilita l’integrazione con altri strumenti come ad esempio quelli della piattaforma sviluppata nel progetto europeo FINSEC (attività attualmente in corso).

In sintesi, TLSAssistant è attualmente in grado di rilevare e fornire mitigazioni per una gran numero di vulnerabilità che vanno da 3SHAKE a Lucky13 passando per i problemi di gestione dei certificati e di gestione di TLS su Android.

Esempio di utilizzo

Per valutarne l’efficacia in ambito aziendale, TLSAssistant è stato utilizzato per analizzare il deployment di un servizio cloud di tipo SaaS (Software as a Service) per la gestione delle segnalazioni di irregolarità nel contesto lavorativo in conformità alla normativa sul whistleblowing. Grazie all’analisi prodotta da TLSAssistant abbiamo riscontrato un problema di configurazione che può dare la possibilità di eseguire un attacco Man in the Middle noto come SSL stripping. Questo attacco ideato nel 2009 permette di forzare la vittima ad utilizzare una connessione non cifrata (HTTP) per la trasmissione delle informazioni, riuscendo quindi a violare la proprietà di confidenzialità normalmente garantita da TLS (e fondamentale nel caso di un servizio di whistleblowing).

Uno dei prerequisiti per realizzare l’attacco è la non adozione del meccanismo HSTS (HTTP Strict Transport Security) da parte del sito web. Anche se HSTS è presente, l’attacco può essere montato nell’intervallo di tempo tra il primo avvio di un browser e la ricezione della direttiva HSTS: questo caso è particolarmente rilevante per i servizi SaaS di whistleblowing che vengono generalmente utilizzati una tantum. Per ovviare a questo, la mitigazione suggerita da TLSAssistant è l’aggiunta del dominio del servizio SaaS all’elenco di “precaricamento”. Il servizio, offerto da Google, consiste nella redazione di un elenco di siti che indicano la propria volontà di attuare la politica HSTS già dal primo avvio del browser.

Conclusioni

TLSAssistant integra rilevazione delle vulnerabilità e indicazioni operative precise per implementare le opportune mitigazioni e definire una configurazione sicura del protocollo TLS. Lo strumento è stato utilizzato sia in contesti aziendali che come ausilio didattico per un’esperienza di laboratorio nel contesto di un corso universitario introduttivo alla sicurezza informatica.
Maggiori informazioni riguardanti lo strumento – nonché il codice – sono reperibili al seguente indirizzo: https://stfbk.github.io/tools/TLSAssistant.html.

Articolo a cura di Salvatore Manfredi, Silvio Ranise e Giada Sciarretta

https://www.ictsecuritymagazine.com/articoli/tlsassistant-uno-strumento-per-mitigare-i-problemi-di-sicurezza-di-tls/

Il primo giovedì di maggio è il World Password Day, giornata dedicata alla sensibilizzazione degli utenti sull’importanza di alcuni criteri di gestione delle proprie credenziali di accesso a sistemi in rete. Il messaggio è quasi sempre: se le password non ti proteggono, la colpa è tua.

Secondo l’ultima indagine di LastPass, il 91% degli intervistati (non in Italia) usa la stessa password per più account e gli utenti, pur consapevoli del rischio, non fanno nulla per ridurlo. Così come il 42% ritiene più importante avere una password facile da ricordare che una sicura.

Cosa fa un utente quando ha molti account? In Italia non sembrano essere molti ad usare i gestori di password come LastPass. C’è anche il rischio di perdere o di svelare la propria “master password”[1] (e quindi di tutti gli account gestiti) che è superiore al rischio di violazione di alcuni dei propri account dovuto alla rivelazione delle relative chiavi di accesso. Quindi, con tanti account, in teoria dovremmo avere tante password: invece ne usiamo pochissime, forse addirittura una sola, pericolosamente.

Bill Gates è stato ottimista affermando, nel 2004: “There is no doubt that over time, people are going to rely less and less on passwords”. Questo over time si sta prolungando e solo ultimamente Microsoft spinge su soluzioni senza password, con PIN locale o altri metodi.
Negli ultimi anni, ICT Security magazine ha pubblicato interessanti articoli al riguardo.

Massimiliano Brolli[2] analizzava in dettaglio le debolezze delle password e alcune tecniche di protezione consigliando i sistemi biometrici (retina, volto), non senza accennare al fatto che potrebbero essere riprodotti fraudolentemente e quindi non sono la soluzione finale.

Andrea Pasquinucci[3] dedicava spazio alla Federazione di identità che si sta diffondendo: per esempio, “Autenticati con Google o Facebook”, che permette di accedere a una risorsa di un fornitore di servizi utilizzando automaticamente le nostre credenziali Google o Facebook. È utile e pratico anche se implica che Google e Facebook finiscono per conoscere i servizi che frequento. Il problema si sposta sul garantire la sicurezza della password per Google o Facebook. Lo stesso Pasquinucci descriveva nel suo secondo articolo[4] l’autenticazione a fattori multipli e quella con codici “one time” che permettono di aggiungere alla password un secondo passaggio di sicurezza, attraverso una smart-card, una chiavetta, un messaggio ricevuto su smartphone (al quale normalmente accediamo con la nostra impronta digitale) oppure una App di autenticazione. Concludeva con il protocollo FIDO2 e la Security Key, che Google ha già disponibile tra le sue soluzioni di autenticazione come la migliore, ma saggiamente affermava: “È però troppo presto per dichiarare che abbiamo finalmente individuato la strada per abbandonare definitivamente le nostre vecchie e care password”.

Precedentemente, Cesare Gallotti[5] aveva riassunto le nuove specifiche sulle password del 2017 del NIST, l’Istituto statunitense per gli standard, notando il cambio di politica: non più parole complesse con numeri e caratteri speciali, né cambio frequente, ma solamente lunghe almeno 8 caratteri e facili da ricordare, per non doverle conservare scritte da qualche parte, con il rischio di divulgazione. Certamente non devono essere banali, ma devono poter contenere anche spazi ed essere lunghe fino a 64 caratteri. Questo porta a poter utilizzare frasi intere, di facile memorizzazione. Su alcune specifiche Gallotti era critico verso il NIST, ma concludeva invitando a seguirne le regole.

Infine, Emilio Souberan[6] passava in rassegna le politiche di sicurezza informatica previste nel nuovo regolamento europeo sulla privacy, evidenziandone alcune lacune.

In tutto questo panorama non si affronta il problema dell’assenza di segnalazione previa all’utente sulle politiche di gestione e conservazione delle password da parte del sito sul quale ci si vuole registrare. Non si tratta solamente di assicurarsi che il login avvenga tramite https[7], requisito non ancora universalmente adottato, purtroppo. Si tratta di sapere ciò che accade alle nostre credenziali, dopo averle “create”.
Mentre a livello europeo si è insistito molto sulla liceità e sul controllo dei cookies[8] imposti dai siti web, che ci costringe a fare uno o più clic su un’informativa[9] prima di navigare, nessuno sembra aver pensato a obbligare i siti a esplicitare cosa fanno della nostra password: la conservano in chiaro, crittografata, hashed[10], salted[11]?

Facciamo qualche esempio reale che mi è capitato.

C’è un venditore italiano online, al quale si possono anche fornire i dati della carta di credito, che inserisce ancora oggi la password dell’account del cliente in chiaro direttamente nella URL[12], rendendola quindi immediatamente visibile e memorizzata in tutti gli elenchi di pagine visitate da me (cronologia), proxy inclusi.

La Banca Dati Esperti Pubbliche Amministrazioni ha una procedura di recupero password che invia per posta elettronica all’utente la sua password in chiaro, così come la domanda e risposta di sicurezza. Di fronte alla mia protesta per la sua debolezza intrinseca, mi hanno risposto:

• l’amministratore del sistema, così come ogni altro operatore, non ha alcuna possibilità di conoscere la password dell’utente che, come altri dati, è cifrata al momento della creazione: questa modalità non permette di risalire in nessun modo alla password, che viene decrittata in automatico quando un utente usa la funzione di recupero;
• le password vengono inviate in chiaro solo in occasione della prima iscrizione, del loro aggiornamento da parte dell’utente e in caso di recupero delle credenziali: si tratta di una scelta deliberata per agevolare gli utenti, nella chiara consapevolezza che le modalità di conservazione della password dipendono dal buon senso di ciascun utente e non sono governabili a distanza, potendo solo semmai segnalare orientamenti corretti.
• Si evidenzia, infine, che, proprio allo scopo di tutelare al meglio la privacy, gli utenti iscritti alla Banca Dati sono tenuti a rinnovare la password ogni 6 mesi per poter riaccedere alla propria pagina personale.

Decrittare in automatico vuol dire che il sistema conserva la password cifrata e non il suo hash. Chiunque ha accesso al sistema con privilegi alti può eseguire la funzione di decifratura: non è quindi vero che l’amministratore non può conoscerla. Inoltre qualsiasi amministratore di sistema ha accesso alla posta elettronica inviata e può leggere il messaggio che contiene in chiaro password e risposta di sicurezza. Rimandare il problema al buon senso dell’utente è uno scaricabarile: ancora una volta si dà la colpa a chi accede e non a chi gestisce. L’obbligo del cambio ogni 6 mesi in questo caso aumenta i rischi, perché si moltiplicano i messaggi con la password in chiaro: almeno due all’anno a testa.

Tornando alle specifiche NIST, già in una bozza del 2009 si leggeva che non serve cambiare password con frequenza: se la cambiavo ogni sei mesi invece che ogni anno, i delinquenti dovevano semplicemente duplicare gli sforzi. In uno degli scenari illustrati si aggiungeva che, se invece usavo caratteri speciali oltre alle semplici lettere, allungavo da 12 minuti a 2 ore circa il tempo per violarla, mentre se da 8 caratteri di lunghezza portavo la password a 12, allungavo di 500 anni il tempo necessario.

Ancora un esempio con le specifiche della password di un sito importante a cui accedo abitualmente:

• deve essere lunga almeno 8 caratteri
• deve contenere almeno una lettera (porre attenzione alle maiuscole e minuscole che sono considerate differenti!)
• deve contenere almeno un carattere numerico
• deve contenere almeno un carattere speciale tra i seguenti: !”#%&'()*+,-./:;<=>?@|
• deve essere diversa da una delle ultime 3 password.

Le specifiche apparentemente rigorose sono del tutto vanificate dalla prima che dà un vantaggio enorme a chi vuole decifrarla: si riducono infatti notevolmente le combinazioni possibili se so già quanto è lunga la password.

La password – o meglio il suo hash – del mio account LinkedIn, insieme ad altri 6 milioni, fu rubata nel 2012 quando quell’azienda fu oggetto di un attacco. Era di 12 caratteri, includendo numeri e caratteri speciali: più che robusta, secondo gli standard dell’epoca. Ma è stata decifrata. C’è voluto un po’ di tempo e l’anno scorso ho iniziato a ricevere quei messaggi di posta elettronica ricattatori che dicono all’incirca: “Conosco la tua password…”, seguito da richiesta di soldi. Vuol dire che la mia password è stata messa a disposizione o venduta, insieme a quelle di molti altri. Non utilizzo le password di siti importanti in siti diversi: non ho avuto conseguenze su LinkedIn perché l’ho cambiata subito, a differenza di altri che hanno visto compromessi vari altri account per i quali usavano la stessa password. LinkedIn fu accusata di non aver usato il sistema salted per l’hash delle password, avendo facilitato il compito di decifratura attraverso le rainbow tables[13]: come tutti gli altri fornitori di servizi, purtroppo, non aveva dichiarato nulla sul trattamento delle password stesse.

Con il mio account Adobe nel 2013 andò peggio, insieme a milioni di utenti, perché le password non erano neppure in hash, ma semplicemente crittografate: non avevano pubblicato le politiche di gestione.

Ci sono ancora CMS[14] in giro che salvano in chiaro nel database le password dei loro utenti abilitati a effettuare modifiche o pubblicare. Ma non lo sa nessuno se non, forse, l’amministratore che si è dimenticato di attivare la crittografia.

È quindi evidente che manca un tassello importante nella vicenda password: non si possono colpevolizzare solamente gli utenti. A parte i furti nei server dei fornitori e le relative discussioni sulla loro capacità di difesa, non c’è trasparenza su questo tema.

La mia proposta è imporre almeno l’inserimento delle politiche di gestione delle password nell’informativa sul trattamento dei dati personali.
Meglio ancora sarebbe aggiungere uno standard minimo, del tipo salted hash e almeno 12 caratteri di qualsiasi tipo con una black list di password banali (ad esempio, nome e cognome dell’utente).

L’obiezione ovvia è che ci saranno siti che non pubblicheranno nulla o mentiranno nell’illustrare le loro politiche, ma questo vale per qualsiasi obbligo di dichiarazione. Almeno dai fornitori più importanti potremo sapere quali rischi corriamo nel consegnare le nostre chiavi di accesso: non è sempre colpa nostra.

Note

[1] Proprio LastPass nel 2015 fu vittima di un attacco e consigliò ai suoi utenti di cambiarla.

[2] www.ictsecuritymagazine.com/articoli/le-password-un-falso-segreto/

[3] www.ictsecuritymagazine.com/articoli/lautenticazione-che-si-evolve-dalla-password-ai-token-u2f/

[4] www.ictsecuritymagazine.com/articoli/lautenticazione-che-si-evolve-dalla-password-ai-token-u2f-parte-2/

[5] www.ictsecuritymagazine.com/articoli/nuove-specifiche-nist-le-password/

[6] www.ictsecuritymagazine.com/articoli/le-policy-sicurezza-informatica-nel-regolamento-europeo-sulla-privacy/

[7] Protocollo che crittografa i dati inviati dall’utente al server che lo autentica.

[8] Meccanismo di memorizzazione di dati relativi alla navigazione dell’utente, al fine del loro riutilizzo.

[9] Quest’obbligo genera il rischio di abituarsi a un clic previo senza nessuna lettura del messaggio, con il pericolo che il pop up sia un malware invece dell’informativa legittima. Quanti utenti rispondono “no” alla memorizzazione dei cookies? È valsa veramente la pena aggiungere questo livello intermedio per accedere a informazioni in rete?

[10] Vuol dire che se ne conserva una trasformazione irreversibile: se conosco un hash, non posso ricavarne la password.

[11] È un sistema di rafforzamento della sicurezza dell’hash: a password uguali corrispondono hash diversi

[12] http://www.xyz.xy/dettagli.php?user=m.crudele&password=Compro!Bene&articolo=150419

[13] Sono più o meno lunghissimi elenchi di hash con la decodifica già fatta.

[14] Content Management Systems che permettono di pubblicare pagine web in modo facilitato e dinamico.

Articolo a cura di Michele Crudele

https://www.ictsecuritymagazine.com/articoli/la-password-e-debole-di-chi-e-la-colpa/

Diritto alla riservatezza e protezione dei dati personali: diritti fondamentali ma flessibili

Il diritto alla riservatezza e alla protezione dei dati personali sono diritti fondamentali sì, ma elastici, ossia possono essere compressi – temporaneamente – per ragioni di salute pubblica, come previsto dall’art. 9.2 del GDPR e dall’art.15 della direttiva ePrivacy in un quadro di regole scritte dal Parlamento nel rispetto dei principi di bilanciamento degli interessi, proporzionalità, necessità, ragionevolezza, trasparenza e accountability. 

È dunque al Parlamento – legislatore in via ordinaria – che, in questa seconda fase della gestione della pandemia Covid-19, occorre restituire la centralità prevista dalla Costituzione.

Come giustamente ricordato anche dalla Pres. Prof.ssa Cartabia nella Relazione annuale 2019 della Corte Costituzionale, la nostra Costituzione “non contempla un diritto speciale per i tempi eccezionali (…) ma offre la bussola anche per navigare per l’alto mare aperto nei tempi di crisi, a cominciare proprio dalla leale collaborazione fra le istituzioni”.

L’App in corso di implementazione, per quanto noto, dovrebbe essere compatibile con il GDPR e uniformata alle prescrizioni rilasciate da EDPB nelle Linee Guida 04/2020 sull’uso dei dati di localizzazione e degli strumenti per il tracciamento dei contatti nel contesto dell’emergenza legata al COVID-19, oltre che del Garante nel Parere del 29 aprile 2020 sulla proposta normativa per la previsione di un’applicazione volta al tracciamento dei contagi da COVID-19.

Trasparenza, proporzionalità, minimizzazione e temporaneità: l’art. 6 del DL 28/20

Trasparenza, proporzionalità, minimizzazione dei dati e temporaneità sono principi tendenzialmente recepiti, seppur con qualche prospettiva di miglioramento in sede di conversione in legge, dal DL 28/20 e dovranno riflettersi necessarimente anche sulla regolamentazione attuativa dell’applicativo scelto dal Ministero dell’innovazione per la sorveglianza digitale.

A tale scopo risponde l’art. 6 del DL 28/20 che statuisce, fra l’altro, quanto segue:
“Al solo fine di allertare le persone che siano entrate in contatto stretto con soggetti risultati positivi e tutelarne la salute attraverso le previste misure di prevenzione nell’ambito delle misure di sanità pubblica legate all’emergenza COVID-19, è istituita una piattaforma unica nazionale per la gestione del sistema di allerta dei soggetti che, a tal fine, hanno installato, su base volontaria, un’apposita applicazione sui dispositivi di telefonia mobile”.

Rischi correlati all’adozione di un’App anticontagio unica a livello nazionale

Si può creare un falso senso di sicurezza nei cittadini nel caso in cui l’App non sia preceduta da adeguata campagna informativa nazionale e non sia supportata da adeguate misure tecnologiche, procedurali e organizzative.

Il rischio che si corre è quello di creare affidamento sociale incolpevole nella cittadinanza su uno strumento che da solo non è certo risolutivo.

Occorre essere chiari: nessun potere taumaturgico può essere associato al mero utilizzo dell’App.
Si tratta solo di un utile strumento complementare nel quadro complessivo delle azioni messe a terra dal Governo per il contrasto al Covid-19 che va ad integrare, non sostituire, il contact tracing analogico.

L’art. 6 del  DL 28/20 precisa correttamente che:
“Le modalitaàoperative del sistema di allerta tramite la piattaforma informatica di cui al presente comma sono complementari alle ordinarie modalità in uso nell’ambito del Servizio sanitario nazionale”.

Questo al cittadino, si ribadisce, deve essere reso ben chiaro dalle Istituzioni attraverso campagna informativa ad hoc: altrimenti si rischia di ingenerare, corre l’obbligo di essere sottolineato nuovamente, una falsa percezione di sicurezza che potrebbe addirittura essere controproducente.

Inoltre, come ha giustamente osservato anche il Garante Soro in un suo recente intervento pubblico, la App senza test Covid massivi (tamponi, test sierologici e test rapidi, c.d. “pungidito”) – che ancora oggi sono somministrati con il contagocce – rischia di servire a poco o nulla.

Il Garante pone correttamente un limite al tracciamento di massa delle persone, osservando criticamente che sfugge l’utilità: “di una sorveglianza generalizzata alla quale non dovesse conseguire sia una gestione efficiente e trasparente di una mole così estesa di dati, sia un conseguente test diagnostico altrettanto generalizzato e sincronizzato”.

Non è prudente polarizzare, quindi, l’attenzione solo sulla App: si rischiano appunto effetti indesiderati.

Cito l’esempio per tutti dei falsi positivi e negativi. Anche l’EPDB raccomanda che tutte le procedure e i processi, compresi gli algoritmi implementati dalle App per il tracciamento dei contatti, debbano svolgersi “sotto la stretta sorveglianza di personale qualificato al fine di limitare il verificarsi di falsi positivi e negativi. In particolare, le indicazioni fornite in merito ai passi da compiere successivamente alla ricezione di un alert non dovrebbero basarsi unicamente su un trattamento automatizzato”.

Inoltre, si consideri che l’efficacia di un’App di contact tracing può essere influenzata non solo dal numero di soggetti che decidono di istallarla (dato sensibilmente variabile dal 30% al 60% secondo varie analisi ad oggi disponibili) ma anche da eterogenei e non meno importanti fattori umani oltre che dai limiti intrinseci della tecnologia prescelta: falsi positivi e falsi negativi, il non uso,  l’utilizzo non corretto e l’abuso costituiscono alcuni significativi esempi ostativi al successo di un App di tracciamento digitale dei contagi

L’integrazione di dati di prossimità rilevati dal bluetooth e dati di geolocalizzazione rilevati dal GPS

Il Ministero dell’Innovazione ha chiarito di escludere l’utilizzo da parte dell’App di dati relativi alla geolocalizzazione.

L’art. 6, comma 2 del DL 28/20 pervero attualmente esclude solo la geolocalizzazione dei singoli utenti:
“c) il trattamento effettuato per allertare i contatti sia  basato sul trattamento di dati di prossimitaàdei dispositivi, resi  anonimi oppure, ove ciò non sia possibile, pseudonimizzati; è esclusa  in ogni caso la geolocalizzazione dei singoli utenti”.

Non pare, quindi, ostativo, ribadisco, per il trattamento dei dati di geolocalizzazione aggregati.

Anche il Parere del Garante sull’App COVID-19 del 29 aprile 2020 è stato rilasciato positivamente sulla base del seguente assunto:
“e) selettività e minimizzazione dei dati: i dati raccolti devono poter tracciare i contatti stretti e non i movimenti o l’ubicazione del soggetto. Devono essere raccolti solo i dati strettamente necessari ai fini della individuazione dei possibili contagi, con tecniche di anonimizzazione e pseudonimizzazione affidabili. Anche la conservazione deve limitarsi al periodo strettamente necessario, da valutarsi sulla base delle decisioni dell’autorità sanitaria su parametri oggettivi come il periodo di incubazione. A tal riguardo le disposizioni dello schema di norma su tali aspetti è opportuno che siano ulteriormente articolate in sede di attuazione dal Ministero della salute ai sensi del comma 2, anche con riferimento alla sorte dei dati raccolti sul dispositivo di chi, in un momento successivo all’installazione dell’applicazione, abbia poi deciso di disinstallarla”.

Bene non utilizzare i dati di geolocalizzazione dei singoli utenti, ferma restando l’ammissibilità della geolocalizzazione dei dati aggregati e anonimi, come utilimente fatto anche in Regione Lombardia nel pieno rispetto delle regole vigenti, dell’anonimato e della tutela dei dati personali.

Certo dall’eventuale incrocio di dati di prossimità rilevati dai Bluetooth con i dati di geolocalizzazione del GPS dello smartphone la garanzia di anonimato dell’interessato si indebolisce progressivamente: bene quindi ha fatto il Ministero dell’Innovazione a escludere tale possibilità.

Se poi aggiungiamo l’abbinamento delle prime due cifre del Cap – come annunciato dal Ministero dell’Innovazione – l’indebolimento è ulteriore: più ampliamo il novero dei dati trattati, più rendiamo fragile la tutela dell’anonimato dell’interessato rendendo non solo possibile ma anche più facile l’identificazione del soggetto vigilato.

Centrale in proposito – a prescindere dalle FAQ del Ministero dell’Innovazione, che non hanno efficacia normativa ma solo informativa – sarà il sistema di garanzie dettagliate nella normativa regolamentare oltre a quanto rappresentato nella valutazione di impatto del trattamento che dovrà essere rilasciata dal Ministero della Salute prima dell’inizio del trattamento con l’App prescelta.

Anche le Linee Guida EDPB raccomandano attenzione, precisando che:
“L’anonimizzazione fa riferimento all’uso di una serie di tecniche finalizzate a eliminare la possibilità di collegare i dati a una persona fisica identificata o identificabile con uno sforzo “ragionevole”. Questo “test di ragionevolezza” deve tenere conto sia degli aspetti oggettivi (tempi, mezzi tecnici) sia di elementi di contesto che possono variare caso per caso (rarità di un fenomeno, la densità di popolazione, la natura e il volume dei dati). Se i dati non superano tale test, non sono anonimizzati e pertanto rientrano nel campo di applicazione del regolamento generale sulla protezione dei dati”.

E ancora, la valutazione della robustezza della tecnica di anonimizzazione adottata dipende da tre fattori: (i) individuabilità (singling out) (possibilità di isolare una persona all’interno di un gruppo sulla base dei dati); (ii) correlabilità (possibilità di correlare due record riguardanti la stessa persona); (iii) inferenza (possibilità di dedurre, con probabilità significativa, informazioni sconosciute relative a una persona).

Infine, sempre EDPB rileva correttamente che i dati relativi all’ubicazione ritenuti anonimi possono di fatto non esserlo. Le tracce di mobilità dei singoli individui sono caratterizzate intrinsecamente da forte correlazione e univocità. Pertanto, in determinate circostanze possono essere vulnerabili ai tentativi di re-identificazione: più incrociamo dati più aumentiamo il rischio di reidentificazione.

Ulteriori garanzie a tutela della riservatezza e dei dati personali nella legge di conversione in Parlamento

Innanzitutto, in conformità anche alle linee guida EDPB già citate, potrebbe essere resa più esplicita e chiara la filiera soggettiva degli attori coinvolti nel processo di istituzione e gestione della piattaforma unica nazionale evitando di utilizzare il sistema poco chiaro del rinvio ad altri testi normativi. L’art.6 – commi 1 e 5 – potrebbe essere riformulato in termini più chiari e trasparenti, intelleggibili anche al cittadino comune, trattandosi di intervento normativo interferente con diritti fondamentali della persona.

Si potrebbe essere più trasparenti – già in sede di conversione in legge – in relazione all’esclusione dell’incrocio dei dati Bluetooth, GPS e CAP – ammesso e non concesso che alla fine vengano tutti utilizzati dalla nuova App – esplicitando le principali macromisure adottabili per prevenire il rischio di reidentificazione: misure dettagliate nella normativa attuativa.

Inoltre, esplicitare chiaramente quali dati saranno centralizzati e quali conservati anche – o esclusivamente – nei dispositivi mobili dell’interessato.

In terzo luogo, si potrebbe esser più trasparenti anche sulla durata dell’emergenza: non credo sia opportuno indicare una data troppo breve sapendo di doverla prorogare.

Sebbene nulla si dica sulla possibilità di proroga della durata oltre e a quali condizioni.

Attualmente l’art. 6 comma 6 del DL 28/20 stabilisce che:
“L’utilizzo dell’applicazione e della piattaforma,  nonchè ogni trattamento di dati personali effettuato ai sensi al presente articolo sono interrotti alla data di cessazione dello stato di emergenza disposto con delibera del Consiglio dei ministri del 31 gennaio 2020, e comunque non oltre il 31 dicembre 2020, ed entro la medesima data tutti i dati personali trattati devono essere cancellati o resi definitivamente anonimi”.

La durata al 31/12/2020 potrebbe essere eccessivamente ottimistica e, quindi, non trasparente per i cittadini perché verosimilmente soggetta a proroga. Un termine massimo di 12 mesi dall’entrata in vigore potrebbe essere più appropriato: termine che il Ministro della Salute potrà certamente abbreviare nel caso in cui l’emergenza cessi prima di tale data.

Inoltre, andrebbe espressamente previsto che la reiterazione della durata del trattamento non potrà essere prorogata utilizzando lo strumento omnibus del “milleproroghe” ma con una legge ad hoc, occorrendo.

Come noto, in Italia le situazioni temporanee sono suscettibili di protrarsi senza fine.

Ancora manca ogni regolamentazione delle App regionali: oltre alla statuizione di principio che la piattaforma unica di allerta è nazionale, potrebbe essere questo il contesto normativo appropriato per mettere ordine e meglio chiarire i limiti di operatività di analoghe iniziative regionali, prevedendo regole uniformi a tutela dei dati dei cittadini. Altrimenti si rischi il caos e l’insuccesso della stessa piattaforma nazionale.

Infine, occorre sviluppare la parte relativa agli obblighi informativi; che non si esauriscono nell’ambito delimitato dell’informativa privacy richiesta dal GDPR ma che richiedono, invero, una specifica strategia di comunicazione e una campagna informativa, a beneficio della cittadinanza, che andrebbe attuata preliminarmente alla diffusione dell’App per un uso consapevole e per mitigare i rischi di false aspettative.

La mancanza di comunicazione pubblica efficace e di trasparenza può minare la fiducia delle persone, generare fallaci aspettative di sicurezza, affidamento incolpevole pericoloso per tutti i cittadini: sia per coloro che sceglieranno di utilizzarla sia per coloro che riterranno di poterne fare a meno.

 

Articolo a cura di Emilio Tosi

https://www.ictsecuritymagazine.com/articoli/app-di-tracciamento-digitale-sorveglianza-sanitaria-e-tutela-dei-dati-personali-alla-luce-del-gdpr-una-prima-lettura-del-dl-28-20/