Questo secondo articolo è tratto dalla mia seconda presentazione tenuta in occasione dell’ICT Trade di ferrara.
Il focus è dedicato alle problematiche inerenti il “cloud”.
Uno dei termini che va per la maggiore al giorno d’oggi è il termine “cloud”.
Cosa in realtà significhi questo termine e cosa ci sia dietro, però, eè spesso oggetto di confusione e fraintendimento, che differenza c’è fra “cloud”, “internet” e “remoto”? cosa sono davvero i servizi cloud? e cosa significa “cloud” in termini di sicurezza?
Le Basi del Cloud
Innanzi tutto occorre capire cosa significhi cloud. In funzione dei vari messaggi MKTG cui siamo bombardati in prima istanza un servizio basato sul “cloud” (mi si conceda di non usare l’equivalente italiano “nuvola” che mi suona ridicolo almeno quanto chiamare un mouse “topo”) è un servizio che si trova in una località non meglio precisata su internet e cui l’utente accede remotamente grazie alla propria connessione alla grande rete.
questa definizione, valida ai fini di una comunicazione rivolta alla grande massa degli utenti, non è però valida per capire cosa sia il cloud in realtà, ne ci da indicazioni di quali siano le differenze tra un servizio “cloud” ed uno remoto generico, se non il fatto che vi si accede attraverso una rete pubblica o una rete virtuale provata (VPN).
Un primo chiarimento su cosa significhi in realtà cloud lo si può ottenere andando a vedere presentazioni dei diversi servizi cloud.
Pur non dandoci ancora indicazione precise su cosa significhi “cloud” da un punto di vista implementativo, la classica definizione di “cloud” come erogatore di un “Qualcosa” “come un servizio” XaaS, “X” as a service arricchisce il concetto di “cloud” come qualcosa decisamente più complesso, dandoci anche indirettamente le prime indicazioni delle inerenze del cloud in termini di sicurezza.
Definizioni tipiche dei servizi cloud come “Platform as a Service“, “Software as a Service” già ci dovrebbero far capire che il livello di complessità legato al cloud è non indifferente, non tanto nei termini di uso da parte dell’utente\cliente ma in termini implementativi e di design da parte di chi si occupa di sicurezza e da parte di chi eroga il servizio.
Le problematiche di sicurezza del cloud infatti possono essere legate alle esigenze specifiche degli utenti ma anche a quelle dei provider che erogano tali servizi. Nel mare magnum dei termini legati al cloud molti sono di difficile comprensione proprio perchè non si ha una esatta idea di cosa si stia parlando.
Occorre quindi fare un passo indietro e capire cosa ci sia dietro il termine “cloud”
Dentro il cloud
Invece di partire dalla definizione ufficiale (ne esistono, tanto per cambiare, decine) partiamo dalla prima impressione di qualcosa erogato in una località non meglio precisata ed apriamo queste “nuvole” di servizi per vedere cosa siano in realtà…
Squarciando il velo delle nuvole quello cui ci ritroveremmo a vedere è: un insieme di dacenter.
La prima osservazione che occorre fare è che stiamo parlando di più di un datacenter, questo perchè nel concetto di “cloud” è insito il fatto che vi siano più punti di erogazione del servizio geograficamente dislocati in modo tale da poter offrire la stessa qualità di servizio agli utenti abilitati “ovunque” essi siano.
Un singolo server, un singolo datacenter non sono cloud anche se si appoggiano su “internet” per l’erogazione dei servizi. l’entità geografica dei servizi “cloud” è un tratto distintivo specifico. Ovviamente questa distinzione non sempre viene evidenziata a dovere e quindi diventa difficile distinguere tra un generico servizio di hosting, ad esempio, da un vero servizio “PaaS” (Platform as a Service).
La discriminante geografica è di sicuro un elemento distintivo necessario, ancorchè non sufficiente.
essendo questi datacenter legati tra loro ma distinti e distanti in termini di locazione geografica, appare evidente che questi ultimi devono essere in qualche modo interconnessi.
Questo punto non è di secondaria importanza ed ha impatti specifici abbastanza pesanti come ha dimostrato anche la storia recente, basti pensare che l’encryption dei canali di comunicazione tra datacenter è una novità di questi ultimi anni, a seguito dello scandalo NSA-Snowden. Persino i server di Google prima dello scoppio di questa questione si limitava ad inviare i messaggi in chiaro tra i suoi vari datacenter.
Le problematiche di sicurezza Cloud quindi hanno aspetti inaspettati a chi non ha una idea di cosa sia effettivamente un servizio cloud.
I nodi della questione
Per rendere comprensibile un argomento altrimenti abbastanza complesso, potremmo iniziare a considerare i servizi cloud come dei servizi erogati da più nodi separati geograficamente che utilizzano, per consentire l’accesso agli utenti, internet in veste di cloud pubblico e tecnologie internet ma in gestione privata quando parliamo di private cloud.
Per rendere ancora più esplicito il messaggio questi nodi sono datacenter in qualche maniera tra loro connessi che offrono servizi tramite protocollo tcp\ip e altri protocolli “standard” o non propietari.
Nel caso gli IP di erogazione del servizio non siano accessibili via rete pubblica possiamo parlare a ragion veduta di cloud privato. si noti che invece autenticazione o uso di canali criptati non definisce di per se un cloud privato, infatti qualsiasi erogatore di servizi cloud può richiedere autenticazione ed encryption (ssl\ipsec\tls) per accedere ai servizi erogati.
Questi nodi “datacenter” sono in linea di massima descrivibili in termini di:
- infrastruttura
- potenza di calcolo
- capacità di storage
- comunicazione
ognuna di queste aree ha ricadute in termini di sicurezza specifiche sia per quello che concerne le esigenze del provider erogante che di quelle dell’utilizzatore.
Infrastruttura:
un aspetto della sicurezza poco curato, almeno nel nostro paese, è quello infrastrutturale. Sotto questa definizione si può mettere un sacco di roba, in realtà, tutto quello, ad esempio, che afferisce alla infrastruttura fisica: dai calcoli di carico statico dei rack al power consumption e il raffreddamento sia intermini di temperatura che di volumi di aria mossi.
Non è banale pensare che un datacenter debba essere accuratamente pianificato anche da questo punto di vista, altrimenti perfomance e potenza di calcolo potrebbero essere seriamente compromesse, ad esempio da un eccessivo calore o da serie limitazioni all assorbimento energetico in aree critiche del datacenter stesso.
Altro aspetto critico è l’accesso e la sorveglianza fisica del datacenter. In una struttura cloud vengono tenuti gestiti ed elaborati dati provenienti da diversi utenti con diverse esigenze in termini di sicurezza, controllo e compliance. L’accesso alle strutture potrebbe essere un requirement necessario in alcune aree geografiche, ma contemporaneamente un problema per alcuni utenti. immaginate una server farm che ospiti un servizio “X” scherato tra diversi clienti, immaginate che si conceda l’accesso a uno di questi che inavvertitamente o con dolo senziente danneggi l’operatività funzionale di un altro…
Sebbene la politica più comune e pratica sia quella di non concedere accessi a terzi se non al personale del provider, anche questo è, in realtà, un blocco più formale che sostanziale: vendor, consulenti, contractor hanno spesso accesso a queste aree.
CPU:
Superato lo scoglio infrastrutturale, che impatta principalmente il provider di servizi (ed il propietario del datacenter fisico, qualora non coincidano), ci troviamo alle classiche problematiche di condivisione della potenza di calcolo.
Qui le problematiche sono tra le più disparate in quanto si va dallo sharing di risorse a risorse più o meno dedicate, SLA e capacità distributiva del carico di lavoro in termini geografici.
per fortuna le tecnologie di virtualizzazione e grid computing hanno fatto passi da gigante e le modalità commerciali di offering oggi offrono uno spread di modalità abbastanza esaustivo. rimane la problematica di calcolare quali siano gli effettivi bisogni e di come blindarli in SLA opportuni a costo del rischio di rendere vano il nostro investimento nel cloud.
Storage:
Lo storage è in questo senso, molto più complesso. non si tratta solo di distribuire una risorsa fisica che deve essere allocata opportunamente, ma anche di garantire che i dati siano protetti. NSA insegna accedere ai dati non è impossibile, e in alcuni casi persino il service provider più integerrimo può essere obbligato a dare accesso ai dati su “disco” anche in maniera distruttiva, si pensi alla vicenda legata a megaupload ad esempio.
Le problematiche legate alla tipologia di dati salvati nel cloud sono quindi particolarmente complesse e hanno a che fare sia con il tipo di dato che la sua locazione geografica. tecnologie di encryption multilayer sono di solito indispensabili, dove per multilayer si intende che da un lato il provider deve, o dovrebbe, fornire un minimo livello di data encryption, ma poi l’utente dovrebbe provvedere con un secondo layer indipendente dal provider che lo metta al sicuro da eventuali intrusioni.
Connectivity:
per quanto banale possa sembrare, la connettività è da sempre un problema, e nei servizi cloud questo problema è particolarmente evidente.
Da un lato ci sono le prestazioni e la raggiungibilità, un servizio cloud deve essere raggiungibile dai suoi utilizzatori, per banale che sia questa è una osservazione importante.
La raggiungibilità è un punto focale anche se si introducono tecnologie di sicurezza quali ipsec o vpn\ssl, per questo di solito queste tecnologie sono utilizzate in ambienti cloud private, mentre per quello che concerne l’accesso dell’utilizzatore si punta generalmente a fornire accessi https con buona pace del bug heartbleed.
Alcuni servizi solitamente trascurati, come il DNS, sono fondamentali tanto che molti provider di servizi cloud, si pensi a Google ad esempio, hanno deciso di intervenire sulla questione offrendoli direttamente al pubblico con l’aggiunta del layer di security DNSsec che ancora stenta ad essere adottato in ambito italiano.
Della connettività si devono preoccupare tanto i clienti, che devono valutare con attenzione gli standard di accesso promossi dal provider cloud, che il cloud provider stesso anche per le comunicazioni inter-datacenter.
in particolare il provider di servizi cloud deve porre attenzione alle dorsali di connettività ed assicurarsi, a meno che non sia esso stesso un propietario di tutta la catena fisica di comunicazione, che le comunicazioni tra i suoi vari nodi rimangano protette anche in presenza di salti carrier su carrier.
Storicamente questo è infatti uno dei punti di attacco comune da parte di hacker e forze dell’ordine, agire sul carrier da accesso immediato al flusso di dati e quindi consente un monitoraggio “facile” e trasparente. NSA ancora docet in questo senso, ma pensiamo anche all’affaire telecom di qualche anno fa in italia.
Cryptare le comunicazioni diventa quindi un “obbligo” anche se i grandi content provider ci sono arrivati solo negli ultimi due anni…
Problematica duale è quella per l’utilizzatore del servizio cloud, anche questo infatti dovendo accedere al cloud attraverso un internet service provider dovrà preoccuparsi che le modalità di autenticazione e trasmissione dati offerte siano tali da consentire un adeguato livello di sicurezza.
Strong authentication, token, e diversi encryption level sono sicuramente auspicabili da parte di chi si vuole servire di tali servizi o vuole implementarli privatamente.
Services:
in termini di servizi le problematiche variano, ovviamente, da servizio a servizio ma vi sono due aspetti che sono aprticolarmente critici sopratutto per gli utilizzatori:
Lock in e Lock out
di cosa si tratta? ben nel primo caso abbiamo una situazione in cui la migrazione dei propri dati dal provider attuale ad uno nuovo è cosi onerosa che, nei fatti, siamo bloccati e costretti a rimanere “fedeli” al nostro provider.
La questione diventa particolarmente significativa se i dati processati dal servizio sono sensibili, i costi di migrazione potrebbero diventare proibitivi ed annullare tutti gli eventuali “savings”.
In realtàquella di lock in non è una problematica solo dei servizi cloud, ma genericamente afferibile a qualsiasi tipo di servizio: più la tecnologia utilizzata è di tipo “legacy” e non standard (o meglio open standard) più si corre il rischio di incappare in problematiche di lock-in.
Duale al lock-in è il lock-out, dove invece non si riesce ad accedere ai propri dati nonostante se ne abbia il diritto. per quanto improbabile questa è una eventualità che può capitare, ed è più legata a problemi di ordine legale che di tipo tecnologico, ne siano esempio leggi sulla privacy che impediscono al provider di servizi di fornire le chiavi di accesso di uno specifico utente anche se questi non lavora più in azienda, o dati bloccati per indagini in corso anche se il cliente non è direttamente coinvolto, si pensi ancora alla vicenda megaupload, dove la chiusura forzata del servizio aveva impattato anche chi stava usando quella piattaforma per un servizio SaaS (Storage as a Service) assolutamente legale.
Per quello che concerne la parte di autenticazione e gestione degli utenti, per fortuna, sono stati introdotti standard di supporto quali SAML che consentono di demandare all’utente la gestione degli accesso al servizio cloud togliendoli almeno parzialmente dal diretto controllo del provider.
Ma alla fine perchè dovrei usare il coud in una delle sue declinazioni?
nonostante questi aspetti da valutare il cloud rimane un grande opportunità per lo sviluppo dei servizi di business, suia da parte degli utilizzatori che possono effettuare dei notevoli savings in termini di risorse e competenze impegnate, che dal punto di vista dei provider che hanno la possibilità di espandere una area di business ancora relativamente immatura.
Dal lato savings la immagine sopra ci può avvicinare a capire quali siano dal punto di vista di un utilizzatore.
maggiore è lo spostamento verso servizi software as a service maggiore è il saving infrastrutturale ottenuto dal cliente.
Considerando che già ad oggi l’offering Cloud è di tutto rispetto e copre dalla infrastruttura ai servizi di sicurezza con tutto quello che passa in mezzo.
e se non ci credete pensate semplicemente ai servizi di storage as a service che già utilizzate e che magari non avete pensato fossero un “X” as a service.
