Il dossier: fra archivistica, cronaca, ModI e sicurezza

Il dossier, per l’archivistica^[1]Una definizione di dossier si trova nel glossario di InterPares: InterPARES 2 Project: Terminology Database., è un’aggregazione di documenti che riguardano uno stesso affare o relativi a una stessa persona, evento, luogo, progetto o altra materia. In buona sostanza, un sinonimo francofono di fascicolo.

L’archivistica, però, ha il suo fascino anche nella motilità delle definizioni e giurerei di aver letto anni addietro qualche definizione di dossier che lo individuava come una raccolta di fascicoli che consente di avere il quadro completo di un affare (o persona) ampio che attraversa, anche in un arco temporale esteso, più funzioni del soggetto che produce l’archivio e che quindi ha un riflesso in più aggregazioni documentali di tipo fascicolo. Per esempio, per ancorarci all’attualità, dopo il 2026 le amministrazioni pubbliche italiane potranno avere ciascuna un suo “dossier PNRR”, raccolta di tutti i fascicoli che riguardano l’attuazione di progetti PNRR, le misure organizzative adottate e gli incentivi distribuiti al personale per realizzarli ecc.

Ci sono anche casi in cui con dossier si indica una sezione ristretta di un fascicolo: per esempio, in ambito sanitario, il dossier sanitario è l’insieme della documentazione sanitaria di un soggetto raccolta presso una struttura che poi confluisce insieme a quelli di altre strutture in quello che chiamiamo “fascicolo sanitario elettronico” (qui, però, anche il concetto di fascicolo diverge dalla definizione archivistica stretta), che a sua volta contiene il dossier farmaceutico.

Per la cronaca, anche recente, il dossier è comunemente noto come l’esito della sorveglianza, fondamentalmente illecita, di una persona tesa a raccogliere informazioni di varia natura, da quelle che riguardano situazioni e movimenti finanziari a quelle che riguardano la sfera strettamente intima, relazionale, da utilizzare poi per finalità varie, spesso altrettanto illecite e censurabili quanto gli strumenti di raccolta delle informazioni. Nel corso della storia massicce operazioni di dossieraggio sono state condotte anche dai governi di stati vittime di derive autoritaria (o anche di veri e propri naufragi). Cinematograficamente note sono, in tal senso, le attività della STASI della Repubblica democratica tedesca o delle agenzie governative statunitensi nel periodo maccartista. Anche la storia italiana contemporanea, fra ventennio fascista e periodi di “devianza istituzionale” del secondo dopoguerra, non è priva di esempi di attività di raccolta di dati, osservazione e sorveglianza di soggetti ritenuti pericolosi o in qualche modo sgraditi.

Le recenti notizie di cronaca danno conto di un’ulteriore manifestazione di questo fenomeno che si presenta periodicamente, con caratteristiche e sfaccettature diverse. A prescindere dalle motivazioni di chi raccoglie informazioni illecitamente, un aspetto distintivo e comune delle attività di raccolta abusiva di informazioni è l’accesso non autorizzato a dati contenuti in banche dati informatiche.

L’accesso ai dati da parte dei soggetti autorizzati

Solitamente, l‘accesso ai dati detenuti da un soggetto erogatore da parte di un soggetto fruitore avviene tramite uno strumento che il soggetto erogatore realizza e mette a disposizione. Se conveniamo di dare un senso generico e vasto ai termini, possiamo chiamarlo punto di accesso o interfaccia. Il punto di accesso può essere una pagina web alla quale il soggetto autorizzato si autentica e che, dopo l’identificazione (tramite identità digitali SPID o CIE, per esempio), offre strumenti di ricerca e visualizzazione dei dati. Oppure può essere un software specifico che utilizza protocolli di autenticazione, sicurezza e trasferimento di dati diversi da quelli tipici del web.

