Gestione delle identità cloud
Un problema comune nel settore informatico è determinare in modo accurato chi sta usando un sistema in un determinato momento. L'identità di un utente finale è importante per diversi motivi, il più importante dei quali è limitare la capacità dell'utente di accedere a risorse cui non è autorizzato ad accedere e di eseguire azioni che non ha diritto di eseguire. Una persona che usa la posta elettronica basata sul Web, ad esempio, non deve essere in grado di vedere i messaggi inviati ad altri utenti. Analogamente, quando un amministratore di database accede a un servizio cloud, non deve essere in grado di accedere ai database di cui non è responsabile o eseguire altre attività amministrative che esulano dall'ambito delle sue mansioni. Nulla di tutto ciò è possibile se non si conosce l'identità dell'utente.
Gli esempi di come l'identità viene stabilita e presentata per la verifica nelle attività quotidiane sono numerosi. In molti paesi/aree geografiche si usano ID, ad esempio i codici fiscali, per identificare le persone a fini fiscali o concedere l'accesso a programmi degli enti pubblici. Le normative prevedono che gli automobilisti presentino patente e libretto di circolazione del veicolo per identificarsi e dimostrare di essere qualificati a usare un autoveicolo. Le agenzie per il controllo delle frontiere richiedono ai viaggiatori di esibire il passaporto per indicare la propria cittadinanza.
Nel mondo online l'identità viene in genere determinata chiedendo all'utente di specificare credenziali che lo identificano in modo univoco, ad esempio un nome utente e una password, un'impronta digitale o, come avviene sempre più spesso negli smartphone, un viso. Con i recenti progressi nel campo dell'intelligenza artificiale, il riconoscimento facciale non è più magia, ma scienza. All'utente può essere richiesto di immettere le credenziali quando accede al sistema per la prima volta ed è in genere ciò che accade nei portali amministrativi per i servizi cloud. Oppure potrebbe non visualizzare alcuna richiesta fino al momento in cui accede a una risorsa protetta, ad esempio una pagina Web disponibile solo agli utenti autenticati. L'autenticazione è il processo di determinazione dell'identità di un utente, ovvero la conferma della sua identità oltre ogni ragionevole dubbio. È un processo distinto dall'autorizzazione, che invece determina quello che un utente può e non può fare dopo l'autenticazione.
Gli esempi di come viene determinata l'identità online sono vari e numerosi. E dipendono molto anche dal tipo di scenario. Verranno ora esaminati due esempi comuni di come viene usata l'autenticazione per stabilire l'identità di un utente. Il primo riguarda un sito Web pubblico che richiede all'utente di eseguire l'accesso prima di poter visualizzare alcune o tutte le risorse in esso contenute. Il secondo riguarda l'autenticazione degli utenti che accedono a condivisioni file, dispositivi di rete e altre risorse interne. In entrambi i casi, determinare l'identità dell'utente prima di concedergli l'accesso è fondamentale per l'implementazione di un sistema solido e sicuro.
Autenticazione di utenti del sito Web esterni
Un uso comune dell'identità digitale è rappresentato dall'accesso a una pagina Web disponibile solo per gli utenti autenticati, ad esempio utenti che hanno acquistato l'abbonamento all'edizione online di un giornale. La prima decisione che gli sviluppatori del sito Web devono prendere è se scrivere autonomamente la logica che consente agli utenti di registrarsi (creare account) e accedere oppure se usare un provider di identità di terze parti. Un provider di identità è un servizio che consente l'autenticazione degli utenti tramite protocolli standard quali ad esempio OAuth 2.0, OpenID Connect e SAML 2.0, ognuno dei quali implementa meccanismi per garantire l'autenticità delle informazioni scambiate. Usano ad esempio le firme digitali per assicurarsi che le informazioni relative all'identità non vengano modificate durante la trasmissione in Internet.
Sono disponibili molti servizi di provider di identità digitali. Le aziende di social media, ad esempio Facebook e Twitter, possono fungere da provider di identità, consentendo agli utenti di usare le credenziali stabilite sui propri siti per accedere ad altri siti. Anche Microsoft e Google offrono servizi di provider di identità, consentendo agli utenti di accedere ad altri siti con i propri account Microsoft o Google. È esattamente quanto accade quando si usa l'account Microsoft per accedere a Posta di Outlook o l'account Google per accedere a Gmail, YouTube o altri siti che supportano gli account Google. I provider di servizi cloud offrono servizi di provider di identità, oltre a modalità per la propria integrazione o quella di altri provider di identità nei siti Web. Con Microsoft Entra ID, ad esempio, la creazione di un sito Web che accetta account di accesso privati, account di accesso "pubblici" tramite account Facebook, Twitter, Microsoft o Google oppure qualsiasi combinazione di entrambi, è relativamente semplice.
L'uso di provider di identità di terze parti per l'autenticazione degli utenti offre tre vantaggi:
Maggiore sicurezza: i provider di identità di terze parti quali ad esempio Microsoft e Google hanno una profonda esperienza nell'archiviazione e nello scambio di credenziali di accesso in modo sicuro. Alcune delle violazioni della sicurezza di alto profilo avvenute negli ultimi anni si sono verificate perché sviluppatori non esperti in materia di sicurezza hanno implementato i propri sistemi di accesso e sono stati vittima di errori comuni, ad esempio l'archiviazione di password in testo non crittografato in un database. Le password non vanno mai archiviate, anche se crittografate. Archiviare invece i codici hash unidirezionali delle password e usare tecniche note quali il salting per rendere più difficile la violazione delle password1.
Molti provider di identità supportano anche l'autenticazione a più fattori (MFA) per rendere più difficile l'uso di credenziali rubate. Quando ad esempio si accede a un sito Web e viene richiesto di immettere un codice di accesso inviato tramite SMS al proprio telefono cellulare, l'azienda sta usando l'autenticazione a più fattori. Infine, i provider di identità di terze parti spesso implementano l'Accesso condizionale, ovvero un sistema che erige immediatamente barriere di sicurezza aggiuntive se giustificate dalla cronologia degli accessi, dalla posizione geografica o da altri fattori. Questo è il motivo per cui talvolta vengono richieste informazioni aggiuntive se si accede a un sito Web mentre si è in viaggio. Il provider di identità rileva un indirizzo IP dal quale non si è mai eseguito l'accesso e aggiunge un ulteriore livello di sicurezza al processo di autenticazione.
Supporto per l'accesso Single Sign-On (SSO): l'uso di 20 nomi utente e password per accedere a 20 siti Web diversi non è solo scomodo, ma è anche un problema di sicurezza. Per gli utenti che si trovano a gestire decine di nomi utente e password, le probabilità di adottare comportamenti di sicurezza non corretti, ad esempio scegliendo password facili da indovinare o usando la stessa password per più account, sono maggiori. Un report indica che il numero di account che gli utenti devono monitorare raddoppia ogni cinque anni, un fenomeno noto come proliferazione degli account.
Se invece 20 siti Web non correlati consentono agli utenti di accedere con i propri account Microsoft, Google o Facebook, sarà possibile usare un unico set di credenziali per tutti e 20 i siti. Questo processo è noto come Single Sign-On. Riduce la proliferazione degli account, e migliora pertanto la sicurezza, limitando il numero di credenziali che gli utenti devono gestire.
Riduzione dei tempi di sviluppo: la scrittura del proprio codice per gestire account e credenziali di accesso implica anche la scrittura del codice necessario per creare nuovi account, cambiare le password, recuperare quelle dimenticate, implementare l'autenticazione a più fattori e l'Accesso condizionale e altro ancora. I provider di identità di terze parti offrono questi servizi gratuitamente. La maggior parte delle attività di scrittura del codice comporta la comunicazione con i provider di identità tramite protocolli stabiliti e a questo scopo sono disponibili numerose librerie. Non è insolito, quando si usano i provider di identità, implementare un sistema di accesso e di gestione degli account completo in meno di 100 righe di codice. Il codice scritto dal provider di identità, al contrario, è di diversi ordini di grandezza più lungo e più complesso.
La figura 3.1 illustra una rappresentazione semplificata dell'interazione tra un utente e un sito Web che usa un provider di identità di terze parti per l'autenticazione degli utenti:
Il sito è configurato per l'uso di un provider di identità considerato attendibile per l'autenticazione degli utenti. Quando l'utente visita il sito o accede a una pagina che richiede l'autenticazione, il sito contatta il provider di identità e richiede l'autenticazione dell'utente.
Il provider di identità richiede all'utente di immettere le proprie credenziali. Il provider usa queste credenziali per stabilire l'identità dell'utente e rilascia un token di sicurezza che asserisce l'identità. Il token è firmato digitalmente per evitare manomissioni e talvolta include informazioni quali il nome e il cognome e l'indirizzo di posta elettronica di un utente.
Il browser trasmette il token al sito Web. Il sito Web verifica l'autenticità del token.
Se la convalida ha esito positivo, l'utente può procedere.
Figura 3.1: Autenticazione degli utenti di un sito Web.
In genere, dopo aver confermato la validità del token, il sito Web rilascia un cookie HTTP crittografato con informazioni sull'identità dell'utente in modo che questo possa tornare alla pagina per un certo periodo di tempo senza dover eseguire di nuovo l'accesso. Il cookie autentica in modo efficace l'utente nelle richieste successive come ha fatto il token ID a seguito della richiesta iniziale.
Una funzionalità importante di questo flusso è rappresentata dal fatto che il sito non vede mai le credenziali dell'utente. Il sito non conosce infatti la modalità di autenticazione dell'utente. Di conseguenza, la responsabilità di archiviare le credenziali dell'utente in modo sicuro è affidata al provider di identità. Il proprietario del sito Web può inoltre cambiare il meccanismo fisico usato per l'autenticazione degli utenti, passando ad esempio da nomi utente e password alle impronte digitali, modificando la configurazione del provider di identità anziché riscrivendo una grande quantità di codice.
Autenticazione degli utenti interni all'organizzazione
La discussione nella sezione precedente è rilevante per un team di sviluppo software che crea un sito Web che supporta utenti autenticati all'esterno dell'organizzazione. Ma si supponga di essere un amministratore IT e che l'obiettivo sia quello di autenticare gli utenti all'interno dell'organizzazione al fine di proteggere l'accesso a condivisioni file e altre risorse locali. Questo scenario richiede un approccio diverso all'identità.
La maggior parte delle aziende archivia localmente le informazioni di identità relative agli utenti all'interno dell'organizzazione, ad esempio i dipendenti di un'azienda, in un servizio directory. Il servizio archivia nomi utente, hash delle password e altre informazioni in un database, in genere un database distribuito che supporta i grafici gerarchici, e ne espone il contenuto tramite protocolli standard, ad esempio Lightweight Directory Access Protocol o LDAP. Alcuni servizi directory usano protocolli proprietari che tuttavia stanno diventando sempre meno frequenti a causa della crescente migrazione delle organizzazioni verso soluzioni open source e standard aperti. Quando gli utenti entrano a far parte dell'azienda oppure la lasciano, gli amministratori aggiornano la directory. Quando un utente lascia l'azienda e viene rimosso dalla directory non può più accedere alle risorse presenti nella rete aziendale.
Uno dei servizi directory più diffusi è Active Directory di Microsoft, ovvero una famiglia di servizi progettati per archiviare le informazioni sugli utenti e proteggere l'accesso alle risorse di rete. Active Directory archivia oggetti che possono rappresentare utenti, computer, condivisioni file, stampanti e altre risorse. Gli oggetti possono essere organizzati in domini, i quali possono essere organizzati in alberi che a loro volta possono essere organizzati in foreste, garantendo la flessibilità necessaria per modellare le organizzazioni di piccole e grandi dimensioni.
Non è importante comprendere come funzionano i servizi directory o conoscere i protocolli che usano o il flusso di informazioni che si crea tramite questi protocolli. Ciò che è importante sapere è che i servizi directory offrono un repository centrale per le informazioni di identità relative agli utenti all'interno di un'organizzazione. Come si vedrà, è possibile estendere i servizi directory locali in modo che siano applicabili anche alle risorse cloud. In questo modo, le organizzazioni possono autenticare gli utenti che accedono alle risorse cloud nello stesso modo in cui autenticano quelli che accedono alle risorse locali. Tra l'altro, ciò consente agli amministratori di proteggere l'accesso alle risorse cloud con le stesse identità che usano per proteggere l'accesso alle risorse locali. Gli utenti possono inoltre usare un unico set di credenziali per accedere a entrambe.
Riferimenti
- Auth0 (2018). Adding Salt to Hashing: A Better Way to Store Passwords (Aggiunta di salting agli hash: un modo migliore per archiviare le password). https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/.