home >> mb156
di

Marco Piraccini

Nella stessa sezione>
liferaySymposium
html5mobile-2
cloudsecurity-1
portlet-3
rest_ws-3
Nella stessa serie
cloudsecurity-1
News on Feed


Bookmarking
bookmark on Delicious bookmark on Digg bookmark on Furl bookmark on Reddit bookmark on Slashdot bookmark on Technorati
 
 


MokaByte 156 - Novembre 2010

La sicurezza nel cloud computing

I parte: Il lato oscuro della nuvola

Il Cloud Computing presenta indubbi vantaggi e si sta affermando come una soluzione sempre pi¨ diffusa e conveniente. In questo articolo presentiamo una panoramica sul Cloud Computing dal punto di vista della sicurezza. L'obiettivo Ŕ quello di spiegare come, a fronte dei notevoli aspetti positivi, esistano anche delle questioni relative alla sicurezza che devono essere affrontate in maniera adeguata.

In questo articolo presentiamo una panoramica sul Cloud Computing guardato attraverso la lente della sicurezza. L’obiettivo è dare consapevolezza su quanto deve essere necessariamente preso in considerazione nell’ipotesi di "andare sulle nuvole". Oltre agli indiscussi vantaggi, infatti, nella "nuvola" si nascondono nuovi problemi, molti dei quali non sono di semplice soluzione. In questa prima parte ci occupiamo dei numerosi aspetti (tecnici, legali etc.) relativi alla sicurezza, analizzando da vicino le tipologie più comuni di rischi e le opportune contromisure da adottare.

Cloud Computing

"Computing may some day be organized as a public utility, just as the telephone system is a public utility" (John McCarthy, 1961).

Pensandoci bene, nessuno è in realtà interessato al possesso della linea telefonica o dei tubi della rete idrica che arrivano a casa propria: quello che ci interessa è l’erogazione dei relativi servizi. Perche’ questo non è possibile anche per i servizi IT? Il paradigma del Cloud Computing -in estrema sintesi- è esattamente questo: portare questi concetti, ovvi nella realtà quotidiana, anche a livello dell’IT.

Stiamo quindi parlando di una grande opportunità con un fortissimo "appeal" per il business. Tramite le piattaforme cloud, le risorse sono ottimizzate: si paga solo quello che si usa (cioè non si allocano risorse se non servono) ed è possibile richiedere risorse "on demand" in modo elastico rispetto all’effettiva richiesta di uso. Queste considerazioni (e l’evidente profitto che i provider possono ottenere dall’offrire questi servizi) spiegano l’esplosione del Cloud Computing.

Occorre specificare che quando si parla di Cloud Computing in realtà si intende un insieme di servizi differenti, tutti classificabili sotto il cappello del Cloud. Il U.S. National Institute of Standards and Technology (NIST) fornisce una definizione che è oggi ampiamente accettata, e che prevede:

  • 5 caratteristiche essenziali: on demand services, ubiquitous network access, location independent resource pooling, rapid elasticity, measured Service;
  • 3 Delivery Models (globalmente indicati come SPI): Software as a Service (SaaS), Platform as a Service (PaaS) e Infrastructure as a Service (IaaS);
  • 4 modelli di deployment: cloud pubblico, privato, community o ibrido.






 

Figura 1 - NIST: Definizione del Cloud Computing.

 

 

Per i nostri scopi, cioè discutere del Cloud Computing dal punto di vista della sicurezza, è importante capire le differenze tra i modelli di delivery e tra publice private cloud.

IaaS, SaaS e PaaS

Sempre appoggiandoci alla classificazione NIST, possiamo riferirci al Cloud Reference Model. Il modello rappresenta tutto quello che può essere incluso in un’architettura cloud in cui i tre differenti modelli di Delivery rappresentano tre insiemi di quello che è erogato dai servizi cloud. Secondo questo modello, IaaS è la base per tutti i servizi cloud, i servizi PaaS possono essere costruiti su infrastruttura IaaS (anche se trasparente) e il software SaaS può a sua volta includere implicitamente tutto lo stack.






