Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Reti di Calcolatori Identity Management in piattaforme di Cloud Computing IaaS Anno Accademico 2013/2014 Candidato: Gianfranco Balzano matr. N46/001059 Indice Identity Management in piattaforme di Cloud Computing IaaS ...........................................................I Indice .............................................................................................................................................. III Introduzione ..................................................................................................................................... 4 Capitolo 1: Cloud Iaas...................................................................................................................... 8 1.1 Perché scegliere il cloud IaaS ................................................................................................ 8 1.2 Il problema dell’Identity Management .................................................................................. 9 1.3 Identity Management as a Service ....................................................................................... 10 1.4 Sicurezza nel Cloud IaaS ..................................................................................................... 11 Capitolo 2: Approcci per l’Authentication and Identity Management .......................................... 12 2.1 Metodologie di controllo degli accessi ................................................................................ 12 2.1.1 RBAC ............................................................................................................................ 12 2.1.2 Vantaggi dell’approccio RBAC .................................................................................... 14 2.1.3 HIBC ............................................................................................................................. 14 Capitolo 3: Shibboleth ................................................................................................................... 18 3.1 Struttura di Shibboleth ......................................................................................................... 18 3.2 Processo di autenticazione ................................................................................................... 20 3.3 Gestione delle autorizzazioni ............................................................................................... 21 Capitolo 4: OpenStack ................................................................................................................... 22 4.1 Metodi di autenticazione ...................................................................................................... 23 4.1.1 Metodi interni ................................................................................................................ 23 4.1.2 Metodi esterni ............................................................................................................... 24 4.2 Metodi di autorizzazione ...................................................................................................... 24 Conclusioni .................................................................................................................................... 26 Bibliografia .................................................................................................................................... 28 Introduzione Il NIST (National Institute of Standards and Technologies) definisce il Cloud Computing [1] come un modello per abilitare un accesso ubiquo, conveniente ed a richiesta, basato sulle reti, ad un pool di risorse computazionali con il minimo sforzo di amministrazione ed interazione con il provider dei servizi. Con gli odierni accessi ad internet a banda larga, gli utenti possono acquisire risorse computazionali, spazi di archiviazione e altri tipi di servizi software senza doversi preoccupare di rotture dei dischi o breakdown dei sistemi. Utenti diversi possono, inoltre, condividere informazioni tra di loro e lavorare insieme semplicemente, come se stessero giocando online tra di loro. Le tipologie di Cloud Computing principali sono le seguenti: Software as a Service (SaaS): permette all’utente di utilizzare le applicazioni del provider dei servizi le quali girano sull’infrastruttura cloud. Tali applicazioni sono accessibili da un’interfaccia utente minimale come un web browser, o tramite un programma apposito. L’utente non ha alcun controllo sull’infrastruttura del cloud sottostante l’applicazione, con la limitata possibilità di poter variare delle specifiche impostazioni di configurazione. Le applicazioni che vengono fornite tramite questa metodologia hanno un’ulteriore livello di sicurezza e di protezione dalla pirateria, in quanto tutto rimane sui server del cloud. Sono inoltre soluzioni molto flessibili, e permettono l’implementazione di servizi on-demand. Esempi di cloud di tipi SaaS sono Google Apps ed iCloud. Platform as a Service (PaaS): permette all’utente di distribuire nell’infrastruttura 4 cloud applicazioni acquisite o create mediante dei linguaggi di programmazione supportati dal provider dei servizi. Anche in questo caso l’utente non ha controllo sulla struttura sottostante dei server cloud sui quali opera, ma ha il controllo sulla sua applicazione e sulla configurazione dell’ambiente che ospita l’applicazione. La soluzione PaaS è quella che presenta più rischi per l’utente. Trasferirsi da un provider ad un altro potrebbe essere un’operazione molto onerosa e se chi dovesse erogare il servizio dovesse cessare l’attività, l’impatto sulle attività dell’utente potrebbero essere devastanti. Un esempio di cloud PaaS è Google App Engine. Infrastructure as a Service (IaaS): con questa tipologia di cloud non si mette al servizio dell’utente un software, ma il controllo di uno o più server e di tutte le risorse computazionali fondamentali (reti, potenza computazionale, spazio di archiviazione), sul quale l’utente può immettere tutti i tipi di software, inclusi interi sistemi operativi. Un esempio di IaaS è EC2/S3 di Amazon. Le principali tipologie di distribuzione dei servizi cloud precedentemente descritte sono tre: Tipologie di distribuzione dei servizi cloud Public Cloud: Quando l’infrastruttura si trova completamente online allora vengono identificate con il termine di Public Cloud. Tra i benefici di questo modello abbiamo l’abbattimento dei costi per l’investimento iniziale e una distribuzione in genere molto più veloce e con maggiore scalabilità. Tuttavia tale approccio presenta un problema di sicurezza e privacy dei dati, in quanto l’utente finale perde il controllo degli stessi affidandoli a terze parti per la gestione. 5 Private Cloud: Quando l’infrastruttura si trova invece completamente in locale si parla di Private Cloud, cioè vi è un uso esclusivo di una singola organizzazione che comprende più consumatori. Il vantaggio nell’utilizzo di tale modello riguarda principalmente la sicurezza e riservatezza poiché solamente gli utenti dell’organizzazione possono accedere al cloud privato. Hybrid Cloud: Il cloud ibrido è costituito da due o più cloud privati o pubblici per offrire i vantaggi di entrambi i modelli, restando però entità uniche dove ognuna mantiene la propria identità. In tale modello di distribuzione l’organizzazione gestisce risorse interne ed altre fornite esternamente. Questo perché generalmente un’azienda può eseguire un’applicazione inizialmente su un cloud privato e affidarsi ad un cloud pubblico durante i picchi di utilizzo. L’effetto combinato della nostra sempre più elevata dipendenza dalla tecnologia e della sua evoluzione ad alto ritmo, rende la sicurezza dei nostri beni digitali un’ardua sfida. Originariamente la sicurezza negli ambiti informatici era fatta tramite delle vere e proprie barriere fisiche intorno ai data-center, ma con l’aumento della connettività e della mobilità dei terminali, è diventato sempre più difficile creare un perimetro sicuro intorno ad essi. L’attenzione si è quindi spostata dalla sicurezza fisica dei datacenter alla protezione dei terminali stessi, tramite firewall, restrizione degli accessi e altre misure. La connettività è andata sempre più aumentando col tempo, quindi l’attenzione della sicurezza si è spostata verso l’enorme numero di applicazioni che dipendono dalla rete, portando quindi i meccanismi di difesa allo strato applicativo. L’ultima “migrazione” avvenuta in termini temporali è stata quella verso il cloud, e, come tutte le precedenti, anch’essa ha richiesto una riconsiderazione dei metodi di sicurezza, portando anche alla nascita di nuove aree di studio della sicurezza informatica, come quella dei workgroup virtuali (Skype e Google Hangouts solo per citare i più famosi). [11] Provvedere alla sicurezza dei dati nei cloud pubblici e privati è relativamente semplice, mentre più difficile risulta essere la sicurezza per il cloud di tipo Hybrid. Di solito per i primi due tipi di cloud vi è un solo provider dei servizi, da cui discende la necessità di una 6 sola autenticazione per l’accesso alle risorse dei server, mentre per l’Hybrid cloud, i provider sono solitamente molteplici, ciò comporta un problema specialmente per la distribuzione delle chiavi d’accesso e per la mutua autenticazione ai vari sistemi. Una delle soluzioni a questo problema è quella di creare una gestione federata dell’identità digitale, dando ad ogni utente un identificativo univoco con il quale possa accedere ai differenti servizi offerti dai molteplici provider di servizi cloud. Varie soluzioni sono state implementate durante gli anni, in questa sede verranno analizzate due di queste: Shibboleth; Open Stack; 7 Capitolo 1: Cloud Iaas Il principale vantaggio dell’uso del cloud IaaS è quella di poter sfruttare tutta la potenza elaborative dei server presenti nel cloud anche da apparecchi poco performanti come cellulari o computer portatili. [2] Questa potenza di calcolo non è fissa, ossia non viene bloccata anche quando l’utente non ne sta facendo uso, ma viene predisposta on-demand, quando il cliente ha bisogno di più risorse, queste gli vengono assegnate, tali risorse saranno poi liberate quando l’utente ha terminato il loro utilizzo e non ne ha più bisogno. 1.1 Perché scegliere il cloud IaaS Il cloud IaaS è il principale alleato delle piccole aziende che sono appena nate oppure sono ancora nello stato embrionale. Esso è nato proprio per quelle realtà dove c’è bisogno di una grande potenza elaborativa, ma non si hanno i fondi necessari per realizzare un’infrastruttura di calcolo in locale. Vista la rapida nascita di sempre nuove aziende e start-up nel settore informatico, il cloud IaaS è la tipologia di cloud in maggior ascesa tra tutte le altre. Si stima infatti che nel 2016 i guadagni relativi alle infrastrutture IaaS sarà di circa 207 miliardi di dollari. La grande crescita del settore cloud porta però con sé alcuni grandi problemi, come, ad esempio, la protezione dei dati personali salvati sui server, oppure i privilegi di accesso a determinate aree di memoria del cloud. Come fare, in parole povere, a sapere chi, in un determinato istante, sta accedendo ai miei dati? Ecco quindi che si presenta il problema dell’Identity Management. 8 1.2 Il problema dell’Identity Management L’identità digitale è la “rappresentazione di un’entità (o di un gruppo di entità) nella forma di uno o più elementi di informazione (attributi) che danno la possibilità all’entità di essere riconosciuta all’interno di un determinato contesto”. [4] Nell’ambito della sicurezza informatica, l’Identity Management è uno dei campi più importanti, se non fondamentali, per la salvaguardia dei dati presenti nella rete. L’utente provvede a creare una propria identità nell’ambito cloud ogni qualvolta esso utilizza un nuovo servizio cloud, di solito questa operazione avviene mediante il riempimento di un documento online al quale vengono assegnate le proprie informazioni personali. Queste informazioni hanno bisogno di essere protette, per prevenire un eventuale furto d’identità. Le sfide principali alla sicurezza dei dati conservati nel cloud sono: Autenticazione: bisogna sempre sapere chi si sta connettendo in ogni momento all’infrastruttura cloud, ma, al giorno d’oggi, questo non può più essere assicurato semplicemente dal binomio username-password, c’è bisogno di implementare vari strati di certificati e di aumentare gradatamente la complessità della criptazione; Protezione della privacy: i dati devono essere conservati in luoghi dove il provider dei servizi ha piena giurisdizione su di essi; Un servizio che fornisce l’Identity Management è fatto di protocolli e componenti software che assicurano le identità degli individui attraverso tutto il ciclo di vita delle loro identità. Il servizio di Identity Management può essere di due tipologie: La prima, mostrata in Figura 1 è la IDM for a Cloud, dove il sistema di Identity Management è esterno all’infrastruttura dei server. Così facendo viene utilizzato un servizio pre-esistente di IdM che fornisce i propri servizi al provider del Figura 1: IDM for a Cloud cloud e che sicuramente può contare su di una forte esperienza nel campo dell’autenticazione e della criptazione. 9 La seconda, mostrata in Figura 2, è la IDM in a Cloud, dove il sistema di IdM viene implementato dallo stesso provider dei servizi cloud, che porta ad una riduzione dei costi relativi alle soluzioni di IdM in quanto vengono Figura 2: IDM in a Cloud sfruttate solamente quelle richieste e non tutte quelle offerte da un provider esterno. La prima tipologia di gestione crea un ulteriore servizio denominato Identity Management as a Service (IDaaS) [3], il quale è capace di fornire tutti i servizi di un IAM a tutti i clienti che ne hanno bisogno. E’ una tipologia di SaaS orientata prettamente alla gestione delle identità. 1.3 Identity Management as a Service Il fulcro delle soluzioni IDaaS è un’applicazione basata sul cloud che unisce tutte le funzionalità fondamentali del Identity Management, le quali devono essere assistite da un “ponte d’identità” che permette la creazione di un canale tra la piattaforma IDaaS ed il sistema del cliente affinché possano essere implementate tutte le impostazioni di sicurezza. Una buona soluzione IDaaS deve avere, almeno, i seguenti attributi: Sicurezza: deve essere basata sugli ultimi e più potenti standard in fatto di sicurezza cosicché possa essere garantita un’architettura sicura, ubiqua e basata sul cloud; Basata sul Cloud: deve poter fornire ai clienti tutti i benefici del cloud computing di tipo SaaS; Identità unificata: deve fornire il supporto per tutte le possibili richieste di specifiche di controllo dell’identità da parte del cliente; Con il continuo affermarsi sul mercato delle tecnologie cloud e delle aziende che ne fanno uso, oramai l’utilizzo di servizi di tipo IDaaS per la fruizione di servizi di Identity Management è predominante a dispetto dei semplici servizi di IAM sul luogo. 10 1.4 Sicurezza nel Cloud IaaS Il Cloud Computing ha dalla sua parte molti vantaggi, tra i quali riduzione dei costi e condivisione delle risorse, vantaggi che sono apprezzati principalmente dalle aziende nascenti. Ma la sicurezza insita nell’avere i propri dati conservati in locale viene persa proprio nella concezione che si ha di Cloud. Le responsabilità nell’ambito della sicurezza per il cloud IaaS vengono divise tra il provider ed il cliente. Ad esempio, Il servizio di Amazon Elastic Compute Cloud (EC2) afferma che [12] la responsabilità di Amazon nei confronti della sicurezza riguardano solamente la sicurezza fisica, ambientale e sulla virtualizzazione. Viene lasciata al cliente la responsabilità della sicurezza del lato informatico, come il SO installato sulla macchina oppure le applicazioni che vi vengono fatte girare sopra. Le principali minacce alla sicurezza dei dati presenti sui cloud IaaS sono i protocolli di sicurezza delle infrastrutture sulle quali i dati viaggeranno per arrivare dai server agli utenti. Si possono implementare le più recenti politiche di sicurezza sui server, ma saranno del tutto inutili poiché i dati saranno comunque trasmessi sulla tecnologia internet sottostante. Possiamo quindi riassumere che le principali minacce che si possono ritrovare nella trasmissione dei dati tramite la rete affliggono anche il cloud. 11 Capitolo 2: Approcci per l’Authentication and Identity Management I sistemi di Authentication & Identity Management si dividono principalmente in due macro-classi: Soluzioni User-centered: dove gli identificativi e gli attributi aiutano ad identificare e definire un utente, questa soluzione è adottata poiché ogni utente può accedere ai servizi cloud da differenti postazioni ogni volta e quindi i dati devono essere trasferiti in maniera sicura ad ogni nuovo accesso. Soluzioni Federate: possono essere comparate con l’identità centralizzata che si utilizza all’interno di reti aziendali chiuse. Le soluzioni federate sono adottate per risolvere il problema degli utenti che vogliono accedere a reti esterne a quella aziendale, o quello di utenti esterni che vogliono accedere alla rete. Queste soluzioni preservano la privacy tramite delle tecniche di sicurezza dette zero-knowledge proof-based che permettono, tramite una singola prova interattiva di provare la conoscenza di molteplici attributi d’identità senza la necessità di mostrare queste ultime in chiaro. Queste soluzioni hanno, però, bisogno di essere integrate con delle soluzioni di Identity Management di livello enterprise. 2.1 Metodologie di controllo degli accessi 2.1.1 RBAC [10] Uno dei principali sistemi di controllo degli accessi di tipo User-centered è il Role-based Access Control (RBAC). Si basa sul concetto che gli utenti finali non sono i proprietari delle risorse a cui accedono, 12 Figura 3: Struttura RBAC ma gli è soltanto concesso il permesso di visualizzarle. Il framework RBAC permette agli amministratori di rete di regolamentare chi può fare quale azione, quando, da quale punto di accesso e controllare anche ulteriori circostanze. Il perno principale attorno al quale ruota questo tipo di controllo degli accessi è la presenza dei ruoli. Un ruolo può essere visto come un insieme di regole, ciascun ruolo sarà poi assegnato agli utenti, a seconda dei vari privilegi che il suddetto utente può ricevere. E’ stato provato che RBAC può supportare diversi principi e politiche di sicurezza utilizzate da aziende o società che lavorano con informazioni sensibili. Le tre regole principali per il RBAC sono: 1. Assegnazione dei ruoli: un utente può effettuare un’azione solamente se gli è stato assegnato un ruolo; 2. Autorizzazione dei ruoli: un utente può possedere solo un ruolo per il quale è stato autorizzato; 3. Autorizzazione dei permessi: un utente può esercitare un permesso solo se il suddetto permesso è autorizzato per il ruolo dell’utente. Insieme alle regole 1 e 2, questa regola si assicura che l’utente possa esercitare solo i permessi per il quale il suo ruolo risulti autorizzato; 13 2.1.2 Vantaggi dell’approccio RBAC Tra i vari vantaggi della soluzione di tipo RBAC per il controllo degli accessi ci sono: la semplicità sia d’utilizzo che di implementazione, la flessibilità nel riuscire a risolvere richieste che possono cambiare dinamicamente ed un’efficiente maneggevolezza dei privilegi, l’estensione ad altri tipi di controlli, come, ad esempio, accesso vincolato alla posizione (Location-based RBAC), oppure all’orario (Temporal RBAC). Un ulteriore vantaggio è il supporto che dà agli amministratori di rete. Con il framework RBAC è possibile aggiungere e modificare i privilegi concessi ad un utente semplicemente rimuovendolo da un ruolo e assegnandone un altro. Inoltre consente di avere una visuale di controllo degli accessi al livello di astrazione col quale sono di solito condotti i lavori, tramite la regolazione statica e dinamica de i privilegi degli utenti con gerarchie, relazioni e quant’altro, proprio come all’interno di un gruppo di lavoro esistono dei sottoposti e dei supervisori. 2.1.3 HIBC [5] [6] L’HIBC (Hierarchical Identity-based cryptography) è una soluzione di gestione delle identità di tipo federato che sta prendendo molto piede negli ultimi anni. L’idea da cui è nata questa tipologia di criptografia è che gli utenti non utilizzano un solo servizio di cloud per tutta la vita, ma, contando soprattutto la crescente presenza di modelli lavorativi basati sul cloud, ne utilizza diversi, ed avrà quindi bisogno di molteplici “identità”, una per ogni provider di servizi. Sicuramente questo non è un approccio user-friendly. L’idea si basa sul modello di crittografia basata sull’identità proposta per la prima volta da Shamir nel 1984, ma il primo approccio efficiente è stato sviluppato da Boneh, Franklin e Cocks nel 2001. Prima di arrivare al modello gerarchico, spieghiamo brevemente come si comporta il modello su cui si basa. La crittografia basata sull’identità è una specie di schema a chiave pubblica, che può essere usato per lo scambio di messaggi tra due parti ed effettivamente verificare la firma di ognuno. La chiave pubblica non è una stringa casuale di bit, ma è l’identità dell’utente stesso 14 che viene usata per la criptazione e la verifica della firma. Un primo vantaggio di questo approccio è quello della criptazione e decriptazione che può avvenire anche offline, senza essere per forza connessi al sistema generatore delle chiavi. Nell’approccio di Boneh e Franklin, sono stati definiti quattro passi principali dell’algoritmo per una completa criptazione basata sull’identità: 1. Setup: Il generatore di chiavi pubbliche crea una chiave K ed i parametri di sistema P. La chiave viene tenuta privata ed è usata per creare le chiavi private degli utenti, mentre i parametri sono resi pubblici cosicché gli utenti possano generare le proprie chiavi pubbliche con le loro identità; 2. Estrazione: Quando un utente richiede la propria chiave privata, il generatore usa l’identità dell’utente, i parametri P e la chiave K per la generazione della chiave; 3. Criptazione: Quando un utente vuole criptare un messaggio per inviarlo ad un altro utente, utilizza i parametri P, l’identità del ricevitore ed il messaggio per creare il testo cifrato; 4. Decriptazione: Al momento della ricezione di un testo cifrato, l’utente può utilizzare i parametri P e la chiave privata ricevuta dal generatore nella fase di Setup per decriptarlo. Il generatore di chiavi ha, quindi, sia il compito di generare le chiavi private per tutti gli utenti, sia quello di verificare le identità e di stabilire i canali di comunicazione sicuri. Si nota facilmente come questo, in una rete molto ampia, possa essere un lavoro molto pesante. Nel HIBC non esiste un singolo generatore di chiavi, ma vi è una struttura gerarchica dei generatori. Un primo generatore è chiamato generatore root, il quale genera e distribuisce le chiavi ai generatori di dominio, i quali hanno il compito di ridistribuirle agli utenti. Una schematizzazione molto simile ai server DNS. Questa tipologia di distribuzione delle chiavi private aggiunge anche un ulteriore strato di sicurezza, in quanto l’autenticazione degli utenti e la distribuzione delle chiavi private può essere fatta anche localmente, senza nessuno scambio di messaggi verso l’esterno della rete. L’algoritmo di criptazione di Boneh e Franklin viene così modificato: 15 1. Root Setup: Il generatore root crea i parametri pubblici ed una chiave di root segreta. La chiave sarà usata per la generazione delle chiavi private da parte dei generatori di più basso livello, mentre i parametri sono usati per la generazione di chiavi pubbliche per i generatori di livello inferiore e degli utenti; 2. Setup di livello inferiore: I generatori prendono i parametri di root e generano le chiavi segrete per il proprio dominio. Queste chiavi di dominio saranno utilizzate per generare le chiavi private degli utenti all’interno del dominio; 3. Estrazione: Quando un utente di un dato livello t richiede la sua chiave privata dal generatore di livello superiore i (1 ≤ i ≤ t), il generatore utilizza l’identità dell’utente, i parametri di sistema e la sua chiave privata per generare la chiave dell’utente; 4. Criptazione: Il messaggio cifrato viene creato a partire dai parametri di sistema, l’identità del ricevente ed il corpo del messaggio; 5. Decriptazione: Un messaggio cifrato può essere decriptato mediante i parametri di sistema e la chiave privata del ricevente; 6. Firma e verifica: L’utente può creare un propria firma digitale tramite i parametri di sistema, la propria chiave privata ed il messaggio. Tale firma viene inviata insieme al messaggio cifrato. Il ricevente può verificare la firma utilizzando i parametri, il messaggio e l’identità dell’utente che ha inviato il messaggio. Con la possibilità di ogni utente di poter verificare l’autenticità dei messaggi scambiati tramite l’utilizzo della chiave privata del mittente e la propria chiave pubblica, si semplifica anche la costruzione dei suddetti messaggi. Il protocollo utilizzato per lo scambio di messaggi è SOAP (Simple Object Access Protocol) e, prima dell’avvento di HIBC, l’header di un singolo messaggio conteneva informazioni circa il metodo ed il valore della firma, le informazioni sul messaggio e altre informazioni su come interpretarlo. Con l’utilizzo di HIBC nell’header viene solo riportata la chiave privata del mittente così facendo, la firma può essere verificata dal destinatario mediante la relativa chiave pubblica. Con l’assunzione della distribuzione gerarchica dei generatori si ovvia al problema del 16 probabile Single Point of Failure insito dall’unico generatore presente nel modello descritto precedentemente. Purtroppo questo nuovo modello non può ovviare un problema presente anche prima: i generatori possono decriptare ogni singolo messaggio degli utenti presenti all’interno di un dominio, c’è quindi bisogno che i generatori siano altamente affidabili. 2.1.4 Vantaggi dell’approccio HIBC Avere un database centralizzato delle identità è utile, in quanto può essere settato una sola volta nella giusta maniera e poi utilizzato in più posti. Questo comporta una sfida maggiore per la protezione di un gran numero di identità conservate in un unico luogo, ma è uno scotto che si può pagare volentieri in cambio del maggior controllo e del minor numero di database delle identità disseminati all’interno della rete. Inoltre l’utente non avrà più il bisogno di ricordare le credenziali per ogni singolo servizio al quale è iscritto, ma gli sarà possibile identificarsi una sola volta e poi ci penserà il database centrale ad identificarlo di volta in volta per tutti i servizi ai quali vuole accedere. Una soluzione federata delle identità consente inoltre un sostanziale risparmio sia di risorse, inteso come traffico dati, che di tempo. Di risorse in quanto si riducono sensibilmente i dati inviati dagli utenti a causa delle svariate password dimenticate e quindi tutti i dati prodotti dai processi di recupero e modifica delle password. Il tempo risparmiato è quello speso ad amministrare l’identità di una stessa persona su piattaforme diverse, che ora possono confluire in una sola identità utilizzata da più piattaforme. 17 Capitolo 3: Shibboleth Shibboleth è un progetto open-source che permette l’autenticazione e l’autorizzazione degli utenti su determinate piattaforme, basato su SAML (Security Assertion Markup Language, uno standard informatico per lo scambio di dati tra Identity Provider), utilizza il concetto di identità federata. [7] Fornisce un servizio di Single Sign-On (SSO) che permette ad un utente di autenticarsi una sola volta e può riutilizzare la stessa autenticazione per accedere a varie applicazioni, senza doversi autenticare ogni volta. 3.1 Struttura di Shibboleth E’ formato principalmente da due parti: Identity Provider (IdP); Service Provider (SP); 3.1.1 Identity Provider L’IdP è l’elemento responsabile per l’autenticazione degli utenti e controlla le loro credenziali e i loro attributi. E’ formato da quattro componenti fondamentali: Handle Service (HS): autentica gli utenti con il meccanismo di autenticazione e consegna un “handle token” (praticamente un contenitore delle credenziali dell’utente) all’utente. Il meccanismo di autenticazione non è fisso, ma ogni 18 organizzazione può scegliere il proprio; Attribute Authority (AA): L’AA gestisce le richieste per gli attributi del SP, applicando le regole di privacy sul rilascio dei suddetti attributi. Permette agli utenti di specificare chi può accedere a tali attributi. Come sopra ogni organizzazione è libera di settare il Directory Service a proprio piacimento; Directory Service (esterno a Shibboleth): luogo dove sono conservati gli attributi degli utenti; Meccanismo di autenticazione (esterno a Shibboleth): permette agli utenti di autenticarsi con il servizio tramite una coppia nome utente/password; 3.1.2 Service Provider Il SP è il luogo dove sono conservate tutte le risorse a cui l’utente accede. Rinforza il controllo degli accessi alle risorse basandosi sulle informazioni inviate dall’IdP. Un singolo SP può essere composto da molte applicazioni, ma sarà sempre trattato come una singola entità da parte dell’IdP. I suoi componenti principali sono tre: Assertion Consumer Service (ACS): responsabile della ricezione dei messaggi da parte dell’IdP per stabilire un ambiente di lavoro sicuro; Attribute Requester (AR): responsabile di ottenere e passare gli attributi dell’utente al RM; Resource Manager (RM): intercetta le richieste per le risorse e prende le decisioni sul controllo degli accessi basandosi sugli attributi dell’utente; Vi è anche una struttura opzionale all’interno di Shibboleth chiamata WAYF (“Where Are You From”) che permette di creare un’associazione tra l’utente e l’organizzazione. Quando l’utente tenta di accedere ad una risorsa, viene diretto verso un’interfaccia dove gli verrà richiesto a quale istituzione egli appartiene. Dopo aver effettuato questa scelta, l’utente è re-indirizzato per iniziare il vero e proprio processo di autenticazione. 19 3.2 Processo di autenticazione Figura 4: Processo di autenticazione di Shibboleth Come si può notare dall’immagine, il processo di autenticazione dell’utente da parte di Shibboleth è composto in tutto da 15 passi. All’inizio (1) l’utente richiede l’accesso ad una risorsa al SP, il quale lo reindirizza al WAYF (2). Qui avvengono le operazioni prima descritte (3). L’utente inserisce poi i suoi dati relativi all’identità, i quali vengono gestiti dall’HS, il quale autentica in seguito l’utente (58). La richiesta di autenticazione viene inviata poi all’ACS ed al AA. La richiesta inviata all’ACS viene poi gestita dall’AR. Se tutto risulta essere in regola, viene stabilita una sessione di lavoro (9,10). L’AR richiede poi gli attributi dell’utente all’IdP, il quale controlla se questi ultimi possono essere rilasciati. Se questi ultimi possono essere rilasciati, l’AA risponde alla richiesta dell’AR con questi ultimi (11-13). L’SP riceve gli attributi tramite l’AR e li passa all’RM, il quale carica le risorse dalla memoria e le presenta all’utente (14,15). 20 3.3 Gestione delle autorizzazioni Shibboleth utilizza un sistema di gestione delle autorizzazioni di tipo distribuito e federato basato sull’identità dell’utente, un’implementazione quindi di HIBC. Figura 5: Layer AAI Si pone come una “Authentication and Authorization Infrastructure” [8], quindi come un layer aggiuntivo che gestisce le autorizzazioni di un determinato utente, il quale non avrà bisogno di chiavi diverse per poter accedere a diversi servizi, ma basterà essere riconosciuto da Shibboleth, tramite il processo di autenticazione prima descritto, e potrà accedere liberamente a tutte le risorse senza dover autenticarsi ogni volta. In conclusione, Shibboleth offre un’effettiva soluzione per un accesso alle risorse Web da parte di più organizzazioni. L’utilizzo principale viene fatto per fornire accesso a servizi esterni ai campus da parte di studenti universitari (uno dei casi più famosi è stato quello della Penn State University che, tramite l’uso di Shibboleth, ha fornito ai propri studenti la capacità di accedere al famoso servizio di streaming musicale Napster, nel 1994), poiché Shibboleth fornisce un servizio che risponde a molte richieste fatte da parte dei provider universitari, come gli standard per la gestione delle identità ed il controllo della privacy, nonché le autorizzazioni basate sugli attributi. 21 Capitolo 4: OpenStack OpenStack fornisce un’architettura modulare che permette di offrire un set di funzionalità basilari che permettono scalabilità ed elasticità. I componenti principali sono: Figura 6: Struttura OpenStack Dashboard (Horizon); Compute (Nova); Block Storage (Cinder); Networking (Quantum); Image Service (Glance); Object Store (Swift); Identity Service (Keystone); Tutti i moduli hanno un proprio nome rappresentativo, ovviamente quello che andremo ad analizzare qui è il blocco di Identity Service, Keystone. 22 Quest’ultimo è un servizio condiviso che fornisce autenticazione e servizi di autorizzazione attraverso tutta l’architettura cloud. In questo modulo sono presenti delle “prese” [9] alle quali possono essere aggiunti, espandendo i servizi offerti, dei componenti secondari. Keystone propone molti metodi di autenticazione, spaziando dai semplici nome utente e password, a LDAP (Lightweight Directory Access Protocol, un protocollo standard per l’interrogazione e la modifica dei servizi di directory), sino ad arrivare a metodi di autenticazione esterni al sistema come scanner biometrici oppure lettori ottici di card. Quando avviene l’autenticazione, il sistema fornisce un token all’utente che verrà usato successivamente per la richiesta dei servizi. Il lifetime di default di un token è di un’ora, anche se nelle prime versioni di OpenStack era di un giorno intero. Ovviamente tale valore può essere modificato a seconda delle necessità, poiché alcuni servizi di cloud computing potrebbero cessare le attività iniziate se il token scade durante l’esecuzione dei lavori. 4.1 Metodi di autenticazione Come detto precedentemente, Keystone ha delle “prese” a cui possono essere aggiunti dei servizi esterni, dividiamo quindi i metodi di autenticazione tra quelli che fanno parte del “core” di Keystone e quelli esterni più importanti che possono essere aggiunti successivamente. 4.1.1 Metodi interni Keystone può conservare le credenziali degli utenti in un Database, il quale può essere implementato via SQL, oppure via LDAP. Tale DB può trovarsi anche fisicamente separato da quelli usati da OpenStack per altre operazioni per evitare rischi di compromissione delle credenziali. L’Identity Service non supporta molte implementazioni sulla sicurezza nel caso di utilizzo di soli username e password, non ha politiche sulla forza della password, oppure sugli attacchi a forza bruta. Le organizzazioni che sono interessate ad implementare tali servizi, 23 sono invitate a considerare una delle estensioni di Keystone. 4.1.2 Metodi esterni La causa principale dell’uso di metodi esterni a Keystone, è quella della non compatibilità dei metodi interni con degli esistenti metodi di autenticazione. Le organizzazioni che vogliono poi aumentare la propria sicurezza possono implementare dei servizi esterni che comprendono dei metodi di autenticazione più sofisticati, in quanto, anche se la password è il metodo di autenticazione più comune, è anche quello che può essere compromesso in più modi. Le principali aggiunte che vengono fatte a Keystone sono le seguenti: Politiche di rafforzamento delle password: viene richiesto che la password sia conforme a delle norme di sicurezza come lunghezza, diversificazione dei caratteri, ecc.; Autenticazione a più fattori: viene richiesto all’utente qualcosa che solo lui ha, come una certificato X.509 oppure uno smartphone su cui ricevere un messaggio di testo, e qualcosa che solo lui sa, come una password; Protocollo Kerberos: inventato dal MIT, è un protocollo che permette l’autenticazione mediante la crittografia, facendo sì che due utenti possano comunicare su di una rete insicura proteggendo le proprie identità e dati tramite crittografia. 4.2 Metodi di autorizzazione OpenStack utilizza un metodo di autorizzazione di accesso ai contenuti basato sui ruoli, quindi riconducibile alla tipologia RBAC descritta nel secondo capitolo di questo elaborato. Keystone utilizza un middleware il quale opera come “vigilante” e controlla che le politiche di accesso a determinate risorse siano coerenti con i permessi posseduti dall’utente che richiede la risorsa. Il middleware permette un controllo degli accessi alle risorse molto granulare, infatti solo 24 l’amministratore può creare nuovi utenti e può avere accesso alle funzioni di gestione. Le politiche di controllo degli accessi sono da documentare ed implementare prima della configurazione di tutti i ruoli, gruppi ed utenti. Tali politiche devono essere consistenti con le regolazioni legali richieste dalle organizzazioni coinvolte e devono includere anche la possibilità di creazione e modifica sia degli account che dei privilegi legati ad essi. La documentazione ufficiale di OpenStack afferma che bisogna definire, per ogni servizio, un utente amministratore di tale servizio, al quale viene concessa l’autorizzazione di autenticare i vari utenti che accedono a tale risorsa. Ovviamente per aumentare la sicurezza ed evitare accessi non autorizzati sono presenti tutte le varie aggiunte (non abilitate di default) che possono essere attivate per aumentare la sicurezza, come, ad esempio, la possibilità di utilizzare una connessione SSL tra l’utente e la risorsa. 4.3 Futuro di OpenStack Al momento, OpenStack propone usa sua versione di gestione delle identità e dei privilegi basata sui ruoli, ma è in lavorazione una API da poter aggiungere, tramite metodo esterno, al modulo Keystone, la quale permette l’implementazione della gestione federata delle identità. L’implementazione federata delle identità in OpenStack prevede due metodologie di attuazione [13] : una che utilizza Keystone non più come un IdP, ma come un Service Provider, le identità saranno quindi gestite da un IdP esterno (la Wiki di OpenStack suggerisce l’uso di Shibboleth in questo caso), il quale è responsabile per l’autenticazione degli utenti e comunica il risultato di tale operazione a Keystone, il quale mappa l’utente che ha ottenuto l’autenticazione con i permessi appartenenti al gruppo dell’utente. La seconda implementazione prevede di continuare l’utilizzo di Keystone come IdP, ma tale feature è ancora in fase di beta-testing, infatti non è supportata dalla versione attuale di OpenStack (Juno), ma dovrebbe essere supportata, seppur non con piena compatibilità, nella prossima, Kilo. 25 Conclusioni In questo elaborato è stata affrontata una trattazione su un tema critico dell’informatica odierna: la sicurezza dei dati e l’identificazione degli utenti. E’ stata fatta una panoramica generale sugli ambienti di lavoro e di sviluppo dove tendono oramai tutte le aziende che lavorano in questo campo, ossia il Cloud, in particolare della tipologia IaaS, e come siano gestite le misure di sicurezza al suo interno. Sono stati analizzate le due metodologie più comuni di implementazione: una basata sui ruoli (RABC) ed una di tipo federato (HIBC). Sono stati poi portati esempi pratici di implementazione di queste due tipologie di Identity Management: per RBAC è stato presentato OpenStack con il suo modulo di gestione delle identità, Keystone, e Shibboleth con il suo layer “Authentication and Authorization Infrastructure” per HIBC. Visto lo sviluppo esponenziale che le piattaforme di Cloud Computing stanno avendo in questi ultimi anni, si capisce sempre di più come il modello di sviluppo RBAC sta venendo progressivamente rimpiazzato dalle soluzioni federate, anche se continuerà ad essere utilizzato all’interno di network privati per gestire i permessi dei singoli utenti, ma il login singolo fornito dal modello HIBC e la maggiore sicurezza offerta sono solo alcune delle qualità che stanno permettendo a questo modello di diventare lo standard di fatto nell’ambito delle reti Cloud. Da notare, infatti, che anche OpenStack, nato come modello implementativo di RBAC, stia migrando sempre di più verso soluzioni federate della gestione delle identità, sviluppando sempre più API e plugin per il suo modulo di gestione delle identità, Keystone. Inizialmente 26 questa migrazione verso la gestione federata è avvenuta appoggiandosi a provider preesistenti, quali Shibboleth, ma in futuro OpenStack consentirà di implementare entrambe le modalità di autenticazione, rendendolo di fatto una soluzione plasmabile attorno a tutte le possibili necessità e richieste nell’ambito della sicurezza informatica. 27 Bibliografia [1] Peter Mell, Timothy Grance: The NIST Definition of Cloud Computing, http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf [2] S. Subashini, V. Kavitha: A survey on secuirty issues in service delivery models of cloud computing, http://ants.mju.ac.kr/2013Fall/survey%20security%20issues%20cloud%20computing.pdf [3] Hitachi ID Systems, Inc.: Identity Management as a Service. [4] Elisa Bertino, Federica Paci, Rodolfo Ferrini, Ning Shang: Privacy-preserving Digital Identity Management for Cloud Computing, ftp://131.107.65.22/pub/debull/A09mar/bertino.pdf [5] Liang Yan, Chunming Rong, Gansen Zhao: Strengthen Cloud Computing Secuirty with Federal Identity Management Using Hierarchical Identity-Based Cryptography, http://csnotes.upm.edu.my/kelasmaya/pgkm20910.nsf/0/d32aeb6f3caeec4b482578480023 ec66/$FILE/Strengthen%20Cloud%20Computing%20Security%20with%20Federal.pdf [6] Craig Gentry, Alice Silverberg: Hierarchical ID-Based Cryptography, http://vanilla47.com/PDFs/Cryptography/Cryptography/Hierarchical_IDBased_Cryptography.pdf [7] Marcos A.P. Leandro, Tiago J. Nascimento, Daniel R. dos Santos, Carla M. Westphall, Carlos B. Westphall: Multi-Tenancy Authorization System with Federated Identity for Cloud-Based Environments Using Shibboleth, http://www.researchgate.net/profile/Carlos_Westphall/publication/257200931_MultiTenancy_Authorization_System_with_Federated_Identity_for_CloudBased_Environments_Using_Shibboleth/links/0deec524a20bfcce4c000000 [8] Jan Du Caju, Authentication and Authorization Infrastructure – Shibboleth, 28 https://shib.kuleuven.be/docs/AAI-Shibboleth-BelnetUserDay-27oct2005-v.1.1.pdf [9] OpenStack Security Guide, Chapter 6: Identity, http://docs.openstack.org/security- guide/content/identity.html [10] David F.Ferraiolo, Janet A.Cugini, D. Richard Kuhn: Role_Based Access Control (RBAC): Features and Motivations, http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-cugini-kuhn-95.pdf [11] Brian Hay, Kara Nance, Matt Bishop: Storm Clouds Rising: Security Challenges for IaaS Cloud Computing, http://nob.cs.ucdavis.edu/bishop/papers/2011-hicss-1/iaas.pdf [12] Amazon Web Services Security Center, http://aws.amazon.com/security/ [13] OpenStack Wiki: Configuring Keystone for http://docs.openstack.org/developer/keystone/configure_federation.html 29 Federation,
© Copyright 2024 Paperzz
