Ogni accesso SPID lascia una traccia: cosa viene registrato

Ogni autenticazione SPID (Sistema Pubblico di identità Digitale) non è un semplice “login” paragonabile all’inserimento di username e password su un sito qualunque. È una transazione federata, regolata da norme tecniche e giuridiche, nella quale più soggetti si scambiano messaggi firmati digitalmente per attestare l’identità dell’utente, verificare il livello di autenticazione richiesto e consentire l’accesso al servizio.

Dietro il pulsante Entra con SPID si snoda un’infrastruttura basata su regole precise che derivano dal Codice dell’Amministrazione Digitale, dal DPCM 24 ottobre 2014, dai regolamenti e le regole tecniche AgID, dal GDPR, dal Codice Privacy e, sullo sfondo europeo, dal regolamento eIDAS. Il risultato è che ogni accesso lascia tracce tecniche, ma non tutte le tracce hanno lo stesso significato e non tutti i soggetti vedono le stesse informazioni.

Il punto centrale è questo: SPID registra gli eventi necessari a dimostrare che un’autenticazione è avvenuta, chi l’ha richiesta, verso quale servizio era diretta, con quale esito e con quale livello di sicurezza. Non registra, almeno presso l’Identity Provider (IdP), tutto ciò che l’utente fa dopo essere entrato nel portale.

I soggetti coinvolti: Identity Provider, Service Provider e AgID

Per capire quali dati sono registrati con SPID bisogna partire dai ruoli. L’IdP, come abbiamo spesso evidenziato, è il gestore dell’identità digitale. È il soggetto accreditato che ha identificato l’utente, gli ha rilasciato le credenziali SPID e gestisce il processo di autenticazione. Sono IdP, ad esempio, i gestori riconosciuti da AgID.

Il Service Provider (SP) è invece il soggetto che offre il servizio online: una Pubblica Amministrazione, un ente, una società privata aderente a SPID, un portale sanitario, previdenziale, tributario o amministrativo. Il SP non autentica direttamente l’utente con proprie credenziali, ma chiede all’IdP di confermarne l’identità digitale.

AgID ha un ruolo di regolazione, vigilanza e gestione dell’infrastruttura di fiducia. Definisce regole tecniche, modalità operative, requisiti per l’accreditamento, convenzioni e controlli. Non significa però che AgID disponga automaticamente di una cronologia centralizzata di ogni singolo accesso effettuato da ciascun cittadino.

SPID come sistema federato: perché i log sono distribuiti

Come abbiamo spesso ricordato, SPID è un sistema federato: significa che l’identità digitale è gestita da un soggetto diverso rispetto al servizio a cui l’utente ha chiesto di accedere.

Quando l’utente apre il sito di un ente e seleziona Entra con SPID, il SP genera una richiesta di autenticazione e la invia all’IdP dell’utente. L’IdP l’utente e restituisce al SP una risposta contenente un’asserzione, cioè una dichiarazione tecnica firmata che attesta l’avvenuta autenticazione. Le tracce dell’operazione sono quindi distribuite.

Ciascun IdP conserva evidenza di ogni autenticazione eseguita. Il SP, a sua volta, conserva evidenza dell’accesso  e delle operazioni compiute all’interno del proprio sistema. I due punti di osservazione evidentemente non coincidono: l’IdP vede la transazione di autenticazione, SP vede l’utilizzo del servizio.

Si tratta di una separazione fondamentale anche sul piano della privacy: evita che un unico soggetto disponga di una visione completa e dettagliata di tutte le attività svolte dall’utente presso ogni amministrazione o servizio privato.

Il protocollo SAML 2.0: quali dati viaggiano durante l’accesso

Le regole tecniche SPID sono costruite intorno al protocollo SAML 2.0, Security Assertion Markup Language. SAML è uno standard usato nei sistemi di Single Sign-On (SSO) per scambiare informazioni di autenticazione e attributi tra entità diverse.