Figura 2 - Relazioni tra IaaS, PaaS e SaaS.

 

 

In sintesi, i servizi IaaS forniscono un’infrastruttura utilizzabile (VM da istanziare, reti, storage e servizi a corredo), i servizi PaaS forniscono un ambiente di sviluppo e di deploy completo (es, Google App Engine) mentre si parla di SaaS quando ciò che è fornito è il servizio offerto da applicazioni finite (es, Gmail, Google Calendar).

Public Cloud / Private Cloud

Ai fini della nostra analisi è altresì utile considerare la distinzione tra Public Cloud e Private Cloud. Una Public Cloud è una infrastruttura condivisa da diversi Cloud Customer, tipicamente in multi-tenancy (ad esempio due VM di due clienti diversi possono condividere lo stesso hypervisor o la stessa rete). I Private Cloud sono al contrario infrastrutture cloud per una singola organizzazione. La struttura può essere gestita dall’organizzazione stessa o anche da terze parti. Quando gestita all’esterno, sono normalmente accessibili tramite VPN.

Cloud computing e sicurezza

I vantaggi dal punto di vista economico sono innegabili e non è scopo di questo articolo calcolare i punti favorevoli di una infrastruttura cloud in termini di ROI. Ma è tutto oro quello che luccica? In realtà c’è un lato oscuro. Secondo Forrester, nel 3Q del 2009, circa la metà degli IT Manager in USA e Europa hanno deciso di non utilizzare il Cloud Computing per motivi di sicurezza. Hanno ragione? Proviamo a definire una (breve) lista di vantaggi e svantaggi, che poi analizzeremo meglio in seguito.

Vantaggi

  • La sicurezza è un problema di tutto il cloud e quindi è implicitamente più semplice da gestire. Ad esempio, grazie alla virtualizzazione (possiamo dare tranquillamente per scontato che tutte le piattaforme IaaS si basano su di essa) è possibile identificare pattern legati all’uso di risorse per identificare situazioni di uso non "normale".
  • La gestione degli aggiornamenti dell’infrastruttura è facilitata, ed è quindi semplice avere un sistema sempre aggiornato all’ultimo livello di patch.
  • La sicurezza in alcune modalità (p.e.: SaaS) è completamente in carico al Cloud Provider e quindi non è un problema per le organizzazioni che utilizzano questi servizi.

Svantaggi

  • Esistono numerosi rischi legati alla condivisione delle risorse e alla gestione dell’isolamento (reti, dischi, hypervisor).
  • È possibile che le infrastrutture cloud vengano utilizzate in modo malevolo per condurre attacchi o gestire reti di Botnet.
  • Le legislazioni sono carenti e inadatte: si ragiona ancora in termini di server "fisici" e ben localizzati. Come si gestisce la privacy dei dati in un contesto cloud?
  • La sicurezza delle API esposte dai servizi cloud è critica (la sicurezza globale dipende dal disegno corretto delle API in termini di modello di sicurezza e dalla possibilità che queste siano sfruttabili per attacchi).
  • La mancanza del controllo fisico e la condivisione delle risorse può portare a problemi di spionaggio industriale, perdita o manipolazione dei dati, esposizione dei dati a terzi.

In generale non si può affermare che il Cloud Computing sia implicitamente più o meno sicuro dei sistemi "tradizionali". Infatti, come ogni cosa, il Cloud Computing crea nuove opportunità e introduce nuovi rischi. La novità è che oltre ai rischi tradizionali (che rimangono) se ne affiancano anche altri "nuovi" che derivano da questo paradigma (declinato sui tre Delivery Model). Le questioni spaziano quindi dagli ambiti più "tradizionali" della sicurezza a aspetti contrattuali e legali che in parte erano assenti nelle architetture tradizionali e che in certi ambiti non sono affatto secondari. In sintesi, il Cloud Computing include tutti i rischi tradizionali per l’information security e ne aggiunge altri. Vedremo di seguito le diverse tipologie di rischi e presenteremo le adeguate contromisure.