Ci sono anche casi in cui il soggetto erogatore mette a disposizione solo l’interfaccia “di basso livello” (in senso informatico), tramite l’esposizione di una API (Application Programming Interface) che consente all’erogatore di accedere a un e-service tramite strumenti propri da adeguare opportunamente, per fornire all’operatore lo strumento di ricerca e visualizzazione. Questa modalità, comunemente nota come interoperabilità, consente inoltre – ed è il suo grande vantaggio – di mettere in collegamento con la banca dati sistemi automatizzati che lavorano senza l’intervento diretto di un operatore.

Negli ultimi anni, stando dietro alle galoppanti evoluzioni tecnologiche, l’interoperabilità fra dati e sistemi della pubblica amministrazione italiana ha trovato una sua sistematizzazione, anche tecnica, nel ModI, il Modello di Interoperabilità, che è descritto e regolamentato nelle Linee guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni. Una componente infrastrutturale fondamentale per l’interoperabilità del sistema informativo pubblico è la PDND (Piattaforma Digitale Nazionale Dati), anch’essa disciplinata da linee guida di dettaglio.

Nel seguito vorrei fornire una panoramica, suggestiva e non esaustiva, degli strumenti che ModI e PDND offrono per il controllo degli accessi ai dati contenuti nelle banche dati. Lo farò attraverso tre esempi concreti. Prima, però, occorre puntualizzare cosa si intende per accesso non autorizzato ai dati e distinguere almeno due casi: il caso in cui un soggetto (organizzazione) forza le protezioni per accedere a una banca dati alla quale diversamente non avrebbe alcuna forma di accesso e il caso in cui un soggetto abilitato all’accesso a una banca dati compie su questa operazioni di ricerca ed estrazione che vanno oltre le sue legittime necessità. Fattispecie sgradevoli diverse che richiedono contromisure diverse.

Prima ancora, una precisazione: quanto segue non intende evidenziare o stabilire nessuna correlazione fra l’assetto delle regole in materia di interoperabilità delle banche dati e della PDND e i fatti criminali riportati dalle cronache. Questi ultimi sono solo di stimolo per l’esposizione e per analizzare quai presidi di sicurezza sono disponibili a tutela dei dati pubblici.

Accesso di soggetti non autorizzati

Chi accede forzosamente a una banca dati che altrimenti gli sarebbe preclusa, lo fa cercando tutti i canali di accesso possibili e immaginabili, non si concentra solo sul punto di accesso “ufficiale” messo a disposizione da chi detiene la banca dati (e, infatti, talvolta fa accesso anche a banche dati che chi detiene nemmeno si sognava di mettere in condivisione con soggetti autorizzati). Oltre a forzare la porta di accesso principale – solitamente controllata – cerca strade secondarie, magari sfruttando vulnerabilità o falle di sicurezza, e, quando ha successo, trova ulteriore giovamento nel fatto che il detentore della banca dati potrebbe anche non accorgersi della violazione.

Il Modello di Interoperabilità (ModI), ovviamente, può occuparsi solo di come proteggere la porta di accesso principale, quella ufficiale che al ModI deve conformarsi. La protezione degli accessi secondari attiene a misure generali e ben più vaste di sicurezza informatica e protezione dei dati. Per garantire la sicurezza dei canali ufficiali di accesso ai dati, le Linee guida sull’interoperabilità prevedono misure di sicurezza che si rifanno a standard tecnici internazionali.

Per avere un’idea, le Linee guida per l’interoperabilità tecniche delle pubbliche amministrazioni definiscono alcune regole, i cosiddetti “pattern di sicurezza (a cui è dedicato l’allegato 2):