Nel flusso SPID classico, il SP genera una AuthnRequest, cioè una richiesta di autenticazione. Tale richiesta include informazioni quali l’identificativo del SP, il servizio a cui si desidera accedere, il livello di autenticazione SPID richiesto, gli endpoint tecnici utilizzati per lo scambio delle comunicazioni e altri parametri indispensabili per consentire al sistema di elaborare correttamente la richiesta stessa.

Lìutente è poi reindirizzato verso l’IdP: dopo l’autenticazione, l’IdP produce una Response SAML. Se l’autenticazione ha successo, la risposta contiene una Assertion, firmata digitalmente, con le informazioni necessarie al SP per riconoscere l’utente.

La Response SAML deve essere verificata dal Service Provider prima di essere accettata: i controlli sono incentrati sulle firme digitali, sulla validità temporale dell’asserzione, sulla corrispondenza del destinatario, sull’identificativo dell’emittente, sull’aderenza ai metadati e sulla coerenza del messaggio rispetto alla richiesta originaria.

Una parte delle tracce tecniche di SPID non è quindi costituita soltanto da righe di log applicativo, ma anche da messaggi SAML, identificativi di richiesta e risposta, timestamp, firme, certificati, endpoint e attributi.

Cosa registra l’Identity Provider

L’IdP SPID deve conservare informazioni necessarie alla gestione dell’identità digitale, alla sicurezza del servizio e alla ricostruzione degli eventi. In una transazione di autenticazione, i dati registrabili comprendono tipicamente:

• la data e l’ora della richiesta di autenticazione;
• l’identificativo del Service Provider;
• il livello di autenticazione richiesto;
• l’esito dell’autenticazione;
• l’identificativo tecnico della transazione;
• il riferimento alla sessione;
• l’indirizzo IP da cui proviene la richiesta dell’utente;
• informazioni sul dispositivo, sul browser o sull’app utilizzata, quando trattate dai sistemi di sicurezza;
• eventuali errori, anomalie o tentativi falliti;
• l’uso di fattori ulteriori, come OTP, app di conferma o sistemi equivalenti.

L’IdP deve sapere verso quale SP l’utente si sta autenticando, altrimenti non potrebbe produrre una risposta valida e indirizzata correttamente. Il gestore SPID conosce che l’utente ha chiesto di accedere a un certo servizio. Tuttavia, come indicato in precedenza, questa conoscenza è limitata alla fase di autenticazione.

Se, ad esempio, l’utente accede al sito dell’Agenzia delle Entrate, un IdP può registrare che è avvenuta una transazione di autenticazione verso quel servizio. Non vede però quale dichiarazione sia stata consultata, quale istanza sia stata inviata o quale documento sia stato scaricato.

Cosa registra il Service Provider

Il SP, come detto, registra una porzione diversa della storia. Riceve la risposta SAML dall’IdP e, dopo averla verificata, associa l’identità digitale alla sessione applicativa dell’utente. Da quel momento in poi, il SP gestisce gli eventi interni: pagine consultate, pratiche aperte, documenti scaricati, istanze presentate, deleghe utilizzate, modifiche effettuate, consensi espressi.

Le regole tecniche SPID richiamano un obbligo importante: ciascun SP deve conservare per 24 mesi le informazioni necessarie a imputare alle singole identità digitali le operazioni effettuate sui propri sistemi.

Deve esservi la possibilità di ricondurre determinate operazioni a una specifica identità digitale. Se un utente presenta una domanda, modifica una posizione, invia un’istanza o accede a una funzione, il SP deve poter dimostrare chi ha compiuto quell’azione.

Se un cittadino sostiene di non aver mai presentato una determinata richiesta, oppure se un’amministrazione deve verificare l’origine di un’operazione, i log conservati per 24 mesi consentono di ricostruire il collegamento tra identità digitale, sessione e azione effettuata.

Naturalmente, i log devono essere protetti, accessibili solo a personale autorizzato, trattati secondo principi di minimizzazione, integrità, riservatezza e accountability.

Gli attributi SPID: non tutti i dati sono sempre trasmessi