Iniziamo a considerare i rischi legali, per poi passare alle questioni più tecniche

Rischi legali e relative contromisure

È utile capire che i rischi a livello legale esistono e vanno affrontati. Questo articolo non vuole essere ovviamente un manuale legale, ma vuole "spaventare" a sufficenza il lettore affinche’ capisca che certi problemi possono benissimo verificarsi. È molto meglio sapere di avere un potenziale problema piuttosto che ignorarne completamente l’esistenza!

È interessante osservare che il problema, dal punto di vista giuridico, è in realtà legato solo ai dati. Per il giurista, il Cloud Computing si traduce nella condivisione o conservazione, da parte degli utenti, di dati o applicazioni su server di proprietà o gestiti da terzi, ai quali si accede tramite Internet. Questo diventa un problema nel momento in cui le informazioni sono sparse in centri che rispondono a regimi giuridici differenti.






Figura 3 - Dove sono i dati?

 

 

Alcuni problemi che in generale possono emergere nell’uso di un cloud sono i seguenti.

  • Rivelazione, da parte del Cloud Provider, di segreti, a causa di una imposizione di governi stranieri; rischio di obbligo di consegna dei dati all’autorità giudiziaria.
  • Fallimento economico di un Cloud Provider e possibile trasferimento del patrimonio aziendale.
  • Spionaggio industriale
  • Difficoltà nel reperimento di informazioni per far valere una pretesa in giudizio o per esercitare il diritto di difesa.
  • Rischi connessi alla titolarità dei diritti di proprietà intellettuale.
  • Licenze non adatte "per il cloud" e che quindi possono diventare un problema.

Esistono legislazioni che tutelano da questi problemi? In ambito UE, esiste la direttiva 95/46/CE (Data Protection Directive) che norma la gestione dei dati. L’articolo 42 dichiara:

 

Le disposizioni del presente codice non possono essere applicate in modo tale da restringere o vietare la libera circolazione dei dati personali fra gli Stati membri dell’Unione Europea, fatta salva l’adozione, in conformità allo stesso codice, di eventuali provvedimenti in caso di trasferimenti di dati effettuati al fine di eludere le medesime disposizioni.

 

Il che implica che utilizzare servizi cloud all’interno dell’UE è possibile ed è normato dalle direttive europee. Diversi provider, infatti, hanno installato data center all’interno dell’UE per erogare servizi ai cittadini europei. La direttiva 95/46/CE è comunque ora in revisione (ad esempio non è chiaro il ruolo che ha il Cloud Provider rispetto al titolare dei dati).

Che succede però se il provider utilizza data center che non sono in Europa? Il trasferimento dei dati verso un Paese al di fuori dell’Unione Europea è consentito se laCommissione Europea constata che un Paese non appartenente all’Unione Europea garantisce un livello di protezione adeguato.

In sintesi: se sono in UE, e i provider mi garantiscono che i dati sono in UE, sono a posto, ma per gli altri casi? A oggi mancano gli accordi internazionali e una visione comune delle policy da adottare per la privacy dai vari provider, anche se esistono accordi in essere, come il "Safe Harbor" che prevedono una certificazione per le aziende USA che vogliano dichiararsi compatibili con la direttiva UE 95/46/EC.

Come scegliere il Cloud Provider per evitare problemi? Considerate che, in termini legali, il "titolare" dei dati (che in questo caso presumibilmente è chi acquista il servizio dal Cloud Provider) rimane comunque responsabile. Deve quindi essere sempre in grado di verificare se quanto descritto dal contratto con il Cloud provider coincide con la realtà. Sintetizzando, si possono dare una serie di indicazioni per la scelta del provider e per la contrattazione:

  • Richiedere i livelli minimi di servizio (SLA) sulla protezione dei dati e sulla continuità.
  • Richiedere trasparenza in merito alla logica applicata al trattamento dei dati e in generale sulle policy di sicurezza applicate.
  • Richiedere una policy pubblica del fornitore in merito alla riservatezza dei dati.
  • Se in UE, richiedere che i dati siano mantenuti in data-center collocati fisicamente in UE (p.e.: Amazon permette di scegliere la "zona" dei data-center). Mantenere comunque la conoscenza di dove i dati sono, informandosi delle restrizioni dei Paesi e delle zone.
  • Capire, in relazione alle zone, le circostanze sotto le quali gli storage possono essere confiscati da terze parti o da entità governative. Assicurarsi che gli SLA del Cloud Provider prevedano la segnalazione che i dati sono stati confiscati o, meglio, che stanno per esserlo.