• l’uso di certificati di sicurezza TLS^[2]SiI fa riferimento ai pattern di sicurezza [ID_AUTH_CHANNEL_02] e [ID_AUTH_CHANNEL_02] del ModI. rilasciati da un’autorità di certificazione o scambiati dopo aver stabilito un rapporto di reciproca fiducia^[3]In inglese informatichese si parla di “trust”.;
• l’autenticazione tramite un token ^[4]Il riferimento è ai pattern di sicurezza [ID_AUTH_SOAP_01], [ID_AUTH_SOAP_02], [ID_AUTH_REST_01], [ID_AUTH_REST_02]. L’identity provider designato è la PDND che chiama “voucher” … Continue reading emesso da un soggetto terzo (l’identity provider) che interviene in apertura di ogni sessione di accesso. L’erogatore ha il dovere di verificarlo contattando a sua volta il soggetto terzo che lo ha emesso. Il token (codice) di autenticazione ha una durata limitata nel tempo (tipicamente da pochi secondi a pochi minuti) che mitiga il rischio di riuso anche da parte di chi dovesse intercettarlo^[5]Ovviamente, tutte le comunicazioni tramite protocollo HTTPS sono cifrate, ma i dati scambiati potrebbero comunque essere intercettati prima della loro cifratura (o dopo la decifratura).;
• la firma dei messaggi di richiesta^[6]Il riferimento è ai pattern [INTEGRITY_SOAP_01], [INTEGRITY_REST_01] e [INTEGRITY_REST_02]. che, oltre a garantire l’integrità del messaggio, ne garantiscono ulteriormente anche la provenienza e quindi scongiurano ulteriormente il riuso non autorizzato del token di autenticazione nel suo periodo di validità.

A queste misure se ne possono aggiungere altre, quale – per restare nel banale – l’abilitazione della comunicazione a un numero ristretto di indirizzi IP chiamanti (anche a livello di firewall del dominio dell’erogatore).

Naturalmente, queste misure da sole non bastano a garantire l’assoluta inviolabilità di un sistema, anche perché il criminale che intende fare accesso dove non gli è consentito usa ogni mezzo possibile e si sottrae a ogni convenzione.

Accesso abusivo di soggetti autorizzati

Quando invece l’accesso a una banca dati avviene in una cornice formalizzata e autorizzata, gli strumenti di sicurezza elencati nel ModI vengono in aiuto per tenere sotto controllo gli accessi ai dati ed evitare che i fruitori della banca dati facciano consultazione eccedenti rispetto alle loro effettive necessità. In un contesto in cui i fruitori aderiscono alle regole imposte dall’erogatore, per questi è possibile (e relativamente semplice) implementare meccanismi di verifica dell’attività di ricerca ed estrazione dei dati.

I casi proposti nel seguito, basati sull’analisi della documentazione e delle specifiche elaborate dai rispettivi soggetti erogatori, chiariscono quali misure preveda il ModI per mitigare i rischi connessi a consultazioni eccessive e come possano applicarsi in concreto.

In via generale vale la pena ricorda che, fra i pattern di sicurezza non nominati in precedenza, l’allegato 2 alle Linee guida sull’interoperabilità tecnica ne prevede un paio che hanno lo scopo di trasmettere all’erogatore i “dati tracciati nel dominio del fruitore”: in definitiva, si tratta di allegare a ogni richiesta di dati alcune informazioni che individuano l’utente umano che ha scatenato l’interrogazione remota della banca dati^[7]Il riferimento è ai pattern [AUDIT_REST_01] e [AUDIT_REST_02].. Le informazioni riguardano il nome utente con cui l’operatore umano è collegato al sistema della sua organizzazione, il nome della sua postazione di lavoro e il livello di sicurezza del meccanismo di autenticazione al sistema stesso^[8]L’acronimo tecnico è LoA – Level of Authentication. Per esempio, un LoA pari a 3 equivale a un sistema con doppio fattore di autenticazione..

ANPR – Anagrafe Nazionale della Popolazione Residente

