Linee Guida sull’infrastruttura tecnologica della PDND per l’interoperabilità dei sistemi informativi e delle basi di dati

Infrastruttura tecnologica della PDND per l’interoperabilità dei sistemi informativi e delle basi di dati

Le presenti Linee Guida disciplinano l’infrastruttura tecnologica della Piattaforma Digitale Nazionale Dati (PDND) ai sensi dell’articolo 50-ter, comma 2, del CAD. Definiscono gli standard tecnologici, i criteri di sicurezza, accessibilità, disponibilità e interoperabilità, nonché il processo di adesione e di fruizione del catalogo API. Il documento è rivolto alle pubbliche amministrazioni e agli altri soggetti di cui all’articolo 2, comma 2, CAD, ai privati che operano per finalità di interesse pubblico e al gestore della piattaforma.

Quadro normativo e finalità della PDND

La PDND è richiamata come strumento del modello di interoperabilità delle pubbliche amministrazioni. Ai sensi dell’articolo 50-ter, comma 1, CAD, la piattaforma è finalizzata a favorire la conoscenza e l’utilizzo del patrimonio informativo detenuto per finalità istituzionali, la condivisione dei dati tra soggetti legittimati e la semplificazione degli adempimenti di cittadini e imprese. Ai sensi del comma 2, la PDND rende possibile l’interoperabilità tramite:

• accreditamento, identificazione e gestione dei livelli di autorizzazione dei soggetti abilitati;
• raccolta e conservazione delle informazioni relative ad accessi e transazioni.

Le linee guida sono adottate da AgID ai sensi dell’articolo 71 CAD e dell’articolo 14-bis, comma 2, lettera a), CAD. Sono richiamati, come riferimenti principali, il GDPR, il Codice privacy, eIDAS, il decreto-legge n. 135/2018, il decreto 22 settembre 2022 sugli obblighi e termini di accreditamento e il decreto 5 dicembre 2023 sulle misure di attuazione dell’articolo 50-ter CAD.

Destinatari e ruoli soggettivi

Le linee guida si applicano a:

• soggetti erogatori, cioè i soggetti pubblici e i privati che, nei limiti dell’ordinamento, mettono a disposizione dati o integrano processi tramite PDND;
• soggetti fruitori, cioè i soggetti pubblici e i privati che fruiscono degli e-service;
• gestore della PDND, incaricato di progettazione, sviluppo e gestione dell’infrastruttura.

È confermato che il trasferimento di un dato tra sistemi informativi non modifica la titolarità del dato né del trattamento, restando ferme le responsabilità dei soggetti che ricevono e trattano il dato come titolari autonomi.

Adesione alla PDND e Accordo di Adesione

L’adesione avviene tramite un processo di accreditamento che comprende:

• identificazione del soggetto aderente o del suo rappresentante/delegato, secondo le modalità dell’articolo 64 CAD;
• qualificazione del soggetto aderente;
• invio al domicilio digitale della comunicazione con le informazioni della richiesta e il codice di controllo;
• recupero, sottoscrizione con firma elettronica e caricamento dell’Accordo di Adesione.

Per i gestori di pubblico servizio, se manca l’iscrizione in IPA o il domicilio digitale è errato, il soggetto deve prima provvedere alla correzione/integrazione dei dati e, fino ad allora, il gestore lo considera impresa privata. L’adesione è subordinata alla permanenza delle condizioni che l’hanno determinata e il gestore deve verificarle periodicamente.

Il gestore deve mettere a disposizione:

• un’istanza di produzione, con dati reali e valore amministrativo;
• un’istanza di collaudo, con dati fittizi e senza valore amministrativo;
• facoltativamente un’ulteriore istanza per verifiche e studio delle funzionalità e delle interazioni.

Delega e operatività per conto di altri aderenti

Le linee guida valorizzano il ruolo del Delegato, una pubblica amministrazione aderente che opera per conto di un’altra PA aderente. La delega può riguardare:

• la registrazione e modifica degli e-service sul Catalogo API, inclusa l’accettazione delle richieste di fruizione, per il Delegato dell’Erogatore;
• la compilazione e presentazione delle richieste di fruizione, inclusa la compilazione delle analisi del rischio, per il Delegato del Fruitore.

La delega decorre dall’accettazione del Delegato e abilita i suoi utenti a operare per conto dell’aderente delegante. Una PA può candidarsi a svolgere il ruolo di Delegato; la delega deve rispettare il vincolo per cui non è possibile designare più delegati per l’erogazione o la fruizione del medesimo e-service.