Rischi tecnici e relative contromisure

In questo capitolo consideriamo un elenco (assolutamente non esaustivo) di alcuni rischi e contromisure da utilizzare in ambiente cloud. L’elenco è in parte preso da "Cloud Computing Security Risk Assessment" di ENISA (European Network and Information Security Agency) e da "Top Threats to Cloud Computing" di CSA (Cloud Security Alliance). Per ogni rischio, oltre al nome, è indicata una descrizione più le eventuali contromisure individuate.

 

Nome rischio

Isolation Failure

Descrizione

In un cloud le risorse (soprattutto in uno scenario IaaS) sono condivise tra diverse VM e, di conseguenza, tra diversi customer. Vulnerabilità, ad esempio nel modello di sicurezza dell’hypervisor, possono portare all’accesso non autorizzato delle risorse non condivise. Inoltre la mancanza di precisi SLA potrebbe portare un customer a monopolizzare le risorse. Vulnerabilità a questo livello possono portare l’attaccante a manipolare assets all’interno del cloud, provocando DOS (spengo le VM), fuga di dati, compromissione di dati (sostituzione di VM con copie modificate) o danno economico (replica e lancio di molte copie di una VM).

Un esempio di attacco che può essere portato è il cosiddetto "cloudburst", del tipo "guest to host escape" basato su una serie di bug che coinvolgonevano il device virtualizzato "VMWare SVGA II" su piattaforma VMWare e che permette(va) l’esecuzione di codice sull’host dal guest.

Altre tipologie di attacchi possibili sono:

  • M Rootkit.
  • VM Hopping: in cui un attaccante, sfruttando vulnerabilità dell’hypervisor, prende il controllo di altre VM che girano sullo stesso hypervisor

Nel caso di PaaS è possibile pensare ad attacchi che si basano su vulnerabilità della piattaforma. Questo tipo di attacchi sono ovviamente meno pericolosi in caso di Cloud Private.

Contromisure

IaaS:

  • Identificare quali tipologie di virtualizzazione sono utilizzate dal provider.
  • Capire quali controlli di sicurezza sono utilizzati nelle VM (HIDS, anti-virus, vulnerability scanning, etc.) oltre all’isolamento fornito dall’hypervisor.

Per tutti:

  • Imporre SLA per il patching e rimedio delle vulnerabilità.
  • Condurre Vulnerability Scanning.

 




Figura 4 - Sfruttando vulnerabilità dell’Hypervisor, l’attaccante può spegnere le altre VM.

 

Nome rischio

Perdita o furto dei dati

Descrizione

I dati sono accessibili al provider e -in caso di problemi di isolamento- anche agli altri clienti. È fondamentale quindi proteggerli negli storage e nei trasferimenti. Particolare attenzione va fornita per i dati e i log sensibili.

Contromisure

  • Identificare e separare dati sensibili (da cifrare) dai dati non sensibili.
  • Criptare e proteggere i dati in tutti i trasferimenti (compresi i backup).
  • Analizzare la protezione dei dati sia a design time sia a runtime.
  • Gestire le chiavi in modo corretto (chiavi SSL, file encryption keys, coppie di chiavi per l’identificazione dei Cloud Provider o dei Cloud Customer). Nel caso sia il Cloud Provider a effettuare Key Management, capire come le chiavi vengono generate, usate, mantenute, cancellate. Comprendere le policy di gestione delle chiavi.
 


