L`autenticazione nel cloud computing

Commenti

Transcript

L`autenticazione nel cloud computing
UNIVERSITA’ DEGLI STUDI DI PARMA
Dipartimento di Matematiche e Informatica
Corso di Laurea in INFORMATICA
Tesi di Laurea in RETI DEI CALCOLATORI
L’AUTENTICAZIONE NEL CLOUD
COMPUTING
Candidato:
Relatore:
Francesco Pesare
Chiar.mo Prof. Roberto Alfieri
Anno Accademico 2013/2014
Indice
Introduzione ........................................................................................................................................... 1
1. Cloud in generale ............................................................................................................................ 5
1.1 Caratteristiche ............................................................................................................................5
1.2 Modelli di servizio ...................................................................................................................... 6
1.3 Modelli di sviluppo .................................................................................................................... 7
1.3.1 Private cloud ................................................................................................................... 7
1.3.2 Public cloud .................................................................................................................... 7
1.3.3 Hybrid cloud ................................................................................................................... 8
1.3.4 Community cloud ........................................................................................................... 9
1.4 Virtualizzazione.......................................................................................................................... 9
1.4.1 KVM .............................................................................................................................. 11
1.4.2 Virtualizzazione vs Cloud .............................................................................................. 11
1.5 Vantaggi del cloud ................................................................................................................... 12
1.5.1 Aspetti Economici ......................................................................................................... 12
1.5.2 Aspetti Tecnici .............................................................................................................. 13
1.6 Problematiche del cloud .......................................................................................................... 13
1.6.1 Sicurezza dei dati .......................................................................................................... 13
1.6.2 Geo localizzazione dei dati ........................................................................................... 14
1.6.3 Homomorphic Encription ............................................................................................. 15
1.6.4 Banda Larga .................................................................................................................. 16
1.7 Sicurezza degli account e dell’accesso alle risorse .................................................................. 18
1.8 Piattaforme di sviluppo del cloud ........................................................................................... 20
2. Piattaforma per lo sviluppo di una infrastruttura cloud: OPENSTACK ....................................... 22
2.1 Componenti ............................................................................................................................. 24
2.1.1 Keystone – Identity Service ..........................................................................................24
2.1.2 Nova – Compute Service .............................................................................................. 26
2.1.3 Glance – Image Service ................................................................................................. 27
2.1.4 Cinder – Block Storage.................................................................................................. 28
2.1.5 Swift – Object Storage .................................................................................................. 28
2.1.6 Horizon – Dashboard .................................................................................................... 29
2.1.7 Neutron – Networking .................................................................................................. 30
i
2.1.8 VPN as a Service ........................................................................................................... 31
2.1.9 Firewall as a Service...................................................................................................... 32
3. OpenStack: Installazione e test .................................................................................................... 33
3.1 Preliminari ............................................................................................................................... 33
3.2 Preparazione e configurazione della rete per OpenStack ....................................................... 34
3.3 Installazione servizi .................................................................................................................. 38
3.3.1 Keystone - Installazione e configurazione .................................................................... 39
3.3.1.1 Creazione utenti, tenants e ruoli .......................................................................... 41
3.3.1.2 Creazione servizio e API ........................................................................................ 42
3.3.1.3 Verifica .................................................................................................................. 42
3.3.1.4 Esempio keystone.conf ......................................................................................... 43
3.3.2 Glance ........................................................................................................................... 44
3.3.3 Cinder ........................................................................................................................... 45
3.3.4 Nova.............................................................................................................................. 46
3.3.5 Neutron ........................................................................................................................ 46
3.3.6 Horizon ......................................................................................................................... 48
4. Caso d’uso: Il cloud Multi-Region dell’ INFN ............................................................................... 49
4.1 Presentazione del cloud Multi-Region .................................................................................... 49
4.1.1 Scelte Implementative ............................................................................................. 50
4.1.2 Limitazioni ................................................................................................................ 51
5. Autenticazione e Strong Authentication: Dalla teoria alla pratica ............................................. 52
5.1 Autenticazione ......................................................................................................................... 52
5.1.1 Autenticazione Federata.......................................................................................... 52
5.1.2 Integrazione dell’autenticazione federata in OpenStack ........................................ 54
5.2 Strong Authentication ............................................................................................................. 58
5.2.1 Politiche di autenticazione e password ................................................................... 59
5.2.2 OTP – One Time Password ........................................................................................61
5.2.3 Test integrativo dell’ OTP nell’ ambiente di test ..................................................... 62
5.2.4 Stato dell’arte globale e il “The Fappening” ............................................................ 65
ii
6. Conclusioni ed eventuali sviluppi ................................................................................................. 67
6.1 Risultati raggiunti..................................................................................................................... 67
6.2 Sviluppi futuri .......................................................................................................................... 67
Bibliografia .......................................................................................................................................69
Ringraziamenti .............................................................................................................................. 73
iii
Introduzione
Oggigiorno una moltitudine di vendor offrono servizi di storage per dati
multimediali personali, esaltandone la comodità e facilità d’accesso. Tuttavia, il
cloud non è la panacea che risolve tutti i mali e purtroppo non comporta solo
vantaggi.
Con il termine cloud si fa riferimento alla convergenza di una serie di tecnologie
sviluppatesi negli ultimi trent’anni. Tali sviluppi sono il risultato della stretta
interconnessione tra tecnologia informatica e ricerca scientifica. Da sempre la
ricerca scientifica è svolta da comunità di ricercatori geograficamente distribuiti sul
territorio mondiale e caratterizzati da un’eterogeneità di risorse (quali sistemi di
calcolo, strumenti scientifici, banche dati, reti); i migliori risultati scientifici
perseguiti, sono la conseguenza delle molteplici collaborazioni che hanno portato la
scienza a far progredire l’informatica e l’informatica a far raggiungere nuovi
traguardi scientifici.
Tale interconnessione ha dato vita all’e-science, ovvero ricerca scientifica che
utilizza una grande quantità di risorse di calcolo e grandi quantità di dati
geograficamente distribuiti.
Questo ci porta al concetto di Grid Computing. Esso è emerso come uno dei
principali paradigmi di calcolo che consentono la creazione e la gestione di
infrastrutture basate su internet per la realizzazione di e-Science ed e–Business a
livello globale.
1
I campi di applicazione dell’informatica alla scienza sono innumerevoli. Il problema
principale, nonché sfida tecnologica, nasce nel riuscire a far convergere i dati
provenienti da diversi campi scientifici su un unico computer, in particolar modo in
quelle discipline che sono al confine tra due settori. Questo spiega perché i centri di
ricerca scientifica più importanti del mondo abbiano affiancato alla determinazione
di conseguire i propri obiettivi, la necessità di migliorare i propri sistemi informatici,
troppo poco adeguati a causa del ridotto budget disponibile.
Inoltre, l’obiettivo che si vuole raggiungere è quello di riuscire a realizzare una
virtual private cloud, consci del fatto che la potenza di calcolo dei server utilizzati
in ambito grid non è sempre quella massima esprimibile dagli stessi server; dunque
si vuole realizzare una trasformazione dagli attuali data center fisici, a dei mainframe
software, attraverso la definizione di strati software che compongono quello che ad
oggi viene comunemente chiamato virtual data center.
Il grid computing ha dalla sua, alcuni svantaggi legati alla complessità di utilizzo,
inerenti la suddivisione di un “big job” sui vari server, e alle risorse finanziarie.
Infatti, le risorse se da una parte sono condivise a livello mondiale dall’altra, sono
limitate dalla disponibilità economica di ogni ente di ricerca. A livello pratico, se si
pensa al carico produttivo medio, nelle ore giornaliere di massima produttività gli
enti appartenenti alla stessa zona del globo, hanno meno risorse da condividere tra
di loro.
Il cloud dunque basandosi sul grid computing e avvalendosi della virtualizzazione
propone di ridurre il sotto sfruttamento dei server, consentendo ai suoi utenti di
ridurre le spese hardware in particolar modo se si pensa che, quando un’azienda fa
un investimento, tende a sovradimensionare le risorse di cui ha necessità per evitare
di trovarsi in una situazione di saturazione delle risorse nei confronti dei propri
clienti. Il cloud è la soluzione a questo problema, nessuno deve comprare le proprie
risorse in funzione delle previsioni del successo del proprio business. Il punto chiave
del cloud è per l’appunto l’elasticità delle risorse e la facilità di utilizzo: la possibilità
di richiedere risorse in funzione della loro reale necessità, avendo l’illusione di
poterne aver un numero illimitato e on-demand, pagando in funzione del loro
effettivo utilizzo, senza dover avere competenze specifiche. Tutte caratteristiche che
fanno comodo a grandi enti di ricerca ma anche all’ultimo dei neo-imprenditori,
lasciando intendere come il cloud possa essere utilizzato da una vasta gamma di
utenti, in svariati settori.
Vantaggi che da un lato fanno risparmiare una quantità ingente di denaro e dall’altro
consentono a molte più aziende e a molti più utenti di poter essere competitivi sul
mercato e di poter aumentare il proprio fatturato, sia utilizzando il cloud come utenti,
sia vendendo servizi cloud come provider.
2
L’obiettivo della tesi è analizzare il cloud computing e l’autenticazione in questo
ambito, valuteremo pro e contro, affrontando le tematiche “di moda” sui problemi
che circondano il rapido sviluppo del cloud all’interno delle aziende e fornendo una
panoramica sulle vulnerabilità principali.
Inizieremo con una presentazione basilare attraverso la quale chiariremo il concetto
di cosa si intende per cloud computing, definendo le basi, le caratteristiche, i modelli
di sviluppo e i dettagli su come si può sviluppare un tale framework , argomento che
è stato anche oggetto di tirocinio.
Presenteremo OpenStack e i suoi servizi, illustreremo come questi interagiscono tra
di loro per poter dar vita a una piattaforma cloud di qualsiasi tipo e con qualsiasi
caratteristica, con l’analisi dei moduli di estensione per l’utilizzo di Firewall e VPN
all’interno del cloud per fornire sicurezza nelle comunicazioni.
Useremo questo, come trampolino di lancio per parlare del cloud multiregion,
analizzando il caso reale dell’I.N.F.N. e discutendo dei potenziali limiti presenti in
questa implementazione legati all’autenticazione.
Parleremo della problematica dell’autenticazione in ambiente cloud, e faremo un
focus sulla strong authentication considerando uno scenario in cui sarebbe servito
averla implementata.
Il lavoro di tesi sarà dunque così composto:
Capitolo 1 – Cloud in generale
Cenni sulla struttura del cloud, definizione della tecnologia e analisi dei potenziali
vantaggi e delle potenziali problematiche che girano intorno al mondo cloud.
Capitolo 2 – Piattaforma per lo sviluppo di una infrastruttura cloud:
OpenStack
Presentazione dell’open-framework OpenStack, oggetto di studio di molte
organizzazioni scientifiche e aziende leader nel settore della virtualizzazione, scelto
per l’implementazione dell’ambiente di test, che ha caratterizzato il percorso di
tirocinio e tesi.
Capitolo 3 – Openstack: Installazione e test
Presentazione del lavoro di installazione, configurazione e test dell’ambiente
utilizzato nel percorso di tirocinio e tesi.
3
Capitolo 4 – Caso d’uso: Il cloud Multi-Region dell’ INFN
Descrizione di un caso d’uso reale che coinvolge l’INFN.
Capitolo 5 – Autenticazione e Strong Authentication: Dalla teoria alla pratica
Approfondimento sul tema dell’autenticazione e sulla sicurezza delle credenziali di
accesso.
Capitolo 6 – Conclusioni ed eventuali sviluppi futuri
Conclusioni ed eventuali sviluppi futuri.
4
CAPITOLO 1
Cloud in generale
Il cloud computing è una macrostruttura distribuita di istanze di calcolo, scalabile
dinamicamente, destinata a minimizzare gli sforzi e i costi e a massimizzare
l’efficienza.
Il Cloud computing consente infatti ai clienti di condividere risorse dinamicamente
e di pagare in base all’utilizzo effettivo.
Questa tecnologia solleva però numerose preoccupazioni circa i requisiti di
sicurezza: protezione dei dati, localizzazione, identità e gestione degli accessi,
perdita di dati, web e email security, violazione gestionale, gestione degli eventi,
criptazione, segregazione dei dati, business continuity e disaster recovery sono
sicuramente di interesse per i clienti e ancor più sono una necessità per il provider
dei servizi.
I modelli di cloud computing hanno infatti tre attori:
 cloud provider: colui che fornisce l’infrastruttura al cliente
 service provider: colui che utilizza l’infrastruttura per fornire applicazione o
servizi agli utenti finali
 service consumer: colui che utilizza i servizi sull’infrastruttura
