Domande frequenti sulla gestione degli accessi

Quella della gestione delle identità e degli accessi (IAM, Identity and Access Management) è una branca della sicurezza dei dati che comprende due set di funzionalità: IGA (Identity Governance and Administration) e AM (Access Management).

L’IAM fornisce un quadro metodico per concedere (e richiedere) l'accesso ad applicazioni (IGA), attuare controlli (AM) e garantire la visibilità degli accessi (AM).

Le soluzioni IGA aiutano a rispondere alle domande “Chi è autorizzato ad accedere a quale applicazione?” e “A chi è stato concesso l'accesso a quale applicazione, da chi e quando?” Le soluzioni AM aiutano a rispondere alle domande “Chi ha avuto accesso a cosa e quando, e in che modo è stata verificata la loro identità?”

Una soluzione IAM (Identity and Access Management) è composta da funzionalità IGA (Identity Governance and Administration) e AM (Access Management). Le soluzioni IAM forniscono un quadro metodico per concedere (e richiedere) l'accesso ad applicazioni (IGA), attuare controlli (AM) e garantire la visibilità sugli eventi di accesso (AM). Dato che la maggior parte delle organizzazioni impiegano le componenti IGA e AM separatamente, queste discipline sono considerate sempre più spesso famiglie di soluzioni distinte e indipendenti, piuttosto che funzionalità composite di una singola suite IAM.

La gestione degli accessi è una funzionalità che permette di determinare se un utente ha il permesso di accedere a una certa risorsa, e consente l'applicazione dei criteri di accesso istituiti per tale risorsa.

La gestione degli accessi è attuata sulla base dei criteri di accesso definiti dagli amministratori IT che includono informazioni come i gruppi di utenti (ad es. reparto vendite, ricerca e sviluppo, risorse umane) a cui è consentito l’accesso a determinate applicazioni cloud (ad es. Salesforce, Office 365, Jira, Taleo), come anche il set di attributi utente necessari per accedere (ad es. rete fidata, password, OTP).

Il criterio di accesso può richiedere la valutazione di più o meno attributi utente a seconda della sensibilità di un’applicazione cloud. Questi attributi vengono valutati utilizzando l’autenticazione contestuale o basata sul rischio, fondamentale per applicare i diversi criteri di accesso definiti per ciascuna applicazione cloud (per ulteriori dettagli, leggi il nostro articolo sull’autenticazione contestuale).

Fondamentale per la gestione degli accessi al cloud è anche il Single Sign-On che, per accedere a tutte le applicazioni cloud, consente l’utilizzo di un unico set username/password o “identità” (per ulteriori dettagli, leggi il nostro articolo sul Single Sign-On).

IDaaS è un’IAM as-a-service, è chiamata anche identity-as-a-Service. IDaaS descrive le soluzioni IAM (Identity and Access Management) che offrono un modello di delivery as-a-service basato sul cloud per la gestione delle identità e degli accessi. Anche se negli ultimi anni l’IDaaS viene visto come un mercato distinto, considerate le tendenze recenti in futuro verrà separato in due discipline separate: quella della gestione degli accessi e dell’IGA, i cui metodi di distribuzione comprendono installazioni on-premises, piattaforme software o basate sul cloud.

L’IGA (Identity Governance and Administration) è un set di funzionalità che aiuta a rispondere alle domande “Chi è autorizzato ad accedere a quale applicazione?” e “A chi è stato concesso l'accesso a quale applicazione, da chi e quando?” Ad esempio, una soluzione IGA può aiutare a stabilire che il team di ricerca e sviluppo ha diritto ad accedere ad alcune applicazioni come GitHub, Jira e Confluence. Una soluzione IGA può garantire l’accesso automatico a queste applicazioni in base all’appartenenza al team di ricerca e sviluppo. Un utente di questo team può anche richiedere l’accesso ad altre applicazioni, che gli verrà garantito previo un processo di approvazione da parte della direzione supportato da alcune soluzioni IGA.

La federazione di identità è un’architettura basata su un unico IdP (Trusted Identity Provider) che disciplina l’autenticazione degli utenti: le applicazioni affidano il processo di autenticazione al provider di identità ogni volta che un utente cerca di accedervi. Le applicazioni che affidano il processo di autenticazione all’IdP si chiamano fornitori di servizi.