Nome rischio

Esaurimento delle risorse

Descrizione

Le risorse sono usualmente allocate in base a proiezioni statistiche. Può succedere che il provider non sia in grado di allocare le risorse richieste (magari a seguito di un attacco DDSO).

Contromisure

Assicurarsi che le SLA siano chiaramente definite, misurabili, applicabili e adeguate per i requisiti.


 

Nome rischio

Cancellazione dei dati insicura

Descrizione

Quando è richiesta una cancellazione di risorse, questo può non portare al wiping (cancellazione completa) dei dati. In un ambiente multi-tenant ciò può risultare pericoloso. Quando il wiping sia necessario (casi da identificare) occorre verificare se è effettivamente possibile.

Contromisure

  • Capire il processo di retirement degli storage del provider.
  • La distruzione dei dati è estremamente difficoltosa in un ambiente con multi-tenancy. Capire se le API supportano il wiping qualora sia necessario.

 

Nome rischio

Cloud Provider Malicious Insider

Descrizione

Può esserci poca visibilità del modo in cui gli impiegati del Cloud Provider accedono all’infrastruttura: i loro accessi sono monitorati? In che maniera? Questo può portare a situazioni in cui gli impiegati del Cloud Provider vengono ingaggiati da aziende avversarie o da hacker per recuperare dati in modo fraudolento o per prendere il controllo dei servizi senza essere individuati.

Contromisure

  • Specificare i requisiti sulle risorse umane a livello contrattuale.
  • Richiedere trasparenza su tutte le pratiche di sicurezza e di gestione, così come l’accesso ai report di compliance.
  • Crittografare tutti i dati sensibili.


Nome rischio

Conflitti tra le procedure di hardening del cliente e quelle del Cloud Provider

Descrizione

I Cloud Provider devono definire una chiara segregazione di responsabilità che articola il set minimo di azioni che il Cloud Customer deve applicare. Infatti, i clienti in qualche caso hanno dato erroneamente per scontato che il fornitore del servizio fosse responsabile delle attività per la sicurezza dei dati e le applicasse: quindi è molto meglio che le responsabilità siano messe in chiaro fin da subito. Inoltre l’ambiente dei Cloud Provider è implicitamente multi-tenant (almeno a livello di condivisione rete e di HW ed escludendo il caso di Private Cloud): questo può portare a conflitti in termini di compliance. Ad esempio: se io ho necessità di seguire una compliance (p.e.: PCI) e un altro customer no... come la si gestisce in un ambiente in cui diversi clienti condividono la stessa rete?

Contromisure

Chiarire a livello contrattuale le policy per la sicurezza e le relative responsabilità.

 

Nome rischio

Vulnerabilità dei Cloud Storage

Descrizione

I Cloud Storage sono vulnerabili agli attacchi tradizionali (SQL-Injection) o, in caso di API REST o SOAP, alla relativa versione XML (XML-Injection nelle varie declinazioni). Sono ovviamente possibili anche attacchi di tipo XSS.

Più specifici degli storage su Cloud, sono gli attacchi di tipo "Enumeration", che danno la possibilità di elencare i contenuti pubblici pubblicati su storage (p.e.: sui bucket di Amazon S3). Questo può accadere perche’ si vuole mettere a disposizione contenuti sperando che la non conoscenza degli URL sia una condizione sufficiente a non fare scaricare i dati a utenti cui questi non sono diretti (security through obscurity). Un esempio di un attacco di questo tipo può essere portato tramite S3 Ripper che permette, dato un nome di un bucket, di enumerarne i contenuti e di scaricarli.

Contromisure

Contro SQL/XML-Injection:

  • Input validations.

  • Encoding dei dati (i dati devono rimanere sempre dati e non essere interpretati).

Contro attacchi di tipo Enumeration:

  • Usare tecniche tipo "Signed URL" per distribuire contenuti.

Applicazioni host-proof