Secondo il NIST [1] (National Institute of Standard and Technology) i modelli di
cloud computing sono caratterizzati da cinque caratteristiche fondamentali, tre
modelli di servizio e quattro modelli di sviluppo [2].
1.1 CARATTERISTICHE
1. On-demand self service: Il cliente può procurarsi le risorse di calcolo che
necessità autonomamente
2. Broad network access: le risorse accessibili sulla rete
3. Resource pooling: diverse risorse fisiche e virtuali vengono assegnate dal
provider in base alla domanda del cliente
4. Rapid elasticity: le risorse possono essere assegnate al cliente in qualsiasi
quantità e in qualunque momento
5. Measured service: Sia provider che cliente possono monitorare e controllare
l’utilizzo di risorse
5
1.2 MODELLI DI SERVIZIO
1. SaaS (Software as a Service): E’ usato dai clienti per utilizzare il software del
provider e associare ai dati in esecuzione all’infrastruttura cloud
2. PaaS (Platform as a Service): i clienti creano applicazioni attraverso questi
servizi, utilizzando strumenti supportati dal provider, ad esempio come
Force.com, Red Hat OpenShift, Google App Engine, Windows Azure e
VMware Cloud Foundry
3. IaaS (Infrastructure as a Service): Sostanzialmente risorse di calcolo fornite
al cliente per sviluppare ed eseguire software. Qualche esempio di IaaS sono
Amazon Web Services, Citrix, CloudPlatform, windows Azure, Microsoft
System Center, OpenStack, Rackspace, Savvis and VMware vCloud Suite
Figura 1. Confronto dei modelli di servizio
1.3 MODELLI DI SVILUPPO
6
Quando si offre una soluzione di cloud computing è indispensabile decidere quale
modello deve essere implementato. Ci sono quattro tipi di cloud computing:
1.3.1 Private cloud
Questa infrastruttura fornisce uso esclusivo a un singola organizzazione includendo
clienti multipli. Questa tipologia di cloud viene implementata all’interno di
un’azienda e l’approvvigionamento, la gestione e la messa in sicurezza delle risorse
fisiche è compito del personale IT.
Figura 2. Rappresentazione Private Cloud
1.3.2 Public cloud
Questa infrastruttura è per l’uso aperto e consente l’accesso degli utenti al cloud
attraverso interfacce utilizzando un browser web. Gli utenti pagano solo per il tempo
di utilizzo del servizio; tuttavia i cloud pubblici sono meno sicuri rispetto agli altri
modelli perché il mezzo utilizzato, Internet, è intrinsecamente insicuro. La maggior
parte dei problemi di sicurezza avviene in questo tipo di cloud anche perché il cliente
si rivolge a terze parti per la gestione dei propri dati, perdendone il controllo fisico.
Standard di sicurezza, accordi, licenze e suddivisione precisa di ruoli e responsabilità
deve avvenire tra cliente e provider per preservare i dati (SLA).
7
Figura 3. Rappresentazione Public Cloud
1.3.3 Hybrid cloud
E’ la composizione di 2 o più distinti modelli di sviluppo, che congiunti posso offrire
la sicurezza di una cloud privata, senza rinunciare alla possibilità di espandere in
maniera “illimitata” le risorse in caso di necessità, senza preoccuparsi del carico di
lavoro della struttura fisica.
Questa tipologia di cloud, tuttavia va attuata tenendo in considerazione che allo stato
attuale, non esistono ancora degli standard di sviluppo per le implementazioni cloud:
dunque per essere realmente scalabile è consigliato che nella cloud privata, vengano
8
rispecchiate le caratteristiche e le varie estensioni che sono supportate, ad esempio
da servizi come Amazon Web Service [3].
Figura 4. Rappresentazione Hybrid Cloud
1.3.4 Community cloud
E’ una tipologia di cloud condivisa tra determinati gruppi di utenti appartenenti ad
un’organizzazione o comunità, che hanno interessi in comune. L’ implementazione
di questa tipologia può essere gestita internamente o da terze parti, ospitata
internamente o esternamente.
1.4 VIRTUALIZZAZIONE
L'obiettivo delle tecnologie di virtualizzazione è astrarre tutte le componenti
hardware di una macchina fisica al fine di renderle disponibili come risorse logiche
a diverse istanze di sistemi operativi eseguiti parallelamente. La gestione
9
dell'hardware e quindi delle relative componenti virtualizzate è demandata ad uno
strato software chiamato Hypervisor posizionato ad uno dei livelli più bassi della
pila delle componenti che formano un sistema virtualizzato.
L'Hypervisor viene eseguito su una macchina fisica denominata “host” e il suo ruolo
principale è intercettare e tradurre le chiamate di sistema effettuate dai sistemi
operativi “ospiti” (guest), affinché vengano correttamente eseguite dalla CPU anche
nel caso in cui esistano più guest in esecuzione in maniera concorrente.
Esistono differenti implementazioni degli hypervisor, categorizzate a seconda della
tipologia di virtualizzazione che rispettivamente gestiscono:
Virtualizzazione Completa: È la tipologia di virtualizzazione che permette ai sistemi
operativi guest di essere eseguiti senza essere a conoscenza di trovarsi, in realtà, in
un ambiente virtualizzato. Con questa tipologia di virtualizzazione, qualunque
sistema operativo che funzionerebbe sull'hardware host, funzionerà nell'ambiente
virtualizzato e sarà compito dell'hypervisor gestire e allocare le risorse ai singoli
guest, fornendo una rappresentazione logica di tutte le periferiche e le componenti
hardware. Questa tipologia di hypervisor può essere implementata in due modalità
differenti:
- Bare metal, chiamata anche Type 1 è l'implementazione dell'hypervisor
direttamente sul hardware host; è l'implementazione che offre le migliori
prestazioni in quanto, permette ai guest di trovarsi solo un livello sopra
l'hypervisor. Esempi di questa tipologia di hypervisor sono VMware ESX,
Xen e KVM.
- Hosted, chiamata anche Type 2 è l'implementazione dell'hypervisor su un
sistema operativo preesistente. In questa implementazione l'hypervisor per
funzionare si basa sulle risorse messe a disposizione dal sistema operativo in
esecuzione. Esempi di questo hypervisor sono VirtualBox e VMware Server.
Para Virtualization: È la tipologia di virtualizzazione che necessita che il sistema
operativo guest sia modificato in maniera opportuna. In tale tipologia l'hypervisor
mette a disposizione ai sistemi operativi guest un'interfaccia software con la quale
le macchine virtuali comunicano, utilizzando specifiche chiamate di sistema. Grazie
a questa tecnica le macchine virtuali possono delegare l'hypervisor a eseguire
determinate operazioni direttamente sull'hardware, evitando di eseguirle in un
contesto virtuale, computazionalmente più costoso. Un esempio di questo hypervisor
è Xen.
10
Virtualizzazione a livello di Sistema Operativo: Tipologia che si distacca molto dalla
precedenti, nella quale non viene implementato un vero e proprio hypervisor, ma il
kernel del Sistema Operativo offre la possibilità di generare contesti multipli in userspace, altamente isolati fra di loro. Questo tipo di virtualizzazione non crea quasi
alcun overhead, non dovendo virtualizzare alcun componente; ma è poco flessibile,
in quanto tutte le istanze gireranno utilizzando il medesimo kernel. Esempi di tale
tipologia di virtualizzazione sono, il meccanismo Linux-V Server incluso nel kernel
Linux e OpenVZ.
1.4.1 KVM
La schematizzazione spiegata nel paragrafo precedente, permette di definire a grandi
linee il funzionamento degli hypervisor, ma non sempre è possibile associare un
determinato hypervisor entro i confini di una singola categoria. Un esempio pratico
è rappresentato da KVM (Kernel-based Virtual Machine) che è nato come modulo
del kernel Linux e quindi, per quanto sia implementato come un hypervisor Type 1
necessita di un sistema operativo Linux-based per essere utilizzato, entrando nei
confini della categoria Type 2.
Per funzionare KVM utilizza un set di istruzioni aggiuntivo delle CPU x86 ma
esistono versioni modificate per fornire servizi di virtualizzazione anche su
architetture differenti, come i processori ARM, utilizzando tecniche simili alla
paravirtualizzazione di XEN.
1.4.2 Virtualizzazione vs Cloud
Per far chiarezza tra le differenze sostanziali che ci sono tra la tecnica di
virtualizzazione e sistemi cloud basta far riferimento a quando dichiarato dal NIST
nella definizione delle due tecnologie [2] [4].
La virtualizzazione nell’ IT ha il significato di isolare le risorse di calcolo in maniera
tale che un oggetto in uno strato possa essere eventualmente impiegato senza avere
la preoccupazione di modifiche apportate negli strati sottostanti. La virtualizzazione
isola le risorse di calcolo, offre dunque l’opportunità di riposizionare e consolidare
le risorse isolate per un miglior utilizzo e una maggiore efficienza.
Il cloud computing è invece la capacità di rendere le risorse disponibili su richiesta:
dunque alta accessibilità e disponibilità in qualsiasi momento. Nel cloud computing
un servizio identifica qualcosa, disponibile on-demand e self-service. Così si intende
11
il software SaaS, ossia un software la cui offerta è disponibile su richiesta e
l’attenzione è riposta sulle funzioni disponibili entro e non oltre l’applicazione. PaaS
fornisce un ambiente di runtime on-demand e la portata di questo servizio è costituita
da tutto l’insieme di funzionalità disponibili on-demand, per le applicazioni
distribuite in questo ambiente runtime. IaaS è invece la capacità di implementare
macchine virtuali on-demand.
Sostanzialmente, la maggior parte delle cose che si possono fare in ambito cloud
potrebbero essere fatte sfruttando anche alcune estensioni dei più noti sistemi di
virtualizzazione come ad esempio virtualizzare un intero ambiente virtuale, aver
accesso da remoto, avere self-servering di risorse, ma nella virtualizzazione il selfservering ad esempio non è una componente né necessaria né sufficiente, al contrario
del cloud.
1.5 VANTAGGI DEL CLOUD
I vantaggi del cloud computing [5] sono numerosi e posso essere raggruppati in due
categorie analizzando l’aspetto economico, legato dunque ai costi infrastrutturali e
di mantenimento, e l’aspetto tecnico.
1.5.1 Aspetti economici



Abbattimento dei costi fissi iniziali: risparmio per i non più necessari
investimenti, iniziali e successivi, sul software e hardware (acquisto,
configurazione, installazione, manutenzione e dismissione di hardware e
software). Non è necessario possedere computer di fascia alta per accedere ai
servizi cloud online: i programmi e i dati risiedono nell'infrastruttura cloud,
gestita da personale (teoricamente) molto esperto e qualificato;
Maggiore flessibilità: la possibilità di un facile e tempestivo adeguamento
delle condizioni contrattuali in funzione delle maggiori o minori esigenze;
Maggiore attenzione al proprio core business: vengono liberate energie umane
prima completamente dedite alla gestione dell'infrastruttura; la gestione di
tutta l'architettura informatica è demandata al provider.
1.5.2 Aspetti tecnici


Maggiore scalabilità: di fronte alla necessità di maggiori o minori risorse, il
gestore può espandere o limitare con estrema flessibilità l'infrastruttura;
Accesso al cloud in mobilità: la connessione ai dati può avvenire da qualsiasi
posto e in qualsiasi momento, anche attraverso smartphone, netbook, portatili
o pc desktop, smart-tv;
12



Sicurezza del sistema: possibilità di mettere in atto un sistema di sicurezza
volto a proteggere i dati e le reti con servizi sempre presidiati da backup, senza
costi per l’eventuale infrastruttura
Indipendenza dalle periferiche: trattandosi di programmi e dati online, non si
è vincolati ad utilizzare particolari hardware o determinate configurazioni di
reti ma è appena sufficiente qualsiasi dispositivo fisso o mobile capace di
collegamento internet attraverso un browser qualsiasi.
Continuità di servizio: il cloud computing in quanto servizio, permette di non
fare investimenti in soluzioni hardware/software ridondanti. In questo modo
si ha la possibilità di ridurre i costi, ma di aumentare la continuità di servizio.
Infatti in caso di un problema o di un upgrade al server del cloud dove sta
girando una istanza, tale istanza viene spostata interamente su un altro server.
1.6 PROBLEMATICHE DEL CLOUD
Una domanda che ci si pone spesso è: quanto è sicuro il cloud?
Ci sono molti aspetti legati alla sicurezza e molti fattori da valutare: sicurezza delle
informazioni immagazzinate, sicurezza delle informazioni in transito, accesso alla
cloud etc…
Secondo un’indagine statistica sembra essere il problema principale di molti team di
IT. [6]
1.6.1 Sicurezza dei dati
La sicurezza dei dati è un argomento estremamente delicato in ambiente cloud.
Esso infatti riguarda molti aspetti legati non solo a un aspetto tecnico ma anche alle
norme vigenti sulla riservatezza dei dati in termini di privacy e responsabilità.
Hp ha inserito all'interno della propria offerta di soluzioni HP Atalla [7] una
tecnologia di cifratura in attesa di brevetto che garantisce la cifratura dei dati nel
cloud sia in condizione di riposo sia mentre sono in uso, che protegge le chiavi di
cifratura mentre sono in uso e persino nel caso di violazione.
Con HP Atalla Cloud Encryption ogni oggetto legato ai dati (per esempio un disco)
è memorizzato in un dispositivo virtuale sicuro e viene crittografato utilizzando un
metodo di crittografia a chiave separata in due.
La prima parte, la cosiddetta Master Key, è uguale per tutti i "data object"
nell'applicazione e rimane in possesso solo del proprietario dell'applicazione e non
13
viene mai memorizzata in forma aperta né sull'account cloud dell'utente né sul
servizio di gestione chiavi di HP (HP Key Management Service).
La seconda parte della chiave è differente per ogni "data object" e viene generata
dall'appliance virtuale sicura all'interno del servizio di gestione delle chiavi di HP e
memorizzata dopo averla ulteriormente cifrata con una chiave privata RSA.
Sintentizzando:
In ambito cloud, gli hard disk virtuali risiedono su hard disk fisici condivisi ed è
perciò opportuno averli criptati.
1.6.2 Geo localizzazione dei dati
Per quanto concerne le cloud private, il problema di geo localizzare i propri dati può
essere influente in quanto la possibilità di implementare un data storage locale, è
solo una scelta implementativa.
Per le hybrid cloud e le public cloud, la necessità di geo localizzare i propri dati può
essere un problema.
Nel Public cloud i servizi IT, siano essi di tipo applicativo o di tipo elaborativo, di
storage e di sicurezza, vengono acquisiti presso provider esterni. I dati vengono
ospitati fuori dall’azienda; ciò necessità di un adeguato livello di attenzione per
l’esternalizzazione di servizi da parte di aziende o amministrazioni pubbliche che
adottano soluzioni di cloud computing. Infatti, non sono esenti da responsabilità
legali [8] in merito, per esempio, al trattamento o alla diffusione di dati sensibili
personali.
Per garantire il livello di protezione sono state messe a punto sofisticate soluzioni di
cifratura e gestione delle chiavi, tool per garantire la conformità, sistemi di gestione
dell’accesso sicuro e operanti all’interno di strutture federate sicure.
Il Garante della Privacy ha affrontato il tema della riservatezza e confidenzialità
delle informazioni collocate in ambiente public cloud e ha messo in evidenza alcuni
aspetti che vanno considerati per un utilizzo consapevole, che si possono riassumere
in questi punti:




verifica dell’affidabilità e competenze del fornitore;
attenta selezione dei dati gestiti in modalità cloud;
controllo dell’effettiva allocazione fisica dei dati;
utilizzo di servizi che favoriscono la portabilità dei dati e la loro disponibilità
in caso di necessità;
14


