Elaborato Palmieri Marco Rosario n46000128

Transcript

Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
tesi di laurea triennale
Problematiche di Sicurezza di Sistemi Cloud
Anno Accademico 2011-2012
Relatore
Ch.mo Prof. Antonio Pescapè
Candidato
Marco Rosario Palmieri
matr. N46000128
Dedica.
Elenco delle figure
2.1
FISMA Risk Management Framework . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.1
Vulnerabilità per Cloud Pubblico e Privato . . . . . . . . . . . . . . . . . . . . . .
24
3.2
Architettura per Cloud Ibrido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.3
National Security Cloud Architecture . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.4
Architettura On-Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3
Introduzione
Visti i passi da gigante che l’informatica ha fatto negli ultimi decenni, non desta quasi più clamore
assistere all’ultima rivoluzione messa in campo nel settore, cioè l’introduzione del paradigma
Cloud Computing. In effetti, basta considerare la grande capacità di calcolo ottenibile, oppure
la possibilità di avere dati e applicazioni sempre disponibili, anche in mobilità ed accedibili da
un’eterogeneità di dispositivi, per capire che tale approccio rappresenta un’opportunità imperdibile
sia per le aziende che per i privati. Un sistema Cloud può offrire dei servizi per l’archiviazione e
per l’elaborazione dei dati, con l’utilizzo di risorse hardware e software virtualizzate e distribuite
in rete. L’interrogativo che ci si pone a tal punto è il seguente: come verranno gestiti i propri
dati dal fornitore dei servizi? La questione è di estrema importanza, perché i dati sono ciò che
ci identificano nel mondo digitale dicendo, a noi e agli altri, chi siamo. Chi metterebbe, infatti,
i propri risparmi in una banca se non fosse sicuro che questa è in grado di garantire l’integrità e
la confidenzialità delle informazioni sul proprio deposito? Memorizzereste, in un sistema Cloud,
tutti i vostri file (senza esclusione alcuna), quali il progetto su cui state lavorando, i dati che
compongono agende e appuntamenti, dati fiscali oppure foto o filmati personali? Cosa accadrebbe
se poi non riusciste, per qualche motivo, a recuperarli, oppure se venissero resi pubblici? Quale il
danno? Vi fidereste se il nostro Governo usasse un sistema per memorizzare i dati (del tipo: fedina
penale, pendenze fiscali, situazioni economiche dei singoli cittadini) in un sistema dove non sono
ben chiare le politiche di gestione? Proprio a causa di questo - potenzialmente enorme - campo
di impiego, per assicurare uno sviluppo meno traumatico ed ottenere la fiducia degli utilizzatori,
è importante dare le necessarie rassicurazioni a tutte le entità coinvolte. Lo scopo di questa tesi
sarà analizzare le problematiche di sicurezza che si possono avere utilizzando il Cloud Computing,
facendo riferimento ai papers sottocitati. In prima battuta vedremo come, in taluni casi, un uso
approssimato di questa tecnica è stato nefasto. Così facendo, cercheremo di fare chiarezza sui
4
Facoltà di Ingegneria - Corso di Studi in Ingegneria Informatica
rischi che si corrono se non si pone la giusta attenzione su determinati aspetti. Passeremo, poi,
a presentare i maggiori enti che si impegnano a garantire sicurezza e affidabilità, mostrando i
loro diversi ruoli e spiegandone la necessità e l’importanza. In ultimo, vedremo come è possibile
mettere in sicurezza i propri dati, al fine di evitare che persone non autorizzate possano carpire il
contenuto e le modalità per il loro recupero in caso di malfunzionamenti delle differenti componenti
del sistema.
5
Capitolo 1
Problematiche del cloud
computing
1.1
Attacchi nella storia
La sicurezza è un processo iterativo che si basa sulla conoscenza del passato per la protezione
contro attacchi futuri. Vediamo, quindi, alcuni problemi di sicurezza che hanno avuto i maggiori
fornitori di sistemi Cloud.
Nel giugno del 2008, molti utenti hanno ricevuto un’email di spam che invitava gli stessi a
scaricare un aggiornamento per i loro sistemi. In realtà, l’ignaro lettore, installava un software
che creava una backdoor nel suo computer preparandolo per essere utilizzato dai malintenzionati.
L’innovazione di questo attacco è stata la sua attuazione: fino ad allora si usavano servizi di
“bulletproof hosting” (fornitori di servizi che hanno una politica di apertura nei confronti di utenti
con fini poco legittimi) oppure botnet (rete di computer privati) mentre questa volta il mittente
è stata un’organizzazione accreditata quale Amazon Web Services. La tradizionale soluzione che
si adotta in casi di spam (collocare gli indirizzi IP mittente in una black-list) è stata ovviamente
fallimentare perché Amazon usa un meccanismo di assegnazione degli indirizzi dinamico, quindi
non si può tener traccia dei mittenti. Questa misura ha portato a bloccare tutti gli IP della
società e quindi sono state cestinate tutte le email, incluse ricevute di acquisto, fatture, campagne
di marketing. Ciò si è concretizzato in un vero e proprio Denial Of Services per i clienti lasciando,
6
così, l’opportunità agli attacanti di inviare mail e costruire un nuovo botnet.
Amazon ha risolto il problema semplicemente vincolando ogni account con un numero massimo
di email inviabili, facendo quindi sbloccare gli indirizzi dalla lista nera di Spamhaus e prevenendo
rapidamente ad abusi futuri.
Può essere necessario, per risolvere problemi inaspettati come questo appena visto, la presenza
continua di esperti con permessi particolari in grado di accedere ai dati sensibili degli utilizzatori del
Cloud per diagnosticare e risolvere in modo efficace le falle. Questa figura è prevista e regolarizzata
nei contratti dei servizi Server, ma la sua assenza nei sistemi Cloud crea seri rischi per la sicurezza.
Un problema innescato da una situazione simile si è presentato alla Google dove, un dipendente
con accesso a mail, chat e registrazioni telefoniche, ha sfruttato la sua posizione per spiare alcuni
utenti. Una volta scoperta la violazione della privacy, il malintenzionato è stato licenziato e sono
stati apportati miglioramenti al sistema che controlla gli accessi ai dati e la loro frequenza da parte
dei dipendenti.
Sicuramente non ha avuto meno scalpore ciò che è successo alla Microsoft con il Business
Productivity Online Suite. Per un errore di configurazione, qualsiasi utente poteva scaricare la
rubrica di altri ignari utilizzatori. Sebbene sia stato sistemato tutto in un paio d’ore, diversi utenti
hanno potuto scaricare dati illegittimi. Caso analogo è successo al famoso sistema di Dropbox che,
in seguito ad un update, permetteva a chiunque di loggarsi in tutti gli account senza le password
corrette avendo piena gestione dei file privati. [1]
1.2
Rischi per l’utente
Quando bisogna scegliere un fornitore di servizi Cloud a cui affidarsi è importante controllare
bene le varie proposte perchè ci sono tanti diversi rischi da non sottovalutare. Secondo esperti
quali I. Foster, Y. Zhao, I. Raicu e S. Lu, i sette più importanti sono:
1. L’accesso esclusivo degli utenti e privacy: assicurare che i dati sensibili memorizzati nei
server siano accessibili e propagati solo agli utenti autorizzati.
2. Conformità alle normative delle infrastrutture, certificazioni di sicurezza e controlli esterni(in
genere più affidabili di quelli interni).
7
3. L’ubicazione dei dati: è molto rilevante la posizione geografica dove i dati saranno conservati
per sapere a quale giurisdizione saranno affidati, quindi a quali diritti e doveri sono soggetti
i propietari.
4. La segregazione dei dati: bisogna garantire che i dati di un utente siano completamente
segregati da quelli di un altro utente;
5. Ripristino e recupero: è importante che il cloud provider disponga di un meccanismo di
recupero efficace per ripristinare i dati in caso di catastrofi.
6. Il sostegno investigativo: data la complessità ad effettuare indagini su servizi cloud, se
l’utente ritiene necessario, bisogna aggiungere una clausola appropriata nel contratto.
7. Disponibilità a lungo termine: i dati devono essere disponibili per il recupero anche nel caso
in cui la società proprietaria del provider fallisca o cede i servizi a terzi.
Purtroppo, però, questi non sono gli unici rischi che un utilizzatore può incombere usando un
sistema Cloud. Ad esempio, ci sono tutti quelli associati alla virtualizzazione dell’ hardware che
dipendono in grande misura dal software utilizzato (i più diffusi sono VMWare vSphere, Microsoft
Virtual PC, Xen).
Inoltre, l’utente deve fare attenzione anche alle politiche del provider in caso di migrazione dei
dati e dei programmi verso un altro fornitore di servizi per non rischiare di rimanere bloccati in
un sistema che non soddisfa a pieno le sue esigenze. [2, 3]
1.3
Tipologie di attacchi
Come avviene nella maggioranza dei sistemi digitali, nel Cloud Computing ogni utente è riconosciuto tramite le sue credenziali. Queste spesso diventano l’obiettivo di attacchi da parte di
malintenzionati per ottenere l’accesso alle preziose informazioni personali. Sebbene questo sembra
il modo più intuitivo per sottrarre dati da un account, non è l’unico e ne tanto meno il più diffuso.
Perciò diventa importante conoscere i quattro diversi tipi di attacchi per proteggere e proteggersi
dalle intrusioni.
8
Uno dei modi più diffusi per rubare le credenziali degli account è sicuramente il phishing.
L’attaccante crea un’interfaccia apparentemente identica a quella del sistema interessato dove il
malcapitato sarà invitato ad inserire i propri dati per effettuare il login inconsapevole che questi
saranno raccolti e resi disponibili al malintenzionato.
Solitamente il phishing è accompagnato da campagne di spam. Queste sono veri bombardamenti di messaggi pubblicitari inviati per lo più attraverso email o chat che invitano il destinatario
a visitare le pagine fraudolenti. Gli indirizzi dei riceventi vengono trovati in rete, copiandoli da
forum, blog e liste oppure indovinati da sistemi di generazione pseudorandom.
Molto diffusi sono anche gli attacchi DoS (Denial of Service). Come suggerisce lo stesso nome,
questo attacco porta l’inibizione dei servizi offerti da un sistema rendendolo irraggiungibile e
quindi inutilizzabile per le persone autorizzate. Il principio di funzionamento è tanto semplice
quanto efficace: portare i servers a saturazione riempendoli di richieste contemporanee. In modo
particolare sono sfruttati quei casi dove a richieste di pochi byte il server risponde con una mole
molto maggiore di dati, scatenando così un traffico esponenziale. Un particolare tipo di DoS è
il DDoS (Distributed DoS) che sfrutta reti di computer (per lo più botnet, insieme di computer
infettati da virus che eseguono determinate azioni automaticamente) per rendere l’attacco più
performante, più difficile da arrestare e per fare in modo che sia difficile rintracciare i creatori [1].
Man In The Middle attack è un altro tipo di intromissione nel quale l’attaccante si posiziona
in mezzo tra un mittente ed un destinatario in modo da poter leggere, inserire o modificare a
piacere i messaggi scambiati tra i due, rimanendo ovviamente invisibile agli stessi. Per fare questo
il malintenzionato ha bisogno di accedere al flusso di informazioni scambiate tra la sorgente e
la destinazione. Un attacco di questo tipo è sicuramente facilitato se sono presenti bug nelle
interfacce o nella gestione delle API che, in taluni casi, permettono accessi anonimi, riuso di
password e logging.
Come è ovvio aspettarsi, tutte queste azioni fraudolenti non fanno altro che rallentare lo
sviluppo dei sistemi Cloud perchè vanno contro i suoi principi fondamentali di confidenzialità,
integrità e disponibilità dei dati (CIA).
Ad esempio, un attacco di phishing combinato ad una campagna di spam potrebbe portare
un utente di un servizio di Cloud a svelare le sue credenziali ad un hacker permettendogli così il
pieno accesso all’account. Quest’ultimo potrebbe sfruttare i dati in suo possesso per acquisire altre
informazioni sensibili del cliente come dati bancari o progetti di lavoro, oppure manomettendo o
9
cancellando file a suo piacimento.
Con un attacco di tipo DoS (o meglio ancora DDoS) ad un provider di servizi Cloud è possibile
rendere inutilizzabile l’intero sistema ai clienti con conseguenti danni produttivi, economici, perdita
di affidabilità e di immagine della azienda.
Una situazione analoga la si avrebbe di fronte ad un Man In The Middle attack che permetterebbe ad un malintenzionato di sniffare ed eventualmente manomettere i messaggi scambiati
da un utente. Si capisce subito l’entità del problema pensando ad una transazione di denaro che
potrebbe essere dirottata su un conto diverso da quello desiderato. [3, 4, 5]
1.4
Uso scorretto e leggi sul Cloud
Il Cloud Computing, come molte innovazioni, è nato con fini nobili quali aiutare i ricercatori nel
loro lavoro. Sebbene l’intenzione iniziale non lo prevedeva, questi sistemi possono essere abusati
in modo nefasto diventando una minaccia per l’incolumità dei dati.
Un esempio di abuso è l’utilizzo di sistemi Cloud per il salvataggio di informazioni ricavate
attraverso operazioni di phishing. Non meno importante il caso in cui all’interno del personale
dell’azienda che offre servizi Cloud ci siano uno o più addetti malintenzionati che potrebbero
facilmente accedere ai dati dei clienti e modificarli a loro piacimento. Secondo un sondaggio del
CERT Insider Threat Center 2010 Cyber Security Watch Survey, più del 67% degli intervistati ha
ammesso che gli incidenti interni sono più dannosi di quelli esterni. [7] Quindi, per evitare questa
situazione, è buona pratica attivare sistemi di monitoraggio anche all’interno della stessa azienda
e distribuire i privilegi sui dati tra i vari dipendenti in modo da evitare accentramenti.
E’ necessario essere molto prudenti su queste tematiche di sicurezza ed è importante puntare
sulla prevenzione poichè le norme attuali in questo ambito non sono molto chiare e, a volte, sono
addirittura discordanti tra diverse nazioni cosa molto influente data la dislocazione dei server.
Infatti, alcuni paesi, in maggioranza quelli europei, prevedono l’obbligo di distribuire i server
di uno stesso Cloud solo sul territorio sotto la loro giurisdizione impedendone la distribuzione
all’estero.
Il governo francese ha recentemente introdotto leggi stringenti sulla gestione dei dati, regolamentando anche i casi di trasferimenti da un provider ad un altro attraverso linee guida e standard
da seguire. [3, 4, 6]
10
Capitolo 2
Enti per la sicurezza
2.1
Cloud Security Alliance
Molti gruppi ed organizzazioni hanno focalizzato la loro attenzione sul Cloud Computing e le
sue problematiche, soprattutto per quello che riguarda la Sicurezza.
La Cloud Security Alliance è un’organizzazione no-profit che ha promosso l’uso delle migliori
pratiche di Sicurezza ed ha permesso la loro diffusione, in modo tale che chiunque potesse esserne
a conoscenza e potesse avere delle linee giuda da seguire.
Nel Marzo 2010 la CSA ha pubblicato le sue ricerche che avevano lo scopo di identificare i
maggiori rischi che si corrono utilizzando i servizi Cloud ed il miglior modo di proteggersi da essi.
Ed è proprio grazie a questi studi che la suddetta associazione ha potuto stilare una breve lista
dei maggiori pericoli, che viene di seguito riportata:
• Abuso ed uso nefasto del Cloud Computing
• Interfacce e applicazioni non sicure
• Dipendenti malintenzionati
• Vulnerabili tecnologie di condivisione
• Inconsistenza o perdita di dati
• Espropriazione di account e servizi
11
• Altri rischi
Sulla base del lavoro della CSA, un sistema cloud può essere modellato su sette livelli:
Facility A questo livello si parla di controllo di sicurezza effettuato fisicamente, cioè utilizzando
mezzi di sorveglianza per controllare il presonale dell’azienda che offre il servizio cloud,
l’accesso ai dati e la frequenza delle operazioni mediante, ad esempio, telecamere a circuito
chiuso. Inoltre bisognerebbe effettuare una distribuzione dei privilegi, in modo tale da non
permettere a tutti l’accesso ai dati archiviati, visto che potrebbero esserci malintenzionati
anche all’interno del personale, i quali avrebbero altrimenti un facile accesso alle informazioni
e la loro manipolazione diventerebbe un gioco da ragazzi. Inoltre il provider deve tener
conto anche degli aspetti logistico-ambientali, che potrebbero sembrare poco importanti;
invece bisogna garantire una sicurezza architettonica tale da poter proteggere il centro dati
da attacchi fisici data l’importanza dei dati in esso contenuti. È chiaro che la società in
questione deve offrire una certa flessibilità, nel senso che deve tener conto che le politiche di
sicurezza cambiano col passar del tempo e quindi è necessario tenersi aggiornati e modificare
man mano le prevenzioni adottate. [8]
Network Una delle caratteristiche principali del cloud computing consiste nell’avere l’accesso ai
dati e la possibilità di controllarli tramite la rete Internet. Sappiamo però che Internet è per
definizione inaffidabile, quindi necessita di protezioni quali firewall, sistemi di rilevamento di
intrusioni o proxy di rete. Ad esempio, un firewall posto al confine del cloud con il compito
di bloccare i pacchetti “fastidiosi” può limitare ma non eliminare l’accesso all’interfaccia da
parte di entità maligne. Una soluzione utilizzata dal cloud computing è quella di mantenere
una “lista nera” - blacklist - di indirizzi IP, soluzione efficace se si considera che l’accesso
alla blacklist da parte del provider è rapido e quindi efficiente. L’utilizzo di un proxy, invece,
potrebbe non essere efficiente se il volume di traffico che entra ed esce dal centro dati è molto
elevato, influendo quindi sulle prestazioni del sistema (anche in termini di velocità). Potrebbe
essere una buona idea solo nel caso in cui il provider abbia effettuato una distribuzione dei
compiti ed abbia la possibilità di controllare lo stato della rete attraverso un processo di
packet capture, che richiederebbe un’indicizzazione di una serie di dati da conservare per
12
un lungo periodo di tempo, quindi le prestazioni comunque non sarebbero quelle desiderate,
senza contare il fatto che l’utente dovrebbe star lì a controllare continuamente il lavoro del
provider. [8]
Hardware Il concetto su cui si basa il Cloud Computing è che l’utente che usufruisce del servizio
possa interagire soltanto con un ambiente virtualizzato, non fisico. Per questo motivo, la
responsabilità del mantenimento e del monitoraggio dell’hardware ricade sul provider. In
particolare, questo deve controllare che i mezzi messi a disposizione non abbiano problemi
a livello di processore, memoria, memorizzazione su disco, temperatura, tensione o qualsiasi
altro tipo di problema che un sistema informatico possa incontrare. Inoltre deve misurare
la mole di dati da memorizzare e distribuirla in modo da bilanciare il carico e rendere più
efficaci le risorse. Deve poi controllare la presenza di anomalie e garantire che l’hardware
non sia stato manomesso, utilizzando adeguati protocolli di sicurezza per evitare comportamenti sospetti o, nel caso in cui questo non sia stato possibile, almeno porvi rimedio
immediatamente. [8]
OS Qualsiasi sistema operativo in un servizio di Cloud dev’essere estremamente sicuro e controllato. In generale, un minor numero di caratteristiche di un sistema operativo si traduce in
un minor numero di punti di errore; poiché un sistema operativo in un ambiente cloud ha bisogno di poche funzionalità, quelle non essenziali devono essere rimosse. Tutto ciò che resta
deve essere controllato accuratamente perché non si può accettare alcun tipo di vulnerabilità,
visto che altrimenti potrebbero essere compromessi tutti i dati del cliente. Il ruolo del sistema operativo in un cloud è quello di monitorare ed organizzare tutte le chiamate di sistema
tra le varie macchine virtuali e l’hardware, in modo che si possa accedere correttamente ai
dati. In taluni casi potrebbe essere opportuno che i dati sensibili vengano crittografati prima
di essere memorizzati, perché teoricamente in questo modo nessuno potrebbe avere accesso
ai dati; in realtà non è proprio così visto che il sistema operativo gestisce tutte le funzioni
delle macchine virtuali e quindi potrebbe accedere al testo memorizzato in chiaro, nonché
alle chiavi utilizzate dal processore per effettuare la crittografia. Inoltre sarebbe opportuno
che il provider utilizzasse un unico sistema operativo virtualizzato in modo da tenere sotto
controllo l’immagine ad esso associata e, in caso di modifiche, controllarne l’attendibilità e,
se necessario, ripristinare il backup (che comunque dev’essere memorizzato su dispositivi di
sola lettura) per ritornare all’ultimo stato valido. Il provider dovrebbe poi indagare ulterior13
mente su tutti gli eventi per cercare di identificare la causa iniziale. Questo atteggiamento
consentirebbe di individuare la falla della politica di sicurezza attuata e di aggiornarla per
adattarsi alla minaccia e prevenire problemi futuri. Questa modalità è stata certificata ed è
infatti attualmente utilizzata da alcuni provider.[8]
Middleware [9] Parlare di Middleware significa parlare di un sistema che mette in comunicazione le applicazioni con il sistema operativo che coordina le risorse utilizzate per assicurare la
fruizione dei servizi Cloud. Alcuni Middleware svolgono anche un’azione di sicurezza, monitorando la comunicazione tra i vari componenti del sistema, che per lo più avviene attraverso
dati crittografati. È ovvio che la presenza di questa proprietà fa aumentare le responsabilità
a carico del provider, che deve garantire la sua integrità e la sua immutabilità (in particolare deve controllare che i suoi addetti non manipolino in alcun modo il sistema); un danno
al Middleware potrebbe risultare più grave rispetto ad un problema al sistema operativo:
questo perché il Middleware tende ad avere i diritti per accedere, manipolare e distribuire
i dati all’interno del Cloud, oltre a funzioni specializzate come la gestione di controllo degli
accessi. La società fornitrice dei servizi deve assicurare principalmente tre cose:
1. L’integrità dell’architettura software, escludendo falle che potrebbero derivare da una
configurazione errata delle risorse umane o politiche. Tali difetti possono essere indicati
da un abuso di funzioni normali del Middleware, anche se - in generale - non sempre
le anomalie si correlano efficientemente a violazioni di sicurezza. Bisognerebbe dunque
effettuare un monitoraggio delle funzioni del Middleware, ma ciò risulta abbastanza
complicato.
2. La codifica dei dati memorizzati in modo da non renderli vulnerabili. Durante la
creazione del software, lo sviluppatore potrebbe testare la vulnerabilità utilizzando
strumenti di fuzzing oltre alle normali procedure di collaudo. Ciò significa fornire
input errati al programma in un ambiente controllato e documentare eventuali crash ed
errori in modo da poter risolvere il problema sin dall’inizio, prima della distribuzione.
La documentazione dovrebbe contenere le informazioni riguardanti le falle scoperte ed
un piano di gestione per le stesse.
14
3. I servizi di sicurezza, che includono il monitoraggio, il controllo degli accessi, la convalida dei dati, e altre funzioni. Ovviamente il cliente deve fidarsi del software che
gestisce la sicurezza, perché non può pensare di osservare da vicino le procedure utilizzate, anche se ha il pieno diritto di essere a conoscenza delle modalità di sicurezza
che gli vengono offerte. Le aziende hanno la libertà di utilizzare le modalità che più
ritengono opportune e di sviluppare soluzioni proprietarie personalizzate. Qualunque
sia la soluzione, il fornitore deve indicare cosa e come si controlla in modo che il cliente
possa assumere decisioni consapevoli. Anche se realizzare questo monitoraggio richiede
la memorizzazione di un grande volume di dati, è fattibile e, dunque, è consigliabile
effettuarlo per la tranquillità del cliente.
Application Per applicazione si intende il mezzo attraverso il quale un provider si interfaccia
con gli utenti, i quali dovrebbero preferire quelle in cui il codice sorgente e la logica di
business sono stati attentamente esaminati da terzi, piuttosto che affidarsi ad un qualsiasi
tipo di “security through obscurity”. Il problema principale che incontrano le applicazioni
è il fatto che la maggior parte di esse è Web-based, cioè deve operare in un ambiente non
sicuro quale il browser. Perciò le applicazioni devono effettuare operazioni di monitoraggio
per rilevare comportamenti anomali e violazioni di sicurezza. Inoltre è necessario che i
provider si occupino di prendere le pratiche migliori per il web, visto che in questo campo
le percentuali di attacco sono superiori alla media. La possibilità di implementare politiche
di sicurezza molto più severe è un vantaggio del Cloud Computing. Un modo per prevenire
problemi potrebbe essere la distribuzione di certificati digitali SSL (Secure Sockets Layer),
un protocollo progettato per consentire alle applicazioni di trasmettere informazioni in modo
sicuro e protetto; le applicazioni che utilizzano i certificati SSL sono in grado di gestire l’invio
e la ricezione di chiavi di protezione e di criptare e decriptare le informazioni trasmesse
utilizzando le stesse chiavi. Un’altra idea potrebbe essere quella di utilizzare DNSSEC
(Domain Name System Security Extensions), per dimostrare la legittimità dei domini in
modo che il cliente possa autenticare le risorse. SSL e DNSSEC sono esempi di crittografia
a chiave pubblica che possono essere utilzzati per verificare i servizi forniti attraverso il
Cloud. Le chiavi private associate a quelle pubbliche non dovrebbero mai essere inserite nel
Cloud, ma devono rimanere esclusivamente in possesso del cliente. L’attenzione da parte del
15
provider a diffondere metodi di sicurezza aiuta a prevenire la manomissione di dati sensibili.
[9]
User Se il Cloud Computing servisse soltanto per la distribuzione di informazioni pubbliche, quali pagine web o video, l’interesse da parte dell’utente nei confronti della sicurezza avrebbe
sicuramente un impatto limitato. Se, invece, i dati memorizzati fossero privati, al cliente
interesserebbe molto di più che questi venissero messi al sicuro. In generale, però, le politiche
adottate dal provider devono andare al di là dell’interesse del cliente. L’obiettivo principale
è quello di informare il cliente dei risultati del monitoraggio effettuato ed eventualmente
avvisarlo di comportamenti anomali. Ad esempio, Google Apps monitora gli accessi ai dati
(conservando anche l’indirizzo IP dal quale viene effettuato l’accesso) e comunica all’utente
ciò che avviene. Data la facilità con cui un utente può rendere instabile un sistema pressocché sicuro con pochi click (ad esempio, utilizzando una password estremamente facile
da scoprire), potrebbe essere opportuno educare i clienti meno informati sulle politiche di
sicurezza attraverso programmi e servizi appositi, quali PhishGuru, in modo tale da permettergli di avere una giusta consapevolezza sui rischi che si corrono, vista la vulnerabilità dei
browser e delle applicazioni che utilizziamo quotidianamente. [9]
2.2
NIST
Come avviene per tutte le innovazioni tecnologiche, arriva il momento in cui è necessario regolarne e disciplinarne l’uso. Negli Stati Uniti d’America è nata la US National Institute of Standard
and Technology (NIST), un’agenzia del Commerce Department’s Technology Administration, che
lavora costantemente per definire standard e linee guida per la gestione della sicurezza nel Cloud
Computing ed evidenzia i punti cruciali dove è opportuna l’istituzione di leggi apposite. Proprio
da questo gruppo, recentemente, è nato il “Guide to Adopting and Using the Security Content Automation Protocol” che introduce un nuovo protocollo creato sui casi d’uso raccolti dalla comunità
che supporta il progetto. La partecipazione della comunità, in queste circostanze, è fondamentale
per garantire un lavoro imparziale che tiene conto delle diverse proposte di soluzioni adottate,
prevenendo così l’imposizione di comportamenti da seguire che potrebbero favorire lo sviluppo di
alcune aziende a scapito di altre. Proprio per garantire una trasparenza del loro lavoro, la NIST
16
ha creato il sito scap.nist.gov grazie al quale è possibile rimanere sempre aggiornati sul lavoro
svolto e proporre al team le proprie idee e considerazioni.
Il National Institute of Standard Technology (NIST) ha definito il Cloud Computing
come “a model for enabling convenient, on-demand network access to a shared pool of
configurable computing resources (e.g., networsks, servers, storage, applications, and
services) that can be rapidly provisioned
and released with minimal management effort or service provider interaction.” [10]
2.2.1
SCAP
La gestione della sicurezza dei sistemi informativi è un compito costoso ed impegnativo e la
maggior parte delle organizzazioni ha un ampio insieme di requisiti di sicurezza da rispettare.
Per superare questi limiti e ridurre i costi, il NIST ha sviluppato il Security Content Automation
Protocol, usufruendo delle risorse di sicurezza supportate dalla comunità.
SCAP è una suite di specifiche che standardizzano il formato e la nomenclatura con la quale i
software di sicurezza comunicano informazioni riguardo l’identificazione e i flussi del software e le
configurazioni di sicurezza. Questo protocollo multipurpose supporta il controllo automatizzato
delle vulnerabilità, il controllo tecnico delle attività e alcune misure di sicurezza. [11]
SCAP è stato creato per organizzare ed esprimere informazioni relative alla sicurezza in modalità standard; può inoltre aiutare a mantenere la sicurezza di sistemi aziendali verificando
l’installazione delle patches oppure controllando le impostazioni di configurazione del sistema
di sicurezza.
I provider devono garantire la sicurezza di diversi sistemi, applicazioni e sistemi operativi
che hanno modalità di gestione differenti; inoltre devono riconfigurare i software o installare le
patches quando vengono scoperte falle o attacchi al sistema. Quando le vulnerabilità non hanno
nomi standard, lo staff addetto alla sicurezza potrebbe non sapere se sono state già rilevate e
rapportate. Lo scopo della standardizzazione introdotta da SCAP è quindi quello di consentire
alle aziende di gestire questi processi di errore e di superare la mancanza di interoperabilità tra
diversi sistemi di sicurezza.
17
SCAP, comunque, non vuole sostituire gli altri tool di protezione, infatti può essere incorporato
un supporto apposito nei software esistenti.
Le specifiche tecniche di SCAP possono essere raggruppate in tre categorie:
• linguaggi per specificare liste di controllo o “checklists”, generare rapporti sulle liste di
controllo e specificare le procedure di testing usate dalle checklists;
• enumerazioni, che includono nomenclature e dizionari per la sicurezza e le informazioni
relative ai prodotti;
• misure di vulnerabilità e sistemi di scoring, che misurano le caratteristiche delle falle e
generano valutazioni basate su esse.
SCAP usa riferimenti standard ai dati per identificare i difetti del software e le configurazioni di
sicurezza. Questo riferimento dei dati è fornito dal National Vulnerability Database (gestito dal
NIST e sponsorizzato dal Department of Homeland Security).
Vediamo adesso in che modo le aziende possono utilizzare SCAP per usufruire dei suoi benefici.
Standardizzare Le Checklists : Una lista di controllo generata che rispetta le norme di
SCAP da informazioni riguardo le impostazioni di sicurezza desiderate, le patches installate e
altri elementi di sicurezza in un formato standard. Le organizzazioni possono ottenere checklists espresse tramite SCAP grazie al NIST Configuration Checklist Program (disponibile su
http://checklists.nist.gov) e personalizzarle per soddisfare specifici requisiti aziendali.
Dimostrare La Conformità : Le checklists conformi al protocollo contengono degli identificatori di configurazione che consentono di generare automaticamente una valutazione che verifica
la conformità ai requisiti stabiliti dal governo americano. Quest’automazione riduce sensibilmente
lo sforzo necessario per ottenere i risultati della valutazione, prevedendo una notevole riduzione
dei costi.
Usare Le Enumerazioni Standard : Le organizzazioni usano vari tools per la gestione della
sicurezza; SCAP consente a queste di standardizzare le enumerazioni quando ci si riferisce a falle
di un software, problemi di configurazione di sicurezza e piattaforme. Utilizzare le enumerazioni
standard rende più facile l’uso degli strumenti di sicurezza, la condivisione di informazioni e
l’istituzione di linee guida per affrontare i problemi che si presentano.
18
Misurare La Vulnerabilità : SCAP consente alle aziende di misurare la vulnerabilità di
un software attraverso sistemi che usano il Common Vulnerability Scoring System - CVSS - (cfr
http://nvd.nist.gov); questo permette di priorizzare il risanamento dei difetti legati alla sicurezza
del software. Quando viene scoperta una nuova falla, viene annunciata pubblicamente e il NIST
crea una CVE (Common Vulnerabilities and Exposures) apposita, identifica i prodotti interessati
con un CPE (Cloud Processing Equipment) e ne effettua una misurazione tramite il CVSS. Tutte
queste informazioni vengono poi inserite nel National Vulnerability Database, in modo tale da
permettere alle aziende di sfruttarle per risolvere i problemi riscontrati e controllare quelle nuove.
Validazione dei Prodotti Conformi a SCAP : Per testare l’attitudine dei prodotti a
sfruttare le caratteristiche e le funzionalità messe a disposizione da SCAP è previsto un programma
di validazione, che evidenzia l’architettura modulare che permette l’interoperabilità tra i prodotti
conformi al protocollo. La validazione viene fatta sulla base di risultati di test effettuati in diversi
laboratori; le validazioni vengono poi pubblicate sulla pagina web del NIST SCAP Validated Tool
(http://nvd.nist.gov/scapproducts).
Integrare SCAP su Prodotti Software : Molti prodotti possono valutare le impostazioni
di configurazione del software utilizzando SCAP invece di affidarsi a controlli manuali. Inoltre,
i fornitori dei prodotti ed altri sviluppatori di checklist creano le loro liste di controllo utilizzando SCAP ed in questo modo contribuiscono al National Checklist Program per promuovere ed
ampliare la disponibilità delle liste di controllo.
In definitiva, SCAP sta rendendo possibile l’automazione di un numero sempre maggiore di
compiti da svolgere necessariamente per avere un certo grado di sicurezza, riuscendo quindi a
risparmiare tempo e denaro che inevitabilmente andavano impegnati quando tutto ciò non era
possibile. [11]
2.2.2
FISMA
Il E-Government Act fu una proposta di legge accettata dal 107° Congresso e trasformata in
legge dal Presidente degli Stati Uniti nel Dicembre del 2002: riconosce l’importanza della sicurezza
delle informazioni per gli interessi della sicurezza economica e nazionale degli Stati Uniti. Il III
Titolo del E-Government Act, intitolato Federal Information Security Management Act (FISMA),
19
richiede alle agenzie federali di sviluppare, documentare ed implementare un programma per
provvedere alla sicurezza dei sistemi che supportano le loro operazioni e attività, incluse quelle
fornite o gestite da altre sorgenti. [12]
FISMA assegna responsabilità specifiche alle agenzie federali, National Institute of Standards
and Technology (NIST) e Office of Management and Budget (OMB), per rafforzare la sicurezza
dei sistemi informativi. In particolare richiede alle aziende di implementare politiche e procedure
di sicurezza che permettano di ridurre il costo ed i rischi ad un livello accettabile.
Secondo FISMA, il termine “Information Security” significa “proteggere le informazioni ed i sistemi informativi da accesso, utilizzo, divulgazione, perturbazione o
distruzione non autorizzati per fornire integrità, confidenzialità e disponibilità”. [13]
In accordo con FISMA, il NIST è responsabile per lo sviluppo di standards, metodi e tecniche per
fornire un’adeguata sicurezza delle informazioni per tutte le operazioni delle aziende, escludendo la
sicurezza dei sistemi nazionali. NIST lavora a stretto contatto con le agenzie federali per migliorare
la loro comprensione e l’attuazione di FISMA, per proteggere le loro informazioni e pubblicare
protocolli e linee guida che forniscono la base per i programmi di sicurezza dei dati.
NIST sviluppa standards, metriche, tests e programmi di validazione per promuovere, misurare
e validare la scurezza nei sistemi e servizi informativi. Per questo motivo nel Gennaio 2003 fu
stabilito il FISMA Implementation Project con lo scopo di supportare l’implementazione e la
conformità al FISMA. [14]
2.2.2.1
FISMA Implementation Project
In risposta al FISMA, NIST ha avviato la Fase I del suo FISMA Implementation Project, che
comprende il Risk Management Framework (RMF) in figura 2.1.
Mentre la RMF è “system oriented”, concentrata cioè sulla tutela di un sistema informativo e
le informazioni ad esso correlate, il progetto FISMA riguarda la gestione dei rischi per l’impresa,
che si manifestano mediante violazioni della sicurezza dei propri sistemi informativi e dei dati ad
essi associati.
20
Figura 2.1 – FISMA Risk Management Framework
La RMF comprende anche attività come la valutazione dei rischi, la pianificazione della sicurezza e altre funzioni correlate alla sicurezza che si verificano all’interno del ciclo di vita di un
sistema di sviluppo.
Per andare incontro ai requisiti del FISMA, il NIST ha deciso di revisionare FIPS 102, la
certificazione del suo sistema di sicurezza rilasciato nel 1983. In particolare, il nuovo standard
FIPS 199 (Federal Information Processing Standard 199, Standards for Security Categorization of
Federal Information and Information Systems) introduce alcuni cambiamenti significativi su come
il governo degli Stati Uniti dovrebbe proteggere la sicurezza dei suoi sistemi informativi.
Emanato nel Febbraio 2004 ed entrato in vigore il giorno stesso in cui è stato rilasciato, FIPS
199 soddisfa il requisito che FISMA affida a NIST di “sviluppare standard che le agenzie federali
possono usare per categorizzare le informazioni ed i sistemi di informazioni basati sull’obiettivo di
fornire adeguati livelli di sicurezza delle informazioni in base ad una serie di livelli di rischio.” [15]
Questo standard si basa su un concetto semplice e ben consolidato, quello di determinare priorità idonee per i sistemi informativi delle aziende e di conseguenza applicare misure appropriate
per proteggere adeguatamente questi sistemi. I controlli di sicurezza applicati su un particolare
sistema informativo dovrebbero essere commisurati alla criticità ed alla sensibilità del sistema
stesso, calcolate sulla base di una serie di paramentri quali il potenziale impatto su operazioni
21
dell’azienda e le sue attività, oppure sulla possibilità che ci possano essere individui che manomettano la sicurezza attraverso la perdita di confidenzialità (una divulgazione non autorizzata),
integrità (una modifica non autorizzata) o disponibilità dei dati(denial of service).
FIPS 199, insieme al FISMA RMF, può dunque essere usato come una parte del programma di
gestione dei rischi di un’azienda per garantire che vengano applicati controlli di sicurezza adeguati
ai sistemi informativi.
Nella Fase II del progetto di implementazione FISMA, il NIST intende collaborare con organizzazioni professionali ed accademiche per stabilire un programma di accreditamento per le
organizzazioni in grado di svolgere i processi di valutazione dei controlli di sicurezza discussi
precedentemente.
L’obiettivo di questa attività sarebbe quello di creare un gruppo di organismi competenti nella
valutazione dei controlli di sicurezza che potrebbero essere assunti dalle agenzie governative per
aiutarle con le loro valutazioni.
In conclusione il FIPS 199, la FISMA RMF e la suite associata di documenti di orientamento
cambieranno significativamente la modalità in cui le agenzie federali categorizzano e danno priorità
ai loro sistemi e quelle in cui selezionano, documentano e implementano i controlli di sicurezza
del sistema. Inoltre impatteranno sul modo in cui si effettuano certificazioni ed accreditamenti, e
su come viene eseguito il monitoraggio dei controlli per garantire che continuino ad operare come
previsto con risultati visibili a livello di costi, consistenza, miglioramento di sistemi e riduzione
dei rischi. [15]
22
Capitolo 3
Architetture per la sicurezza di
sistemi Cloud
Le tecniche di sicuezza del Cloud Computing nascono su principi precedentemente sviluppati
nell’ambito dei sistemi informatici. E’ risultato molto utile attingere alle basi del sistema operativo Multics (Multiplexed Information and Computing Service), le quali sono diventate elementi
essenziali non solo dei sistemi operativi ma anche del Cloud moderno. [16]
Ad esempio, Multics implementa meccanismi per la protezione basati su permessi (anzichè su
esclusioni) con controllo degli accessi.
Inoltre, tali sistemi seguono il famoso principio di Kerckhoffs, trascurando la riservatezza
dell’algoritmo di crittografia seppur mantenedo segreta la chiave.
Ovviamente le tecniche già sviluppate non potevano essere sufficienti per proteggere un Cloud
Computing, per cui sono state affiancate ad altri principi e architetture che variano a seconda
della finalità del sistema. [17]
3.1
Architettura basata sul modello proattivo per Cloud
ibrido
I modelli di distribuzione Cloud vengono classificati dal NIST come:
23
Figura 3.1 – Vulnerabilità per Cloud Pubblico e Privato
• Private Cloud - Usato in modo privato, tipicamente l’utilizzatore è il proprietario o ha un
contratto d’affitto dell’infrastruttura
• Community Cloud - Condivisione di infrastrutture tra una o più comunità che condividono
gli stessi interessi
• Public Cloud - Offerto al pubblico, solitamente si tratta di mega-infrastrutture distribuite
su larga scala
• Hybrid Cloud - Composizione di due o più Cloud
A seconda del sistema utilizzato, si può prevedere una predisposizione ad alcuni rischi ed una
maggiore protezione nei confronti di altri.
In particolare consideriamo solo i modelli di distribuzione privati e pubblici in quanto gli altri
due sono delle combinazioni di questi. Con riferimento al primo capitolo, possiamo vedere la figura
3.1 che ci fornisce una visione rapida delle vulnerabilità dei due sistemi.
Possiamo concludere che il Cloud pubblico è più vulnerabile rispetto quello privato, motivo
che spinge diverse aziende ad adottare il secondo.
Una recente ricerca fatta da Novell mette in evidenza come il mercato sta andando in direzione
del Cloud ibrido, che accosta l’agilità, la flessibilità e l’economicità di quello pubblico alla sicurezza
e all’affidabilità di quello privato. [18]
In una conferenza internazionale dell’IEEE tenuta nel Maggio 2011, è stata presentata una
nuova architettura per Cloud ibrido focalizzata sulla sicurezza, la quale utilizza un Private Cloud
che offre un controllo attivo del provider.
In particolare la soluzione offerta è duplice:
24
Figura 3.2 – Architettura per Cloud Ibrido
• un aumento delle politiche di sicurezza
• un sistema dedicato alla sicurezza, implementato come un sottostrato sull’infrastruttura di
Cloud privato che controlla in modo proattivo e segnala eventuali violazioni delle policy.
Questa architettura prevede, in cascata, i seguenti passi:
• creazione di dettagliate politiche di gestione
• identificazione dei Cloud Service Provider compatibili con tali politiche
• stesura di un dettagliato Service Level Agreement con le disposizioni per il monitoraggio dei
servizi
• continuo monitoraggio per scovare eventuali intrusioni
• rilascio di feedback per raffinare il modello
Ruolo fondamentale ricopre la ricerca delle politiche di gestione, dove [19] devono essere tenute in
considerazione le sfide ed il gran numero di minacce alla sicurezza. E’ importante la partecipazione
in questa fase di tutti i tipi di figure professionali coinvolte nel sistema, inclusi gli utenti finali e gli
amministratori che, per ovvi motivi, hanno un punto di vista completamente differente. Proprio
25
per la loro importanza, queste politiche devono chiaramente descrivere gli utenti privilegiati, la
locazione dei dati, lo schema di crittografia, il recovery, la modalità di investigazione, la disponibilità a lungo termine, la gestione dei dati, le applicazioni di sicurezza, la sicurezza delle interfacce
e delle API ed i meccanismi di cancellazione delle informazioni.
Il sottosistema dedicato alla sicurezza provvede a 4 compiti primari:
1. monitorare gli indirizzi IP e le blacklist per prevenire attacchi DoS
2. utilizzare strumenti di scansione automatica delle vulnerabilità del sistema
3. utilizzare strumenti di test di penetrazione, come il Metasploit Framework [20], senza però
causare alcuna interruzione del servizio
4. effettuare il logging di sistema per conoscere le modifiche apportate e poterle rapidamente
ripristinare
3.1.1
Raccomandazioni e linee guida del NIST per Cloud pubblico
Per far crescere la fiducia delle organizzazioni nell’utilizzo del Cloud Computing, il Laboratorio
di Information Technology (ITL) del NIST ha recentemente pubblicato SP 800-144, “Guidelines on
Security and Privacy in Public Cloud Computing”. L’articolo discute dei vantaggi e degli svantaggi
di servizi cloud pubblici e, in funzione di questi, delinea dei punti fondamentali per assicurare
un’adeguata protezione puntando sull’istruzione degli utenti finali alle metodologie adottate.
Ad esempio, consiglia di pianificare sempre in modo dettagliato il lavoro da svolgere per assicurare la conformità delle policy di sicurezza organizzative, il rispetto della privacy, e che le risorse
IT vengano utilizzate saggiamente. Questo approccio dimostra la sua efficacia massima quando
un’azienda comincia a trasferire i propri servizi su un’infrastruttura esterna all’organizzazione
innescando il meccanismo dell’outsourcing dei dati. Fin da subito bisogna prestare massima attenzione ai problemi e alle procedure di sicurezza perchè, un errore o una mancanza in fase iniziale
può provocare un’esposizione del sistema a rischi inutili senza considerare l’aumento esponenziale
del costo di riparazione delle falle. Inoltre, prima di scegliere il fornitore Cloud è bene studiare le
certificazioni e il carico che può sopportare in modo da poter offrire una buona qualità dei servizi
soddisfando le eventuali richieste e vincoli che il progetto impone.
26
Assicurarsi che il lato client (con le relative interfacce) rispetta le esigenze organizzative, come
la separazione tra gli utenti, e di privacy. Un problema comune è quello innescato dalle interfacce
web che, attraverso estensioni e plugin dei browsers, possono permettere la pubblicazione di dati
sensibili. La grossa diffusione degli smartphone ha portato la necessità di utilizzare le risorse
Cloud in estrema mobilità. Tali dispositivi hanno un hardware più limitato di quello dei personal
computer e per questo motivo non implementano tutte le politiche di sicurezza, innescando così
un meccanismo a catena che può ledere l’integrità di tutto il sistema condiviso.
Come ultimo consiglio, l’ITL propone di monitorare le attività e valutare l’attuazione di politiche, standard, procedure, controlli e linee guida che stabiliscono e proteggono la riservatezza,
l’integrità e la disponibilità delle risorse di sistema di informazione. [21]
3.2
National Security Cloud Architecture
Per modelli di sicurezza nazionale, il modello ibrido proposto nel paragrafo precedente non è
completamente adatto in quanto necessita del contributo del Community Cloud. Tali sistemi sono
utilizzati non solo per supporto a missioni di sicurezza, ma sono messi a disposizione anche di
comunità di interessi - COI - (da qui l’esigenza del Community Cloud). Il COI è un approccio di
cooperazione in un gruppo di utenti che condividono un interesse e un vocabolario comune per lo
scambio di informazioni nel perseguimento dei loro obiettivi di missione. Il COI è generalmente
a breve termine: deve essere creato in modo rapido e immediatamente risolto una volta che gli
obiettivi della missione sono stati raggiunti. Le reti COI, quindi, si distinguono dalle altre per
creazioni, gestioni e distruzioni veloci e dinamiche, caratteristiche principali dei sistemi Cloud.
Ad ogni modo, spostare i sistemi di sicurezza nazionale in un sistema Cloud non è un compito
facile. Diversi papers suggeriscono linee guida per fare queste operazioni [22-27] ma solo in uno
si parla di una architettura studiata appositamente [28]. Questa tiene in considerazione le nuove
esigenze introdotte dalla presenza dei COI, considerando la possibilità di questi di creare continui
rapporti di collaborazione con diverse associazioni esterne che devono avere un accesso limitato al
sistema, accostandole al cloud ibrido già implementato.
L’architettura proposta è formata da:
• Private Cloud per quelle informazioni sensibili la cui condivisione è ristretta a pochi utenti
27
Figura 3.3 – National Security Cloud Architecture
• Community Clouds per la condivisione di informazioni sia a lungo che a breve termine e per
progetti di collaborazione
• Public clouds per la raccolta e la diffusione delle informazioni pubbliche
• Cloud per la ridondanza dei dati, per il recupero e il ripristino dello stato e dei dati in
presenza di malfunzionamenti
Requisiti del National Cloud impongono delle restrizioni sulla separazione fisica e logica delle
partizioni dell’infrastruttura tra gli utilizzatori. Ad esempio, non è tollerabile l’utilizzo di una stessa Virtual Machine (VM) tra più comunità nè tantomeno l’esecuzione di VM multiple all’interno
della stessa partizione. Per ovviare a questo problema, l’architettura proposta prevede la gestione
della memoria in robuste partizioni a grana fine. Inoltre, sono implementati anche degli algoritmi per la cancellazione sicura in modo da assicurare che nessuno possa recuperare informazioni
dell’utente che ha precedentemente usato la memoria assegnatagli.
Oggigiorno sono ancora poche le nazioni che usano queste architetture, ma ovunque sono state
adottate hanno avuto un notevole successo, come per esempio nelle forze armate americane con il
Rapid Access Computing Environment (RACE) dello U.S. Defense Information Systems Agency
28
(DISA) [29], oppure nel sistema sviluppato e gestito dal U.S. General Services Administration
storefront accedibile dal sito apps.gov [30]
3.3
Architettura On-Demand
Avere una sicurezza forte comporta un importante consumo di risorse IT e aumenta le difficoltà
di utilizzo. Per garantire una giusta protezione con una gestione semplice e contrastare lo spreco
delle risorse è possibile utilizzare un’architettura on-demand, la quale si propone di garantire una
sicurezza differenziata per i vari servizi di cloud computing.
L’architettura è diviso in tre strati:
1. input, che si divide a sua volta in
• livello di sicurezza
• tipo di servizio
• rischio di accesso alla rete
2. lo strato delle politiche di gestione che ha tre unità diverse corrispondenti ai tre domini di
sicurezza
3. meccanismo di sicurezza
Scopo del processo in cascata appena descritto è la produzione di parametri in relazione agli
input in ingresso che servono per configurare il tipo di protezione da adottare per uno specifico
servizio. Per questo motivo, devono essere settati i tre parametri in modo congruente con la rete e il
servizio richiesto, scegliendo valori maggiori rispetto a quelli che l’operatore del Cloud ha impostato
come livelli minimi per garantire un funzionamento accettabile. In caso di non configurazione dei
parametri di input, il sistema può assegnare un servizio con un livello di sicurezza minimo, che
spesso non risulta essere il più adatto. Questo tipo di architettura così studiata è utile quando
29
Figura 3.4 – Architettura On-Demand
vengono offerti servizi differenti. Ad esempio, uno streaming multimediale ha restrizioni circa il
ritardo ed è permissivo rispetto l’integrità mentre un trasferimento dati, solitamente, ha esigenze
totalmente opposte.
Il parametro di rischio di accesso alla rete dipende da come l’utente si collega all’infrastruttura
(ad esempio reti 3G, WiFi pubblici e connessioni via cavo). E’ chiaro che è più pericolo un accesso
ad un WiFi pubblico rispetto ad una connessione via cavo privata. Questo comporta un’esigenza
di meccanismi di sicurezza più forti che devono rispettare le politiche di gestione.
I vantaggi di questa organizzazione possono essere visti come:
• sviluppo di tutte le applicazioni con lo stesso processo data la piena flessibilità del modello
• scalabilità dell’architettura tra più sistemi con possibilità di distribuirli tra diversi provider
• pochi ingressi da gestire in fase di sviluppo
• facilità nell’estensione grazie alla sua integrabilità con sistemi preesistenti
• possibilità di gestire la sicurezza con meccanismi di feedback per migliorarla durante l’esecuzione
30
In conclusione, la politica adottata utilizza i tre principi (il rischio di accesso alla rete, il tipo di
servizio e il livello di sicurezza) per produrre i paramentri utilizzati per la configurazione dei diversi
servizi di sicurezza. In questo modo vengono soddisfatte le varie esigenze di utenti e provider.
31
Capitolo 4
Conclusioni
Data la posta in gioco, sembra inevitabile che la sicurezza diventi un significativo elemento di
differenziazione di Cloud Computing business. Anche se questa protezione comporta un aumento
del costo del prodotto finale, è facile aspettarsi che il mercato preferisca un sistema così fatto.
Infatti, diversamente da altri casi dove si cerca l’economicità a scapito anche della qualità, gran
parte del Cloud Computing si rivolge a clienti che lo usano per fini lavorativi e perciò è necessario
affidare alla sicurezza una priorità elevata. Una giusta via di mezzo potrebbe però essere quella
di offrire uno spettro di primitive di sicurezza selezionabili tramite diversi livelli “plug and play”,
lasciando la scelta all’utente, opportunamente istruito.
In definitiva, le diverse architetture che gli esperti stanno proponendo hanno lo scopo di raggiungere un giusto compromesso tra sicurezza ed accessibilità, adatti all’ambito in cui il Cloud
sarà utilizzato, facilitando e invogliando così la migrazione dai vecchi sistemi.
32
Bibliografia
[1] M. J. Schultz,
"A Survey of Cloud Security Issues and Offerings",
Avaiable:
http://www.cse.wustl.edu/~jain/cse571-11/ftp/cloud/index.html
[2] I. Foster, Y. Zhao, I. Raicu, S. Lu, "Cloud Computing and Grid Computing 360-Degree
Compared"
[3] A. Tripathi, A. Mishra, "Cloud Computing Security Considerations"
[4] Future Generation Computer Systems, Md. T. Khorshed, A.B.M. S. Ali, S. A. Wasimi "A survey on gaps, threat remediation challenges and some thoughts for proactive attack detection
in cloud computing", 2012
[5] L. M. KaufMan, J. Harauz, L. M. Kaufman, B. Potter, "Data Security In The World Of
Cloud Computing", July/August 2009
[6] P. Massonet, S. Naqvi, C. Ponsard, J. Latanicki, T. Theresis, B. Rochwerger and M. Villari
"A Monitoring and Audit Logging Architecture for Data Location Compliance in Federated
Cloud Infrastructures", 2011
[7] CERT
Insider
Threat
Research,
2010
CyberSecurity
Watch
Survey,
http://www.cert.org/archive/pdf/ecrimesummary10.pdf, December 2010
[8] Jonathan Spring Software Engineering Institute, "Monitoring Cloud Computing by Layer,
Part 1", March/April 2011
[9] Jonathan Spring Software Engineering Institute, "Monitoring Cloud Computing by Layer,
Part 2", May/June 2011
[10] A NIST Definition of Cloud Computing, NIST Special Publication (SP) 800-145
33
[11] S. Radack and R. Kuhn, "Managing Security: The Security Content Automation Protocol",
National Institute of Standards and Technology, January/February 2011
[12] http://csrc.nist.gov/groups/SMA/fisma/overview.html#background
[13] Official FISMA Standard "TITLE III - Information Security"
[14] http://csrc.nist.gov/groups/SMA/fisma/index.html
[15] R. Ross, S. Katzke, and P. Toth, "The New Fisma Standards And Guidelines. Changing The
Dynamic Of Information Security For The Federal Government"
[16] Jerome H. Saltzer. Protection and the control of information sharing in multics. Commun.
ACM, 17(7):388–402, 1974.
[17] Y. Chen, V. Paxson, R. H. Katz, "What’s New About Cloud Computing Security?", January
2010
[18] Novell
survey,
http://www.informationweek.in/Cloud_Computing/10-10-
05/Novell_survey_reveals_widespread_enterprise_adoption_of_private_clouds.aspx
,
January2011
[19] Kresimir Popovic and Zeljko Hocenski , “Cloud computing security issues and challenges,” in
Proceedings of the 33rd International Convention, MIPRO 2010
[20] Metasploit Framework, http://www.metasploit.com/framework/, December 2010
[21] Shirley Radack Editor, "Guidelines For Improving Security And Privacy In Public Cloud
Computing", ITL Bulletin For March 2012
[22] Amazon.com, "Amazon Web Services: Overview of Security Processes," September 2008.
[23] M. Armbrust, et al., "Above the Clouds: A Berkeley View of Cloud Computing," UC Berkeley
Reliable Adaptive Distributed Systems LaboratoryFebruary 10 2009.
[24] Cloud Security Alliance, "Security Guidance for Critical Areas of Focus in Cloud Computing,
ver. 2.1," 2009.
[25] M. Jensen, et al., "On Technical Security Issues in Cloud Computing," presented at the 2009
IEEE International Conference on Cloud Computing, Bangalore, India 2009.
34
[26] P. Mell and T. Grance, "Effectively and Securely Using the Cloud Computing Paradigm," ed:
National Institute of Standards and Technology, Information Technology Laboratory, 2009.
[27] N. Santos, et al., "Towards Trusted Cloud Computing," in Usenix 09 Hot Cloud Workshop,
San Diego, CA, 2009.
[28] A. Kim, J. McDermott, and M. Kang, "Security and Architectural Issues for National Security
Cloud Computing", International Conference on Distributed Computing Systems Workshops,
2010
[29] E. Chabrow. (2009, May 27) DISA’s Cloud Computing InitiativesGovinfosecurity.com.
Available: http://www.govinfosecurity.com/articles.php?art_id=1493
[30] GSA
News
nistration
Release.
Launches
(2009,
GSA
December
Cloud
5
Storefront
2009).
Obama
Apps.gov.
AdmiAvailable:
http://www.gsa.gov/Portal/gsa/ep/contentView.do?contentType=GSA_BASIC&contentId=28477
35

Elaborato Palmieri Marco Rosario n46000128

Transcript

Documenti analoghi

My Cloud EX2 and EX4 Brochure

My Cloud EX2 Brochure

Qualta è il primo rivenditore di a offrire l`innovativa soluzione

CLOUD COMPUTING

PureCloud Communicate - Interactive Intelligence

Goggle Cloud Print

scheda tecnica

Attività

Sistemi Distribuiti e Cloud Computing

Enigen Formazione Certificata Salesforce 21.01.16