g-docweb-display Portlet

Parere sullo schema di “Regole tecniche per la gestione delle sessioni di autenticazione e single sign-on” nell’ambito del Punto di accesso telematico (di seguito, “PAT”) di cui all’art. 64-bis del d.lgs. 7 marzo 2005, n. 82 (“CAD”) - 21 luglio 2022 [9808982]

Stampa Stampa Stampa
PDF Trasforma contenuto in PDF

[doc. web n. 9808982]

Parere sullo schema di “Regole tecniche per la gestione delle sessioni di autenticazione e single sign-on” nell’ambito del Punto di accesso telematico (di seguito, “PAT”) di cui all’art. 64-bis del d.lgs. 7 marzo 2005, n. 82 (“CAD”) - 21 luglio 2022

Registro dei provvedimenti
n. 271 del 21 luglio 2022

IL GARANTE PER LA PROTEZIONE DEI DATI PERSONALI

NELLA riunione odierna, alla quale hanno preso parte il prof. Pasquale Stanzione, presidente, la prof.ssa Ginevra Cerrina Feroni, vicepresidente, il dott. Agostino Ghiglia e l’avv. Guido Scorza, componenti, e il cons. Fabio Mattei, segretario generale;

VISTO il 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 – di seguito, “Regolamento”);

VISTO il decreto legislativo 30 giugno 2003, n. 196, recante “Codice in materia di protezione dei dati personali” (di seguito, “Codice”);

VISTA la documentazione in atti;

VISTE le osservazioni formulate dal segretario generale ai sensi dell’art. 15 del regolamento del Garante n. 1/2000;

RELATORE il prof. Pasquale Stanzione;

PREMESSO

Con la nota del 25 marzo 2022, successivamente integrata con le note del 24 maggio e del 7 giugno 2022, l’Agenzia per l’Italia digitale (di seguito, “AgID”) ha sottoposto al parere del Garante lo schema di “Regole tecniche per la gestione delle sessioni di autenticazione e single sign-on” nell’ambito del Punto di accesso telematico (di seguito, “PAT”) di cui all’art. 64-bis del d.lgs. 7 marzo 2005, n. 82 (di seguito, “CAD”).

L’emanazione di tali Regole tecniche è prevista dalle “Linee guida sul punto di accesso telematico ai servizi della Pubblica Amministrazione” (di seguito, “Linee guida sul PAT”), adottate con determinazione AgID n. 598 dell’8 novembre 2021 (su cui il Garante ha espresso parere favorevole con il provv. n. 394 del 1° novembre 2021, doc. web n. 9714315), nelle quali è stabilito che “con successive regole tecniche sarà disciplinata anche la possibilità di veicolare l’accesso ai servizi gestiti dai Soggetti erogatori tramite un meccanismo di federated identity (eventualmente anche con modalità single sign-on)” (all. 2, cap. 1, secondo periodo, p. 52).

1. Lo schema di Regole tecniche in esame

Lo schema di Regole tecniche si occupa di individuare “le modalità operative con cui il Punto di accesso telematico assicura: l’identificazione e l’autenticazione degli utenti finali dei servizi in rete resi disponibili dal Punto di accesso telematico [(“considerando il profilo di autenticazione individuato nelle Linee Guida OpenID Connect in SPID”)], dipendente dallo stato delle identità rilasciate agli stessi utenti nel Sistema pubblico per la gestione delle identità digitali (SPID) di cui all’articolo 64 del CAD; la realizzazione del meccanismo di single sign-on tra il Punto di accesso telematico e i servizi in rete resi disponibili dai soggetti erogatori per dare inizio a specifici flussi o azioni dispositive integrate nell’esperienza dell’utente all’interno del Punto di accesso telematico”.

Inoltre, per quanto concerne l’identificazione e autenticazione degli utenti finali tramite l’identità digitale CIE, è previsto che “nel rispetto delle presenti Regole tecniche e secondo gli accordi intercorrendi con il Ministero dell’Interno, il CieID server, quale IdP unico della federazione CIE, abilita l’utilizzo delle sessioni lunghe e del single sign-on mediante il punto di accesso telematico” (cap. 1).

1.1. La gestione delle sessioni di autenticazione (cap. 3 dello schema)

Secondo quanto stabilito nello schema in esame, “l’autenticazione realizzata dal Punto di accesso telematico prevede la generazione di una identità, mantenuta dallo stesso Punto di accesso telematico, derivata e dipendente da un’identità SPID emessa da uno degli IdP SPID”, con “la creazione di una sessione di autenticazione generata a partire da un’identità SPID detenuta da uno dei IdP SPID” e “l’allineamento periodico della sessione di autenticazione con lo stato della identità SPID su cui la stessa è stata creata”.

Nel descrivere il processo per assicurare l’identificazione e autenticazione degli utenti finali del PAT, viene in particolare previsto che il time-to-live (cioè, il periodo di validità) del c.d. Access Token (che consente di ottenere gli attributi dell’identità digitale SPID dell’utente finale) sia “al massimo pari a 12 ore”, mentre il time-to-live del c.d. Refresh Token (che consente di ottenere un altro Access Token quando quello originario è scaduto, senza dover richiedere una nuova autenticazione) possa essere “pari al massimo a 270 giorni, individuati in base alle esigenze di usabilità ed accessibilità che sono state analizzate e rappresentate dal gestore del Punto di accesso telematico e diminuibili di concerto con gli IdP”.

