Le aziende che si sentono soddisfatte di come sono in grado di gestire le policy di identificazione e di accesso nei data center, si devono oggi chiedere se queste regole e questi processi funzionano altrettanto bene in un ambiente cloud; un’altra domanda da porsi è se il cloud implichi rischi non previsti all’interno di un environment on-premises. La risposta a entrambe le domande è “sì”.
Nei network tradizionali, gli utenti sono spesso raggruppati all’interno di sottoreti, dai cui indirizzi Ip è facile identificare a quali organizzazioni appartengono. La gestione per sottoreti facilita molto l’applicazione di policy basate sull’appartenenza a gruppi di lavoro.
Le cose di complicano nel cloud e nel mondo mobile. Gli utenti che accedono alle applicazioni e ai dati aziendali da questi nuovi ambienti, possono non utilizzare indirizzi conosciuti e quindi rischiano di essere visti dal front end web (i server che gestiscono l’interazione fra i data center aziendali e Internet) come utenti qualsiasi. In altre parole, il web server può non inferire l’identità dell’utente dal Ip address che espone.
Tutto si complica ulteriormente quando le applicazioni sono pensate per l’implementazione sul cloud. Dal momento che il cloud è naturalmente predisposto alla protezione delle applicazioni dai guasti dei sistemi (spostandole in altri punti di essi) o a ridurre il carico delle applicazioni al fine di evitare i crash, gli sviluppatori tendono a creare applicazioni costituite da molte componenti al fine di poter sfruttare meglio queste feature. Questo approccio comporta però un aumento del rischio di creare senza volerlo delle backdoor (“porte” di servizio predisposte dagli sviluppatori per poter entrare velocemente in un programma violato) che possono essere sfruttate dagli hacker.
Quali sono le opzioni di IAM disponibili
Ancor più che nei data center tradizionali, nel cloud le identità degli utenti e i loro diritti di accesso alle applicazioni devono diventare espliciti, non riconoscibili solo attraverso meccanismi complicati e difficili da implementare e attuare. È qui che entra in gioco la disciplina dello IAM. Ed è bene comprendere che l’Identity and Access Management è qualcosa che include, ma va molto oltre il single sign-on (insieme di procedure software automatizzate che consentono agli utenti di accedere più applicazioni e siti web diversi autenticandosi una volta sola).
Tutti i tool IAM sono costituiti da due parti:
- una associa gli utenti alle loro identità
- e la seconda abbina alle identità i permessi, o diritti, di accesso.
Grazie a queste due funzionalità, una persona reale, una volta identificata, acquisisce un certo numero di prerogative che, quasi sempre, sono memorizzate in un repository ben protetto.
I processi di identificazione possono essere basati sul metodo tradizionale della combinazione di ID e password, oppure utilizzare dispositivi hardware (chiavette USB/dongle), o ancora affidarsi alla biometria (riconoscimento dell’impronta digitale, del viso, della retina etc.).
Le strategie basate su ID e password non sono molto apprezzate perché non è facile, per gli utenti, adottare approcci razionali alla scelta e al cambiamento delle password. Per aggirare il problema sono stati sviluppati processi che costringono gli utenti a rinnovare periodicamente le parole chiave. L’approccio basato su dongle (piccolo dispositivo hardware, costituito solitamente da una chiavetta Usb che contiene una password cifrata, o che genera Otp – one-time-password – alla pressione di un tasto) è più utile quando i diritti di accesso sono da associare più a un ruolo che a un singolo specifico individuo. Dal momento che un dongle può essere perso o rubato, a questo metodo viene spesso associato anche quello che richiede l’inserimento di un ID e di una password. I sistemi biometrici sono i più sicuri e si stanno facendo strada come una soluzione complessiva ai problemi di identificazione.
L’aspetto del controllo degli accessi dello IAM può essere affrontato in diversi modi:
- il primo consiste nel fornire agli utenti di dongle; dal momento che questi necessitano di essere provati e collaudati per ciascuna applicazione, può essere necessario modificare il software delle applicazioni;
- un secondo approccio contempla l’installazione delle applicazioni in una zona sicura del network; le applicazioni sono quindi inserite in “enclavi” all’interno di queste reti. L’accesso a queste enclavi è subordinato all’identificazione degli utenti da parte di un sistema che è in grado di modificare le regole del firewall;
- un terzo modo prevede di aggiungere ai messaggi tra utente e applicazione dei token (non in senso di device hardware, ma di “bonus” di accesso; un esempio sono i cookie) che possono essere verificati dai firewall o dalle stesse applicazioni. Questo metodo permette di mettere in sicurezza zone delle piattaforme cloud o dei data center.
Quali sono le opzioni di IAM più adatte per il cloud
In ambiente cloud gli ultimi due metodi sono preferiti al primo, in quanto il test dei device hardware da parte di ogni singola applicazione può creare problemi di performance; peraltro, nello IAM sul cloud ci si va orientando verso concetti di “virtualizzazione” che forniscono maggiore flessibilità. A ogni persona reale è attribuita la proprietà di un’identità virtuale (identity property) cui è associato direttamente un set di policy o di token che da diritto ad accedere a determinate applicazioni e informazioni. Allo stesso tempo, la stessa identity property è in grado di assegnare all’utente anche uno o più ruoli. A ciascun ruolo corrispondono altri diritti di accesso. L’esperienza insegna che la maggior parte dei diritti di accesso da concedere sono legati più al tipo di lavoro svolto che all’identità della persona. In ambienti stratificati e distribuiti come il cloud, è più semplice gestire uno IAM che prima di tutto identifica l’utente e quindi gestisce l’assegnazione dei diritti sulla base del ruolo o dei ruoli ad esso associati.