La federazione di identità risolve le sfide e le frustrazioni di gestire separatamente credenziali per numerose applicazioni web, interne o esterne a un’organizzazione, e consente ad amministratori e utenti di mantenere un unico set username/password (o “identità”) per svariate applicazioni e risorse IT. La federazione di identità elimina l’affaticamento da password, migliora la sicurezza e risolve il problema di gestione di innumerevoli reset.

La federazione di identità si fonda su protocolli di federazione come SAML e Open ID Connect, come anche su protocolli proprietari come WS-Federation di Microsoft.

L’accesso federato è una funzione dei protocolli di federazione (come SAML, Open ID Connect, ecc.) che permette agli utenti di accedere a svariate applicazioni utilizzando la loro identità aziendale corrente. Ad esempio, invece di accedere ad applicazioni cloud separate utilizzando diversi set username/password, o “identità”, l'accesso federato consente agli utenti di accedere a Office 365, Salesforce, AWS e così via con la stessa identità che usano per accedere alla rete aziendale la mattina, o alla VPN la sera.

Un provider di identità è un sistema che autentica gli utenti che stanno cercando di accedere ad altri siti web non affiliati (“Fornitori di servizi”). I provider di identità, insieme ai fornitori di servizi, comprendono un’architettura di federazione di identità in cui gli utenti che cercano di accedere a un sito web (o fornitore di servizi) vengono affidati al provider di identità per essere autenticati. Il provider di identità verifica i dati di autenticazione dell’utente (ad es. i cookie, il dispositivo, la rete, l’OTP) e produce una risposta di “accettazione” o “negazione” inviata al fornitore di servizi. I provider di identità possono anche richiedere l'autorizzazione per accedere ad alcuni dati per conto di un altro sito web non affiliato. I dati di autorizzazione possono includere il permesso di accedere a informazioni come gli indirizzi e-mail da un account webmail o i nomi degli amici da un account di social network.

Ad esempio, il servizio di autenticazione SafeNet agisce da provider di identità quando gli utenti accedono alle applicazioni cloud come nell’esempio appena descritto.

Un servizio di token di sicurezza è un sistema che autentica gli utenti che stanno cercando di accedere ad altri siti web non affiliati (“Relying party”). I servizi di token di sicurezza e i relying party comprendono un’architettura di servizi di token di sicurezza in cui gli utenti che cercano di accedere a un sito web (relying party) vengono affidati al servizio di token di sicurezza per essere autenticati.

I servizi di token di sicurezza vengono anche chiamati modelli di provider di identità o autenticazione basata sui token. Un servizio di token di sicurezza è equivalente a un provider di identità, e un Relying Party è equivalente a un fornitore di servizi. E invece di scambiare asserzioni SAML, questi ultimi vengono chiamati token di sicurezza. I nomi sono diversi ma il concetto è lo stesso.

Il SAML (Security Assertion Markup Language), pronunciato “sammel”, è uno standard aperto basato su XML che consente di scambiare dati di autenticazione tra siti web non affiliati, una funzionalità chiamata anche federazione di identità o autenticazione federata.

La federazione di identità è la capacità di estendere al cloud le identità aziendali attuali degli utenti, consentendo loro di accedere alle applicazioni cloud solo con questi dati. L’autenticazione federata alle app cloud con SAML consente agli utenti di accedere alle applicazioni cloud con la propria identità aziendale corrente, permettendo loro di mantenere un unico set username/password invece che decine.

Come funziona SAML
Quando un utente cerca di accedere a un’applicazione basata sul cloud viene reindirizzato al provider di identità per l’autenticazione. Il provider di identità raccoglie le credenziali dell’utente, ad esempio il suo username e la sua OTP, e restituisce una risposta all’applicazione cloud a cui si vuole accedere. La risposta si chiama asserzione SAML, e contiene un’accettazione o una negazione.

In base a questa risposta, il fornitore di servizi, ad es. Salesforce, Office 365 o DropBox, impedisce o concede l’accesso all’applicazione.