È inoltre previsto che “gli IdP SPID, differentemente da quanto indicato nelle [LG SPID OIDC], devono applicare la tecnica di Refresh Token Rotation, prevedendo che a ogni utilizzo di un Refresh Token lo stesso è sostituito da un nuovo Refresh Token la cui validità ha effetto dal momento dell’emissione, con time-to-live costante”.

Il PAT “deve assicurare la creazione di una sessione di autenticazione PAT a partire da un’identità SPID detenuta da uno dei IdP SPID” con “autenticazione di SPID di livello 2” e “deve creare una nuova sessione di autenticazione PAT:

in assenza di una sessione di autenticazione PAT per l’utente finale;

nel caso in cui l’utente finale ha selezionato l’utilizzo di sessioni lunghe, se il time-to-live del Refresh Token associato a una sessione di autenticazione PAT risulta scaduto;

nel caso in cui l’utente finale non abbia selezionato l’utilizzo di sessioni lunghe, se il time-to-live del Access Token associato a una sessione di autenticazione PAT risulta scaduto;

in tutti i casi in cui le interazioni con l’IdP SPID diano esito negativo”.

Il PAT “deve garantire all’utente finale la scelta di eventuali sessioni lunghe” (par. 3.1).

Per quanto concerne le modalità di creazione di una sessione di autenticazione a partire da un’identità SPID, lo schema prevede che l’applicazione utilizzata dall’utente finale per interagire con i servizi resi dal PAT (di seguito, “AppPAT”) debba “chiedere all’utente finale di selezionare l’IdP SPID di suo interesse e, nel contempo, raccogliere la selezione da esso effettuata in merito all’utilizzo delle sessioni lunghe e inoltrare tali scelte a PAT Backend”, dopodiché descrive le interazioni previste (par. 3.1.2).

Lo schema in esame prevede, inoltre, che il PAT “deve assicurare la tracciatura delle richieste di login effettuate da AppPAT comprensivo della selezione effettuata dall’utente finale in merito all’utilizzo delle sessioni lunghe, i cui tempi di conservazione sono individuati dal gestore del Punto di accesso telematico in coerenza con le [Linee guida sul PAT] e nel rispetto di quanto prescritto al paragrafo 4.1. Tracciature identity provider del Regolamento recante le regole tecniche ex articolo 4, comma 2, D.P.C.M. 24 ottobre 2014 [(ossia 24 mesi)]. Nello specifico delle autenticazioni realizzate tramite “login veloce” PAT Backend deve tracciare gli eventi e gli oggetti scambiati per abilitare la creazione di una sessione di autenticazione a valle della verifica della firma prevista per il “challenge” tra AppPAT e PAT Backend” (par. 3.1.3). Sono poi indicate le misure di sicurezza adottate (par. 3.1.4).

Lo schema stabilisce che “nel caso in cui l'utente finale abbia selezionato l’utilizzo di sessioni lunghe, il Punto di accesso telematico è responsabile dell’autenticazione degli utenti finali per cui è stata creata una sessione di autenticazione nelle modalità indicate” (par. 3.2), precisando che “le entità AppPAT e PAT Backend sono responsabili dell’autenticazione dell’utente finale e l’associazione alla sessione di autenticazione precedentemente creata per lo stesso utente”, mentre “gli IdP SPID sono responsabili di fornire lo stato delle identità SPID di propria competenza e devono assicurare che UserInfo Endpoint restituisca gli attributi dell’utente associato alle identità SPID attualizzati al momento della richiesta da parte del Punto di accesso telematico” e i medesimi, “nel caso in cui l’identità SPID associata ad un Refresh Token risulti sospesa o revocata, devono rispondere con un errore sulla base della lista di codici di errori riconosciuti dal protocollo” (par. 3.2.1). Nello schema vengono altresì descritte le interazioni previste (par. 3.2.2) e la tracciatura delle interazioni (par. 3.2.3).

Per quanto concerne le misure di sicurezza adottate per l’accesso all’AppPAT in presenza di sessione di autenticazione valida, si prevede che il PAT debba “assicurare in maniera alternativa i seguenti meccanismi di identificazione dell’utente finale: 1. tramite riconoscimento biometrico dell’utente finale, per il tramite degli strumenti messi a disposizione dal dispositivo utilizzato dallo stesso; 2. in assenza di supporto al biometrico da parte del dispositivo o della scelta dell’utente finale di non usarlo, tramite meccanismo di sblocco registrato dallo stesso in fase di inizializzazione del AppPAT o per successive modifiche realizzate tramite la stessa AppPAT”. Inoltre, è previsto che l’“AppPAT può utilizzare meccanismi di sblocco, quali PIN, Password o Pattern (segno di sblocco) implementati dalla stessa AppPAT o recuperati dalle funzionalità del sistema operativo ospitante” e che “le contromisure adottate dal gestore del Punto di accesso telematico sono oggetto della valutazione d’impatto sulla protezione dei dati personali di cui alle” Linee guida sul PAT (par. 3.2.4).