La banca dati contiene i dati di residenza e composizione dei nuclei familiari di chi risiede in Italia. Si possono fare interrogazioni per avere conferme (verifiche) di dati in possesso del fruitore della banca dati e ricevere una risposta di tipo booleano (vero o falso), oppure fare estrazioni dei dati (accertamenti) a partire da dati identificativi del soggetto^[9]L chiavi di ricerca sono: codice fiscale oppure generalità complete oppure ID ANPR, il codice per la circolarità dei dati anagrafici di recente introduzione.. L’interazione fra fruitore ed erogatore avviene interamente nel perimetro definito dal ModI e poggia sulla PDND come unico intermediario e strumento esterno.

GlI e-service esposti da ANPR richiedono l’autenticazione tramite voucher PDND e firma dei messaggi di richiesta che, come visto in precedenza, attengono principalmente a tenere alla larga soggetti non autorizzati alla consultazione e garantire l’integrità dei dati scambiati.

ANPR implementa anche altre misure utili a tenere sotto controllo l’accesso ai dati. Vediamo quali.

Inoltro dei dati tracciati nel dominio del fruitore

Ogni richiesta del fruitore porta con sè^[10]Secondo il pattern di sicurezza [AUDIT_REST_02] le informazioni sui dati dell’utente connesso al sistema del fruitore sono inserite nell’header della request HTTP sotto la proprietà … Continue reading informazioni puntuali circa:

• il nome utente dell’operatore che, nel dominio del fuitore, scatena l’interrogazione della banca dati (l’etichetta del dato “userId”);
• il nome della postazione da cui si scatena l’interrogazione (l’etichetta del dato è “userLocation”);
• il livello di sicurezza dell’autenticazione ai sistemi del fruitore (l’etichetta del dato è “LoA”).

La compilazione puntuale e corretta delle informazioni consente, come evocato dal nome tecnico [AUDIT_REST_02] della misura, successive attività di auditing e verifica in caso di necessità. A ben vedere, però, questi dati consentono anche di mettere in piedi, da parte dell’erogatore, meccanismi di controllo automatizzato dell’andamento degli accessi, anche attraverso il confronto con l’andamento storico delle interrogazioni (o con l’andamento atteso) e rilevare anomalie e discostamenti. Per restare terra-terra, un sistema automatizzato potrebbe essere in grado di rilevare che un certo utente di un certo soggetto fruitore effettua un numero considerevolmente maggiore di interrogazioni rispetto ai suoi colleghi: un campanello d’allarme per un dipendete infedele o almeno poco attento a deontologia professionale e doveri d’ufficio?

Ovviamente, questo ha un senso se il fruitore fornisce dati sensati. Da parte dell’erogatore, infatti, non è così immediato rilevare compilazioni “fatte un tanto al chilo”.

Motivo dell’interrogazione e contatore delle interazioni

La parte semantica dell’interazione con ANPR, quella cioè che riguarda il contenuto di dati scambiati e, nello specifico, il contenuto della richiesta composta dal fruitore – che esula da quanto regolato dal ModI – prevede obbligatoriamente:

• che il fruitore dichiari il motivo dell’interrogazione con riferimento puntuale a un numero di pratica o di protocollo^[11]Le specifiche OpenAPI riportano testualmente, nella spiegazione del campo motivoRichiesta: “campo per l’indicazione obbligatoria del numero di riferimento della pratica per quale è … Continue reading. Il dato, evidentemente, consente di contestualizzare la richiesta e, in caso di necessità, verificare se questa è pertinente rispetto all’attività dichiarata come motivo dell’interrogazione;
• che si fornisca il numero progressivo della richiesta: il fruitore deve tenere un contatore delle richieste e, stando alle regole previste dal ministero, l’e-service di erogazione dei dati dovrebbe ignorare richieste che recano un valore del contatore non coerente^[12]Le specifiche, nella descrizione del campo idOperazioneClient recitano testualmente: “identificativo univoco attribuito all’operazione dall’ente. Deve essere numerico e crescente. … Continue reading: se la richiesta ha un numero più piccolo di una già elaborata e non è una mera ripetizione, cioè se reca richieste di interrogazioni relative a un soggetto diverso, il servizio risponde con un errore (che dovrebbe insospettire chi lo riceve).