Riassumendo, il problema più grosso per e applicazioni su cloud rimane la perdita del controllo "fisico" dei dati. Questo problema, come visto, si può affrontare utilizzando la crittografia su quelli che sono considerati i dati sensibili. Questo, però, induce complicazioni nella gestione delle chiavi (messa in sicurezza dei keystore negli storage, nel transito e nei backup, gestione dell’accesso ai keystore, backup delle chiavi, etc...).

In alcuni casi, su piattaforma di tipo IaaS, si potrebbe pensare di deployare applicazioni che considerano il server come "untrusted", almeno parzialmente. Secondo questa filosofia, tutto quello che è manipolazione dei dati "sensibili" potrebbe essere effettuata lato browser.

Esiste a questo scopo un pattern architetturale chiamato Host-proof Applications (qualche volta anche indicato come Zero-knowledge Applications") che si basa su questi principi:

  • I dati sensibili vengono criptati (tramite librerie Javascript) sul Browser, utilizzano una passphrase conosciuta solo dall’utente.
  • I dati criptati vengono mandati al server che li memorizza. In questo caso, il server non deve gestire chiavi, dato che non è in grado di decriptare i dati inviati dal client (...e questo può essere un problema...).
  • Quando necessario, il client richiede i dati al server che glieli invia. Il Browser decripta i dati utilizzando la passphrase e poi è in grado di utilizzarli.








Figura 5 - Il server non è in grado di decriptare i dati inviati dal browser.

 

 

Quali sono gli svantaggi di questo tipo di approccio? Innanzitutto, è sensato pensare che solo alcune tipologie di applicazioni (o parti di applicazioni) possano basarsi su un’architettura di questo tipo. Inoltre è chiaro che tutta la logica di manipolazione dei dati deve essere applicata lato JavaScript sui Browser (oppure anche sul server, considerando la comunicazione protetta e imponendo come regola che comunque i dati manipolati non possono essere salvati su storage in alcun modo).

A oggi, esistono esempi di applicazioni di questo tipo perfettamente funzionanti (ad esempio alcuni online password manager come Clipperz [9]), anche se si tratta di un pattern ancora relativamente poco utilizzato.

Conclusioni

Andare sulle nuvole mette alla prova la consapevolezza e il controllo che si ha della sicurezza, sotto tutti gli aspetti. Rappresenta, infatti, l’estremizzazione della "perdita" del controllo fisico. Questo porta a considerare seriamente la sicurezza come un problema di primo piano e non un "fastidio" da ignorare il più possibile, come accade troppo spesso nelle architetture tradizionali. C’è però un effetto positivo: questo processo, se ben condotto, porta inevitabilmente a un sistema più forte dal punto di vista della sicurezza. Non c’è d’avere paura: basta agire, conformemente con le best practices di sicurezza, in termini di analisi dei rischi e di conseguenti contromisure da adottare. Come al solito, insomma; ma con un po’ di attenzione in più.

 

Riferimenti

[1] enisa, Cloud Computing Security Risk Assessment

 

[2] Pierluigi Perri, "Sicurezza, privacy e Cloud Computing: aspetti legali"

 

[3] CSA, Security Guidance for Critical Areas of Focus in Cloud Computing V2.1

 

[4] CSA, Top Threats to Cloud Computing, v1.0

 

[5] Katherine Sainty, Partner & Andrew Ailwood, "Managing Compliance in the Global Space -Transborder data flow"

 

[6] Kostya Kortchinsky, "Cloudburst. A VMware Guest to Host Escape Story"

 

[7] Grant Bugher, "Secure Use of Cloud Storage"

 

[8] NIST on Cloud Computing

 

[9] Clipperz - online password manager

 

Invia un messaggio alla redazione su questo articolo

Mittente (facoltativo - immetti una email valida se desideri ricevere una risposta)

Come hai trovato questo articolo?

 

Mi sono addormentato

Interessante con il giusto taglio

Argomento non interessante

Molto interessante

Argomento interessante, ma non approfondito

Efficace, ha risolto i miei problemi

Interessante

Mi sono commosso

 

Lascia un commento su questo articolo