A seguire, lo schema introduce “i servizi assicurati dal gestore del Punto di accesso telematico per permettere agli utenti finali di gestire, in caso di perdita del controllo del AppPAT o del dispositivo utilizzato per istanziare la AppPAT, gli accessi realizzati e le eventuali sessioni di autenticazione ancora attive”, che consistono in un “servizio di consultazione degli accessi eseguiti […] reso agli utenti finali all’interno di AppPAT” e nella “possibilità di dare seguito alla distruzione, in breve logout, delle sessioni di autenticazione generate” tramite AppPAT o, in caso di perdita del dispositivo, in modalità remota (par. 3.3).

Da ultimo, AgID ha altresì trasmesso un documento, redatto da PagoPA S.p.A. (in qualità di gestore del PAT), volto a spiegare le ragioni sottese alla “scelta di fissare a 270 giorni il tempo massimo (“time-to-live”) del Refresh Token previsto per le sessioni lunghe nel contesto della cosiddetta “Login Veloce”” (cfr. allegato alla nota del 7 giugno 2022).

1.2. Single sign-on con i servizi dei soggetti erogatori (cap. 4 dello schema)

Secondo quanto stabilito, il PAT “deve implementare e rendere disponibile ai Soggetti Erogatori un meccanismo di single sign-on che, nell’ambito delle sessioni di autenticazione generate dal Punto di accesso telematico nei modi [precedentemente] indicati […], permette di abilitare l’accesso dell’utente finale ai servizi resi dagli stessi Soggetti Erogatori per il tramite del Punto di accesso telematico. Il meccanismo di single sign-on realizzato dal Punto di accesso telematico deve prevedere la generazione di un token a partire dalla sessione di autenticazione dell’utente finale per trasportare l’identità dello stesso utente finale presso uno dei servizi di un Soggetto Erogatore”. Tale meccanismo di single sign-on deve essere abilitato “per i soli Soggetti Erogatori censiti nei modi indicati dalle [Linee guida sul PAT] che hanno indicato i servizi per cui richiedono l’utilizzo del meccanismo di single sign-on e i relativi attributi richiesti”, deve essere implementato dai Soggetti Erogatori “nel rispetto delle specifiche tecniche emanate dal gestore del Punto di accesso telematico” e “può essere utilizzato sia in contesti web che in contesti programmatici”.

A questo fine, il PAT “deve assicurare: la creazione di un token che trasporta l’identità dell’utente finale (ID Token), emesso per il singolo Soggetto Erogatore; la firma del token emesso per assicurare l'integrità, immodificabilità e certezza della fonte” (par. 4.1). Per quanto concerne i ruoli dei soggetti coinvolti, “il gestore del PAT e il Soggetto Erogatore trattano i dati personali in qualità di titolari autonomi” (par. 4.1.1). A seguire, lo schema descrive le interazioni previste (par. 4.1.2) e le regole concernenti la tracciatura delle medesime (par. 4.1.3, in analogia con quanto già stabilito al par. 3.1.3).

Con riferimento agli attributi dell’utente finale da inserire nell’ID Token, è stabilito che “il PAT Backend deve popolare l’ID Token con i soli claim relativi agli attributi all’utente finale richiesti dal Soggetto Erogatore nella Authentication Request limitatamente a i soli claim relativi agli attributi dell’utente finale indicati dall’IdP SPID al momento dell’autenticazione e agli altri attributi dichiarati dall’utente finale tramite PAT. I Soggetti Erogatori devono richiedere l’insieme minimo di claim relativi agli attributi dell’utente finale per ridurre il trattamento ai soli dati strettamente necessari per la fornitura dei servizi offerti, nel rispetto del principio di minimizzazione dei dati ai sensi dell’art. 5, par. 1, lett. c) del GDPR”. Relativamente alla tracciatura, le “Authentication Request e informazioni contenute nel payload dell’ID Token devono essere rese persistenti dal PAT Backend”, mentre le “Authentication Request e ID Token firmato da PAT Backend devono essere resi persistenti dai Soggetti Erogatori” (par. 4.1.4).

Anche per la gestione degli accessi ai servizi realizzati tramite single sign-on lo schema prevede un servizio di consultazione, in favore degli utenti finali, dell’elenco dei relativi accessi, disponibile per i tempi di conservazione della tracciatura delle interazioni già indicati (par. 4.2).

Infine, nell’ambito delle misure volte alla prevenzione e alla gestione di eventuali violazioni di dati personali, “ferme le disposizioni in materia di sicurezza e protezione dei dati personali di cui al Capitolo 7 delle Linee guida sul Punto di accesso telematico ai servizi della Pubblica Amministrazione”, lo schema introduce, tra gli altri, obblighi reciproci di informazione tempestiva tra gestore del PAT e Soggetti Erogatori “in caso di violazioni di sicurezza o di qualsiasi minaccia che comporti un rischio per la sicurezza e per i diritti e le libertà degli interessati e stabilendone le modalità all’interno della valutazione d’impatto sulla protezione dei dati personali”, nonché, per i soli Soggetti Erogatori, l’obbligo di effettuare “un’analisi del rischio e, qualora sussistano le condizioni di cui agli artt. 35 e 36 del GDPR, altresì la valutazione d’impatto sulla protezione dei dati personali e l’eventuale consultazione preventiva” (par. 4.3).

OSSERVA

2. Le garanzie contenute nello schema in esame

La versione dello schema di Regole tecniche in esame, trasmessa da ultimo il 7 giugno 2022 all’esito del confronto con l’Ufficio del Garante, tiene conto di gran parte delle indicazioni fornite nel corso di tale attività istruttoria, volte a individuare le opportune garanzie per rendere il trattamento dei dati personali conforme al Regolamento e al Codice. In particolare:

è stata prevista una forma di coordinamento fra l’AgID e il Ministero dell’interno, quale soggetto chiamato a realizzare e gestire l’identità digitale CieID, affinché anche in tale contesto siano adottate garanzie per l’utilizzo delle sessioni lunghe e del single sign-on mediante il PAT, nel rispetto dei principi di correttezza e di privacy by design e by default (cap. 1);

sono state precisati gli obblighi di tracciamento degli eventi relativi alla gestione delle sessioni di autenticazione, con specifico riferimento agli accessi realizzati tramite il c.d. “login veloce” nel rispetto del principio di integrità e riservatezza (parr. 3.1.3 e 3.2.3);

è stato specificato che il meccanismo di single sign-on con i servizi dei Soggetti Erogatori possa essere utilizzato sia in contesti web che in contesti programmatici, nel rispetto del principio di privacy by design e by default (cap. 4), e che il gestore del PAT e il Soggetto Erogatore trattano i dati personali in qualità di titolari autonomi, nel rispetto del principio di liceità, correttezza e trasparenza (par. 4.1.1);

sono state meglio definite le misure tecniche e organizzative volte a prevenire e gestire eventuali violazioni di dati personali, introducendo, tra le altre cose, obblighi di informazione tempestiva e reciproca tra il gestore del PAT e i Soggetti Erogatori, in caso di violazioni di sicurezza o di qualsiasi minaccia che comporti un rischio per la sicurezza e per i diritti e le libertà degli interessati, nel rispetto dei principi di integrità e riservatezza e di accountability (par. 4.3);

sono state irrobustite le misure di sicurezza, sia con riferimento alla gestione delle sessioni di autenticazione (parr. 3.1.4 e 3.2.4) – assicurando, tra le altre cose, che in ogni momento temporale per uno specifico utente finale sia abilitato un solo dispositivo per l’utilizzo dell’AppPAT – che con riferimento al meccanismo di single sign-on (par. 4.1.4), nel rispetto dei principi di integrità e riservatezza e di privacy by design e by default.

Ciò posto, lo schema di Regole tecniche in esame presenta taluni profili di criticità, di seguito illustrati.

3. La valutazione dei rischi

Come già rilevato nel citato parere sulle Linee guida sul PAT, i trattamenti effettuati nell’ambito del Punto di accesso presentano rischi elevati per i diritti e le libertà degli interessati in quanto effettuati su larga scala, con dati personali appartenenti anche a categorie particolari o relativi a condanne penali e reati, potenzialmente relativi all’intera popolazione italiana. L’introduzione di nuove modalità di gestione delle sessioni di autenticazione, anche di lunga durata, e dei meccanismi di single sign-on per l’accesso ai servizi erogati mediante il PAT deve essere quindi accompagnata da una rigorosa valutazione d’impatto sulla protezione dei dati personali, al fine di individuare misure, anche di dettaglio, adeguate a mitigare i predetti rischi.

L’Autorità si riserva, pertanto, di valutare il complesso delle garanzie adottate in relazione agli aspetti disciplinati dallo schema di Regole tecniche nell’ambito dell’esame della valutazione d’impatto a ciò dedicata che verrà predisposta dal gestore del PAT.

Al riguardo, si rappresenta inoltre che tali garanzie dovranno essere individuate anche a valle delle autonome valutazioni d’impatto che ciascun IdP SPID dovrà svolgere, anche in considerazione del fatto che lo schema in esame rimette a tali soggetti l’adozione di alcune impostazioni tecniche con importanti ricadute sulla sicurezza dei trattamenti di dati personali (ad esempio, la scelta di consentire o meno le sessioni di autenticazione di lunga durata e il periodo di validità degli Access Token e dei Refresh Token).

In tale contesto, si ritiene, inoltre, che sugli aspetti inerenti alla sicurezza sopra richiamati, in considerazione degli impatti sui trattamenti effettuati in ambito pubblico, debbano essere raccolte le opinioni dei soggetti a vario titolo coinvolti (cfr. art. 35, par. 9, del Regolamento).

4. La gestione delle sessioni di autenticazione

Come sopra osservato, l’utilizzo di sessioni di autenticazione di lunga durata (di seguito, anche, sessioni lunghe) e del predetto meccanismo di single sign on richiedono che i titolari adottino misure volte a ridurre i rischi per i diritti e le libertà degli interessati prima dell’avvio del trattamento e nel rispetto dei principi di accountability e di privacy by design e by default (artt. 5, par. 2, 24 e 25 del Regolamento).

Nel documento redatto da PagoPA, allegato alla nota trasmessa dall’AgID in data 7 giugno 2022, in relazione alla “scelta di fissare a 270 giorni il tempo massimo (“time-to-live”) del Refresh Token previsto per le sessioni lunghe nel contesto della cosiddetta “Login Veloce””, viene, tra le altre cose, rappresentato che “si è assunto, nell’attuazione del principio di responsabilità condivisa, il corretto comportamento dell’utente finale nell’uso degli strumenti resi disponibili per mitigare il rischio di un accesso non autorizzato causato da credenziali facilmente individuabili (PIN, Password, Pattern…) e/o la perdita del controllo del dispositivo utilizzato. Tali strumenti sono: il rafforzamento della credenziale stessa, applicabile tramite specifiche funzionalità del sistema operativo in uso; la possibilità di effettuare il cosiddetto “logout remoto” assicurato dal PAT Backend”.