Le due misure, visibili solo se si legge fra le pieghe della documentazione, sono senz’altro utili per evitare consultazioni eccessive. La loro corretta implementazione, dalla parte del fruitore, non è però così immediata.

Per l’identificativo univoco del motivo delle richiesta, chi progetta e sviluppa l’integrazione deve porre particolare attenzione al fatto che la consultazione di ANPR sia attivabile dopo che un tale identificativo univoco si sia concretizzato come immodificabile. Per esempio, un numero di protocollo potrebbe non esistere se si interroga ANPR per conoscere l’indirizzo di residenza di una persona a cui si deve notificare un atto. In tal caso il motivo della consultazione (il “numero di riferimento della pratica”) deve essere scelto in un modo che consenta, anche a distanza di tempo, di associare l’interrogazione di ANPR a un’attività specifica. Anche in questo caso, l’erogatore ANPR può poco se il fruitore non è preciso. Senz’altro, compilare i campi con stringhe generiche come “Verifica della residenza” non è una buona idea.

Anche il campo idOperazioneClient può nascondere delle insidie, per esempio quando più sistemi di uno stesso ente consultano lo stesso servizio ANPR nell’ambito di attività afferenti a funzioni diverse dello stesso ente, assistite da sistemi informatici diversi (anche se fra loro comunicanti, come si converrebbe nel sistema informativo di un’organizzazione). Qui non è chiaro se, per risolvere all’origine questa difficoltà tecnica, si possano creare nella PDND due client^[13]Non mi dilungo sui tecnicismi del funzionamento intimo della PDND: rimando al manuale operativo. o due finalità distinte che tengano divise le due esigenze di fruizione del dato, così da consentire due contatori indipendenti per le operazioni. Non ho avuto modo di sperimentare né ho trovato informazioni al riguardo. Questo però ricorda che anche la gestione della PDND, in termini di accordi di fruizione, creazione delle finalità e dei client di interrogazione dei servizi remoti deve avvenire con oculatezza e cognizione di causa, perché le implicazioni sono importanti.

INAD – l’Indice NAzionale dei Domicili digitali

INAD è l’indice dei domicili digitali dei cittadini e dei professionisti e defli enti di diritto privati non iscritti in albi, elenchi o registri. E’ liberamente consultabile via web. Per interrogazioni ripetute e massive da parte delle pubbliche amministrazioni, è a disposizione un’interfaccia API, intermediata dalla PDND.

Proprio perché i dati a cui si accede sono tendenzialmente pubblici e accessibili a tutti addirittura senza autenticarsi ad alcun sistema, l’API presente nel catalogo PDND presenta, come unico strumento di sicurezza mutuato dal ModI, l’autenticazione tramite voucher PDND.

In aggiunta, ogni interrogazione reca con sè anche la dichiarazione di un “riferimento del procedimento amministrativo per il quale si richiede l’estrazione”^[14]Così nella specifica API, pubblicata su GitHub: https://github.com/AgID/INAD_API_Extraction. Il senso del campo “praticalReference” (sic!) è del tutto analogo a quello del campo “motivoConsultazione” di ANPR.

In questo caso la complicazione implementativa è che la API di INAD consente anche di estrarre fino a 1000 domicili digitali con una sola chiamata e un solo riferimento a un solo procedimento amministrativo. Un peccato veniale, probabilmente.

SEND – La piattaforma per le notifiche digitali della pubblica amministrazione

SEND è il SErvizio Notifiche DIgitali, precedentemente noto come Piattaforma Notifiche Digitali che permette a pubbliche amministrazioni e altri soggetti di eseguire notifiche di documenti con valore legale.