esigere dal fornitore opportune garanzie in merito alla sicurezza dei dati e
delle tecniche di trasmissione oltre alla gestione di situazioni critiche che
possono comprometterne la corretta conservazione;
stabilire in fase contrattuale i Service Level Agreement a cui riferirsi, le
penali previste e i tempi di conservazione dei dati dopo la scadenza del
contratto.
1.6.3 Homomorphic Encription
La crittografia omomorfica [9] è un tipo di crittografia basata su tecniche che
permettono la manipolazione di dati cifrati. Ad esempio, avendo due numeri X e Y
(cifrati con lo stesso algoritmo omomorfico a partire da due numeri A e B) è
possibile calcolare la cifratura della somma di A e B sommando direttamente X e Y,
senza bisogno di effettuare la decifratura.
Questa proprietà della crittografia omomorfica è molto importante oggi, soprattutto
con l'avvento del cloud computing: attualmente, infatti, i dati presenti su una
piattaforma di cloud non sono totalmente sicuri, soprattutto se bisogna effettuare
delle operazioni su di essi, poiché per manipolarli c'è bisogno di decifrarli. La
crittografia omomorfica, invece, può risolvere questo problema e fare in modo che
le informazioni memorizzate nel cloud non debbano mai essere decifrate (e che
quindi siano sempre al sicuro).
Esistono due tipi di crittografia omomorfica: crittografia omomorfica totale, in grado
di criptare qualsiasi tipo di dato e crittografia omomorfica parziale, specializzata per
determinate applicazioni.
I costi computazionali della crittografia omomorfica totale risultano essere tutt’ora
elevati, ma se si riuscissero ad abbassare i costi, troverebbe il suo impiego maggiore
negli ambienti cloud.
1.6.4 Banda Larga
Uno dei principali svantaggi del cloud è la necessità di utilizzare una connessione
internet veloce: in Italia siamo messi male. Nel tempo, soltanto due compagnie
italiane si sono affacciate a questa tecnologia, e sono, Telecom Italia e Fastweb. Nel
2012, Telecom Italia e Fastweb, hanno annunciato una collaborazione nell'utilizzo
15
della VDSL2 attraverso l'architettura FTTC [10], che dovrebbe portare una copertura
internet teorica fino a 400 Mbits in 100 città italiane entro il 2014.
Dal 5 dicembre 2012, Telecom Italia ha iniziato la vendita della tecnologia in alcune
città italiane offrendo un unico profilo, con velocità di 30/3 Mbit/s.
Il 5 marzo 2013, Fastweb ha lanciato il suo servizio basato su VDSL2 col quale i
clienti potranno usufruire di velocità di 20Mbit di download e 10 Mbit di upload,
migliorabili fino a 100 in download pagando un piccolo contributo mensile.
Contrariamente a quanto avviene in Italia, a marzo del 2014 la tecnologia VDSL2 è
utilizzata in molti paesi europei:







in Slovenia, dove l'operatore telefonico "AMIS" sta fornendo VDSL2 alla
clientela Corporate dal 2013, "TušTelekom" alle imprese ,"Telekom
Slovenije" dal 5 marzo 2007 ai suoi clienti e la compagnia locale "T-2"
fornisce VDSL2 ai clienti dal maggio 2007 offrendo loro una velocità fino a
60/25 Mbps su linee telefoniche in rame e in fibra ottica vari pacchetti da
10/10 Mbps fino a 1000/1000 Mbps.
in Belgio, dove la compagnia locale Belgacom la utilizza per fornire agli
abbonati il servizio Internet e IPTV.
in Francia, gli operatori Orange, SFR, Bouygues Telecom e Free hanno offerte
dai 50Mbit/s ai 100Mbit/s con prezzi che variano da 29,9€ ai 37,9€ al mese,
incluse telefonate e televisione[5]
in Spagna, gli operatori Jazztel, Movistar e Vodafone, hanno offerte dai
30Mbit/s ai 35Mbit/s con prezzi che variano da 35€ ai 53€ al mese, [6]
in Germania, gli operatori EWE, OsnaTEL, SWB, Deutsche Telecom,
Vodafone, MDCC, hanno offerte dai 50Mbit/s ai 128Mbit/s con prezzi che
variano da 25€ ai 56€ al mese, televisione e spesso telefonate incluse [7]
in Svizzera, dove l'operatore Swisscom la utilizza per fornire agli abbonati il
servizio Internet e IPTV, offrendo loro una velocità fino a 50 Mbps su rame e
100 Mbps in fibra ottica.
a Malta Go Plc offre connessioni VdSL2 (profilo ITU-T G.993.2 Annex B)
con una velocità di 35 Mbps in download e 2 Mbps in upload. La portante,
qualora l'utente si trovi vicinissimo al cabinet di strada, può arrivare a valori
di 34.999/2.000. Attualmente, 8 Maggio 2014, la connessione è offerta senza
limiti di download.
A marzo del 2014, questi paesi hanno una velocità media nazionale di connessione
ad internet tra i 20Mbit/s e i 29Mbit/s, mentre l'Italia ne ha meno di 8Mbit/s, secondo
netindex.com
A marzo del 2014, l'Italia ha meno di 8 Mbit/s di velocità media nazionale di
connessione ad internet secondo explorer.netindex.com. Facendo un confronto con
16
i dati storici di netindex.com, il ritardo italiano nella diffusione della banda larga
corrisponde, per gli altri più avanzati paesi europei, ad un salto indietro nel tempo,
come di seguito:





7 anni di salto indietro nel tempo per la Francia (che aveva una
nazionale inferiore a 8 Mbit/s a marzo del 2008)
6 anni di salto indietro nel tempo per la Germania (che aveva una
nazionale inferiore a 8 Mbit/s a maggio del 2008)
5 anni di salto indietro nel tempo per la Slovenia (che aveva una
nazionale inferiore a 8 Mbit/s ad agosto del 2009)
4 anni di salto indietro nel tempo per il Regno Unito (che aveva una
nazionale inferiore a 8 Mbit/s ad agosto del 2010)
4 anni di salto indietro nel tempo per la Spagna (che aveva una
nazionale inferiore a 8 Mbit/s ad agosto del 2010)
media
media
media
media
media
Nei confronti di questi paesi di PIL paragonabile a quello italiano, l'Italia ha circa da
4 a 7 anni di ritardo tecnologico.
Ad oggi la banda media italiana è leggermente aumentata, nonostante tutto siamo
ancora abbastanza indietro
17
Figura 5. Statistica mondiale sulle velocità medie di connessione a internet in download (a sinistra) e in upload (a destra) [11]
1.7 SICUREZZA DEGLI ACCOUNT E DELL’ACCESSO ALLE
RISORSE
Nella realizzazione di sistemi distribuiti in genere e dei sistemi cloud in particolare,
sorge l’esigenza di verificare che il proprio interlocutore sia effettivamente chi
dichiara di essere prima di poter avere accesso a determinate risorse.
Per proteggere una risorsa, in generale, si deve passare attraverso due fasi:
Autenticazione: è il processo che verifica l’identità, ovvero risponde alla domanda:
“l’utente è chi dice di essere?”
Autorizzazione: è il processo che consente l'accesso alle risorse solamente a coloro
che hanno i diritti di usarle.
18
I metodi attraverso i quali si può autenticare una persona, sono divisi in tre classi:
- qualcosa che si è: per esempio impronte digitali, impronta vocale,
struttura retina o altri identificatori biometrici;
- qualcosa che si ha: tesserino identificativo, certificato, token;
- qualcosa che si conosce: password, numero d’identificazione personale
(PIN).
Per l'autenticazione in rete è normalmente usata la terza classe, che non richiede né
l'utilizzo di hardware speciali né la presenza dell'utente.
Per ragioni di sicurezza, la password scelta dall'utente, o a lui assegnata, deve
soddisfare certi requisiti ed essere:
- non ovvia e di lunghezza minima data;
- non comunicata in chiaro;
- cambiata con una certa frequenza.
L’autenticazione tramite password è oggi il sistema più utilizzato per l’accesso ai
vari servizi della rete. Ma come vedremo in seguito, più usato è ben diverso di più
sicuro.
Questo modo di procedere causa però alcuni disagi, sia agli utenti che usufruiscono
del servizio stesso, sia a chi li fornisce. Infatti gli utenti si trovano spesso a dover
gestire diverse credenziali di accesso;
Considerando che la password dovrebbe essere cambiata spesso, e che un utente
difficilmente ha un solo account da ricordare, ne discende che per l'utente può
diventare gravoso ricordare una coppia username/password. Questo può portare a
errori comuni, come la trascrizione in chiaro delle password in email, cellulare, postit, o sfruttare dei key-manager per lo storage cifrato delle proprie password.
Tali sistemi in realtà non risolvono il problema della sicurezza degli account, in
quanto per poter poi accedere a tutte le proprie password al momento del bisogno,
ne basterà solamente una…
Perciò, recentemente si tende a sviluppare sistemi di autenticazione che possano
essere riutilizzabili per varie funzioni, o servizi. In alcuni casi, tali sistemi si
occupano di gestire un'unica coppia username/password associata a un utente, che
deve comunque essere fornita per ciascun servizio che si intende utilizzare.
In altri casi, almeno per quanto riguarda servizi diversi accessibili all'interno di
un'unica università/azienda, esistono dei veri e propri sistemi di Single Sign On, in
cui un utente si autentica una volta soltanto e accede poi liberamente a tutti i servizi
per cui possiede l'accesso.
19
Meno password da ricordare, più accesso alle risorse…
1.8 PIATTAFORME DI SVILUPPO DEL CLOUD
Esistono diverse compagnie che investono nel cloud computing le loro risorse, non
solo come provider di servizi cloud, ma che fornisco anche supporto per lo sviluppo
di questa tecnologia attraverso la loro idea di cloud e i loro framework di sviluppo.
Figura 6. Top Cloud Companies [12]
Amazon è sicuramente la prima che è riuscita a offrire un servizio pubblico di IaaS:
la sua offerta varia dalla vendita low-cost di servizi di storage alla vendita di servizi
di computazione da 5000$ per ora.
VMware, azienda leader nel settore della virtualizzazione, non è stata di certo a
guardare. In un primo momento, con vCloud offrivano la piattaforma per lo sviluppo
di cloud, ed è solo da circa un anno che hanno cambiato idea decidendo immettere
sul mercato i servizi di una loro implementazione di cloud pubblico.
Altre compagnie come Microsoft e Google offrono servizi come Windows Azure
(Iaas e PaaS, non rinnegando Linux) e Microsoft Office 365 (SaaS) e rispettivamente
Chrome Os (PaaS) e Google Apps (SaaS), Google Engine (PaaS) e Google Drive
per lo storage.
Tuttavia, quello che è veramente importante per la ricerca e lo sviluppo lo stanno
facendo Rackspace e IBM: hanno sposato OpenStack, “LA” piattaforma open source
con la più grande community oggi esistente per il cloud libero. Nata con l’idea di
20
non voler comprare software che non si può controllare, Rackspace ha collaborato
con la NASA per lo sviluppo e IBM da parte sua, punta molto su questa piattaforma,
dichiarando che utilizzerà OpenStack, per tutte le cloud che stanno sviluppando. Il
lavoro fatto da IBM dunque, pone OpenStack come diretto concorrente per VMware.
Dunque, è proprio per questo che abbiamo deciso di adottare anche noi OpenStack
per la nostra installazione di test, stimolati dal suo potenziale e incuriositi dall’ampia
community che ha alle spalle.
21
CAPITOLO 2
Piattaforma per lo sviluppo di una
infrastruttura di Cloud Computing:
OpenStack
OpenStack [13] è un insieme di software open source rilasciato, sotto licenza
Apache che integra il codice dalla piattaforma della NASA Nebula e dalla
piattaforma Rackspace, con lo scopo di fornire infrastruttura cloud pubbliche o
private, largamente scalabili
OpenStack è un progetto IaaS cloud computing di Rackspace Cloud e NASA
fondato nel 2010 e sviluppato principalmente in python. A oggi oltre 200 società si
sono unite al progetto tra cui Arista Networks, AT&T,AMD, Brocade
Communications Systems, Canonical, Cisco, Dell, EMC, Ericsson, F5 Networks,
Groupe Bull, Hewlett-Packard, IBM, Inktank, Intel, NEC, NetApp, Nexenta,
Rackspace Hosting, Red Hat, SUSE Linux, VMware, Oracle e Yahoo!.
Dal 2010 OpenStack è in forte ascesa, e il suo sviluppo è globale: come si può vedere
dalle statistiche di Google Trends, OpenStack risulta essere un termine molto
ricercato sul motore di ricerca, soprattutto se confrontato con le altre due piattaforme
di sviluppo open source, che nel corso degli anni non sembrano aver suscitato un
forte interesse in confronto.
22
Figura 7. Statistiche tratte da Google Trend sulla popolarità di OpenStack [14]
OpenStack associa un nome in codice ad ogni major release con cicli di rilascio di 6
mesi.
Da ottobre 2013 sono state rilasciate 3 release (Havana, IceHouse, e la decima
release col nome Juno), ognuna delle quali apportava miglioramenti sensibili
all’interno dell’infrastruttura. Per Aprile 2015 è attesa Kilo.
23
2.1 COMPONENTI
Figura 8. Modularità di OpenStack
Come abbiamo detto OpenStack è un insieme di software ed ogni componente ha
un nome in codice che lo identifica:
Servizi
OpenStack Identity
OpenStack Compute
OpenStack Networking
OpenStack Image Service
OpenStack Block Storage
OpenStack Object Storage
OpenStack Dashboard
Nome in codice
Keystone
Nova
Neutron
Glance
Cinder
Swift
Horizon
2.1.1 Keystone – Identity service
Keystone è il servizio che si occupa di gestire autenticazione e autorizzazione
all’interno di OpenStack e funge anche da service catalog. In particolare si occupa
della validazione delle credenziali per gli utenti, validazione e gestione dei token per
l’autenticazione una volta che le credenziali siano state verificate, gestisce il
catalogo dei servizi con le informazioni relative agli endpoit di ogni servizio e le
policy ti autorizzazione.
24
Supporta diversi tipologie di back-end come identity provider. Di default utilizza
MySQL ma è anche possibile utilizzare LDAP o può essere esteso con meccanismi
di autenticazione federata di tipo single sign-on.
Quando un utente fa un richiesta a Keystone se l’autenticazione ha esito positivo
allora ottiene un token da poter utilizzare per effettuare le varie richieste.
Quando un servizio, riceve una richiesta da un altro servizio, effettua una chiamata
a Keystone passandogli il token del richiedente: se l’autenticazione ha esisto positivo
allora la richiesta può essere consumata altrimenti viene rigettata.
Figura 9. Diagramma funzionale per l'autenticazione
Per installazioni di testing, questo tipo di approccio è più che valido, ma in ambienti
enterprise è possibile apportare delle migliorie: ad esempio se si pensa a dover
garantire l’accesso alla cloud a una vasta comunità di persone, usare un back-end di
tipo MySQL comporterebbe sicuramente del lavoro sia per l’aggiunta delle nuove
credenziali sia per estrapolare le informazioni dal database della community
successivamente da importare all’interno del back-end di Keystone. E se si pensa
25
alla possibilità che la cloud possa essere utilizzata da più community, non è difficile
immaginare l’ammontare del lavoro che ci sarebbe da fare: in tal caso il supporto
per il SSO di Keystone, chiamato OS_Federation è sicuramente una scelta obbligata.
Inoltre ipotizzando che la cloud possa essere utilizzata simultaneamente da diverse
entità, come si vede dall’immagine precedente, ogni richiesta fatta a un servizio della
cloud comporta la verifica da parte del servizio di un token. Tale verifica, viene
eseguita interrogando Keystone e inviandoli il token in questione e questo comporta
sicuramente un overhead di rete evitabile se si decidesse di utilizzare token di tipo
PKI, i quali verrebbero verificati in loco da ogni servizio sfruttando i certificati x.509
2.1.2 Nova – Compute service
OpenStack Compute (Nova) è un controller per il cloud computing (la parte
principale di un sistema IaaS).
L'architettura di Compute è progettata per scalare orizzontalmente su hardware
standard senza particolari requisiti software o hardware proprietari e tecnologie di
terze parti. È stato progettato per gestire e automatizzare il pool di risorse del
computer e può funzionare con tecnologie di virtualizzazione ampiamente utilizzate,
come pure in configurazioni bare-metal e high-performance computing (HPC). Ad
esempio KVM, XenServer, Hyper-V sono scelte disponibili come hypervisor.
Utilizza un database (generalmente MySQL) per la memorizzazione delle
configurazione e degli stati a run-time dell’infrastruttura, ad esempio quali tipi di
istanza sono disponibili, quali istanze sono in uso, di chi sono quelle istanze, gli
utente le reti etc.
I servizi di nova si suddividono in:
 Nova-api: accetta e risponde alle richieste di computazione da parte degli