Gestione degli attributi degli aderenti

La PDND gestisce un Registro degli Attributi, utilizzato per verificare se un fruitore possiede i requisiti di fruizione richiesti per un dato e-service. Gli attributi possono essere:

• certificati, cioè associati automaticamente sulla base di fonti autorevoli e dati ufficiali;
• dichiarati, cioè affermati dal fruitore sotto la propria responsabilità;
• verificati, cioè dichiarati e successivamente verificati da un erogatore.

Gli attributi certificati sono acquisiti, in sede di adesione o di fruizione, da banche dati e indici istituzionali richiamati dalle linee guida, tra cui IPA, INI-PEC, Registro delle imprese e INAD, oltre alle basi di dati di interesse nazionale o ad altre fonti pubbliche individuate nella valutazione d’impatto del gestore. Il gestore deve informare il richiedente persona fisica sugli attributi certificati associati e sulle banche dati di provenienza.

Gli erogatori, nel definire i requisiti di fruizione, devono verificare la presenza degli attributi necessari nel Registro. Se il riscontro è positivo, usano tali attributi; se è negativo, possono proporre un nuovo attributo, specificando la tipologia richiesta. La piattaforma deve agevolare anche l’ispezione periodica per individuare attributi equivalenti e, in caso di equivalenza confermata, la normalizzazione dei nomi.

Le variazioni degli attributi devono essere segnalate dagli aderenti:

• i fruitori devono segnalare le variazioni degli attributi dichiarati e verificati a loro associati;
• gli erogatori devono segnalare le variazioni degli attributi verificati rilevanti per i propri e-service.

La piattaforma comunica le variazioni agli erogatori interessati, che valutano se proseguire, sospendere o terminare l’erogazione.

Catalogo API, registrazione degli e-service e requisiti tecnici

Il Catalogo API è la componente unica e centralizzata che consente agli erogatori di registrare e pubblicare gli e-service e ai fruitori di consultarli. La pubblicazione favorisce la conoscenza delle API, la gestione del ciclo di vita degli e-service e la riduzione di interfacce ridondanti o semanticamente sovrapposte.

Gli erogatori devono:

• utilizzare tecnologie, pattern e profili previsti dal Modello di interoperabilità e dalle linee guida tecniche di AgID;
• definire i requisiti di fruizione, salvo i casi di e-service che rendono disponibili dati aperti ai sensi della direttiva (UE) 2019/1024;
• indicare la durata dei voucher in relazione alla tipologia di e-service e ai dati trattati, nel rispetto della disciplina privacy;
• indicare se l’e-service tratta dati personali.

Per gli e-service in erogazione inversa, l’erogatore deve svolgere, sotto la propria responsabilità, l’analisi del rischio privacy per ogni specifica finalità di ricezione dei dati. Il Catalogo API riporta almeno descrittori dell’e-service, descrizione dell’API, documentazione accessoria e, facoltativamente, una casella di posta riferita a un’articolazione organizzativa.

Gli erogatori sono responsabili della correttezza delle informazioni pubblicate e della gestione del ciclo di vita degli e-service, tramite i propri utenti o delegando a uno o più delegati dell’erogatore. Una volta pubblicato, l’e-service non può essere modificato in modo da impattare sui fruitori, né può essere dismesso in costanza di fruizione.

Richiesta di fruizione e rilascio del Voucher

Chi intende fruire di un e-service deve:

• individuare l’e-service nel Catalogo API;
• inoltrare la richiesta di fruizione tramite PDND, dichiarando gli attributi dichiarati e/o verificati necessari;
• se richiesti attributi verificati, attendere la verifica dell’erogatore.

La richiesta ha esito positivo se gli attributi certificati, dichiarati e verificati soddisfano i requisiti di fruizione. Se l’e-service richiede un’accettazione esplicita dell’erogatore, il gestore comunica la richiesta all’erogatore; trascorsi 30 giorni senza riscontro, invia una segnalazione di richiesta inevasa.

La piattaforma deve consentire agli aderenti di accedere ai dati relativi alle richieste di fruizione, sospenderle o eliminarle se vengono meno i presupposti o in caso di uso improprio, e recuperarle come documento informatico con integrità e certezza dell’origine. Non devono essere emessi voucher per richieste sospese o eliminate.

Analisi del rischio privacy e configurazione del servizio