WS-Federation, o WS-Fed, è un protocollo di federazione di identità proprietario di Microsoft. WS-Fed utilizza AD FS (Active Directory Federation Services) di Microsoft per estendere le identità archiviate nell’Active Directory alle applicazioni cloud di Microsoft come Office 365 e Azure. Come SAML, WS-Fed utilizza un modello di provider di identità. Quando accede a un’applicazione cloud di Microsoft, l’utente viene reindirizzato ad AD FS per l’autenticazione, e in base alla risposta di questo gli viene concesso o negato l’accesso.

OAuth (pronunciato “oaut”), abbreviazione di “Open Authorization”, è un protocollo standard aperto che permette un’autenticazione federata, o “basata su token” e l’autorizzazione tra siti web non affiliati. Come gli altri protocolli di federazione delle identità, come SAML, Open ID Connect e WS-Fed, OAuth permette di accedere a un’applicazione con un’identità verificata da un fornitore affidabile. OAuth va oltre l’autenticazione federata per consentire agli utenti di autorizzare i siti web di terzi ad accedere a determinate informazioni sull’account, come i nomi e gli indirizzi e-mail. Ad esempio, OAuth è il protocollo utilizzato dai siti dei social network per accedere ai contatti della tua webmail e chiederti se desideri invitarli nella tua rete.

OpenID Connect, come SAML, è un protocollo standard aperto di federazione di identità che utilizza un modello di provider delle identità. Tuttavia, al contrario di SAML che funziona tramite cookie e dunque esclusivamente con applicazioni che si aprono in un browser (“applicazioni basate su browser”), OpenID Connect fornisce un framework di accesso Single Sign-On che consente l’implementazione dell’SSO per applicazioni basate sul browser, app mobili native e client desktop (come i Rich Client e alcune VPN). Così, mentre la maggior parte delle implementazioni Single Sign-On supportano attualmente solo app basate su cloud e browser, con l’adozione crescente di OpenID Connect da parte dei provider di identità saremo in grado di effettuare l'autenticazione una volta sola per accedere contemporaneamente a tutte le nostre risorse: client desktop, applicazioni basate sul browser o app mobili native.

BYOI, o Bring Your Own Identity (“Porta la tua identità”) è un termine usato per descrivere la capacità di un’impresa o di un’altra organizzazione di supportare un’identità rilasciata altrove e consentire un accesso sicuro alle risorse utilizzando tale identità.

Nell’ambito della gestione delle identità, fornitori e organizzazioni stanno cercando di consentire a dipendenti e partner di utilizzare la propria identità per accedere alle risorse aziendali. Potrebbe teoricamente trattarsi di qualsiasi identità che fornisce un livello sufficiente di garanzia, come ad esempio documenti rilasciati dal governo, smart card sanitarie o identità online come quelle dei social network, delle reti professionali e identità disponibili in commercio come FIDO. Il mondo imprenditoriale e dei consumatori sono sempre più simili, e ai team di sicurezza aziendale viene richiesto sempre più spesso di implementare lo stesso tipo di metodi di autenticazione tipici dei servizi di consumo.

Un Identity Broker è un sistema che può supportare sistemi BYOI permettendo all’identità esistente di un’utente (o a svariate identità esistenti) di autenticarsi a siti web non affiliati. Ad esempio, un Identity Broker può supportare l’identità sociale o webmail di un utente e permettergli di accedere a una serie di siti non affiliati. Gli Identity Broker consentono alle organizzazioni di supportare più provider di identità.

Il Single Sign-On (SSO) verifica l’identità una volta sola, autenticandosi quindi automaticamente ogni volta che si accede a varie risorse. Elimina la necessità di accedere e autenticarsi separatamente ad applicazioni e sistemi singoli, fungendo essenzialmente da intermediario tra l’utente e le applicazioni di destinazione. Dietro le quinte, le applicazioni e i sistemi di destinazione mantengono ancora i propri archivi di credenziali e presentano prompt di accesso al sistema dell’utente. L’SSO risponde a tali richieste e mappa le credenziali a una singola coppia di nome utente/password. (Fonte: Gartner)

