IDaaS significa Identity Management as a Service ma può anche essere chiamato AaaS (Autenticazione as a Service). La premessa è che l’internettizzazione di tutte le procedure sta portando a una moltiplicazione degli accessi che per gli amministratori è sempre più difficile da presidiare. Quasi tutte le applicazioni in cloud attualmente in uso richiedono che gli utenti si registrino o si autentichino come utenti unici. Il tutto considerando come gli stessi utenti vorrebbero poter salvare il lavoro fatto utilizzando un’applicazione o un’altra. Dal momento che l’HTTP è un protocollo senza stato, come possono fare le applicazioni Web per stabilire un meccanismo di mantenimento? È necessario trovare una soluzione capace di mantenere le sessioni utente separate da chiunque utilizzi contemporaneamente la stessa applicazione.
IDaaS: i plus per i professionisti della sicurezza
Dal punto di vista dei security manager, la gestione delle identità nel cloud offre un duplice vantaggio:
- Il primo è che ogni applicazione, esclusi i valori anomali specializzati, deve gestire le identità nel cloud. Le applicazioni devono tenere traccia di chi sono gli utenti e devono essere in grado di autorizzarli, autenticarli e differenziarli in modo sicuro
- Il secondo è che l’IDaaS risulta strategico dal punto di vista della governance, dal momento che le conseguenze della mancata definizione delle priorità possono risultare estremamente disastrose
Al di là di queste due motivazioni, va detto anche che negli ultimi anni sono sorti centinaia di problemi relativi all’autenticazione: la letteratura della sicurezza annovera i casi di Dropbox, Microsoft o WordPress, solo per citare i più noti. Fortunatamente, oggi le aziende hanno diverse opzioni per facilitare la gestione e la sicurezza delle identità in cloud.
AaaS o IDaaS come funzionano
Gli strumenti e i servizi tecnologici a supporto degli ambienti cloud si sono evoluti e applicano le stesse dinamiche As a Service e le stesse proprietà alle sfide della gestione dell’identità degli utenti analogamente ad altri approcci applicativi, dallo IaaS al SaaS.
Che si faccia riferimento all’IDaaS) o all’autenticazione come servizio (AaaS), l’idea è la stessa: un fornitore di servizi, esterno all’applicazione che viene distribuita, si assume anche l’onere di autenticare e registrare gli utenti nonché di gestire le loro informazioni. Per facilitare la gestione delle identità nel cloud, questi servizi utilizzano standard ben documentati e analizzati come, ad esempio, il Security Assertion Markup Language (SAML) o l’Open Authorization (OAuth). Ciò consente alle applicazioni di lasciare le meccaniche di implementazione al provider anziché di doverle programmare.
- SAML è uno standard OASIS che consente di creare un’asserzione di sicurezza. Si tratta essenzialmente di una struttura di dati XML che contiene informazioni sullo stato di autenticazione dell’utente. Storicamente, SAML è stato utilizzato per abilitare applicazioni come SSO (Single Sign-On). Il framework consente a una parte di dichiarare a un’altra parte (ad esempio un fornitore di servizi), che l’utente è stato autenticato. Il fornitore di servizi può analizzare l’affermazione ed essere sicuro che l’utente, in quanto già autenticato, non debba farlo di nuovo.
- OAuth è uno standard aperto gestito da Internet Engineering Task Force. Consente lo scambio di dati di autorizzazione, generalmente tramite API REST. OAuth crea token di accesso di una parte che possono essere interpretati da un’altra, utilizzando in genere HTTP Secure come canale di scambio dati. Questo consente lo scambio di informazioni sullo stato di autenticazione tra due componenti senza stato.
Sicurezza e IDaaS: quali sono i vantaggi
Delegare le minuzie della gestione degli account e dell’autenticazione a un fornitore di servizi significa che un’azienda non deve più tenerne traccia nelle sue applicazioni. Il vantaggio è di liberare le organizzazioni dalla responsabilità di tenere traccia delle password, attività per altro sempre esposta al rischio di compromissione. Le organizzazioni possono anche abilitare più facilmente l’autenticazione a più fattori e vivere serenamente, consapevoli che le identità nelle mani degli specialisti della sicurezza saranno ben analizzate.
Anche a livello di programmazione l’IDaaS è vantaggioso: non solo gli sviluppatori devono scrivere meno codice, risparmiando del tempo, ma in prospettiva hanno anche la possibilità di integrare rapidamente estensioni o nuovi servizi applicativi.
Le opportunità si riflettono anche lato utente. Ad esempio, se le aziende utilizzano un provider di identità con cui gli utenti hanno già una relazione, lo stesso provider può consentire agli utenti di accedere con account e credenziali esistenti. Il rischio è che se il fornitore di servizi è inattivo o irraggiungibile, nessuno potrà accedere alle applicazioni. Il che significa che bisogna fare molta attenzione ala scelta dei fornitori.
Implementazione dell’IDaaS: 3 cose da sapere
A fronte dei vantaggi dell’outsourcing in chiave AaaS o IDaaS ci sono alcuni fattori da considerare, a partire dal contesto in cui verranno utilizzati.
- I responsabili dell’attività, ad esempio, dovrebbero valutare se hanno o avranno bisogno in futuro, di integrarsi con applicazioni legacy, gestendo account utente esistenti, come Active Directory (AD) o sistemi SSO. Sebbene questi consigli possano sembrare di buon senso, molte organizzazioni non ne tengono conto trovandosi poi in una posizione difficile quando devono mettere insieme più prodotti o, peggio ancora, acquistare più prodotti ridondanti che hanno la stessa funzione. Con la gestione delle identità in outsourcing, se un’organizzazione deve integrarsi con applicazioni non REST (come applicazioni desktop native o middleware) l’accesso a una vasta gamma di opzioni di integrazione, tra cui SAML, OAuth o OpenID Connect, può essere vantaggioso.
- È molto importante considerare la logistica dell’implementazione cloud, locale o ibrida. Ad esempio, se un’azienda deve integrarsi con un’app Web rivolta all’esterno per utenti residenti su Internet, ci sono vantaggi nell’implementazione del cloud poiché l’infrastruttura locale non sarà un single point of error. Detto questo, se esiste un archivio utente o una directory locale esistente, capire la necessità di alcune applicazioni esterne (ovvero quelle non ospitate nell’infrastruttura dell’azienda) per ottenere l’accesso affinché l’implementazione funzioni.
Le organizzazioni devono cercare di supportare sia i tipi di autenticazione desiderati sia le directory degli account utente esistenti. Ad esempio, in base al contesto e all’utilizzo potrebbe essere meglio aggiungere dei fattori di autenticazione secondari o anche terziari, come token e soluzioni biometriche. La ratio è di ragionare su risiedono attualmente le informazioni sull’account da incorporare e considerare le ipotetiche sfide legate all’integrazione. Ad esempio, un approccio standard come AD è significativamente più facile da integrare, al contrario di un database utente sviluppato su misura per un’applicazione esistente.
Il tutto ragionando come va sempre fatto, in ottica cloud. Il che significa che anche nel caso dell’IDaaS prima di coinvolgere i fornitori bisogna raccogliere i requisiti, pianificare l’architettura, con la dovuta diligenza associata all’integrazione. Ciò consente alle organizzazioni di risparmiare tempo ed energia nel lungo periodo.