Al riguardo, si osserva che, nel definire le misure tecniche e organizzative da adottare in ottemperanza a quanto disposto dagli artt. 24, 25, 32 e 35 del Regolamento, i titolari del trattamento devono tenere conto dei diversi scenari di rischio, al fine di gestirli in modo adeguato ed efficace attraverso un insieme di attività coordinate. Le predette valutazioni non possono, pertanto, fondarsi sulla presunzione di un “principio di responsabilità condivisa” e di un “corretto comportamento dell’utente finale nell’uso degli strumenti resi disponibili”, ma devono prendere in considerazione e analizzare – in termini di origine, natura, probabilità e gravità – le possibili minacce, ivi incluse quelle derivanti anche da comportamenti incauti o fraudolenti dell’utente finale oltre che di terzi, nonché le conseguenze pregiudizievoli nei confronti degli interessati, al fine ultimo di rispettare il Regolamento ed essere in grado di comprovarlo (art. 5, par. 2, del Regolamento).

Ciò, tanto più nel caso del PAT, che risponde al compito di interesse pubblico di veicolare servizi di varia natura nei confronti di un’ampia platea di interessati che comprende anche soggetti con ridotta capacità di comprensione dei pericoli derivanti da un utilizzo non appropriato delle particolari funzionalità che si intende offrire (ad esempio, i minori o coloro che hanno una scarsa dimestichezza con l’uso delle nuove tecnologie).

4.1. Lo schema in esame prevede che l’utente finale, in sede di autenticazione sull’AppPAT, possa esprimere la propria preferenza sull’utilizzo delle sessioni lunghe (con la conseguente generazione e archiviazione di chiavi crittografiche sul dispositivo dell’utente finale, cfr. par. 3.1.2 dello schema), senza, tuttavia, precisare con chiarezza quale sia la modalità predefinita attraverso la quale l’AppPAT prospetterà all’utente finale tale scelta in conformità all’art. 122 del Codice.

Al fine di assicurare un’adeguata consapevolezza dell’utente finale sul corretto utilizzo del PAT, è necessario renderlo edotto dei rischi connessi all’utilizzo di sessioni lunghe, nonché degli strumenti messi a sua disposizione per garantirgli il controllo sull’utilizzo dell’AppPAT (descritti nel par. 3.3 dello schema), soprattutto in caso di perdita del dispositivo su cui è installata (ad esempio, nei casi di furto o smarrimento).

Pertanto, occorre integrare lo schema delle Regole tecniche stabilendo espressamente che il ricorso a sessioni lunghe avvenga solo a seguito di una specifica informativa nei confronti dell’utente finale e di una sua manifestazione di volontà, libera, consapevole e revocabile, nel rispetto dei principi e degli obblighi di correttezza e trasparenza e di privacy by design e by default (artt. 5, par. 1, lett. a), 12, 13 e 25 del Regolamento, nonché art. 122 del Codice).

4.2. Le modalità di gestione delle sessioni di autenticazione stabilite nello schema in esame prevedono l’utilizzo di Access Token (con time-to-live pari al massimo a 12 ore) e Refresh Token (con time-to-live pari al massimo a 270 giorni), attraverso i quali il PAT Backend interagisce con gli IdP per verificare lo stato di validità della sessione di autenticazione e dell’identità digitale SPID ad essa associata. L’Access Token consente anche di acquisire, presso l’IdP che ha rilasciato l’identità digitale SPID all’utente finale, gli attributi a quest’ultimo riferiti (nel caso in esame, trattasi quantomeno di nome, cognome, data di nascita e codice fiscale). In presenza di una sessione lunga, con il Refresh Token diventa invece possibile ottenere nuovi Access Token e un nuovo Refresh Token con validità rinnovata, consentendo di fatto la realizzazione di sessioni di autenticazione senza un limite massimo di durata.

Considerato, dunque, che Access Token e Refresh Token consentono di acquisire i dati personali dell’utente finale a cui sono riferiti, la loro gestione presso il PAT Backend richiede l’adozione di rigorose misure tecniche e organizzative. Ciò, anche tenuto conto che un’eventuale compromissione del PAT Backend a seguito di incidenti di sicurezza informatica potrebbe comportare accessi non autorizzati ai sistemi degli IdP.

Inoltre, nella già richiamata nota redatta da PagoPA, viene evidenziato che “si ritiene che un tempo inferiore al time-to-live proposto [del Refresh Token] di 270 giorni -inteso in ogni caso come tempo massimo della sessione di Login Veloce- vanificherebbe le esigenze di usabilità predette e frustrerebbe l’esperienza utente, costringendo gli utenti finali del punto di accesso telematico ad effettuare una nuova autenticazione con eccessiva frequenza, determinando l’abbandono della base utenti da quello che dovrebbe essere il punto privilegiato di accesso ai servizi in rete”. In base a quanto rappresentato, risulterebbe poi che, con un time-to-live del Refresh Token pari a 270 giorni, a circa l’88% degli utenti finali non sarebbe richiesto di effettuare una nuova autenticazione tramite il proprio IdP, riducendo in tal modo la percentuale di utenti che, a fronte di tale richiesta, desistono dal continuare a utilizzare l’AppPAT.