utenti
 Nova-scheduler: prende da un coda una richiesta di creazione di una macchina
virtuale e determina su quale host fisico deve essere eseguita
 Nova-compute: è il servizio principale che si occupa della creazione e
terminazione delle istanze attraverso le APPI dell’Hypervisor
 Nova-console, nova-vncproxy, nova-consoleauth sono invece i servizio che si
occupano dell’accesso alle console delle macchine virtuali
26
Figura 10. Raffigurazione grafica Nova
2.1.3 Glance – Image Service
Image Service è un servizio centrale per la tipologia Infrastructure-as-a-Service
(IaaS) consente agli utenti di scoprire, registrare e recuperare le immagini delle
macchine virtuali.
Il servizio offre una REST API che consente di interrogare i metadati dell’immagine
della macchina virtuale e recuperare un immagine. È possibile memorizzare le
immagini per le macchine virtuali, messi a disposizione tramite l’Image Service, in
una varietà di locazioni; da semplici file sull’ hard drive ad opportuni sistemi di
archiviazione come ad esempio il servizio di OpenStack Object Storage.
Un certo numero di processi periodici eseguiti su OpenStack Image Service
supportano la cache. Servizi di replica garantiscono la coerenza e la disponibilità
attraverso il cluster ed altri processi periodici consentono di revisionare, aggiornare
e fixare il sistema.
Glance include i seguenti componenti:
27
 glance-api: accetta chiamate API per l'individuazione di immagini, il recupero
e memorizzazione
 glance-registry: immagazzina, processa, e recupera i metadati (informazioni
come ad esempio la dimensione e il tipo) relativi alle immagini
2.1.4 Cinder – Block Storage
Il servizio di OpenStack Block Storage aggiunge storage permanente per una
macchina virtuale. Block Storage fornisce un'infrastruttura per la gestione dei
volumi, e interagisce con OpenStack Compute per fornire i volumi alle istanze. Il
servizio consente inoltre la gestione degli snapshot di volume, e tipi di volume.
Il servizio Block storage è costituito dai seguenti componenti:
 cinder-api: accetta richieste API, e li indirizza verso il cinder-volume
 cinder-volume: interagisce direttamente con il servizio di block storage, e con
processi come cinder-scheduler. Inoltre interagisce anche con questi processi
attraverso una coda di messaggi. Il servizio di cinder-volume risponde per
leggere e scrivere le richieste inviate al servizio di Block Storage per
mantenere lo stato. Può interagire con una varietà di fornitori di storage
attraverso un'architettura a driver
 cinder-scheduler: seleziona il nodo di archiviazione ottimale su cui creare il
volume. Un componente simile alla nova-scheduler
2.1.5 Swift – Object Storage
Analogamente, anche il servizio di OpenStack Object Store (Swift) gestisce via
software grandi quantità di spazio disco, potenzialmente scalabile fino a diverse
centinaia di petabyte. Swift non offre solo un servizio di object storage ma integra
nativamente funzionalità di Content Delivery Network, e quindi di replica
geografica con accesso al medesimo dato da punti differenti in base alla latenza
minore.
Ogni “oggetto” viene memorizzato utilizzando un path derivato dall'hash del file e
dal timestamp dell'operazione, così da assicurare che verrà servita sempre l'ultima
versione disponibile. Tutti gli oggetti vengono raggruppati in strutture logiche
denominate “ring”, che si occupano di mappare i singoli oggetti alla loro posizione
fisica, utilizzando come coordinate le zone, i dispositivi, le partizioni e le repliche.
Il concetto di partizione serve ad assicurare una equa distribuzione dei dati, in quanto
28
ogni partizione sarà distribuita tra tutti i dispositivi che fanno parte dell'installazione;
mentre il concetto di zona serve ad assicurare la replicazione dei dati, in quanto il
sistema assicura una replica delle partizioni per ogni zona presente, dove la zona può
rappresentare
un
disco,
un
server
o
anche
un
datacenter.
Particolare attenzione merita la possibilità di associare un “peso” ai dispositivi fisici
dell'infrastruttura, funzionalità che permette di avere una distribuzione dei dati
bilanciata equamente anche quando vengono utilizzati dischi di differenti
dimensioni.
L'elenco degli oggetti presenti sullo storage è mantenuto da un servizio chiamato
Container Server, che non è a conoscenza di dove fisicamente risiede un singolo
oggetto ma semplicemente associa gli oggetti ai relativi Container.
Così come i Container Server associano gli oggetti ai Container, l'elenco di questi
ultimi è mantenuto da uno o più Account Server, che si occupano, quindi, di
associare i Container ai relativi Account. Tutta la complessità dell'architettura di
storage viene celata all'esterno dal servizio Proxy Server, che esponendo
pubblicamente delle API, per ogni richiesta ricevuta ricercherà la posizione
dell'account, del container o dell'oggetto, ridirigendo la richiesta al server opportuno.
La sicurezza del dato, a livello di singolo disco fisico, è garantita da un filesystem
cifrato basato su tecnologia LUKS. Ai livelli superiori, la scelta del metodo di
cifratura è lasciato all’utente: nel caso del block storage è l’utente che formatta il
proprio volume, mentre nel caso dell’object storage possono essere utilizzati
software di terze parti che cifrano gli oggetti prima di scriverli su Swift. Tutte le
comunicazioni di tipo storage che attraversano reti non sicure sono cifrate con SSL.
2.1.6 Horizon - Dashboard
La dashboard di OpenStack, nota anche come Horizon, è un'interfaccia Web che
consente agli amministratori di cloud e agli utenti di gestire le varie risorse e servizi
di OpenStack.
La dashboard consente interazioni web-based con la cloud OpenStack attraverso le
API. E’ utilizzabile per la gran parte delle operazioni di base, ma non offre la
possibilità di eseguire in modo esaustivo tutti i comandi disponibili da shell.
2.1.7 Neutron – Network service
OpenStack Networking è un sistema per la gestione delle reti e degli indirizzi IP.
OpenStack Networking assicura che la rete non sarà il collo di bottiglia o fattore
limitante in una cloud e offre agli utenti una reale gestione self-service anche delle
loro configurazioni di rete.
29
OpenStack Networking fornisce differenti modelli di rete per le diverse applicazioni
o i gruppi utente. I modelli standard includono flat networks o VLAN per la
separazione del traffico. OpenStack Networking gestisce gli indirizzi IP,
consentendo l'assegnazione di indirizzi IP statici dedicati oppure tramite DHCP.
All’interno di ogni progetto gli utenti possono creare una o più reti private e uno o
più apparti di rete con cui connettere le reti in vario modo, indipendentemente da
come il proprio vicino di tenant abbia configurato la propria rete e questo è possibile
grazie all’utilizzo dei NAMESPACE di linux [15].
I floating IP sono indirizzi che consentono di reindirizzare il traffico in modo
dinamico a qualsiasi risorsa di calcolo gestita da OpenStack, questa caratteristica
può essere utile in caso di manutenzione programmata o in caso di guasto. Gli utenti
possono creare le proprie reti, controllare il traffico e collegare server e dispositivi
per una o più reti.
Un’altra tipologia di rete è denominata shared network, attraverso la quale si mette
a disposizione dell’infrastruttura OpenStack, una rete esistente nel centro di calcolo
per poter creare delle VM sulla rete stessa, in modo da poter usufruire di servizi di
rete presenti. In questa tipologia di rete le policy della rete non sono gestite da
OpenStack e alle varie istanze viene fornito un indirizzo ip direttamente dal server
DHCP della rete alla quale ci si connette.
Gli amministratori possono sfruttare la tecnologia SDN come OpenFlow per
consentire elevati livelli di multi-tenancy e massive scale. OpenStack Networking
ha un extension framework che consente la messa in campo e la gestione di servizi
di rete aggiuntivi, come IDS, bilanciamento del carico, firewall e VPN.
Gli
utenti finali posso interagire con i servizi di Neutron o attraverso Horizon, oppure
attraverso API specifiche di ogni servizio, utilizzate tra l’altro per lo scambio di
informazioni tra i vari servizi.
Oltre ai servizi sopra citati, esistono delle estensioni per Neutron, degni di nota:
FWaaS e VPNaaS.
Queste estensioni forniscono funzioni ausiliare, deducibili dai nomi (Firewall e
VPN), per apportare maggiore sicurezza all’interno delle istanze.
2.1.8 VPN as a Service
VPN as a Service è un’estensione della suite di OpenStack che offre la possibilità di
connettere reti private, appartenenti a tenant diversi, tra di loro e/o con la rete
pubblica attraverso una connessione sicura
30
Inoltre offre la possibilità di connessione anche fra siti distribuiti geograficamente
(Hybrid Cluod, Cloud Multiregion – il caso dell’ INFN [16] [17])
Figura 11. VPNaaS - Site to Site
Il VPNaaS fornisce alle tenants di OpenStack la possibilità di estendere le proprie
reti privati attraverso l’infrastruttura pubblica. Le funzionalità offerte da questa
implementazione iniziale di VPNaaS sono:
 connessioni Site-to-Site tra due reti privati
 Supporto IKEv1(Internet Key Exchange ) policy con 3des, aes-128/192/256
 Supporto IPSec (Internet Procotol Security) con 3des, aes-128/192/256, sha1
authentication, ESP, AH, AH-ESP transform protocol e incapsulamento
tunnel or transport mode
 Deed-Peer-Detection
Questa estensione introduce nuove risorse:
 IKE Policy - Internet Key Exchange Policy: Identifica gli algoritmi di
autenticazione e crittografia usati
 durante le fasi 1 e 2 della negoziazione di una connessione VPN
 IPSec Policy - IP Security Policy: Identifica gli algoritmi di autenticazione e
crittografia e il metodo di incapsulamento usati a connessione VPN stabilita
 VPN Service - Virtual Private Network Service: Associa la VPN con un router
e una subnet specifici
 IPSec Site Connection: Specifica i dettagli della connessione site-to-site
2.1.9 Firewall as a Service
L'estensione FWaaS fornisce agli utenti di OpenStack la possibilità di utilizzare
firewall come servizio della cloud per proteggere le loro reti. L'estensione FWaaS in
particolare consente di:
 Applicare regole firewall sul traffico in entrata e uscita per le tenant networks.
31
 Supporto per l'applicazione di TCP, UDP, ICMP, creazione e condivisione
delle politiche del firewall che tengono un insieme ordinato di regole.
Questa estensione introduce dei nuovi concetti/risorse quali:
 firewall: rappresenta una risorsa logica, firewall, che una tenant può istanziare
e gestire. Un firewall è associato a una firewall_policy.
 firewall_policy: è un insieme ordinato di firewall_rules. Una firewall_policy
può essere condivisa tra più tenant.
 firewall_rule: rappresenta un insieme di attributi come porte, indirizzi IP che