Durante l’autenticazione SPID non viene trasmesso automaticamente l’intero patrimonio informativo dell’utente. SPID prevede un insieme di attributi identificativi e secondari, ma il SP deve richiedere solo quelli necessari alla specifica transazione.

Tra gli attributi possono rientrare nome, cognome, codice fiscale, data di nascita, luogo di nascita, sesso, indirizzo email, numero di telefono o domicilio digitale, a seconda dei casi e delle configurazioni.

Il codice fiscale è spesso l’attributo decisivo nei servizi pubblici italiani, perché consente di associare con certezza l’identità digitale alla posizione amministrativa del cittadino nei sistemi dell’ente. Al momento dell’autenticazione SPID, avrete certamente notato quali e quanti dati sono condivisi con i SP: il volume di informazioni varia notevolmente da un servizio all’altro.

Sul piano tecnico, gli attributi sono inclusi nell’asserzione SAML restituita dall’IdP al SP; sul piano della privacy, la loro trasmissione deve essere giustificata, proporzionata e comprensibile per l’utente.

Il gestore SPID può profilare l’utente?

La profilazione commerciale degli accessi SPID da parte degli IdP non è compatibile con la funzione del sistema: i dati trattati nell’ambito dell’identità digitale devono essere usati per finalità connesse all’erogazione del servizio, alla sicurezza, alla gestione dell’identità, agli obblighi normativi e alla prevenzione degli abusi.

Il fatto che l’IdP possa vedere verso quali SP l’utente si autentica non significa che possa usare liberamente questa informazione per costruire profili commerciali, venderla a terzi o impiegarla per finalità estranee.

Qui entrano in gioco sia le regole del sistema SPID sia il GDPR. La finalità del trattamento è determinata e limitata: ogni uso ulteriore richiederebbe una base giuridica autonoma e dovrebbe comunque rispettare i principi di proporzionalità, trasparenza e minimizzazione.

Un caso particolare si verifica quando uno stesso soggetto ricopre più ruoli, ad esempio quando è al tempo stesso gestore di identità digitale e fornitore di servizi.

In situazioni di questo tipo diventa essenziale mantenere separate i dati: le informazioni raccolte come IdP non devono fondersi impropriamente con quelle raccolte come SP. La separazione tecnica, organizzativa e logica serve a evitare concentrazioni indebite di dati e usi incompatibili con le finalità originarie.

OpenID Connect in SPID: evoluzione tecnica del modello

Sebbene SPID sia nato principalmente su SAML 2.0, AgID ha introdotto anche linee guida per l’integrazione di OpenID Connect in SPID.

OpenID Connect è uno strato di identità costruito sopra OAuth 2.0: usa token, endpoint standardizzati, JSON Web Token, chiavi pubbliche esposte tramite JWKS e meccanismi moderni di federazione.

Il modello rimane simile: un soggetto richiede l’autenticazione, un provider la esegue, un token o una risposta attestano l’identità dell’utente. Cambiano però i formati tecnici, i flussi, i controlli crittografici e la gestione dei metadati.

Anche in un modello OpenID Connect, gli eventi di autenticazione devono essere tracciabili. Possono cambiare i nomi degli oggetti tecnici, ma non scompare l’esigenza di registrare chi ha richiesto cosa, quando, con quale esito e con quali garanzie.

Cosa può essere acquisito in caso di contestazione o indagine

In caso di contestazione, incidente o indagine, le tracce SPID possono essere utilizzate per ricostruire gli eventi:

• L’IdP può fornire evidenza dell’autenticazione: orario, esito, livello, identificativi tecnici e dati collegati alla sessione.
• Il SP può fornire evidenza dell’accesso al servizio e delle operazioni effettuate dopo l’autenticazione.
• Il provider di connettività può, nei casi previsti dalla legge, contribuire a collegare un indirizzo IP a una determinata utenza in un certo momento.

La ricostruzione completa richiede quindi la correlazione di più fonti. È proprio questa frammentazione a rendere il sistema più rispettoso della privacy rispetto a un archivio unico centralizzato.