L’SSO, sia indipendente o in una più ampia soluzione di gestione degli accessi, può essere realizzato attraverso una serie di protocolli di federazione di identità. Questi includono protocolli open-source come SAML 2.0 e Open ID Connect, protocolli proprietari come WS-Federation di Microsoft e altre tecnologie come password vaulting e reverse proxy.

Il vault di password, chiamato anche password manager, è un modo semplice per creare un’esperienza SSO (Single Sign-On) quando un’applicazione di destinazione non supporta protocolli di federazione di identità, come un'applicazione legacy o personalizzata. I vault di password sono sistemi che archiviano e crittografano le password di diversi siti web. Invece di accedere a ogni applicazione con una password dedicata, l’utente può semplicemente autenticarsi con una password master (che decifra a sua volta il vault di password), eliminando la necessità di mantenerne svariate.

L’autenticazione è un processo che garantisce che gli utenti autenticati possano accedere solo alle risorse per cui sono autorizzati, come definito dal titolare o dall’amministratore competente. Nel mondo dei consumatori, l’autorizzazione può anche riferirsi al processo per cui un utente garantisce che un’applicazione basata sul cloud (come un social network) acceda solo a determinate informazioni da un sito web non affiliato (come l'account webmail dell’utente).

L'autenticazione è un processo di verifica o convalida dell'identità di un utente in base alle credenziali fornite quando accede a un’applicazione, un servizio, un computer o un ambiente digitale. La maggior parte delle credenziali di autenticazione consistono in qualcosa che si possiede, come un nome utente e qualcosa che si conosce, come una password. Se le credenziali fornite corrispondono a quelle memorizzate dall’applicazione o dal provider di identità, l’utente viene autenticato e può accedere.

L’autenticazione contestuale è un metodo di autenticazione che si basa su una gamma di informazioni supplementari valutate quando una persona accede a un’applicazione. Il tipo più comune di informazioni contestuali include la posizione di un utente, l’ora, l’indirizzo IP, il tipo di dispositivo, l’URL e la reputazione dell’applicazione. L’autenticazione contestuale, chiamata anche autenticazione adattiva o basata sul rischio, costituisce un elemento centrale nel mondo dell'SSO e della gestione degli accessi dove l'obiettivo è rendere il percorso di autenticazione il più trasparente e indolore possibile.

Valutando gli attributi di accesso utente, che siano contestuali (dispositivo, ruolo, posizione) o basati sul comportamento (ad es. velocità di digitazione, sequenza di visualizzazione delle pagine), il Single Sign-On e le soluzioni di gestione degli accessi sono in grado di far corrispondere continuamente il livello di autenticazione richiesto dall’utente al criterio di accesso definito per ciascuna applicazione. In tal modo l’applicazione viene applicata in maniera granulare (nel modo più fluido possibile) secondo il criterio di accesso di un’applicazione, piuttosto che come regola uniforme e totale per tutte le risorse aziendali.

L’autenticazione continua avviene ogni volta che un utente accede a una nuova applicazione o risorsa, al contrario dell’autenticazione binaria che fornisce una decisione unica “sì/no” valida per un unico accesso a una sola applicazione.

Con un token, una password o un’impronta digitale, l’autenticazione è praticamente una decisione “sì/no”: il sistema convalida l’identità di un utente e consente o nega l'accesso a un’applicazione.

Ma, grazie alle ultime tecnologie come l’autenticazione contestuale o la biometria comportamentale (per es. lo stile di navigazione, di digitazione e altri tratti fisici), l’autenticazione può diventare un processo più continuo. Valutando una serie di attributi come l’indirizzo IP, i parametri mobili, il dispositivo conosciuto, il sistema operativo e così via, l’autenticazione contestuale o basata sul rischio può verificare l’identità di una persona ogni volta che accede a un'applicazione. Infatti, può farlo anche senza che l’utente lo sappia.

L’autenticazione contestuale offre modalità fluide di verifica delle identità. Ed è questo che permette di equilibrare la praticità per l’utente con la capacità di applicare controlli granulari degli accessi a svariate applicazioni cloud. Per questo motivo il concetto di autenticazione continua, basato sull’autenticazione contestuale, costituisce il fondamento della gestione degli accessi al cloud.