Dopo l’esito positivo della richiesta di fruizione, se l’e-service tratta dati personali e non si tratta di dati aperti, il fruitore deve svolgere l’analisi del rischio:

• in erogazione ordinaria, per ciascuna finalità per cui chiede accesso;
• in erogazione inversa, selezionando l’analisi del rischio relativa alla finalità per cui intende trasmettere dati.

L’analisi del rischio deve contenere almeno:

• base giuridica del trattamento ai sensi dell’art. 6 GDPR;
• finalità del trattamento;
• verifica del rispetto dei principi di cui all’art. 5 GDPR e dell’art. 25 GDPR;
• indicazione del periodo di conservazione.

Il fruitore deve inoltre indicare una stima di carico delle richieste. Se tale stima è superata dalla richiesta, la piattaforma comunica all’erogatore quanto registrato dal fruitore e consente la registrazione della finalità solo dopo conferma dell’erogatore, anche in relazione all’eventuale adeguamento dei sistemi. Il fruitore può sospendere, eliminare o modificare la stima di carico; la piattaforma deve consentire la sospensione o il blocco dell’uso per la singola finalità e non emette voucher per finalità sospese o bloccate.

Trust machine-to-machine e voucher di autorizzazione

La PDND realizza il trust machine-to-machine tra sistemi degli aderenti e sistemi della piattaforma, e tra sistemi degli aderenti tra loro. Gli aderenti devono generare e custodire il materiale crittografico di loro competenza; la piattaforma deve generare e custodire il proprio materiale crittografico e rendere disponibile quello pubblico necessario per verificare i voucher.

Per ogni transazione:

• il fruitore chiede l’emissione di un voucher connesso alla richiesta di fruizione e alla relativa analisi del rischio;
• la piattaforma emette un voucher a validità temporale limitata;
• il fruitore usa il voucher per chiedere la fruizione;
• l’erogatore verifica voucher e validità temporale, quindi abilita la fruizione.

L’erogatore può richiedere che il sistema del fruitore sia identificato direttamente, decorando il voucher. Le tecnologie e modalità tecniche sono disciplinate dall’Allegato 3.

Raccolta delle informazioni su accessi e transazioni

La piattaforma deve supportare il tracciamento delle interazioni e la raccolta di informazioni per misurare l’efficacia dell’interoperabilità nel tempo. Sono previsti tre servizi principali:

• probing, per verificare periodicamente la disponibilità delle API;
• auditing, per registrare le autorizzazioni/voucher rilasciati;
• tracing, per raccogliere tracciati quantitativi delle transazioni tra erogatore e fruitore.

Le informazioni devono essere conservate e aggregate almeno per coordinate temporali, aderenti coinvolti e loro ruolo, e-service e esito della chiamata/risposta. La piattaforma non effettua la riconciliazione dei tracciati della stessa transazione provenienti da soggetti diversi.

Interoperabilità semantica e regole di popolamento

Per garantire la qualità dei dati, l’Allegato 7 definisce regole di popolamento delle entità registrate nella piattaforma. Ogni regola deve riguardare un attributo specifico di una singola entità, essere verificabile ex ante con controlli automatici e coerente con vocabolari controllati e modelli di dati nazionali e internazionali.

Gli aderenti devono rispettare tali regole al momento del popolamento. La piattaforma deve impedire il popolamento quando una regola è violata e deve offrire strumenti per correggere le entità già registrate. Il gestore deve inoltre rendere disponibili alla Presidenza del Consiglio dei ministri, o al soggetto delegato, le evidenze delle entità non conformi.

Modello asincrono con callback e segnali di variazione

Le linee guida disciplinano due modalità evolutive di scambio:

• lo scambio asincrono con callback, basato su un pattern RPC PUSH non bloccante, in cui il fruitore indica un servizio di callback e l’erogatore invoca tale servizio quando la risorsa è pronta;
• la distribuzione dei segnali di variazione, con cui un produttore comunica ai consumatori variazioni di stati e fatti relativi a uno specifico e-service.

Nel modello dei segnali di variazione, i messaggi non contengono il dato oggetto della variazione né l’identificatore diretto del soggetto, sostituito da un identificatore pseudonimizzato ottenuto con hashing con seme. Il produttore deve comunicare ai consumatori algoritmo e parametri di hashing e deve periodicamente modificare almeno uno dei parametri di pseudonimizzazione, in proporzione alla sensibilità dei dati.

Livelli di servizio e indicatori di qualità