A tal riguardo, si osserva che 270 giorni rappresentano un periodo temporale molto prolungato di cui occorre valutare attentamente la compatibilità con gli obblighi di sicurezza che i titolari del trattamento sono tenuti ad adottare ai sensi dell’art. 32 del Regolamento. Infatti, come sopra rappresentato, l’individuazione dei periodi temporali di validità dei predetti token deve avvenire solo a seguito di un’adeguata valutazione dei rischi elevati connessi al complesso dei trattamenti che vengono posti in essere dal gestore del PAT, dagli IdP e, in caso di utilizzo del meccanismi di single sign-on, dai Soggetti erogatori, nel rispetto dei principi e degli obblighi di limitazione della conservazione, di integrità e riservatezza e di privacy by design e by default (artt. 5, par. 1, lett. e) e f), 24, 25 e 32 del Regolamento). I periodi temporali in questione devono, infatti, essere definiti tenendo in adeguata considerazione, oltre che le prospettate esigenze di maggior usabilità dell’AppPAT da parte dell’utente finale, anche le imprescindibili necessità e aspettative di sicurezza rispetto a rischi, che le citate modalità di gestione delle sessioni incrementano, di accesso non autorizzato ai dati personali e, più in generale, di compromissione dell’integrità, della disponibilità e della resilienza dei sistemi e dei servizi di trattamento.

Pertanto, è necessario che le valutazioni d’impatto sulla protezione dei dati che il gestore del PAT e gli IdP svolgeranno tengano in debito conto i rischi per i diritti e le libertà fondamentali degli interessati, connessi alle scelte concernenti la durata temporale dell’Access Token e del Refresh Token e all’assenza di un limite alla validità temporale della sessione di autenticazione (di fatto prolungabile all’infinito), e individuino misure adeguate a mitigarli (come indicato nel par. 3 del presente provvedimento).

Appare inoltre contraddittorio il prospettato disagio che deriverebbe da una minore estensione della validità del Refresh Token rispetto al termine prefissato di 270 giorni: tale termine oltremodo esteso sarebbe funzionale a impedire “una nuova autenticazione con eccessiva frequenza” in contesti di utilizzo del tutto sporadico del PAT, in cui l’aggravio rispetto all’usabilità consisterebbe nella necessità di effettuare una nuova autenticazione SPID a intervalli comunque di diversi mesi dalla precedente autenticazione, rendendo incomprensibile, quindi, come questa misura possa incidere sulla user experience al punto da disincentivare l’uso del PAT.

In relazione a tale specifico aspetto, si ritiene pertanto necessario acquisire, anche dagli IdP SPID, le valutazioni effettuate, con la specificazione delle misure individuate per gestire i predetti rischi al fine di consentire all’Autorità di valutarne compiutamente l’adeguatezza e la conformità alla disciplina in materia di protezione dei dati personali.

4.3. Lo schema in esame prevede che, ai fini dell’identificazione dell’utente finale, qualora il suo dispositivo non disponga di funzionalità di riconoscimento biometrico, l’AppPAT possa utilizzare altri meccanismi di sblocco (ad esempio, PIN, password o pattern) gestiti direttamente dalla stessa, ovvero possa avvalersi di quelli configurati nel sistema operativo del dispositivo medesimo.

Tuttavia, non viene previsto che il gestore del PAT debba individuare e utilizzare esclusivamente meccanismi di sblocco dotati di caratteristiche di sicurezza che assicurino un’adeguata protezione contro accessi non autorizzati all’AppPAT – ad esempio, con riferimento al PIN, impedendo l’uso di codici non sufficientemente lunghi e di quelli contenenti le combinazioni più comuni (quali quelle con più di tre volte lo stesso numero, con più di tre numeri in sequenza o contenenti la data di nascita dell’utente finale) – nel rispetto dei principi e degli obblighi di integrità e riservatezza e di privacy by design e by default (artt. 5, par. 1, lett. f), 25 e 32 del Regolamento).

Pertanto, occorre prevedere che i meccanismi di sblocco, alternativi al riconoscimento biometrico, siano dotati di caratteristiche di sicurezza che assicurino un’adeguata protezione contro accessi non autorizzati all’AppPAT. In ogni caso, l’Autorità si riserva di verificare l’adeguatezza dei meccanismi di sblocco individuati dal gestore del PAT, nell’ambito dell’esame della relativa valutazione d’impatto sulla protezione dei dati.

5. Single sign-on con i servizi dei Soggetti Erogatori

Il meccanismo di single sign-on, come disciplinato dallo schema delle Regole tecniche, comporta che, in caso di fruizione di uno specifico servizio messo in tal modo a disposizione da un Soggetto Erogatore, le informazioni sulla identità digitale dell’utente finale gli siano direttamente comunicate senza che sia necessario il superamento di una procedura di autenticazione informatica. Il ruolo assunto dal gestore del PAT in tale contesto risulta quindi analogo a quello degli IdP, che attestano l’identità digitale di un utente finale a un fornitore di servizi a seguito di un’autenticazione SPID o CIE.

Come evidenziato nel par. 3 del presente provvedimento, tale meccanismo presenta rischi derivanti da possibili accessi non autorizzati ai dati personali degli utenti finali e occorre, pertanto, che lo schema in esame fornisca adeguate istruzioni ai Soggetti Erogatori affinché, prima di consentire l’accesso a un servizio online anche con tale modalità, effettuino una valutazione dei rischi tenendo conto delle specifiche caratteristiche dello stesso.