SEND consente, da una parte, un accesso tramite una applicazione web, riservato agli operatori abilitati dell’ente mittente. L’applicazione consente di depositare e avviare a notifica documenti e, successivamente, di visualizzarli e controllare lo stato di avanzamento della loro notifica. Per evidenti motivi di protezione dei dati, gli utenti sono inseriti in gruppi e ogni utente ha diritto di accesso solo ai documenti depositati sulla piattaforma come associati a un gruppo di cui è parte.

La definizione di utenti e gruppi si fa da interfaccia di back-office (Selfcare di PagoPA spa). In caso di deposito di un documento da notificare, il back-office ha una funzione applicativa che consente di associare la richiesta di notifica a uno specifico gruppo. E’ evidente che questa sia una misura minima di sicurezza e protezione dei dati abbastanza basilare: ciascuno ha accesso solo alle risorse di cui ha bisogno. Solitamente le notifiche a valore legale sono relative a fatti che riguardano i loro destinatari, meritevoli di particolare tutela. E’ corretto che solo gli uffici titolari dei relativi procedimenti vi abbiano accesso, anche sulla piattaforma.

SEND mette tutte le sue funzioni applicative a disposizione degli enti anche tramite una API^[15]E’ il caso di ricordare che una API consente di mettere in condivisione non solo dati ma anche funzioni applicative, cioè consente a un sistema di avviare una funzione su un sistema remoto … Continue reading intermediata dalla PDND (con un fattore di sicurezza aggiuntivo per l’autenticazione, una API-KEY gestita ancora nel Selfcare di PagoPA spa). L’interfaccia API permettere di collegare stabilmente il sistema informativo del mittente con la piattaforma. Anche l’associazione delle notifiche ai gruppi è una funzione eseguibile tramite API.

Sono d’obbligo un paio di domande (del tutto aperte):

• quanti enti utilizzatori di SEND hanno correttamente censito gli utenti e i gruppi associando i primi ai secondi? Va da sé che i gruppi dovrebbero corrispondere alle unità organizzative in cui è articolato l’ente. L’articolazione dell’ente in unità organizzative, fra l’altro, dovrebbe trovare rispecchiamento nell’Indice della pubblica amministrazione (IPA) e, di conseguenza, si potrebbe ipotizzare che SEND – che con IPA è collegato – replicasse la struttura organizzative dell’ente mittente da IPA su se stesso;
• soprattutto, però, quante integrazioni di SEND tramite API implementano l’associazione dei documenti e delle notifiche ai gruppi?

Nella malaugurata ipotesi che l’integrazione di SEND con il sistema informativo dell’ente mittente (o, meglio, con il suo sistema di gestione documentale) si fosse dimenticata il dettaglio del gruppo, il danno sarebbe notevole: chiunque entrasse nel back-office di SEND avrebbe accesso a tutte le notifiche del proprio ente.

Conclusioni

Come detto, non si è voluto stabilire o proporre nessuna connessione fra efficacia e applicazione del ModI da una parte e violazioni e abusi di banche dati dall’altra.

Tuttavia, l’interesse per la sicurezza delle banche dati risvegliato dai fatti di cronaca ha dato lo spunto per qualche riflessione. Le misure di sicurezza e di controllo previste dal ModI e dalle API presenti sulla PDND potrebbero sembrare, se viste con superficialità, dei tecnicismi fini a se stessi, roba da nerd. Questi tecnicismi, in realtà, sono uno strumento a presidio dei diritti e della libertà delle persone (e anche delle imprese).

E’ dunque importante parlarne, anche con semplificazioni a scopo divulgativo, perché chi è responsabile della tenuta o della consultazione di dati ha il dovere di comprendere la posta in gioco e conoscere gli strumenti per tutelare la sicurezza degli scambi. Ha inoltre il dovere di pretendere che tutte le integrazioni siano fatte tenendo a distanza qualsiasi tentazione di implementazioni semplicistiche, magari accompagnate dal fatidico riff “tanto che vuoi che succeda”…

Foto di Gerd Altmann da Pixabay