definiscono criteri di corrispondenza e di azione (consentire, o negare) che
devono essere prese sul traffico dati abbinato
Il plug-in Firewall-as-a-Service (FWaaS) aggiunge un firewall di perimetro per
filtrare il traffico al neutron router, mentre le security groups sono attive a livello di
istanza.
Figura 12. Posizionamento logico di FWaaS in OpenStack
32
CAPITOLO 3
OpenStack: Installazione e test
3.1 PRELIMINARI
Per l’installazione di OpenStack si è fatto riferimento alla guida fornita [18], in
particolare per gli aspetti riguardanti la configurazione delle varie macchine e la
suddivisione dei vari servizi della cloud. Prima di procedere dobbiamo definire
alcune parole chiave:
Controller Node: è la macchina che orchestra e gestisce i vari servizi
Network Node: è la macchina che si occupa di tutto ciò che concerne la rete di
OpenStack, ovvero che isola le varie istanze virtuali e che fornisce connettività a
internet all’interno dell’infrastruttura
Compute Node: è necessario che ci sia almeno un compute node per ogni
installazione. E’ la macchina che si occupa di eseguire le istanze virtuali istanziate
all’interno del cloud
Block Storage Node: il block storage node è la macchina a cui sono delegati i servizi
di storage, intesi come volumi logici da associare all’istanze
Object Storage Node: è la macchina che si occupa di conservare dati in modo
permanente, indipendentemente dall’ istanza
Tutte queste macchine cooperano tra di loro attraverso un’infrastruttura di rete e per
ottimizzare la velocità di iterazione tra i vari servizi, viene suggerito di creare per
ogni servizio un host e per i servizi di storage si consiglia l’utilizzo di un bus
dedicato, in modo che un traffico di dati elevato sulla rete di storage, non influenzi
negativamente il lavoro con il resto del cloud.
A tale scopo, l’intera infrastruttura di OpenStack sfrutta più reti
contemporaneamente ognuna con un ruolo prefissato: se per le reti di storage non
c’è bisogno di dare molte spiegazioni, diverso è il discorso per le reti di management,
external network e tunnel.
La rete di management si occupa dell’iterazione dei servizi all’interno della cloud,
dunque viaggiano esclusivamente richieste interne all’infrastruttura.
L’ external network è l’interfaccia di rete che fornisce connettività internet all’intera
cloud. Tale interfaccia è presente esclusivamente sul network node.
33
La tunnel network è la rete che utilizzano le istanze per comunicare con il resto del
mondo, attraverso tunnel GRE (di default).
Dunque lo schema suggerito dalla guida di installazione di OpenStack, è riportato di
seguito:
Figura 13. Architettura consigliata per l'installazione di OpenStack
3.2 PREPARAZIONE E CONFIGURAZIONE DELLA RETE PER
OPENSTACK
Per un’installazione di test come la nostra, alcune cose risultano non strettamente
necessarie e per semplificare il tutto abbiamo adattato l’infrastruttura suggerita, al
nostro scopo: abbiamo accorpato in un unico node le funzionalità del controller node
e del network node, i server per lo storage sono stati del tutto tralasciati, e per il
servizio di block storage abbiamo utilizzato il controller node con l’aggiunta di un
volume logico dedicato.
34
Per quello che riguarda le reti, la nostra installazione ne ha tre: l’external network,
la management network e la tunnel network: i servizi di storage, nel nostro caso
viaggiano attraverso la rete di management.
Le macchine utilizzate per il conseguimento del nostro scopo, inizialmente erano
due: una macchina virtuale destinata alle funzionalità di controller e network node e
un server fisico dedicato alla computazione.
Le scelte sono state fatte tenendo in considerazione due problematiche:
1. durante i test, è normale sbagliare qualcosa ed è più facile utilizzare la
funzionalità di snapshot per il restore ad uno stato funzionante di una
virtual machine, invece di andare a tentativi nella speranza di fixare
l’eventuale problema
2. dato che le istanze del cloud, sono virtualiazzate ci è sembrato opportuno
avere un server fisico dedicato per ottimizzare le prestazioni delle singole
istanze del cloud, piuttosto di avere ambienti virtualizzati in ambienti
virtualizzati
Per la rete invece, utilizzavamo la rete del Dipartimento di Fisica.
Su entrambe le macchine abbiamo installato una Scientific Linux 6 e abbiamo
utilizzato la release IceHouse di OpenStack.
Ci siamo ben presto accorti che una tale implementazione era da maneggiare con
cura: il primo grosso problema che abbiamo riscontrato, era la configurazione del
servizio neutron sul controller node. Neutron, come già detto, si occupa di
virtualizzare il livello2 e il livello3, e nonostante avessimo apparentemente attuato
una configurazione corretta sulle macchine, si è tuttavia verificato uno spiacevole
inconveniente legato alla presenza di un ciclo nel controller che mandava in loop la
rete dipartimentale con un conseguente blocco di alcuni servizi dipartimentali.
Dunque, abbiamo deciso di rivedere l’infrastruttura iniziale e abbiamo optato per un
cambiamento che ci avrebbe permesso di isolare il nostro ambiente di test dalla rete
dipartimentale, in modo da prevenire ulteriori malfunzionamenti.
Abbiamo realizzato all’interno di vSphere il nostro ambiente, e inserito un Bastion
host virtuale (computer specializzato nell’isolare una rete locale da una connessione
internet pubblica, creando uno scudo che permette di proteggere la rete locale).
Inoltre abbiamo deciso di inserire nel nuovo ambiente anche un secondo compute
node: consci di quanto detto sul degrado delle prestazioni di istanze virtuali in
ambienti virtuali, il suo scopo prevedeva il semplice test della configurazione, che
solo successivamente si sarebbe riportata sul compute node fisico.
35
Non ci restava che collegare il compute node fisico all’interno del nostro ambiente
virtuale, e ripartire di nuovo con l’installazione di tutti i servizi.
Figura 14. Configurazione architetturale e dei servizi dell’installazione di test
Un altro problema che abbiamo riscontrato durante l’installazione di OpenStack
IceHouse, si è presentato durante l’installazione dei servizi di cinder: siamo
incappati in un noto bug di OpenStack, legato alla gestione delle partizioni LVM.
La soluzione era cambiare il tipo di partizione usata: varie ricerche ci suggerivano
di passare ad usare Gluster FS, ma al col tempo era uscita la nuova release di
OpenStack: Juno.
Da qui, la scelta di abbandonare IceHouse e ripartire con Juno, mantenendo
l’infrastruttura illustrata.
La nuova release necessitava di una CentOS7 e così abbiamo resettato le macchine
virtuali e installato Scientific Linux 7 anche sul compute fisico. Durante la fase di
installazione di Juno, non sono stati rilevati problemi legati a malfunzionamenti di
alcun tipo, e il processo si è concluso senza troppi problemi.
36
Figura 15. Esempio di Snapshot
37
3.3 INSTALLAZIONE SERVIZI
Illustriamo adesso i vari step, che si sono resi necessari, per l’installazione di tutti i
servizi che ci servono per raggiungere il nostro scopo. OpenStack struttura come
segue l’installazione dei vari servizi:
Figura 16. Suddivisione consigliata per l’installazione dei servizi di OpenStack
Nel nostro caso, lo schema seguente rappresenta i pacchetti necessari da installare
sulle varie macchine per erogare i servizi della cloud. Dato che abbiamo deciso di
non usare un nodo dedicato al Block Storage, sul controller abbiamo installato i
servizi di Cinder, in modo da poter associare alle istanze nella cloud almeno un
volume logico sul quale eventualmente installare il sistema operativo per le varie
istanze.
38
Figura 17. Suddivisione servizi nell'installazione di test
L’installazione dei repository di OpenStack è il primo passo che ci consente di poter
utilizzare l’utility yum per installare i pacchetti necessari e le relative dipendenze.
3.3.1 Keystone - Installazione e configurazione
L’identity service è stato installato sul controller. Di default [19] sfrutta un backend
MySQL per lo store degli utenti e il service catalog.
L’installazione ha inizio:
yum install openstack-keystone python-keystoneclient
39
Adesso si procede con la configurazione del file keystone.conf attraverso openstackconfig
openstack-config --set /etc/keystone/keystone.conf \
database connection
mysql://keystone:[email protected]/keystone
Sul controller node serve avere MySQL e al suo interno dobbiamo creare
manualmente il database per Keystone e settare i relativi previlegi
mysql -u root -p
CREATE DATABASE keystone;
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY
'keystonepass';
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' IDENTIFIED BY
'keystonepass';
exit
Creato il database, col seguente comando vengono opportunatamente create le
tabelle e i record necessari (di default)
su -s /bin/sh -c "keystone-manage db_sync" keystone
Attraverso openssl generiamo un token, da impostare nel keystone.conf che ci
consentirà di eseguire le query all’identity service. Seguono altri parametri di
configurazione:
Auth_token
ADMIN_TOKEN=$(openssl rand -hex 10)
echo $ADMIN_TOKEN
openstack-config --set /etc/keystone/keystone.conf DEFAULT admin_token
$ADMIN_TOKEN
keystone-manage pki_setup --keystone-user keystone --keystone-group
keystone
chown -R keystone:keystone /etc/keystone/ssl
chmod -R o-rwx /etc/keystone/ssl
service openstack-keystone start
chkconfig openstack-keystone on
40
3.3.1.1 Creazione utenti, tenants e ruoli
Keystone per fare autorizzazioni si basa sulla definizione di regole e sul concetto di
tenants. Ogni tenant ha un determinato scope, e per ogni scope vengono impostati
determinati privilegi. Di default l’installazione di test prevede l’uso di 3 gruppi:
 Admin: in questo gruppo esiste solo l’utente admin, membro dell’intera
infrastruttura cloud
 Service: in questo gruppo vengono registrati i vari servizi di OpenStack, in
quanto prima di comunicare tra di loro anch’essi necessitano di autenticazione
e autorizzazioni
 Demo: è un gruppo creato per l’utente di test che ha solo la possibilità di
gestire il suo spazio di lavoro limitato alla sua tenant.
export OS_SERVICE_TOKEN=ADMIN_TOKEN
export OS_SERVICE_ENDPOINT=http://cloud98.fis.unipr.it:35357/v2.0
--Admin
keystone
keystone
keystone
keystone
keystone
user-create --name=admin --pass=adminpass --email=ADMIN_EMAIL
role-create --name=admin
tenant-create --name=admin --description="Admin Tenant"
user-role-add --user=admin --tenant=admin --role=admin
user-role-add --user=admin --role=_member_ --tenant=admin
--Demo
keystone user-create --name=demo --pass=demopass --email=DEMO_EMAIL
keystone tenant-create --name=demo --description="Demo Tenant"
keystone user-role-add --user=demo --role=_member_ --tenant=demo
--Service Tenant
keystone tenant-create --name=service --description="Service Tenant"
41
3.3.1.2 Creazione servizio ed API
Così come tutti i servizi di OpenStack, Keystone utilizza delle REST API. Di default,
tutti gli endpoint esposti utilizzano il protocollo http, in maniera non cifrata, su
determinate porte di servizio. Per Keystone si utilizzano le porte 5000 per le richieste
pubbliche, mentre la 35357 per la parte amministrativa.
Attraverso i seguenti comandi, gli endpoint vengono memorizzati all’interno del
database MySQL
keystone service-create --name=keystone --type=identity -description="OpenStack Identity"
keystone endpoint-create
--service-id=$(keystone service-list | awk '/ identity / {print $2}')
--publicurl=http://cloud98.fis.unipr.it:5000/v2.0
--internalurl=http://cloud98.fis.unipr.it:5000/v2.0
--adminurl=http://cloud98.fis.unipr.it:35357/v2.0
Figura 18. Screenshot della fase d'installazione
3.3.1.3 Verifica
Una semplice verifica dell’installazione di OpenStack consiste nel rimuovere le
variabili d’ambiente in cui erano immagazzinati i token e gli endpoint, per poi
eseguire una richiesta da terminale.
Precisamente vengono effettuate due richieste a Keystone: la prima riguarda la
richiesta di un token di autenticazione, rilasciato dopo aver fornito nome utente e
password, la seconda effettua la richiesta vera e propria verso il servizio target, che
identifica il richiedente attraverso il token.
42
unset OS_SERVICE_TOKEN OS_SERVICE_ENDPOINT
keystone --os-username=admin --os-password=adminpass --os-auth-url =
http://cloud98.fis.unipr.it:35357/v2.0 token-get
keystone --os-username=admin --os-password=adminpass --os-tenantname=admin--os-auth-url=http://cloud98.fis.unipr.it:35357/v2.0 tenantlist
keystone --os-username=admin --os-password=adminpass --os-tenantname=admin --os-auth-url=http://cloud98.fis.unipr.it:35357/v2.0 userlistd
Figura 19. Screenshot della fase d'installazione
3.3.1.4 Esempio di keystone.conf
[DEFAULT]
admin_token=cb7b539565eb2717c229
debug=true
verbose=true
[auth]
auth_protocol = https
auth_uri = https://controller:5000/v2.0
identity_uri = https://controller:35357
insecure = true
methods = password,token
[database]
connection=mysql://keystone:[email protected]/keystone
[token]
provider = keystone.token.providers.uuid.Provider
driver = keystone.token.backends.sql.Token
43
3.3.2 Installazione servizi - Glance
Per glance [20] è stato deciso di utilizzare lo spazio di storage a disposizione sulle
nostre macchine per immagazzinare le immagini di maggiore interesse. Ad esempio
abbiamo registrato in glance le immagini relative a una versione basilare di linux
chiamata cirrOS, che consente di testare se i servizi di nova sono configurati
correttamente. Successivamente abbiamo aggiunto delle release di Ubuntu e
Scientifc Linux per testare il loro comportamento in ambito cloud.
Figura 20. Screenshot della fase d'installazione
44
Figura 21. Screenshot della fase d'installazione
3.3.3 Installazione servizi – Cinder
Il servizio cinder offre volumi persistenti alle macchine virtuali. Dunque mette a
disposizione un’infrastruttura per la gestione di volumi e interagisce con il servizio
di compute per fornire spazio disco alle istanze.
La sua installazione [21] è suddivisa in:
 Installazione cinder-api
 Installazione cinder-volume
 Installazione cinder-scheduler
Per semplicità, su questa installazione abbiamo utilizzato un unico disco virtuale,
realizzato tramite vSphere, partizionato con LVM, per garantire una facile scalabilità
dato che LVM riesce a utilizzare più dischi fisici, come se fossero un unico volume
logico.
45
3.3.4 Installazione servizi – Nova
Nel nostro caso, avendo un nodo fisico e uno virtuale dedicato al compute, le
configurazioni variano leggermente in quanto per l’host virtuale che non supporta
l’accelerazione hardware, bisogna configurare libvirt per utilizzare QEMU di KVM.
La sua installazione [22] è suddivisa in:








Installazione nova-api
Installazione nova-api-metadata service
Installazione nova-compute service
Installazione nova-scheduler service
Installazione di nova-scheduler module
Installazione di nova-network
Installazione di nova-consoleauth
Installazione di novncproxy
3.3.5 Installazione servizi – Neutron
L’installazione e la configurazione di neutron è sostanzialmente la parte tragica di
tutta l’infrastruttura di OpenStack.
Tale servizio si occupa di gestire la comunicazione tra le varie macchine del cloud
e le varie istanze virtuali, tutto a livello software, sfruttando plug-in tipo ML2-plugin
per la simulazione del livello 2 della pila iso/osi e L3-plugin per il livello 3 e
strumenti quali Open vSwitch.
La sua installazione [22] è suddivisa in:




Installazione neutron-server
Installazione neutron-ml2 plug-in
Installazione neutron-openvswitch
Installazione neutron-L3_agent plug-in
A fine installazione di tutti i pacchetti sulle rispettive macchine, si è proceduto poi
inizializzando la rete e suddividendo le varie interfacce per gli scopi prefissi.
Di seguito uno grafico su come neutron interagisce con le istanze per fornire
connettività:
46
Figura 22. Diagramma funzionale di Neutron
47
3.3.6 Installazione servizi – Dashboard
L’installazione [23] della dashboard è abbastanza semplice, in quanto basta aver
installato apache e successivamente impostare qualche parametro, dopo di che l’url
http://controller/dashboard risulta funzionante.
48
CAPITOLO 4
Caso d’uso: Il cloud dell’INFN
Ma cosa si può fare realmente con OpenStack?
La nostra installazione di test, è nata per far fronte a necessità di studio e non per
supportare una mole di lavoro tale da poterla prendere in considerazione in un
contesto reale, né tanto meno ne rispecchia fedelmente caratteristiche e funzioni.
Guardiamo un caso reale…
4.1 PRESENTAZIONE DEL CLOUD MULTI-REGION
L’INFN (Istituto Nazione di Fisica Nucleare) è da anni ha operativo un servizio di
grid computing dedicato alla ricerca: è stato uno dei promotori con il CERN del
progetto Grid computing per Lhc (Wlcg) [24] e oggi è fortemente impegnato a
garantire la regolare gestione di numerosi aspetti relativi alla produzione,
archiviazione, sicurezza, funzionalità e management dell’infrastruttura Grid
dell’esperimento.
Ad oggi, sta lavorando a un progetto, con la collaborazione dell’IGI (Italian Grid
Infrastructure) e EGI (European Grid Initiative) che tende a rendere più facile
e flessibile l’accesso alle infrastrutture di calcolo distribuite, come la Grid, con lo
sviluppo di una nuova interfaccia web e l’uso di ambienti virtuali che permettono ad
ogni utente di acquisire e usare via Internet le risorse del tipo che vuole, quando le
vuole e per il tempo a lui strettamente necessario: questo sforzo è noto come Cloud
Computing e per raggiungerlo si basano su una cloud OpenStack con risorse
dislocate in più sedi INFN geo-distribuite.
Questa infrastruttura si appoggia ad un unico Identity Service (Keystone) distribuito
e ridondante e si avvale del concetto di regione per la suddivisione logica delle
risorse.
Si appoggia inoltre ad un servizio di object storage (Swift) anch’esso distribuito e
replicato su più sedi. In dettaglio sono coinvolte 5 sedi: Bari, Laboratorio Nazionale
del Gran Sasso, Padova Roma 2 e Roma 3.
49
Figura 23. Cloud Multi-Region
Keystone è distribuito su 3 sedi (ba lngs pd) su db Mysql nativo mentre Swift
distribuito anche lui ma su 4 sedi (ba lngs pd rm2).
4.1.1 Scelte Implementative
Perché avere Keystone distribuito?
Il servizio di identità di una infrastruttura cloud distribuita deve essere sempre
disponibile anche in caso di interruzione del collegamento ad un intero sito e deve
perciò essere dislocato in più sedi. Come già detto, questo obiettivo è stato raggiunto
realizzando un cluster di tre server Keystone in tre sedi diverse. Il database SQL
usato come back-end è replicato sui tre siti usando Percona XtraDB cluster, una
soluzione di High Availability per cluster MySQL.
Per ottimizzare le performance, poiché la replica è sincrona e per garantire la
consistenza delle transazioni si è preferito fare in modo che uno solo dei server
Keystone sia attivo in ogni istante, mentre un secondo server è pronto a prendere il
posto.
50
Il terzo server ha lo scopo di contribuire a stabilire il quorum del cluster e può
diventare il server attivo nel caso improbabile di failure dei primi due.
Come comunicano tra di loro le varie sedi?
E’ ancora in fase di test e ha bisogno di maggior tempo per maturare, ma attualmente
le varie regioni comunicano tra di loro attraverso l’estensione VPNaaS di neutron
[17].
4.1.2 Limitazioni
Un potenziale problema che si evince da questa installazione, è legata dalla presenza
di un bacino di utenze che dovranno cooperare con la cloud. In un ambiente di test
come il nostro, l’utilizzo di un backend MySQL per la gestione degli account è più
che sufficiente e avere Keystone configurato in High availability di certo va ben oltre
i nostri scopi: ma quando si ha a che fare con una vasta comunità, una valida
alternativa per l’autenticazione viene offerta dall’ autenticazione federata.
In questo modo non c’è più bisogno di dover farsi carico della gestione delle utenze,
ma basterà integrare gli IdP remoti di ogni singolo ente che appartiene alla
federazione, per poter garantire l’accesso alle risorse e poter comunque gestire le
policy di autorizzazione di Keystone.
Entrando in contatto con alcuni ricercatori dell’INFN, che si stanno occupando di
integrare nella loro installazione di OpenStack IceHouse, l’autenticazione federata,
abbiamo deciso di testare nel nostro piccolo ambiente di test l’autenticazione
federata all’interno di Juno e di analizzare alcuni aspetti che possano incrementare
il livello di sicurezza dell’autenticazione attuale.
51
CAPITOLO 5
Autenticazione e Strong Authentication:
Dalla teoria alla pratica
5.1 AUTENTICAZIONE
L'autenticazione di base è il processo mediante il quale un sistema informatico
identifica positivamente un utente, ed è generalmente richiesta per accedere in
sicurezza ai dati o entrare in una rete sicura.
Per l’identificazione è possibile utilizzare uno dei seguenti metodi:
 Qualcosa che si ha (token, certificato personale)
Bisogna avere con se il token o il certificato personale
 Qualcosa che si conosce (username/password, pin)
Facile da utilizzare
 Qualcosa che si è (lettura biometrica retina, impronta digitale)
Efficace ma tecnologicamente costoso
Il sistema di autenticazione dominante oggi, si basa su nomi utente e password,
comunemente considerato uno dei metodi di sicurezza più deboli del computing
moderno.
Di default è il sistema utilizzato nell’ autenticazione di OpenStack dove nome utente
e password sono memorizzati in un db MySQL.
5.1.1 Autenticazione Federata
L’autenticazione federata è una tecnica di autenticazione adottabile all’interno di
una federazione e nasce per rispondere ad un bisogno di gestione decentralizzata
degli utenti consentendo ad ogni gestore federato di mantenere il controllo della
propria politica di sicurezza.
Attraverso l’autenticazione federata è possibile garantire l’accesso a risorse web (al
cloud) a utenti esterni alla propria organizzazione, appartenenti ad enti e aziende
52
diverse, che fanno tutte parte della stessa federazione, senza la necessità di dover
registrare ogni singolo nuovo utente all’interno dell’identity service della cloud,
grazie a una relazione di fiducia tra gli enti federati.
Quando si parla di autenticazione federata bisogna identificare i soggetti coinvolti
in primis IDP, SP.
 Identity Service Provider
Ogni organizzazione ha un proprio database all’interno del quale memorizza le
credenziali/policy di accesso alle risorse IT per i propri utenti. Nella maggior parte
dei casi si è in presenza di una vera e proprio infrastruttura di autenticazione e
autorizzazione, più che di un semplice database. L’ IdP è il servizio al quale si fa
riferimento quando si necessita di autenticare un utente a una risorsa in un contesto
federato
 Service Provider
Il service provider (letteralmente fornitore del servizio), è la risorsa che un ente
federato mette a disposizione, e alla quale un utente cerca di accedere.
Nel nostro ambiente di test, il service provider è il cloud98 che rappresenta il punto
d’accesso della risorsa, mentre come IdP abbiamo utilizzato TestSHIB per una prima
fase di test e successivamente l’IdP dell’Università degli Studi di Parma.
Il processo di autenticazione avviene, in buona sostanza, nei seguenti termini:
a) l’utente richiede la connessione ad una risorsa protetta facendo sì che il SP
intercetti la richiesta (la risorsa da proteggere è definita nei files di configurazione
del web server che la ospita);
b) il SP, basandosi sulla configurazione di cui sopra, determina a quale IdP far
riferimento e quale protocollo utilizzare attraverso un meccanismo di “scoperta”
noto come servizio WAYF (acronimo di Where Are You From): la richiesta di
autenticazione è così delegata al WAYF che la passa all’IdP selezionato dall’utente;
c) come risultato delle azioni precedenti, una richiesta di autenticazione via browser
è inviata dal SP all’IdP selezionato dall’utente: l’IdP decide se l’utente può
autenticarsi e quali attributi inviare al SP, scelta questa basata prevalentemente sulle
caratteristiche del SP che fornisce il servizio e su quelle dell’attributo principale
dell’utente;
d) l’IdP impacchetta e firma i dati che trasmette sotto forma di asserzione SAML al
SP che la spacchetta e la decodifica eseguendo poi una serie di controlli di sicurezza
per decidere infine se il richiedente abbia o meno diritto di accesso alla risorsa
desiderata;
53
e) infine, se il processo di verifica del punto precedente ha esito positivo, l’utente
viene finalmente ridiretto alla risorsa richiesta.
La figura sotto illustra il processo di autenticazione.
Figura 24. Diagramma per il funzionamento dell'autenticazione federata
Come si può vedere da quanto sopra esposto, il processo di autenticazione avviene
sull’IdP del richiedente e non sul SP che tale risorsa distribuisce; in parole semplici,
l’utente si autentica presso la sua propria organizzazione, utilizzando una sola coppia
di credenziali per più servizi ed evitando di dover allocare una coppia di credenziali
per ogni fornitore di servizi.
5.1.2 Integrazione dell’autenticazione federata in OpenStack
Una volta terminata l’installazione di default di OpenStack e fatto le dovute
osservazioni, l’attenzione si è spostata sulla tematica oggetto di tesi.
Abbiamo analizzato dunque quali altri backend per l’autenticazione Keystone
offrisse, oltre al classico database MySQL. Durante questo studio tra le varie opzioni
abbiamo deciso di concentrare la nostra attenzione sull’autenticazione federata,
oggetto di interesse anche da parte dell’INFN per il loro progetto di ricerca verso il
cloud multiregion, che attualmente usa MySQL.
Per far ciò, come prima cosa abbiamo ritenuto opportuno che in ambito cloud le
connessioni http dovessero essere cifrate. Abbiamo dunque richiesto all’ INFN un
54
certificato x509 per cloud98, e lo abbiamo installato nel server di apache attraverso
mod_nss. Una volta configurato correttamente il certificato e testato il
funzionamento, abbiamo deciso di negare le richieste http per le API di Keystone in
modo da evitare la possibilità di strippare il traffico ssl e bloccare un potenziale
rischio per il furto delle credenziali.
Queste operazioni hanno portato a rivedere alcuni paramenti di default della
configurazione dei vari servizi della cloud, in particolare in quello di Keystone dove
è stato necessario inserire i certificati del server e la chiave per poter erogare
comunicazioni sicure e inoltre all’interno del database Keystone di MySQL, i vecchi
endpoint http sono stati rimpiazzati dai nuovi https.
Documentandoci su come poter implementare l’autenticazione federata in
OpenStack, abbiamo scoperto che esiste un’estensione chiamata OS_Federation [25]
che fa proprio questo.
Per poter attivare l’OS_Federation erano necessarie alcune operazioni preliminari:
dunque abbiamo messo dietro apache Keystone, in modo da farlo lavorare come
servizio web attraverso WSGI (Web Server Grafic Interface - interfaccia standard
per il web service per la programmazione in python), abilitato l’utilizzo delle
Keystone APIv3 e dell’unversion API [26], quest’ultima non prettamente necessaria,
ma forniva maggior retro compatibilità con l’APIv2.
Successivamente abbiamo installato shibboleth SP, estrapolato i metadati dalla
macchina e gli abbiamo inoltrati presso l’IdP di ateneo, che ci ha fornito i metadati
dell’IdP e i seguenti attributi:
<Attribute
<Attribute
<Attribute
<Attribute
<Attribute
name="urn:oid:1.3.6.1.4.14657.1.1.3.7" id="corsolaurea"/>
name="urn:oid:1.3.6.1.4.14657.1.1.3.5" id="matricola"/>
name="urn:oid:1.3.6.1.4.14657.1.1.3.42" id="uniprId"/>
name="urn:oid:1.3.6.1.4.14657.1.1.3.45" id="principal"/>
name="urn:oid:1.3.6.1.4.14657.1.1.3.49" id="uniprStudDip"/>
Il passo successivo era mappare gli attributi forniti dall’IdP, in modo che Keystone
possa comprenderne il significato.
Per far ciò, è necessario creare dei gruppi, ad ogni gruppo vanno associati una
combinazione di attributi in modo da mappare gli attributi remoti su attributi locali.
I gruppi in questione, per ovvie ragioni, possono essere creati esclusivamente
dall’amministratore della cloud.
55
Di seguito i passi per autenticarsi e richiedere un token e successivamente la
creazione del gruppo:
curl -k https://localhost:5000/v3/auth/tokens \
-s \
-i \
-H "Content-Type: application/json" \
-d '
{
"auth": {
"identity": {
"methods": [
"password"
],
"password": {
"user": {
"domain": {
"name": “admin"
},
"name": "admin",
"password": “adminpass"
}
}
},
"scope": {
"domain": {
"name": “admin"
}
}
}
}'
curl -k -X POST https://localhost:5000/v3/groups \
-s \
-H "X-Auth-Token: 898f8e73b78c42d5921fe237c7cbf9bf" \
-H "Content-Type: application/json" \
-d ' \
{
"group": {
"description": "Test group",
"domain_id": “00001",
"name": "Group1"
}
}’
56
Creati tutti i gruppi di cui si necessita, bisogna associarli a determinati
configurazioni di attributi forniti attraverso SAML2 dall’ IdP, come ad esempio
l’associazione di gruppi in base al corso di laurea:
curl -k -X POST https://localhost:5000/v3/groups \
-s \
-H "X-Auth-Token: 898f8e73b78c42d5921fe237c7cbf9bf" \
-H "Content-Type: application/json" \
-d ' \
{
"mapping": {
"rules": [
{
"local": [
{
"user": {
"id": "local_id"
}
}
],
"remote": [
{
"type": "uniprId"
}
]
},
{
"local": [
{
"group": {
"id": " id_local_group"
}
}
],
"remote": [
{
"type": "corsolaurea",
"any_one_of": [
"id_corso_laurea"
]
}
]
}
]
}
}
57
Figura 25. Diagramma per il funzionamento dell'autenticazione federata nell'ambiente di test
5.2 STRONG AUTHENTICATION
L’autenticazione basata su nome utente e password è soggetta ad una serie di difetti,
tra cui scelte sbagliate delle password utente, key-manager, phishing, attacchi manin-the-middle ecc....niente di nuovo.
Per ovviare, la soluzione più comune e convincente è l'uso di Strong Authentication,
altrimenti denominato autenticazione a due fattori.
Un sistema di autenticazione a due fattori funziona richiedendo due metodi di
autenticazione simultanee ma indipendenti comunemente indicato come "qualcosa
che si ha e qualcosa che si conosce." Normalmente, il primo fattore (qualcosa che si
ha) comporta hardware o software che fornisce all'utente un passcode generato
elettronicamente, o un certificato digitale che funge da identificatore univoco per un
58
particolare utente. È dunque accoppiato con il secondo fattore (qualcosa che si sa),
come una password e insieme costituiscono un sistema di strong authentication per
consentire l'accesso alle risorse critiche come una rete aziendale. Sistemi di
autenticazione a due fattori sono molto più sicuri del semplice “nome utente e
password” perché è molto difficile per gli utenti non legittimi poter ottenere entrambi
questi fattori.
Secondo gli esperti, l'autenticazione a due fattori riduce drasticamente l'incidenza di
furto di identità on-line, attacchi di phishing, MITM e altre frodi online, perché la
password della vittima non è più sufficiente a fornire un accesso alle loro
informazioni. Quando si trasferisce la parte IT di un’azienda nel cloud, bisognerebbe
tenerne conto.
5.2.1 Politiche di autenticazione e password
In generale, la maggior parte dei service provider hanno risposto a un numero
crescente di minacce alla sicurezza utilizzando tecnologie obsolete "rinforzate".
Oggi, un dipendente continua ad accedere alle informazioni aziendali attraverso l'uso
di una password. Quello che è cambiato è che adesso la password deve essere di
almeno otto o più caratteri, deve includere simboli e numeri, deve avere almeno un
simbolo in maiuscolo e devono essere cambiate spesso nel giro di pochi mesi o più.
Inoltre, il dipendente può avere bisogno di diverse password per accedere a diverse
aree di banche dati di informazioni-diverso, diverse aree di reti interne, ecc.
Il difetto nel richiedere ai dipendenti di memorizzare le nuove password, è evidente.
E il risultato comune è che le password sono semplicemente scritte in una email
salvata o su post-it, o se prima la password era “password” adesso per poterla
ricordare l’utente utilizzerebbe “Password1”, “Password2”, “Password3” oppure nei
miglior dei casi ci si appoggia a sistemi di key-management per immagazzinare tutte
le proprie password cifrate, ovviamente con accesso al keystore protetto da
un’ulteriore password. Non è esattamente quello che il reparto IT di qualsiasi
azienda, aveva in mente.
A supporto di quanto detto, Forrester Consulting [6] ha rilevato che il 27% delle
aziende intervistate richiede agli utenti di "ricordare" almeno 6 password e il 66%
delle aziende hanno almeno sei diverse Password policies. Il risultato è stato che l’
81% delle aziende considera i problemi di password (e in particolare la sfida per gli
utenti di gestire più password complesse con politiche sulla costruzione e scadenza)
essere la più grande lamentela per l'accesso alle informazioni.
59
Con il cloud è ora di guardare avanti e pensare a un nuovo approccio per
l’autenticazione, che consenta e semplifichi l’accesso alle risorse d’uso quotidiano
senza tralasciare la sicurezza. Il tempo per i token e gli alti costi legati alla loro
distribuzione è passato. Oggi, i telefoni cellulari sono onnipresenti e sono tutto
quello che serve per un efficace, all'avanguardia, soluzione di strong authentication.
Questo significa che gli utenti non devono portare tutto ciò che non hanno già con
se in ogni momento, e i provider di non dover sostenere costi per hardware o i costi
di distribuzione e logistica associati. Pertanto, le aziende dovrebbero cercare una
mobile-credential scaricabile per fare strong authentication in modo più conveniente
per gli utenti finali e anche più conveniente per l'impresa.
Uno dei più diffusi sistemi di mobile-credential a disposizione è Google
Authenticator [27]: è un’applicazione che implementa strong authentication
utilizzando OTP time-based che è supportato da diversi siti e applicazioni.
Sostanzialmente è un app, che può essere installata direttamente sul proprio
smartphone (indipendentemente dalla piattaforma usata) e una volta che l’utente
inserisce il proprio nome utente e password per la risorsa che necessità, produce una
OTP di sei caratteri.
Un altro fork open source è chiamato FreeOTP [28] che è stato pubblicato da
RedHAt.
Figura 26. Siti e applicazioni che supportano Google Authenticator
60
5.2.2 OTP – One Time Password
La tecnica della One Time Password non è certo una scoperta fatta di recente (cit.
Enigma [29]), ma è un argomento tornato alla ribalta come secondo metodo di
autenticazione in un contesto di 2FA. L’obiettivo dell’OTP è prevenire attacchi di
tipo replay inficiando tecniche di attacco come il MITM.
Utilizzando infatti l’OTP come secondo metodo di autenticazione, l’utente richiede
l’accesso con la sua coppia di credenziali (username e password) più l’utilizzo di un
pin OTP, che può essere usato una volta sola. Qual ora un attaccante riuscisse a
intercettare entrambi i fattori d’accesso alla risorsa, per esempio attraverso MITM,
un eventuale accesso successivo con i dati intercettati, sarebbe negato in quanto
quell’OTP risulterebbe già consumato.
La sicurezza dell’OTP si basa inoltre sulla non invertibilità delle funzioni hash: come
è noto, un hash crittografico è una funzione unidirezionale che consente di associare
un messaggio di lunghezza arbitraria a un digest di lunghezza fissa. Pertanto, una
soluzione OTP basata su hash inizia con gli input (parametro di sincronizzazione,
chiave segreta, PIN), li esegue tramite la funzione unidirezionale e produce la
password di lunghezza fissa.
Esistono diversi tipi di OTP:
 TOTP – Time based