5.1. Lo schema in esame prevede che, in caso di ricorso al meccanismo di single sign-on, il PAT Backend inserisca all’interno dell’ID Token le informazioni relative agli attributi all’utente finale specificamente richiesti dal Soggetto Erogatore, nel rispetto del principio di minimizzazione dei dati. Tali attributi vengono acquisiti dal gestore del PAT all’atto dell’autenticazione dell’utente finale presso l’IdP, oppure raccolti direttamente dal medesimo utente finale tramite PAT.
Per quanto riguarda gli attributi da ultimo citati (ossia quelli raccolti direttamente dall’utente finale tramite PAT), al fine di assicurare all’utente finale – in analogia a quanto previsto dalla normativa che disciplina lo SPID – la piena consapevolezza e il controllo sul loro utilizzo, occorre che, nel rispetto dei principi di liceità, correttezza e trasparenza, di esattezza e di privacy by design e by default (artt. 5, par. 1, lett. a) e d), e 25 del Regolamento):

l’AppPAT consenta l’accesso a un servizio con il meccanismo del single sign on solo dopo che l’utente sia stato informato e abbia preso atto dell’elenco degli attributi che verranno trasmessi al Soggetto Erogatore;

siano introdotte misure che consentano all’utente finale di indicare le informazioni che può rendere disponibili ai Soggetti Erogatori e di tenerle costantemente aggiornate;

i Soggetti Erogatori debbano adottare misure per la corretta gestione dei casi di disallineamento tra le informazioni in loro possesso e quelle trasmesse dal gestore del PAT.

5.2. Il meccanismo del single sign on, come disciplinato dallo schema in esame, consente l’accesso ai servizi in rete offerti dalle pubbliche amministrazioni con modalità ulteriori rispetto a quelle attualmente previste ai sensi dell’art. 64 del CAD e della relativa regolamentazione attuativa.

Al riguardo, si osserva che, a fronte del ruolo assunto dal gestore del PAT in tale contesto, al fine di assicurare garanzie analoghe a quelle previste dalla normativa che disciplina lo SPID (cfr. artt. 30 e 30-bis del “Regolamento recante le modalità attuative per la realizzazione dello SPID”), occorre integrare lo schema delle Regole tecniche introducendo specifiche modalità di monitoraggio sul funzionamento del meccanismo di single sing-on e sugli eventuali disservizi, nonché specifici obblighi di notifica al Garante delle violazioni di dati personali occorse in tale contesto (ulteriori rispetto a quelli già stabiliti dall’art. 33 del Regolamento). Ciò, non solo a tutela degli interessati ma anche a vantaggio dei Soggetti Erogatori.

6. Ulteriori aspetti

Lo schema delle Regole tecniche prevede che il PAT Backend assicuri la tracciatura di una serie di eventi relativi alla gestione delle sessioni di autenticazione e all’utilizzo del meccanismo di single sign-on, demandando l’individuazione dei tempi di conservazione al gestore del PAT in coerenza con le Linee guida sul PAT e nel rispetto di quanto previsto dal par. 4.1 (“Tracciature identity provider”) del “Regolamento recante le regole tecniche” dello SPID.

Anzitutto si osserva che, con riferimento alla gestione delle sessioni di autenticazione, il gestore del PAT agisce in qualità di SP, con riguardo al quale l’art. 13, comma 2, del d.P.C.M. 24 ottobre 2014 stabilisce i periodi di conservazione delle informazioni oggetto di tracciatura (pari a ventiquattro mesi), non lasciando quindi spazio a una scelta da parte del gestore del PAT al riguardo.

A ciò si aggiunga che l’art. 29, comma 4, del “Regolamento recante le modalità attuative per la realizzazione dello SPID”, prevede un obbligo specifico nel momento in cui un medesimo soggetto sia al contempo IdP e SP (come il gestore del PAT, nel caso in esame), stabilendo che, “nel caso in cui uno stesso soggetto sia, allo stesso tempo, gestore dell’identità digitale e fornitore di servizi devono essere mantenuti separati i registri di tracciatura delle transazioni così come le banche dati relative alla gestione delle identità digitali. Tale vincolo di separazione deve essere applicato anche nei confronti degli accessi degli operatori di help desk e nella gestione di cruscotti di self-caring”.

Pertanto, premessa la necessità di correggere il richiamo alla regola concernente gli obblighi di conservazione delle tracciature riferite alla gestione delle sessioni di autenticazione allorché il gestore del PAT agisce in qualità di SP, occorre integrare lo schema delle Regole tecniche prevedendo che i tempi di conservazione dei registri di tracciatura degli eventi debbano essere predeterminati e non soggetti a scelta discrezionale da parte del gestore del PAT e che il medesimo gestore mantenga separati i registri di tracciatura degli eventi tenuti in qualità di IdP da quelli tenuti in qualità di SP.

RITENUTO

Lo schema di Regole tecniche in esame disciplina i trattamenti effettuati nell’ambito del punto di accesso telematico di cui all’art. 64-bis del CAD, per la gestione delle sessioni di autenticazione, anche di lunga durata, e per l’accesso con meccanismi di single sign-on ai servizi ivi messi a disposizione dai Soggetti Erogatori, necessari per l’esecuzione di un compito di interesse pubblico, nel rispetto di quanto previsto dall’art. 6, parr. 1, lett. e), e 3, del Regolamento, nonché dall’art. 2-ter del Codice.

