Il riconoscimento dell’identità digitale non è un tema puramente tecnologico ma ha rilevanti riflessi sociali, sia sulle transazioni economiche che sulla vita delle persone. È vero che per effettuare un pagamento non è necessaria l’identificazione della persona fisica, ma lo è per fare valere dei diritti in caso di controversie, come nel caso di truffe legate ad attività svolta nel mondo digitale. Gli attuali sistemi di identificazione digitale garantiscono una elevata qualità nell’autenticare l’accesso ad un sistema informatico ma non hanno la capacità di attribuire in modo semplice all’identità digitale quella reale.
La tematica del riconoscimento dell’identità digitale non è un fatto puramente tecnologico ma necessita di un approccio olistico che consideri anche il mondo reale. Richiede la disponibilità di una soluzione che garantisca una gestione pratica e sicura delle identità nel mondo digitale ed allo stesso tempo sappia fornire un legame dimostrabile con il corretto proprietario nel mondo reale, se necessario. La trasparenza delle regole di gestione e la semplicità d’uso nel trattamento dell’identità sono le caratteristiche principali per agevolare la diffusione di una soluzione.
La qualità dei sistemi di riconoscimento dell’identità nell’ambiente digitale soddisfa esaurientemente i requisiti tecnologici di sicurezza ed anche la praticità d’uso. La gestione dell’identità reale è un processo organizzativo fortemente strutturato, oramai consolidato nella pratica di ogni Paese. È frutto di lunghi e complessi accordi internazionali per poter agire fuori dai confini nazionali, ma sempre fortemente dipendente dalle leggi di ogni singolo Paese per definire regole di rilascio, uso e validità nel proprio territorio. Il mondo digitale non ha confini ben definiti in quanto l’accesso ad Internet è generalmente aperto a tutti, ma l’identità digitale ha validità solo dentro l’ecosistema digitale di appartenenza. Come sua proprietà, tutte le identità nello spazio dei nomi specificato sono uniche.
I metodi di gestione della relazione di corrispondenza tra le due tipologie di identità non sono ancora sufficientemente maturi per garantire la fiducia nella capacità di dimostrare questo legame in sicurezza, con semplicità ma anche in modo aperto e trasparente. Qualunque soluzione di rendere omogenei i processi di gestione delle identità dei mondi reale e digitale, conservando le garanzie di sicurezza, facilità d’uso e indipendenza delle autorità territoriali, rende troppo complessa, e quindi irrealistica, ogni possibile richiesta di cambiamento della gestione dell’identità reale per rafforzare l’equivalente nel mondo digitale.
L’unica strada percorribile è introdurre un nuovo elemento di soluzione sul lato digitale che possa essere sfruttato per rafforzare la condivisione di informazioni tra le attuali tecnologie di gestione dell’identità digitale ed i processi organizzativi dell’identità reale. Per trovare il punto dove agire, è utile ripercorrere i tipici meccanismi di autenticazione secondo una prospettiva organizzativa anziché tecnologica.
Tipici sistemi di autenticazione
Il sistema più semplice (ma anche il più vecchio) è il modello concettuale del mainframe (figura 1) ossia un server centrale in modalità stand-alone che gestisce tutti i servizi dei client senza far affidamento a funzionalità di altri server. In questo schema all inclusive, tutto viene gestito internamente al sistema, dalle risorse, agli utenti e tutti i relativi controlli. Per l’utente significa avere nello stesso ambiente, registrazione dell’identità, autenticazione per l’accesso, autorizzazione sui dati e log delle attività. La struttura è molto solida per la sicurezza ma l’ambiente così chiuso e rigido penalizza l’interoperabilità in un ecosistema digitale più ampio e dinamico.
Il server gestisce tutto, profili utente, processo di autorizzazione e risorse. Il resource owner o user è l’entità che richiede al processo di autorizzazione di accedere alle proprie risorse. Tutti gli utenti sono definiti in un elenco (ACL) che stabilisce per ciascun utente le operazioni consentite su determinate risorse. L’accesso alle risorse è consentito solo tramite form applicativi che filtrano i dati delle varie operazioni utente.
Più flessibile è il sistema di autenticazione interno ad un’organizzazione con più server che dialogano per erogare dei servizi. È basato su un proprio dominio di rete definito da un authentication server dedicato a fornire il servizio di autenticazione a tutte le entità del dominio (figura 2). Il meccanismo di accesso ai servizi è asimmetrico perché solo il client deve essere riconosciuto ma non il server che fornisce i servizi, perché in quanto server è sempre connesso al dominio. Benché sia possibile creare delle relazioni di fiducia tra domini per ottenere un’ambiente di rete più esteso, il sistema di autenticazione è posseduto dall’organizzazione stessa che eroga i servizi e che gestisce direttamente gli utenti registrati nel dominio.
Un server gestisce i profili utente ed il processo di autorizzazione ed un altro le risorse, entrambi sono nello stesso dominio. Il resource owner ha un’applicazione (user-agent) che gestisce la richiesta di accesso ad una risorsa online conservata dal resource server. La richiesta viene filtrata dall’applicazione (o web site) relying party che richiede l’autenticazione all’authorization server. Il processo di autenticazione è a senso unico perché riguarda solo il resource owner e non il relying party, già noto all’authentication server in quanto parte del dominio.
Come estensione del concetto di dominio di rete aziendale abbiamo l’ecosistema digitale (figura 3) che considera tutte le funzionalità presenti secondo il concetto di servizi interoperabili tra loro a prescindere dal fatto che siano o meno di una stessa organizzazione. Lo stesso sistema di autenticazione è un servizio erogato da una terza parte rispetto alle entità utente o fornitore, e rappresenta il baricentro su cui si fonda l’ecosistema digitale. Rispetto agli schemi di autenticazione precedenti è pensato per essere aperto e gestire servizi di organizzazioni differenti per utenti che mantengono le stesse credenziali all’interno dell’intero ecosistema. Il gestore del server di autenticazione è detto fornitore di identità (IdP) e, come già citato, è indipendente dai fornitori di servizio. Per gestire le credenziali di accesso richiede la registrazione di tutte le entità dell’ecosistema, siano esse utenti che fornitori di servizio.
Un server di terza parte gestisce i profili delle entità ed il processo di autorizzazione definendo l'ecosistema ed un altro le risorse. Il resource owner richiede di accedere ad una risorsa che non fa parte della sua organizzazione, inoltre, l’authorization server è gestito da una terza parte che non gestisce le risorse. L’owner del resource server è il service provider (SP), mentre l’authorization server è dell’identity provider. Sia il resource owner che il service provider devono preventivamente essere registrati dall’identity provider. Anche in questa rappresentazione è il resource owner che dove farsi riconoscere dal relying party e mai succede il viceversa che il fornitore del servizio si autentichi sull’utente.
Un ecosistema digitale copre molte delle necessità del riconoscimento dell’identità ma rimangono due temi non opportunamente risolti, l’estensione del dominio di autenticazione ed il legame tra digitale e reale. Il fornitore di identità può federare il proprio dominio con altri fornitori di identità per creare un ecosistema più ampio ma l’estensione di Internet è tale che non potrà mai essere incluso in un unico ecosistema, anche se vengono federati innumerevoli domini. Conseguentemente, un utente deve possedere almeno tante credenziali quanti sono gli ecosistemi di cui ha una qualche necessità di accesso. Il secondo tema riguarda gli attuali protocolli di autenticazione che non sono pensati per il legame tra mondo digitale e reale ma prevalentemente per l’efficacia dell’autenticazione nel mondo digitale. Invece, deve essere rivisto l’approccio usato considerando anche l’eventualità di dover fornire garanzie sull’identità reale del proprietario dell’utenza digitale.
Evoluzione del protocollo di autenticazione
I principali modelli di gestione dell’identità federata sono Security Assertion Markup Language 2.01 (SAML2) che deriva dal paradigma di client-server con messaggi basati su XML e OpenID Connect (OIDC)2, che essendo più recente, preferisce uno scambio messaggi standardizzati basati sui protocolli JSON e HTTP. Entrambi gli standard utilizzano, o sono idonei ad utilizzare, il framework di autenticazione OAuth 2.03, e per questo è attualmente il protocollo di autenticazione più diffuso nella costituzione di un ecosistema digitale. OAuth 2.0 fornisce un meccanismo di autenticazione aperto, semplice e sicuro (figura 4).
Questo schema di autenticazione prevede che un utente richieda al suo user agent l’accesso ad una risorsa sulla quale detiene i diritti. Lo user agent è l’applicazione che riceve la richiesta di accesso e gestisce tutte le fasi di ottenimento della risorsa digitale. Come passo iniziale chiede all’utente le credenziali di autenticazione, poi verifica con l’authorization server se le credenziali sono valide ed infine, con il token di accesso richiede e riceve la risorsa desiderata. OAuth 2.0 fornisce un meccanismo di autenticazione aperto, semplice e sicuro.
Nonostante queste proprietà positive esiste però un limite intrinseco all’ecosistema digitale che viene a crearsi con questo sistema di autenticazione. Il protocollo di autenticazione è pensato per autenticare solo utenti registrati nel dominio (primario o federato) che contiene le risorse. Per poter allargare la base degli utenti è necessario federare ulteriori domini o richiedere una nuova registrazione per gli utenti che accedono alle risorse su altri domini non inclusi nel perimetro di autenticazione. Da notare inoltre che il meccanismo di autenticazione è asimmetrico. Questo significa che è sempre il client a dover farsi riconoscere dal service provider e non il viceversa, ossia non è un mutuo riconoscimento tra l'entità richiedente servizio e quella fornitrice. Paradossalmente è come se dessimo i nostri documenti di identità ad un soggetto che indossa una divisa senza preoccuparci se (la persona con l’uniforme) ha l’autorità per richiederli oppure è un truffatore.
Un protocollo di autenticazione simmetrico4 può superare questo inconveniente. La simmetria deriva dal principio che entrambe le entità devono farsi riconoscere, in modo speculare (figura 5). La simmetria nel ciclo di riconoscimento rafforza anche la sicurezza perché prevede una doppia verifica su percorsi separati ostacolando attacchi del tipo man-in-the-middle (MitM5).
Ogni entità ha un server di terza-parte che gestisce il profilo ed il processo di autorizzazione definendo l'ecosistema che può includere il server delle risorse. Il resource owner richiede di accedere ad una risorsa che non fa parte del suo dominio ed il service provider sarà sicuro che l’identità è reale per mezzo dello scambio di messaggi tra i rispettivi identity provider6. Il meccanismo si basa sullo scambio di token di autenticazione su due vie, tra le entità e tra gli IdP, ma senza la federazione dei domini. La verifica sui token richiede di attribuire fiducia sulle operazioni svolte dagli identity provider, ma la fiducia deve essere meritata.
Questo meccanismo non richiede che l’utente ed il service provider siano nello stesso dominio. La verifica di autenticità dell’identità è fatta per ciascuna entità dal proprio identity provider, che scambia i messaggi di verifica del riconoscimento con l’altro IdP. Pertanto, la federazione di domini diventa inutile ma sono richieste regole rigorose per garantire la fiducia nella correttezza delle operazioni degli IdP e nell’integrità dello scambio messaggi. L’attuale protocollo di autenticazione non deve essere sostituito ma solo adattato con l’aggiunta del caso d’uso dell’autenticazione simmetrica fuori dominio.
Il protocollo simmetrico può essere un’estensione del protocollo OAuth, che senza sostituire alcuna funzionalità, dovrebbe includere un meccanismo per consentire lo scambio incrociato di messaggi fuori dominio al fine di interrogare gli IdP sulla validità dell’altra identità o confermare la propria. Il fulcro del meccanismo di gestione dei token è sempre l’identity provider, che per l’importanza del ruolo svolto deve essere indipendente sia dalle entità richiedenti servizi che da quelle che erogano servizi7, ed ovviamente, indipendenza ed affidabilità devono essere dimostrabili. Questo presuppone un codice di condotta comune tra tutti gli IdP ed un processo di verifica formale in carico ad enti di certificazione internazionali per garantire la correttezza di funzionamento e la robustezza della rete degli IdP. La verifica dovrebbe richiedere uno Statement of Applicability8 specifico e definito in modo prescrittivo dall’autorità di controllo degli IdP.
Evoluzione dell’Identity provider
L’identity provider, nel fornire il servizio di registrazione e riconoscimento delle identità digitali, deve anche garantire un elevato grado di tutela delle informazioni delle proprie entità. Questo significa escludere a priori qualsiasi ulteriore trattamento sulle informazioni delle entità registrate eccedente le necessità del servizio erogato per non compromettere la fiducia accordata dalle entità. Ad esempio, evitare profilazione dei comportamenti o forme di marketing nelle transazioni. Allo stesso tempo, per essere un’attività sostenibile va comunque riconosciuto un equilibrato costo di registrazione ed un abbonamento per l’attività di riconoscimento. Il modello di business deve essere orientato esclusivamente all’autenticazione dei token, perché ogni attività collaterale che non sia il rafforzamento della sicurezza va a minare la fiducia su questo business.
Le identità digitali risultanti consentono solo a chi ha l’autorità di procedere con l’identificazione reale e permettono agli utenti di ricevere una tutela per i propri diritti, rendendo così più affidabili le transazioni economiche.La trasparenza nelle operazioni è fondamentale per la credibilità del sistema nella sua globalità. Per questo, al fine di ottenere un efficace legame tra identità digitale e reale, ma anche come tutela dei dati delle persone fisiche, è necessario suddividere l’insieme degli identity provider in due categorie, i custodian che gestiscono il legame tra identità digitale e reale, ed i trustee che gestiscono l’identità nelle transazioni private o commerciali9. Di seguito le principali differenze tra le due tipologie di IdP.
- Custodian è governato dalla stessa autorità che gestisce l’identità reale ed assegna un’identità digitale con pieno valore legale. Il ruolo prevalente è la custodia, la verifica e l’aggiornamento dei dati della persona naturale, oltre a gestire i legami con le identità digitali emesse dai trustee. Ad esempio, certifica l’attendibilità delle richieste di emissione di identità digitali dell’individuo ai trustee tramite un processo interamente online.
- Trustee è un’entità legale che gestisce solo l’identità digitale nelle transazioni commerciali online. Non ha necessità di conoscere i dati della persona naturale in quanto garantiti dal custodian e con poche formalità online consente l’emissione, la rinomina o la cancellazione delle identità digitali usate su Internet.
Avere il servizio di autenticazione in carico ad una terza parte presenta aspetti non trascurabili in termini di prestazioni del servizio, resilienza del sistema e minori costi rispetto ad un processo in house. Un IdP tratta l’autenticazione come core business che significa garanzia dì una elevata qualità del servizio sempre allineata allo stato corrente della tecnologia. Inoltre, nella gestione della business continuity dell’IdP, il parametro di Recovery Point Objective (RPO10) è poco significativo perché l’integrità della transazione di verifica dei messaggi di autenticazione richiede che, o si completa tutto il ciclo o non è valida. Un ciclo di autenticazione fallito deve essere ripetuto e non ripristinato per evitare vulnerabilità.
Non ultimo, richiedere il servizio di un IdP significa avere dei vantaggi organizzativi concreti:
- evitare la necessità di mantenere una struttura interna fissa con adeguamenti delle competenze nel tempo
- avere tempi certi nell’erogazione delle soluzioni derivanti dalle esigenze di cambiamento
- legare il cambiamento a costi variabili, per il tempo necessario e non all’implementazione di progetti interni
- trasferire i rischi operativi ad una terza parte
Similitudini tra mondo digitale e reale
L’identità reale quando supera i confini del proprio paese richiede il passaporto come mezzo di riconoscimento. Questo documento, basandosi su regole internazionali, sia organizzative che tecniche, consente di avere fiducia nelle informazioni che contiene. Similmente, le identità che provengono dall’esterno dell’ecosistema digitale, richiedono un meccanismo formale per garantire l’integrità e plausibilità delle informazioni di riconoscimento. Il sistema che svolge questa funzione è la rete degli identity provider che deve essere basata su un monitoraggio continuativo di conformità e periodiche visite di audit. La trasparenza delle regole di governo della rete degli IdP serve a favorire la fiducia complessiva nel sistema.
Applicare regole formali sulla gestione delle identità e sugli identity provider non è una limitazione della libertà su Internet, anzi è un aiuto per un uso consapevole della tecnologia. Le identità digitali risultanti consentono solo a chi ha l’autorità di procedere con l’identificazione reale e permettono agli utenti di ricevere una tutela per i propri diritti, rendendo così più affidabili le transazioni economiche. Queste identità digitali, anche reali (DIER) portano una dicotomia in Internet. Utilizzandole abbiamo una zona legale ove ci sono delle tutele come nella vita reale, rispetto alla zona complementare (normali utenze) che consente totale anonimato ma rischi significativi, come nella realtà agendo senza tutele legali. Quale tipo di identità utilizzare è una libera scelta.
Conclusioni
Il tema della gestione del riconoscimento dell’identità digitale ed il suo legame con quella reale va affrontato in modo olistico, sia nella prospettiva tecnologica che civile. Per il mondo digitale è necessario un protocollo di autenticazione che sappia superare il limite della federazione dei domini per essere attuabile, per esempio l’uso dell’autenticazione simmetrica, mentre per il mondo reale è richiesta una affidabile organizzazione che dia fiducia alle entità che gestiscono le identità, per esempio gli IdP che devono innanzitutto soddisfare le leggi locali oltre ai requisiti della tecnologia. L’uso di un protocollo di autenticazione basato sull’autenticazione dei messaggi anziché la federazione di domini, ha le giuste caratteristiche per creare la base tecnologica del sistema di riconoscimento dell’identità digitale.
In sintesi, le attuali modalità di gestione dell’identità reale non devono cambiare. Anche il modo di utilizzare la propria identità digitale sui siti Internet non deve cambiare poiché la modifica del protocollo è trasparente all’utente. In aggiunta, la modifica del protocollo migliora il trattamento dei dati personali, poiché riduce lo scambio di informazioni necessarie per la registrazione dell'identità. Il modello di business dell’identity provider deve essere basato su regole di indipendenza dai fornitori di servizi e di tutela della riservatezza dei dati di identità, per vedere riconosciuta dal mercato la fiducia nel servizio offerto e migliorare la diffusione a livello globale. Un’opportuna autority internazionale, a garanzia del lecito funzionamento degli IdPs, deve avere la capacità di decidere sul comportamento e disabilitazione degli IdP tramite un sistema di regole e verifiche. È una condizione necessaria per guadagnare la fiducia degli utenti e garantire la capacità di realizzare il tracciamento legale delle utenze.
Gli attuali identity provider sono legati alla necessità di agevolare la fruizione di un pool di servizi con un unico ID (single sign-on). È una visione limitata che non va oltre il singolo ecosistema digitale e rende il ruolo dell’identity provider non maturo per essere un business ben riconosciuto dal mercato. Gli ambiti dove migliorare il processo di gestione del riconoscimento dell’identità sono, l’identità digitale legata all’identità reale, il meccanismo di autenticazione indipendente dall’ecosistema di appartenenza e la tutela dei diritti della persona. Il successo dell’intero processo si basa su due aspettative, deve essere semplice ed affidabile.
Riferimenti
1 OAuth, “OAuth 2.0”
2 OpenID, “What Is OpenID Connect”
3 OAuth, “OAuth 2.0”
4 Sbriz, L.; “A Symmetrical Framework for the Exchange of Identity Credentials Based on the Trust Paradigm, Part 1 & 2,” ISACA® Journal, vol. 2, 2022
5 ISACA®, “Man-in-the-Middle Attack (MitM)”
6 Internet Engineering Task Force, “Internet-Draft - Identity Trust System,” November 2024
7 Sbriz, L.; “How to Digitally Verify Human Identity: The Case of Voting,” ISACA Journal, vol. 1, 2023
8 International Organization for Standardization (ISO), ISO/IEC 27001:2022 Information Security, Cybersecurity and Privacy Protection—Information Security Management Systems—Requirements, 2022
9 Sbriz, L.; “Modeling an Identity Trust System,” ISACA Journal, vol. 6, 2023
10 ISACA, “Recovery Point Objective (RPO)”
LUIGI SBRIZ | CISM, CRISC, CDPSE, ISO/IEC 27001 L A, ITIL V4, NIST CSF, TISAX AL3, UNI 11697:2017 DPO
È lead auditor, formatore e consulente senior su tematiche di risk management, cybersecurity e privacy. È stato responsabile del monitoraggio dei rischi presso un'azienda multinazionale del settore automotive per oltre sette anni. In precedenza, è stato responsabile della gestione dei servizi e delle risorse ICT nell’area Asia-Pacific (Cina, Giappone e Malesia) e, prima ancora, è stato responsabile della sicurezza delle informazioni a livello mondo per più di sette anni. Ha sviluppato una metodologia originale di monitoraggio del rischio, integrando strumenti di analisi del rischio operativo, valutazione della maturità del controllo e processi di audit interno basati sul rischio. Inoltre, ha progettato uno strumento di cyber monitoring basato su OSINT e proposto uno standard di autenticazione dell'identità digitale. Sbriz è stato anche consulente per sistemi di business intelligence per diversi anni. Può essere contattato su LinkedIn.