Sono algoritmi basati sulla sincronizzazione temporale, tra il server di
autenticazione e il client che fornisce la password, in cui le otp sono valide
solo per un lasso di tempo predefinito. Superato l’intervallo di validità quel
pin è bruciato e ne viene generato un altro.
Le soluzioni OTP sincronizzate in base al tempo sono largamente diffuse ma
sono soggette allo sfasamento dei segnali di clock: questo comporta che se
client/server non sono sincronizzati l’autenticazione non avverrà mai in
quanto i valori OTP lato server e lato client risulteranno differenti. La
soluzione è fornita sincronizzando lo stesso NTP server e impostando un
“linger time” sufficientemente ampio da convalidare un pin generato con una
differenza temporale minima, ma non così ampio da compromettere al
contempo la sicurezza del sistema.
 HOTP – Counter based
Sono algoritmi che si basano sulla password utilizzata durante l’ultimo
accesso per generare la nuova. Una soluzione OTP sincronizzata in base al
61
contatore prevede la sincronizzazione di un contatore tra il dispositivo client
e il server. Il contatore viene incrementato ogni volta che viene richiesto un
valore OTP al dispositivo. Analogamente alle soluzioni OTP sincronizzate in
base la tempo, quando l'utente desidera eseguire l'accesso, immette il valore
OTP correntemente visualizzato sul dispositivo. Tutta via, anche questo tipo
di approccio può essere vittima di una errata sincronizzazione: il problema
risiede nella non corretta sincronizzazione dei contatori tra server e client. La
soluzione in questo caso è banale… il server conosce sempre l’ultimo counter
che è stato utilizzato per fare l’ultimo accesso e a partire da questo valore, si
calcola l’hash incrementando progressivamente i valori del counter, fino a
trovare la giusta corrispondenza.
In entrambi gli approcci è richiesto che l’utente porti con se un dispositivo hardware
o un software che viene sincronizzato con un server e che prevedono l’utilizzo di un
algoritmo per la generazione della password.
L’OTP tuttavia, va considerato comunque un sistema vulnerabile: infatti
tecnicamente è possibile che un attaccante possa intercettare tutto il pin OTP o
comunque una buona parte e dedurne la restante per poi concorrere con l’utente
legittimo all’autenticazione. Questo tipo di problema tuttavia è aggirabile se si
consente un'unica sessione di autenticazione per volta, in modo da non avere più
utenti che cercando di autenticarsi con le stesse credenziali allo stesso tempo.
Inoltre una falla nel dispositivo che genera il token, risulta fatale. Ad esempio nei
sistemi OTP che inviano il pin tramite sms può non essere così difficile, che un
attaccante possa intercettare il pin di sicurezza o se si utilizzano gli smartphone la
possibilità di intercettare schermate video o altre forme di dati, se il telefono è
collegato a internet non è fantascienza.
5.2.3 Test integrativo dell’ OTP nell’ ambiente di test
L’autenticazione federata non risolve la problematica dell'utilizzo di un singolo
fattore di autenticazione. Abbiamo dunque testato la possibilità di implementare una
versione casereccia dell'OTP che proteggesse l'accesso alla dashboard di OpenStack,
sfruttato un modulo di apache, denominato mod_authn_otp [30].
La configurazione attuata si basava sull'utilizzo di OTP con l'utilizzo di un contatore:
il server, protegge la risorsa chiedendo ad ogni accesso, delle credenziali (nome
utente, password, pin) attraverso la basic authentication del protocollo HTTP. Non
molto bello da vedere...
62
Lato server, il contatore veniva aggiornato ed incrementato ad ogni accesso, mentre
lato client, attraverso un tool potevamo generare il pin OTP, fornendo un valore al
counter. Con valori casuali (dunque counter non sincronizzati) l'accesso alla risorsa
ci veniva negato, mentre con l'utilizzo del corretto valore del counter l'accesso alla
risorsa veniva garantito.
Un altro dettaglio non irrilevante era come i pin venivano generati dal modulo: ogni
utente doveva essere presente in un file di configurazione testuale, insieme
all’ultimo pin utilizzato e alla sua chiave segreta che consentiva la generazione del
pin. Un approccio sicuramente discutibile, ma comunque funzionale.
# Example users file for mod_authn_otp
#
# Blank lines and lines starting with '#' are ignored. Fields are
whitespace-separated.
#
# Fields:
#
#
1. Token Type
See below
#
2. Username
User's username
#
3. PIN
User's PIN, or "-" if user has no PIN, or "+"
to verify PIN via "OTPAuthPINAuthProvider"
#
4. Token Key
Secret key for the token algorithm (see RFC
4226)
#
5. Counter/Offset
Next expected counter value (event tokens) or
counter offset (time tokens)
#
6. Failure counter
Number of consecutive wrong OTP's provided by
this users (for "OTPAuthMaxOTPFailure")
#
7. Last OTP
The previous successfully used one-time
password
#
8. Time of Last OTP
Local timestamp when the last OTP was generated
(in the form 2009-06-12T17:52:32L)
#
9. Last IP address
IP address used during the most recent
successful attempt
#
#
Fields 5 and beyond are optional. Fields 6 and beyond should be
omitted for new users.
#
# Token Type Field:
#
#
This field contains a string in the format: ALGORITHM [ / COUNTERINFO
[ / DIGITS ] ]
#
#
The ALGORITHM is either "HOTP" (RFC 4226) or "MOTP"
(http://motp.sourceforge.net/).
#
#
The COUNTERINFO is either "E" for an event-based token, or "TNN" for
a time based token
#
where "NN" is the number of seconds in one time interval. For HOTP,
the default is "E";
#
for MOTP, the default is "T10".
#
#
The DIGITS is the number of digits in the one-time password; the
default is six.
#
63
#
Examples:
#
#
HOTP
- HOTP event-based token with six digit OTP
#
HOTP/E
- HOTP event-based token with six digit OTP
#
HOTP/E/8
- HOTP event-based token with eight digit OTP
#
HOTP/T30
- HOTP time-based token with 30 second interval
and six digit OTP
#
HOTP/T60
- HOTP time-based token with 60 second interval
and six digit OTP
#
HOTP/T60/5
- HOTP time-based token with 60 second interval
and five digit OTP
#
MOTP
- Mobile-OTP time-based token 10 second interval
and six digit OTP
#
MOTP/E
- Mobile-OTP event-based token with six digit OTP
#
# For more info see: http://code.google.com/p/mod-authnotp/wiki/UsersFile
#
# Some users who have logged in at least once.
HOTP
barney
1234
8a2d55707a9084982649dadc04b426a06df19ab2
21
0 820658 2009-06-12T17:52:32L 192.168.1.1
HOTP
fred
5678
acbd18db4cc2f85cedef654fccc4a4d8bd537891
78
0 617363 2009-06-04T21:17:03L 192.168.1.2
HOTP/T joe
999999 ef654fccdef654fccc4a4d8acbd18db4cc2f85ce 2
2 883913 2009-06-04T21:17:03L 10.1.1.153
# Wilma and Betty are new users. Note betty does not have a PIN so "-" is
used instead as a placeholder
HOTP
HOTP
wilma
betty
5678
-
a4d8acbddef654fccc418db4cc2f85cea6339f00
54fccc418a4d8acbddef6db4cc2f85ce99321d64
# Here is a user who's PIN is verified externally using whatever
"OTPAuthPINAuthProvider" list you have configured.
# E.g. to use an htpasswd type file, specify "OTPAuthPINAuthProvider
file" and then "AuthUserFile /some/file".
HOTP
bambam
+
d8acbddef6db4cc254fccc418a4f85ce99321d64
In ambito enterprise, esistono già soluzioni per la two factor authentication dedicate
al cloud, una tra tutte è proposta dalla Secure-pass [31] azienda partner del GARL
[32]: perché dunque attendere oltre per iniziare a usare il cloud computing, per il
proprio e-business, in modo sicuro?
64
5.2.4 Stato dell’arte globale e il “The Fappening”
Le aziende oggi espongono sempre più informazioni critiche per estendere l'accesso
ai dati aziendali al fine di eseguire in modo più efficace le loro attività.
Ma devono trovare una soluzione per affrontare efficacemente i rischi associati a un
ambiente più aperto una soluzione che soddisfi anche i rispettivi obblighi dei partner
e i requisiti normativi vigenti. Secondo la società di ricerca Forrester Research, Inc.
[6], pochi stanno facendo così. In realtà, la maggior parte delle organizzazioni ancora
usano un semplice “nome utente e password” come unica forma di autenticazione
per i loro dipendenti e partner. Nonostante i successi ben documentati della
soluzione 2FA, solo due terzi delle imprese in Nord America e in Europa hanno
anche iniziato a garantire le informazioni attraverso l'uso di tecnologie di strong
authentication. La maggior parte di queste organizzazioni hanno implementato tale
tecnologia solo su scala limitata.
Non è quindi una sorpresa che le violazioni della sicurezza sono aumentate
rapidamente negli ultimi 12 mesi. Secondo Forrester [6], il 54% delle imprese
intervistate ha subito una violazione nell'ultimo anno, mentre un terzo degli
intervistati ha subito tre o più attacchi.
In generale, ma soprattutto nel cloud le aziende devono cominciare immediatamente
a interessarsi all'accesso alle informazioni, come un componente critico per una
strategia di sicurezza globale dell’azienda.
Two factor authentication è una tecnologia matura, il costo della tecnologia è
diminuito in modo significativo, mentre l'evoluzione delle soluzioni basate su cloud
ha notevolmente diminuito la complessità tecnica. Non è più necessario per gli utenti
utilizzare scomodi token installati nel browser e ricordare le password, ora il
semplice (e onnipresente) telefono cellulare è tutto ciò che è necessario per offrire
alle imprese una protezione da hacker, attacchi di phishing e altre forme di accesso
non autorizzato.
Un recente studio del 2010 condotto da Forrester Consulting [6] e commissionato
per conto di VeriSign Authentication Business indica chiaramente che mentre le
imprese sono consapevoli delle minacce e le considerano un problema molto reale,
non hanno tuttavia preso misure sufficienti per proteggersi.
A supporto di quanto appena detto, nel 2014 Apple è stata vittima di un attacco
informatico alla propria piattaforma iCloud, noto con il nome “The Fappening” [33].
Tale attacco, secondo diverse fonti web [34] [35], sfruttava una falla
nell’implementazione del “Find My iPhone”, per estrapolare nome utente e
password dei vari account tramite bruteforce. Con queste informazioni, gli attaccanti
65
sono stati in grado di accedere agli account di iCloud, rubare le foto dei legittimi
proprietari e renderle pubbliche sul web. Tra le vittime rese note, ci sono attrici e
modelle che avevano sul proprio account di iCloud foto e video con nudo, che
difficilmente avrebbero reso noto e che adesso faranno sempre parte del web.
Se iCloud avesse adottato policy di sicurezza sulle password, che obbligassero gli
utenti ad usare un sistema di strong authentication, nulla di tutto ciò sarebbe successo
e la privacy di oltre 500 utenti non sarebbe stata violata, indipendentemente dalla
falla presente su Find My iPhone.
66
CAPITOLO 6
Conclusioni e sviluppi futuri
6.1 RISULTATI RAGGIUNTI
In questa tesi è stata analizzata una nuova tecnologia che si presenta come una
opportunità per il futuro nell’ambito dell’e-science e dell’e-bussines. E’ stato
studiato e analizzato OpenStack, un framework open source dall’architettura
modulare, con sviluppo e supporto in forte crescita e che può costituire una
importante scelta strategica per il futuro.
Tuttavia, l’ingegnerizzazione e la configurazione di OpenStack è abbastanza
complessa a causa dei molti scenari applicativi supportati, della immaturità del
prodotto e dalla problematica che non tutto è gestibile da interfacce grafiche.
Il focus sull’autenticazione ha evidenziato come l’utilizzo di un’autenticazione
federata in ambito cloud può semplificare la gestione delle utenze e ridurre le
responsabilità per il provider del servizio, il quale delega l’autenticazione all’IdP di
appartenenza dell’utente.
Inoltre, l’introduzione di un secondo metodo di autenticazione rafforza
concretamente l’accesso alle risorse in uno scenario delicato come il cloud
computing, dove l’accesso alle risorse può avvenire da ogni parte del globo grazie
al web.
6.2 SVILUPPI FUTURI
Sviluppi futuri, in uno scenario come quello di OpenStack, di certo non mancano.
Un’ importante analisi potrebbe essere fatta, sempre in ambito dell’ autenticazione,
su come Keystone opera.
Come già detto in questo lavoro di tesi, Keystone di default rilascia all’utente
autenticato un token di tipo UUID, con il quale l’utente è libero di accedere alle
risorse. Tale operazione avviene attraverso questi passi cruciali:
a) L’utente che vuole accedere a una risorsa invia la richiesta verso l’API
del servizio di cui necessita e inoltra il token fornito.
b) Il servizio interrogato, per verificare l’utente, invia a Keystone il token
67
c) Keystone risponde fornendo le informazioni necessarie
In uno scenario ampio, tutte queste richieste alle API di Keystone creano dei
rallentamenti dovuti in parte al carico della rete ma soprattutto al carico di lavoro
che svolgono le API.
Esiste un altro scenario [36] che è rappresentato dall’utilizzo di token PKI firmati da
Keystone, che svolgerebbe il ruolo di CA.
Sfruttando dunque questa tipologia di token, ogni servizio all’interno della cloud ha
una copia della chiave pubblica di Keystone che sfrutta per validare o meno il token
ricevuto da parte di un’utente. Sostanzialmente, quando un utente si identifica a
Keystone, riceve un token PKI che utilizzerà per fare le richieste verso le API dei
vari servizi della cloud. Avremo dunque questo scenario:
a) L’ utente che vuole accedere a una risorsa, invia la richiesta verso l’API
del servizio e inoltra il token questa volta di tipo PKI
a) Il servizio interrogato, per verificare l’utente, utilizza la sua copia della
chiave pubblica dei Keystone per validare la richiesta dell’utente, in loco
Così facendo, per la validazione del token viene sfruttata la potenza di calcolo della
macchina che ospita il servizio e non viene più richiamato Keystone che è libero di
operare su nuove richieste.
Un altro sviluppo futuro potrebbe essere quello di perfezionare l'utilizzo dell'OTP e
renderlo più user-friendly, o implementando un'opportuna app mobile-credentials o
ancora integrando l'utilizzo di Google Authenticator in OpenStack.
68
BIBLIOGRAFIA
[1]
NIST, «National Institute of Standards and Technology,» [Online]. Available:
http://www.nist.gov/. [Consultato il giorno 11 03 2015].
[2]
T. G. Peter Mell, «NIST SP 800-145, The NIST Definition of Cloud Computing,» [Online].
Available: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf. [Consultato il
giorno 11 03 2015].
[3]
Amazon , «Amazon Web Services (AWS) - Cloud Computing Services,» [Online]. Available:
http://aws.amazon.com/. [Consultato il giorno 11 03 2015].
[4]
NIST, «NIST Special Publication 800-125, Guide to Security for Full Virtualization
Technologies,» [Online]. Available: http://csrc.nist.gov/publications/nistpubs/800-125/SP800125-final.pdf. [Consultato il giorno 11 03 2015].
[5]
M. G. &. M. Salvatore, «CLOUD COMPUTING: Significato, Vantaggi, Svantaggi e Tipologie,»
[Online]. Available: http://www.infomart.it/cloud-computing#ixzz3Oz3dkqic. [Consultato il
giorno 11 03 2015].
[6]
«whitepaper-strong-authentication-steps,» [Online]. Available:
http://www.verisign.com/authentication/information-center/authenticationresources/whitepaper-strong-authentication-steps.pdf. [Consultato il giorno 11 3 2015].
[7]
R. Florio, «HP Atalla Cloud Encryption: cifratura nel cloud per i dati in uso e a riposo,» 20 10
2014. [Online]. Available: http://www.tomshw.it/cont/articolo/hp-atalla-cloud-encryptioncifratura-nel-cloud-per-i-dati-in-uso-e-a-riposo/59992/1.html. [Consultato il giorno 11 03
2015].
[8]
«L'Europa in cerca di regole per il Cloud e la privacy,» [Online]. Available:
http://www.ict4executive.it/cloud/interviste/l-europa-in-cerca-di-regole-per-il-cloud-e-laprivacy_43672151417.htm. [Consultato il giorno 11 03 2015].
[9]
A. Longo, «Crittografia a prova di «cloud»,» [Online]. Available:
http://www.ilsole24ore.com/art/tecnologie/2011-09-16/crittografia-prova-cloud190508.shtml?uuid=AaVpZ44D. [Consultato il giorno 11 3 2015].
[10]
Wikipedia, «FTTx,» [Online]. Available: http://it.wikipedia.org/wiki/Fttx. [Consultato il giorno
11 03 2015].
[11]
«Global Broadband and Mobile Performance Data Compiled by Ookla | Net Index,» OOKLA,
[Online]. Available: http://www.netindex.com/. [Consultato il giorno 11 3 2015].
[12]
J. Bort, «The 10 Most Important Companies In Cloud Computing,» [Online]. Available:
http://www.businessinsider.com/10-most-important-in-cloud-computing-2013-4?op=1&IR=T.
[Consultato il giorno 11 3 2015].
[13]
« OpenStack Open Source Cloud Computing Software,» OpenStack, [Online]. Available:
http://www.openstack.org/. [Consultato il giorno 11 3 2015].
69
[14]
«Google Trend,» Google , [Online]. Available: http://www.google.it/trends/. [Consultato il
giorno 11 3 2015].
[15]
S. Orlando, «A few link, about NameSpace,» [Online]. Available:
http://pastebin.com/ruR70tH4. [Consultato il giorno 11 03 2015].
[16]
«Workshop di CCR sull'Infrastruttura Cloud,» INFN , [Online]. Available:
https://agenda.infn.it/conferenceOtherViews.py?view=standard&confId=8785. [Consultato il
giorno 11 3 2015].
[17]
M. Antonacci, «infn-bari-school/VPN-as-a-Service Wiki · GitHub,» [Online]. Available:
https://github.com/infn-bari-school/VPN-as-a-Service/wiki. [Consultato il giorno 11 3 2015].
[18]
openstack, «Chapter 1. Architecture - OpenStack Installation Guide for Red Hat Enterprise
Linux 7, CentOS 7, and Fedora 20 - juno,» [Online]. Available:
http://docs.openstack.org/juno/install-guide/install/yum/content/ch_overview.html.
[Consultato il giorno 11 3 2015].
[19]
openstack, «Chapter 3. Add the Identity service - OpenStack Installation Guide for Red Hat
Enterprise Linux 7, CentOS 7, and Fedora 20 - juno,» [Online]. Available:
http://docs.openstack.org/juno/install-guide/install/yum/content/ch_keystone.html.
[Consultato il giorno 11 3 2015].
[20]
openstack, «Chapter 4. Add the Image Service - OpenStack Installation Guide for Red Hat
Enterprise Linux 7, CentOS 7, and Fedora 20 - juno,» [Online]. Available:
http://docs.openstack.org/juno/install-guide/install/yum/content/ch_glance.html.
[Consultato il giorno 11 3 2015].
[21]
openstack, «Chapter 8. Add the Block Storage service - OpenStack Installation Guide for Red
Hat Enterprise Linux 7, CentOS 7, and Fedora 20 - juno,» [Online]. Available:
http://docs.openstack.org/juno/install-guide/install/yum/content/ch_cinder.html.
[Consultato il giorno 11 3 2015].
[22]
openstack, «OpenStack Networking (neutron) - OpenStack Installation Guide for Red Hat
Enterprise Linux 7, CentOS 7, and Fedora 20 - juno,» [Online]. Available:
http://docs.openstack.org/juno/install-guide/install/yum/content/section_neutronnetworking.html. [Consultato il giorno 11 3 2015].
[23]
openstack, «Chapter 7. Add the dashboard - OpenStack Installation Guide for Red Hat
Enterprise Linux 7, CentOS 7, and Fedora 20 - juno,» [Online]. Available:
http://docs.openstack.org/juno/install-guide/install/yum/content/ch_horizon.html.
[Consultato il giorno 11 3 2015].
[24]
INFN, «GRID,» [Online]. Available:
http://www.infn.it/comunicazione/index.php?option=com_content&view=article&id=241:gri
d&catid=30&Itemid=738&lang=it. [Consultato il giorno 11 3 2015].
[25]
openstack, «Enabling the Federation Extension,» [Online]. Available:
http://docs.openstack.org/developer/keystone/extensions/federation.html. [Consultato il
giorno 11 3 2015].
70
[26]
openstack, «HTTP API,» [Online]. Available:
http://docs.openstack.org/developer/keystone/http-api.html#how-do-i-migrate-from-v2-0to-v3. [Consultato il giorno 11 3 2015].
[27]
google, «google-authenticator · GitHub,» [Online]. Available:
https://github.com/google/google-authenticator/. [Consultato il giorno 11 3 2015].
[28]
«FreeOTP,» [Online]. Available: https://fedorahosted.org/freeotp/. [Consultato il giorno 11 3
2015].
[29]
Wikipedia, «Enigma,» [Online]. Available:
http://it.wikipedia.org/wiki/Enigma_%28crittografia%29. [Consultato il giorno 11 03 2015].
[30]
« mod-authn-otp - Apache module for one-time password authentication,» [Online].
Available: https://code.google.com/p/mod-authn-otp/. [Consultato il giorno 2015 03 11].
[31]
Secure-Pass, [Online]. Available: http://www.secure-pass.net/. [Consultato il giorno 11 03
2015].
[32]
GARL, [Online]. Available: http://www.garl.ch/. [Consultato il giorno 11 03 2015].
[33]
Wikipedia, «2014_celebrity_photo_hack,» [Online]. Available:
http://en.wikipedia.org/wiki/2014_celebrity_photo_hack. [Consultato il giorno 11 03 2015].
[34]
O. Williams, «This could be the iCloud flaw that led to celebrity photos being leaked (Update:
Apple is investigating),» [Online]. Available: http://thenextweb.com/apple/2014/09/01/thiscould-be-the-apple-icloud-flaw-that-led-to-celebrity-photos-being-leaked/. [Consultato il
giorno 11 03 2015].
[35]
theguardian, «Naked celebrity hack: security experts focus on iCloud backup theory,»
[Online]. Available: http://www.theguardian.com/technology/2014/sep/01/naked-celebrityhack-icloud-backup-jennifer-lawrence. [Consultato il giorno 11 03 2015].
[36]
B. Kupidura, «Understanding OpenStack Authentication: Keystone PKI,» [Online]. Available:
https://www.mirantis.com/blog/understanding-openstack-authentication-keystone-pki/.
[Consultato il giorno 11 3 2015].
[37]
openstack, «Chapter 5. Add the Compute service - OpenStack Installation Guide for Red Hat
Enterprise Linux 7, CentOS 7, and Fedora 20 - juno,» [Online]. Available:
http://docs.openstack.org/juno/install-guide/install/yum/content/ch_nova.html. [Consultato
il giorno 11 3 2015].
[38]
G. Parternò. [Online]. Available: http://www.gpaterno.com/. [Consultato il giorno 11 03
2015].
[39]
D. S. Namia, «Corsi di Laurea in Informatica (classe L31): Archivio Tesi Laurea Triennale,»
[Online]. Available: http://www.cs.unipr.it/Informatica/Tesi/Spartaco_Namia_20100428.pdf.
[Consultato il giorno 11 03 2015].
71
[40]
D. A. Gioia, «Corsi di Laurea in Informatica (classe L31): Archivio Tesi Laurea Triennale,»
[Online]. Available: http://www.cs.unipr.it/Informatica/Tesi/Alberto_Gioia_20080326.pdf.
[Consultato il giorno 11 03 2015].
[41]
G. Partenò, «Openstack: security beyond firewalls,» [Online]. Available:
http://www.slideshare.net/GARLsecurity/openstacksecuritybeyondfirewalls?qid=1092943c5c13-4d60-ae8a-2f74c14be99c&v=default&b=&from_search=9. [Consultato il giorno 11 03
2015].
[42]
V. Salvatore Orlando, «Neutron: peeking behind the curtains,» [Online]. Available:
http://files.meetup.com/6653182/1_Salvatore%20Orlando_VMware_h14.pdf. [Consultato il
giorno 11 03 2015].
72

Documenti analoghi