Il rapporto tra gestore e aderenti è regolato dai livelli di qualità definiti nell’Accordo di Adesione. Gli indicatori riguardano sia i servizi/API sia i servizi di supporto:

• tempo di risposta su percentile;
• numero di richieste soddisfatte per unità di tempo;
• numero di richieste con errore per unità di tempo;
• tempestività di ripristino dell’operatività;
• tempestività di risposta alle segnalazioni di anomalie.

Gli indicatori si basano sui log del gestore e sui tempi di presa in carico e risoluzione delle segnalazioni.

Responsabilità dei soggetti e obblighi privacy

Il gestore, l’erogatore e il fruitore devono operare nel rispetto delle linee guida e dei relativi allegati. Le dichiarazioni rese dagli aderenti sono considerate rese ai sensi del DPR 445/2000.

Il gestore deve garantire i livelli di servizio, conservare le evidenze digitali delle attività, adottare misure tecniche e organizzative adeguate e informare tempestivamente gli aderenti in caso di violazioni di sicurezza o minacce rilevanti.

L’erogatore, sotto la propria responsabilità, deve garantire:

• conformità dell’e-service alla normativa, inclusa la privacy by design e by default;
• accesso solo ai fruitori che posseggono gli attributi richiesti e, per l’erogazione ordinaria, che abbiano compilato l’analisi del rischio;
• per l’erogazione inversa, la corretta compilazione dell’analisi del rischio e l’uso dei dati solo per le finalità dichiarate;
• minimizzazione, esattezza, integrità, riservatezza dei dati comunicati;
• tracciamento e conservazione dei log per il tempo necessario;
• conservazione probatoria dei voucher.

Il fruitore deve, tra l’altro:

• richiedere l’e-service solo se ritiene di possedere tutti gli attributi richiesti;
• compilare l’analisi del rischio ove necessaria;
• comunicare o ricevere i riferimenti documentali che dimostrano la liceità del trattamento;
• formare gli utenti interni autorizzati;
• segnalare criticità, incidenti e malfunzionamenti;
• notificare eventuali violazioni dei dati personali secondo gli articoli 33 e 34 GDPR;
• conservare i voucher a fini probatori.

In caso di inadempimento del fruitore, l’erogatore può sospendere anche immediatamente la fruizione dell’e-service.

Ruoli GDPR e trattamento dei dati personali

Le linee guida chiariscono che l’accesso ai dati tramite PDND non modifica la titolarità del trattamento. In generale:

• l’erogatore e il fruitore sono titolari autonomi;
• il gestore è titolare per le attività di implementazione e gestione della piattaforma;
• per la distribuzione dei segnali di variazione, il gestore agisce come responsabile del trattamento del produttore;
• il delegato opera come responsabile del trattamento per conto della PA delegante e il relativo ruolo deve essere formalizzato prima dell’inizio del trattamento.

Minimizzazione, conservazione, DPIA e sicurezza

Il gestore deve limitare il trattamento ai dati strettamente necessari e deve documentare categorie di dati, interessati, finalità e basi giuridiche. Deve inoltre rispettare rigorosi tempi di conservazione:

• accordo di adesione: 10 anni dalla cessazione del rapporto;
• registrazioni degli e-service: 10 anni dalla cancellazione dell’API dal Catalogo;
• attributi: 10 anni dalla cancellazione dell’attributo;
• log di sistema: 24 mesi;
• auditing: 10 anni;
• tracing: 12 mesi.

Il gestore deve predisporre una valutazione d’impatto ex art. 35 GDPR e renderla disponibile agli aderenti. Se il trattamento non è già effettuato al di fuori della PDND, anche erogatore e fruitore devono effettuare la DPIA e registrare il trattamento nel proprio registro.

Il gestore deve fornire un’informativa ai sensi degli articoli 12, 13 e 14 GDPR e garantire l’esercizio dei diritti degli interessati. Può avvalersi di responsabili del trattamento, privilegiando fornitori UE; in caso di Paesi terzi devono essere rispettate le garanzie del Capo V GDPR.

Le misure di sicurezza minime includono:

• cifratura in transito e a riposo;
• anonimizzazione, ove possibile;
• riservatezza, integrità, disponibilità e resilienza;
• capacità di ripristino tempestivo;
• verifica periodica dell’efficacia delle misure.

Il documento richiama inoltre pratiche di cifratura e anonimizzazione, includendo hashing e tokenizzazione, con l’obiettivo di rendere i dati incomprensibili a soggetti non autorizzati e di eliminare, laddove possibile, gli elementi identificativi diretti.