Al riguardo, benché il predetto schema tiene conto delle indicazioni fornite dall’Ufficio nel corso dell’istruttoria nei termini sopra descritti, si ritiene necessario, in ogni caso, formulare le condizioni e le osservazioni rappresentate nei paragrafi nn. 3, 4, 5 e 6, al fine di meglio bilanciare l’esigenza di assicurare una maggiore usabilità dell’AppPAT con gli obblighi di sicurezza volti a mitigare i rischi che le citate modalità di gestione delle sessioni e i meccanismi di single sign-on introducono nel trattamento. Ciò, allo scopo di assicurare la piena conformità ai principi stabiliti in materia di protezione dei dati personali dal Regolamento e dal Codice.

L’analisi delle ulteriori misure che verranno adottate dal gestore del PAT e dagli IdP sarà effettuata in seguito, nell’ambito dell’esame della valutazione di impatto sulla protezione dei dati, che sarà trasmessa da PagoPA al Garante, nonché degli elementi che saranno forniti dagli IdP in ordine alle impostazioni adottate in relazione alla validità temporale degli Access Token e dei Refresh Token.

TUTTO CIÒ PREMESSO, IL GARANTE

1) ai sensi degli artt. 36, par. 4, e 58, par. 3, lett. b), del Regolamento, per le ragioni di cui in motivazione, non può esprimere parere favorevole sullo schema delle “Regole tecniche per la gestione delle sessioni di autenticazione e single sign-on” nell’ambito del Punto di accesso telematico di cui all’art. 64-bis del d.lgs. 7 marzo 2005, n. 82, in assenza dell’osservanza delle seguenti condizioni:

a) siano raccolte le opinioni dei soggetti a vario titolo coinvolti nei trattamenti in merito alle misure di sicurezza adottate dal gestore del PAT e dagli IdP nell’ambito della gestione delle sessioni di autenticazione, anche di lunga durata, e dei meccanismi di single sign-on per l’accesso ai servizi erogati mediante il PAT (par. 3);

b) il ricorso a sessioni lunghe avvenga solo a seguito di una specifica informativa nei confronti dell’utente finale e di una sua manifestazione di volontà, libera, consapevole e revocabile (par. 4.1);

c) i meccanismi di sblocco dell’AppPAT, alternativi al riconoscimento biometrico, siano dotati di caratteristiche di sicurezza che assicurino un’adeguata protezione contro accessi non autorizzati (par. 4.3);

d) sia previsto che i Soggetti Erogatori, prima di consentire l’accesso a un servizio online anche con il meccanismo di single sign-on, effettuino una valutazione dei rischi tenendo conto delle specifiche caratteristiche dello stesso (par. 5);

e) l’AppPAT consenta l’accesso a un servizio con il meccanismo del single sign-on solo dopo che l’utente sia stato informato e abbia preso atto dell’elenco degli attributi che verranno trasmessi al Soggetto Erogatore (par. 5.1);

f) siano adottate misure che consentano all’utente finale di indicare le informazioni che può rendere disponibili ai Soggetti Erogatori e di tenerle costantemente aggiornate (par. 5.1);

g) i Soggetti Erogatori adottino misure per la corretta gestione dei casi di disallineamento tra le informazioni in loro possesso e quelle trasmesse dal gestore del PAT in caso di accesso con il meccanismo di single sign-on (par. 5.1);

h) siano introdotte specifiche modalità di monitoraggio sul funzionamento del meccanismo di single sing-on e sugli eventuali disservizi, nonché specifici obblighi di notifica al Garante delle violazioni di dati personali occorse in tale contesto (par. 5.2);

i) sia previsto che il gestore del PAT mantenga separati i registri di tracciatura degli eventi tenuti in qualità di IdP da quelli tenuti in qualità di SP (par. 6);
e delle seguenti osservazioni:

j) le valutazioni dei rischi svolte dal gestore del PAT e dagli IdP, in relazione alle nuove modalità di gestione delle sessioni di autenticazione, anche di lunga durata, e dei meccanismi di single sign-on per l’accesso ai servizi erogati mediante il PAT, prendano in considerazione e analizzino le possibili minacce, ivi incluse quelle derivanti da comportamenti incauti o fraudolenti dell’utente finale oltre che di terzi (par. 4);

k) i tempi di conservazione dei registri di tracciatura degli eventi connessi alla gestione delle sessioni di autenticazione tenuti dal gestore del PAT siano analoghi a quelli previsti dall’art. 13, comma 2, del d.P.C.M. 24 ottobre 2014;

2) ai sensi dell’art. 157 del Codice, richiede agli IdP SPID accreditati di fornire, entro il termine di trenta giorni dalla data della notifica del presente provvedimento, informazioni circa le valutazioni effettuate e le misure adottate in relazione alla durata temporale dell’Access Token e del Refresh Token e all’assenza di un limite alla validità temporale della sessione di autenticazione (par. 4.2); l’eventuale mancato riscontro può comportare l’applicazione della sanzione amministrativa pecuniaria prevista dall’art. 83, par. 5, lett. e), del Regolamento.

Roma, 21 luglio 2022

IL PRESIDENTE
Stanzione

IL RELATORE
Stanzione

IL SEGRETARIO GENERALE
Mattei