PARTE SECONDA SICUREZZA E CONTROLLO DEI SERVIZI IN CLOUD
2. Gestione della sicurezza nel Cloud computing
2.5 Gestione delle identità digitali e modelli di autenticazione
Nel contesto digitale e online l‟identità è definita come un insieme di in- formazioni corredate da attributi, che descrivono in modo univoco una per- sona o una cosa (a volte riferita come soggetto o entità), che fa richiesta di accedere a delle risorse e che contiene anche informazioni sulle relazioni
51 D. BREDAHL , Federation is the Future of the Cloud, in “Data Center Knowledge”,
2012,http://www.datacenterknowledge.com/archives/2012/09/17/federation-is-the-future-of-
the-cloud/
52 R. BUYYA, R. RANJAN, R. N. CALHEIROS, InterCloud: Utility-Oriented Federation of
Cloud Computing Environments for Scaling of Application Services, in Algorithms and Archi-
tectures for Parallel Processing - Lecture Notes in Computer Science, 2010, vol. 6081, pp 13-31
53Eucalyptus 3 and Amazon Web Services (AWS), in “eucalyptus.com”, 2012,
http://www.eucalyptus.com/sites/all/files/ds-eucalyptus-aws.en.pdf
54 Y. DEMCHENKO, C. NGO, C. DE LAAT, J. GARCIA-ESPIN, S. FIGUEROLA, J. RO-
DRIGUEZ, L. CONTRERAS, G. LANDI, N. CIULLI, Intercloud Architecture Framework for
63 con altre entità55. Ogni attività online comporta l‟interazione con un provider di servizi. Tali interazioni richiedono tipicamente che venga associata una identità digitale al soggetto e queste identità sono, per la maggior parte, me- morizzate e gestite da ciascun provider56. Occorre quindi un‟adeguata politi- ca di gestione delle identità e degli accessi (Identity and Access
Management), che descriva per ciascuna identità individuale come procede-
re all‟identificazione del soggetto, alla sua autenticazione e autorizzazione. Il processo di gestione prevede in generale che ci siano Identity Provider (IdP) che gestiscono le identità, Service Provider (SP), ovvero i fornitori di servizio per le funzionalità applicative (per esempio un provider SaaS), e gli utenti.57 Nel caso delle entità persona, ciascun utente del cloud è associato ad una persona e, come osservato, sarà caratterizzato da un‟identità e da una collezione di attributi che ne definiscono le proprietà (nel caso più semplice almeno due, UserID e password).58
Si hanno tre modelli di gestione delle identità: isolato; centralizzato; di- stribuito.
Il modello isolato è il più diffuso poiché è quello originario, dove cia- scun utente possiede delle credenziali per ciascuno dei servizi a cui è regi- strato su diversi SP e ciascun servizio accede ad un archivio indipendente di credenziali gestito presso lo stesso SP di appartenenza. Le relazioni di fidu- cia con gli utenti descrivono come ciascun provider assicuri registrazione, meccanismi di autenticazione e gestione della singola identità, mentre l‟utente deve garantirsi la gestione completa di tutte le identità dei vari ser- vizi.59
55 P. J. WINDLEY, Digital Identity, O'Reilly Media, Inc, 2008, pp. 8-9 56
I. THOMAS, C. MEINEL, An Identity Provider to manage Reliable Digital Identities for
SOA and the Web, in IDTRUST '10 Proceedings of the 9th Symposium on Identity and Trust on
the Internet, 2010, pp. 26-36
57
R. L. MORGAN, S. CANTOR, S. CARMODY, W. HOEHN, K. KLINGENSTEIN, Fede-
rated Security:The Shibboleth Approach, 2004, in EDUCAUSE Quarterly, vol. 27( 4), pp. 12-
17
58 T. J. SMEDINGHOFF, Introduction to Online Identity Management, in “Uncitral”, 2011,
http://www.uncitral.org/pdf/english/colloquia/EC/Smedinghoff_Paper_Introduction_to_Identiy _Management.pdf
59 A. JØSANG, J. FABRE, B. HAY, J. DALZIEL, S. POPE, Trust requirements in identity
management, in Proceedings of the 2005 Australasian workshop on Grid computing and e-
64 Appare evidente come, nella situazione classica, a ciascuna entità possa- no quindi essere associate identità multiple su diversi SP. Questo comporta per l‟entità persona, per l‟organizzazione dove essa è impiegata e per il pro- vider, una serie di oneri.
L‟utente ha così troppi set di credenziali da ricordare. In secondo luogo, occorre implementare un archivio protetto per le credenziali e assicurarsi che il meccanismo di autenticazione funzioni in modo sicuro e corretto. Infine, il personale addetto deve offrire un supporto molto impegnativo, in quanto si trova a far fronte alla gestione delle nuove registrazioni, alla rimozione di utenti dal sistema e a casi in cui gli utenti perdono le loro credenziali e ne chiedono di nuove. Quindi la gestione delle identità si occupa di tutto il suo ciclo di vita, creazione, gestione e rimozione. In ultima istanza, purtroppo, gli utenti tendono a creare password deboli e facili da ricordare o a definire le stesse per diversi sistemi.
Tutti questi oneri possono essere minimizzati se si ricorre alla fiducia (trust), di una terza parte specializzata, ad un costo inferiore, per ottenere il servizio di gestione delle identità digitali di cui si ha bisogno. Normalmente l‟utente o azienda di un cloud pubblico ripone la fiducia nel cloud provider da cui riceve i servizi. È ragionevole attendersi che a sua volta questo provi- der riponga la fiducia per la gestione delle identità in outsourcing presso un altro provider specializzato in tali servizi. Quest‟ultimo provider (la terza parte), viene definito Identity Provider (IdP) e rientra negli altri due modelli di gestione.
Nel modello centralizzato, invece, è presente un solo IdP a cui fanno ri- ferimento i diversi SP per validare le richieste di autenticazione giunte dall‟utente. In questo caso è possibile abilitare il Single Sign On (SSO), che consente all‟utente di utilizzare la stessa identità su più sessioni, in diverse applicazioni e su diversi SP da cui riceve servizi, poiché l‟identificatore ad essa associato è unico e gestito dall‟IdP, anch‟esso unico (questa è una criti- cità perché rappresenta un unico punto di rottura). Di default si stabiliscono relazioni di fiducia tra i vari SP e l‟IdP all‟interno del dominio60. Per esten-
60 R. WARSCHOFSKY, M. MENZEL, C. MEINEL, Automated Security Service Orchestration
for the Identity Management in Web Service based Systems, in Web Services (ICWS), 2011
65 dere il concetto a relazioni interdominio dobbiamo ripensare il modello in ottica di federazione.
Infine, nel modello distribuito sono presenti diversi IdP e l‟utente pos- siede diverse identità a lui riconducibili, su diversi domini della federazio- ne61.Quindi, in seguito, in una logica di federazione si possono collegare due o più di queste identità, relative allo stesso utente e con accordi di trust tra SP e IdP, e accedere ai diversi servizi della federazione con una unica identi- tà, abilitando il SSO (un utente si autentica su un dominio e poi sarà in grado di accedere alle risorse di questo e di un secondo dominio federato). La ge- stione della federazione delle identità si occupa quindi di preservare le rela- zioni di fiducia che si stabiliscono tra diverse organizzazioni aderenti alla stessa federazione. Il modello si è sviluppato negli ultimi anni tramite diversi standard che abilitano lo scambio di informazioni utente tra gli elementi dei vari domini, tra i quali SAML, OpenID, OAuthe ciascuno può offrire alla federazione un servizio di autenticazione SSO. In questo modo ciascun SP ha la possibilità di verificare le identità gestite da altri IdP nella federazio- ne62
Il Security Assertion Markup Language (SAML) è un set open standard di OASIS63 di tipo “XML-based” per comunicare messaggi di autenticazio- ne, autorizzazione e attributi dell‟identità tra diversi domini della federazio- ne, approvato nel 2002. Attualmente viene utilizzata la versione due, appro- vata nel 2005. Un IdP e un SP possono condividere attributi d‟identità web in un messaggio SAML detto asserzione (o dichiarazione a seguito di richie- sta), trasportato con HTTP. Le asserzioni non sono altro che documenti XML spediti da un IdP a un SP contenenti info di identificazione dell‟utente che ha iniziato la procedura di richiesta SSO64. Possono essere di tre tipi: di
61 Con il termine federazione, in linea con quanto già affermato in precedenza in tema di cloud
federato, si intende l‟associazione di organizzazioni che si uniscono per lo scambio di informazioni sui loro utenti e di risorse.
62 Q. PHAM, A. MCCULLAGH, E. DAWSON, Consistency of user attribute in federated sys-
tems,in Trust, Privacy and Security in Digital Business , 2007, pp. 165-177
63 OASIS, 2013, https://www.oasis-open.org/ 64
OASIS, Security Assertion Markup Language (SAML) V2.0 Technical Overview, in sstc- saml-tech-overview-2.0-draft-1, 2006, p. 5
66 autenticazione65 se emessa per dichiarare l‟identità; di autorizzazione66 se dichiara che l‟utente è stato autorizzato ad accedere a determinate risorse; di attributo67 se specificano una serie di parametri dell‟identità, per esempio il ruolo, l‟email o il dipartimento di lavoro. Un classico scenario è quello che si presenta quando un utente vuole accedere ad un servizio presso un SP che però non gestisce le sue credenziali. Dalla pagina di login dell‟SP, il web
browser dell‟utente sarà reindirizzato a quella dell‟IdP tramite un messaggio
SAML di richiesta autenticazione (che può essere anche cifrato e firmato di- gitalmente). L‟IdP, che gestisce l‟identità dell‟utente, propone il login e una volta effettuato con successo crea un‟asserzione o token, che dichiara la con- ferma dell‟identità fornita e ridirige il browser alla pagina dell‟SP. Quest‟ultimo a sua volta verifica il token e ne estrae le informazioni che poi userà all‟interno dei suoi sistemi. In questi passaggi le credenziali utente non sono mai transitate, vi è stata solo una conferma di fiducia tra SP e IdP.
Creato nel 2005, OpenID68 rappresenta un altro standard aperto per l‟identità federata. Consente ai suoi utilizzatori di usufruire delle funzionali- tà SSO, in un sito web che si affida, per la gestione delle identità, a un pro-
vider OpenID. Gli utenti scelgono il loro provider OpenID preferito (Goo-
gle, Yahoo! e altri che hanno emesso OpenID per tutti i loro clienti) e usano i riferimenti del tipo Uniform Resource Locator (URL) per questi account, gli OpenID appunto, al fine di autenticarsi sui siti web che offrono tale ser- vizio di accesso69. Ancora una volta gli SP non dovranno implementare un sistema di gestione delle identità e i loro utenti non dovranno creare un
account per quello specifico provider. Grazie ad un protocollo di discovery,
dato l‟URL- utente, il Service Provider sarà in grado di risalire al provider OpenID e di reindirizzarvi il browser-utente mostrando il suo form di login. Una volta confermata l‟autenticazione e autorizzato lo scambio tra SP e pro-
65
SAML Authentication, in “oracle.com”, 2011, http://docs.oracle.com/cd/E21455_01/ com-
mon/tutorials/authn_saml_assertion.html
66 SAML Authorization Assertion, in “oracle.com”, 2011, http://docs.oracle.com/cd/
E21455_01/common/tutorials/authz_saml_assertion.html
67 Retrieve Attribute from SAML Attribute Assertion, in “oracle.com”, 2011,
http://docs.oracle.com/cd/E21455_01/common/tutorials/attributes_saml_assertion.html
68 OPENID, 2013, http://openid.net 69
T. ISLES, How Does OpenID Work?, in “My Tech Blathering”, 2008, http://blog.tinisles.com/2008/02/how-does-openid-work/
67
vider OpenID, la web application usa le informazioni restituite per ricono-
scere l‟utente e consentirgli l‟accesso al servizio desiderato70 .
Infine, lo standard aperto OAuth 71fornisce un metodo per gli utenti per concedere a terzi l‟accesso alle loro risorse, proteggendo contemporanea- mente le loro credenziali. La prima versione è stata rilasciata nel 2007 e nel 2012 la versione 2.0 del framework è stata ratificata dall‟IETF 72. L'ispira- zione per OAuth, con l‟avvento dei social network e delle applicazioni per il mobile, è stato quello di standardizzare il modo in cui gli utenti autorizzino un sito o applicazione (client nei ruoli definiti dallo standard) ad accedere ai dati del profilo utente registrato in un altro sito (il server di risorse), senza che il client debba chiedere all‟utente di fornirgli le credenziali, per poi poter fare da se la chiamata all‟API. In questo modo il client non dovrà richiedere al nuovo utente di registrarsi, ma potrà far usare al suo posto, per esempio, l‟account di Facebook (server di autorizzazione), che a login avvenuto rila- scerà un token di autorizzazione che consentirà al client di conoscere le in- formazioni del profilo utente (nome, foto, genere, elenco amici) ed integrarle nella nuova applicazione73.