A Brave Chi detiene la sicurezza in-the-cloud?

Transcript

A Brave Chi detiene la sicurezza in-the-cloud?
A Brave
Chi detiene la sicurezza
in-the-cloud?
Un punto di vista
di Trend Micro
Febbraio 2011
Dave Asprey,
VP Cloud Security
CHI DETIENE LA SICUREZZA IN-THE-CLOUD?
I.
CHI DETIENE LA SICUREZZA IN-THE-CLOUD?
Il cloud computing è la parola più in voga del momento nell’ambito tecnologico. La fornitura
di servizi software e infrastrutture IT su richiesta tramite Internet può offrire ai team IT
vantaggi ineguagliabili per quanto riguarda efficienza, risparmi di costi e scalabilità. Tuttavia,
questi vantaggi rivoluzionari sono accompagnati da un insieme di nuove sfide che diminuiscono la validità di molti approcci tradizionali alla sicurezza. Il paradosso al centro di
questo nuovo paradigma informatico consiste nel fatto che il cloud computing da un lato
offre la possibilità di un IT semplificato, con tariffe al consumo, in cui le attività più pesanti
vengono demandate all’outsourcing, ma introduce anche numerose problematiche relative
alla conformità e aree potenziali di rischio per la protezione dei dati.
DI loro iniziativa o perché sono costretti a farlo da ragioni aziendali, i responsabili IT stanno
rivalutando le loro opzioni alla luce del nuovo ambiente informatico del 21° secolo. Vogliono
conoscere i rischi connessi e soprattutto a quale livello si debbano collocare responsabilità
e contabilità relative alla sicurezza.
In questo documento intendiamo affrontare tali problematiche nel contesto di IaaS
(Infrastructure as a Service), cioè dell’ambito che consente ai responsabili IT di affittare reti,
spazio di archiviazione, server e altri elementi operativi. Inoltre, IaaS offre alle imprese una
maggiore autonomia nell’implementazione di un maggior numero di controlli rispetto a modelli
come SaaS.
II.
PERCHÉ IN-THE-CLOUD?
Dal punto di vista del metodo del cloud pubblico, ciò che soprattutto conta è la scalabilità
e la capacità di utilizzare le spese di esercizio anziché le spese in conto capitale. I clienti
che adottano cloud computing evitano spese per capitale per hardware, software e altri
servizi infrastrutturali, pagando ai loro vendor solo ciò che utilizzano, secondo un modello di
fornitura di servizio. La fornitura su richiesta di risorse consente inoltre alle aziende una
scalabilità dinamica, regolata secondo le esigenze informatiche in tempo reale, migliorando
notevolmente l’agilità aziendale.
Dal punto di vista privato, il cloud computing verte soprattutto su un aumento di flessibilità
e reattività rispetto alle esigenze dei consumatori interni.
Con questo genere di vantaggi, non è certo sorprendente che vi sia un grande interesse nei
confronti di questo nuovo paradigma informatico. Una ricerca Cisco di dicembre, ad esempio,
ha rilevato che il 52% dei professionisti IT a livello globale utilizza o intende utilizzare il cloud
computing entro i prossimi tre anni. Da un sondaggio analogo relativo alla sicurezza dei dati
effettuato da ISACA (marzo 2010) è emerso che un terzo delle organizzazioni europee ha già
adottato sistemi di cloud computing, mentre Accenture, in un’inchiesta a livello globale (luglio
2010), ha riscontrato che la metà dei suoi clienti esegue in-the-cloud varie applicazioni
mission critical.
1 | Punto di vista Trend Micro™ | Chi detiene la sicurezza in-the-cloud?
CHI DETIENE LA SICUREZZA IN-THE-CLOUD?
III.
LA PROTEZIONE DEL PERIMETRO NON È MORTA: DUE APPROCCI
PER LA PROTEZIONE IN-THE-CLOUD
Si è detto molto a proposito del fatto che, con il modello del cloud pubblico, la tradizionale
protezione del perimetro aziendale semplicemente cessa di esistere. Firewall, sistemi di
prevenzione delle intrusioni e altre funzionalità standard di protezione, secondo tale visione,
non possono estendersi in-the-cloud e le aziende devono invece affidarsi al livello di base
di protezione del perimetro offerta dal vendor del servizio in-the-cloud.
Tuttavia, da un’altra prospettiva, l’operatività del modello della protezione del perimetro non
cessa assolutamente, bensì diviene un utile elemento di un’architettura attiva della protezione, ma non l’unico elemento. Nell’adottare il modello in-the-cloud, le aziende mantengono la nozione di perimetro. La scelta per le aziende è se estendere il perimetro
all’ambiente in-the-cloud, estendere il modello in-the-cloud all’interno del perimetro oppure
adottare entrambe le soluzioni. In ogni caso, sono necessari livelli ulteriori di protezione,
così come avviene negli ambienti interni di protezione aziendale. Tuttavia, entrambi gli
scenari hanno alcuni svantaggi relativamente alla potenziale carenza di visibilità e controllo
che derivano dall’utilizzo dei servizi forniti in-the-cloud. I CISO (Chief Information Security
Officer, responsabile della sicurezza informativa) devono essere attenti, operare con la
dovuta cura ed essere coscienti dei rischi conseguenti.
1) Il primo scenario, cioè l’estensione del perimetro del cloud, comporta l’impostazione di
un tunnel VPN IPSec verso i server dei provider del cloud pubblico e l’implementazione di
protezione di livello aziendale sui server del cloud pubblico, di solito mediante software di
protezione e dispositivi virtuali.
Il vantaggio di questo approccio è che non è necessario riconfigurare l’Active Directory
e molti altri strumenti di gestione preesistenti dovrebbero poter funzionare anche
in-the-cloud, dal momento che i server in-the-cloud si trovano in effetti all’interno del
“perimetro” aziendale.
Tuttavia, per quanto concerne gli svantaggi, si deve dire che, a seconda dell’efficacia nella
protezione dei server in-the-cloud, si potrebbero introdurre nella propria architettura i rischi
associati al cloud computing (illustrati di seguito). Per favorire la riduzione del rischio,
è importante che il collegamento fra ambiente in-the-cloud e server interni venga controllato
alla ricerca di traffico sospetto, come del resto deve avvenire per tutti i server più importanti,
a prescindere dalla loro collocazione in ambiente in-the-cloud. Un’altra opzione è l’aggiunta
di un’ulteriore DMZ e di un firewall, benché ciò comporti la creazione di un altro perimetro
da proteggere.
Molte aziende dimenticano o ignorano questo passaggio nella fretta di adottare il modello
in-the-cloud, specialmente quelle di dimensioni più piccole che non dispongono del tempo
e delle risorse IT per gestire l’architettura di tali barriere di protezione.
È inoltre essenziale attivare un livello di protezione sufficiente a livello dei server
in-the-cloud in modo da poterli utilizzare con fiducia (firewall bidirezionali IDS/IPS ecc.).
2 | Punto di vista Trend Micro™ | Chi detiene la sicurezza in-the-cloud?
CHI DETIENE LA SICUREZZA IN-THE-CLOUD?
RISCHI
I CIO devono essere coscienti dal fatto che i server in-the-cloud saranno soggetti a minacce
diverse da quelle che sono abituati ad affrontare internamente all’azienda.

Uno dei principali motivi di preoccupazione è che i vendor in-the-cloud ben difficilmente
forniranno all’azienda i registri di accesso, fisico o amministrativo. In che modo l’azienda
potrà sapere se un amministratore IT che lavora per il vendor del cloud pubblico ha
effettuato un accesso ai dati aziendali? La minaccia interna può essere mitigata in una
certa misura mediante la gestione dei registri di accesso, ma questa carenza di visibilità
a livello in-the-cloud dovrebbe comportare un’adozione diffusa dalla crittografia dei dati
come metodo standard.
(A dicembre è emerso un accesso ai dati aziendali di proprietà di aziende clienti della
suite di applicazioni BPOS in hosting di Microsoft; i dati sono poi stati scaricati da altri
utenti del software a causa di un errore di configurazione. Benché il problema sia stato
prontamente risolto, pone in risalto le possibilità di errore e l’importanza di disporre di una
visibilità a livello dei sistemi dei vendor in-the-cloud per garantire che rispettino sia i loro
standard regolamentari sia quelli aziendali).

Gli archivi condivisi presentano un’ulteriore area a rischio per quelle aziende preoccupate
della protezione dei loro dati, qualora vengano archiviati nel medesimo disco in-the-cloud
utilizzato da un’azienda concorrente.

Alcuni vendor del cloud pubblico non affrontano le tematiche della sicurezza con la giusta
attenzione, o non si comportano in modo trasparente circa le loro attività, come invece
dovrebbero fare. Innanzitutto, se si intende collocare dati mission-critical in-the-cloud,
è necessario verificare almeno il rigoroso rispetto delle best practice per la sicurezza,
come le normative ISO 27001 e SAS70 II, ed esaminare con la massima attenzione il
livello dei servizi (SLA) e le politiche di sicurezza del vendor.

In collegamento al punto precedente, molti vendor in-the-cloud, nel caso di violazione dei
dati, prevedono un rimborso del solo costo del servizio fornito, anche quando il problema
è stato causato da una loro negligenza. Una violazione dei dati che può causare un
danno incalcolabile alla reputazione, multe e perdite economiche potenzialmente
nell’ordine di milioni, ad esempio, ricadrà sulle spalle del cliente.
2) Il secondo scenario, cioè l’estensione del cloud nell’azienda, consente di estendere
efficacemente tale ambito all’interno del perimetro e comporta l’installazione in sede di un
nodo cloud da parte di un vendor di cloud pubblico IaaS o MSSP.
Il vantaggio di questa soluzione, che si sta diffondendo sempre di più nelle imprese di
grandi dimensioni, è che si tratta di un modello relativamente ben conosciuto. Akamai, ad
esempio, segue questa strada da più di dieci anni, gestendo un server collocato all’interno
del perimetro di protezione del cliente, mentre MSSP come Integralis forniscono da anni
servizi di gestione remota dei firewall “from the cloud”. Altri esempi sono Trend Micro Smart
3 | Punto di vista Trend Micro™ | Chi detiene la sicurezza in-the-cloud?
CHI DETIENE LA SICUREZZA IN-THE-CLOUD?
Protection Network, che collega i server di protezione all’interno della rete aziendale a una
rete di protezione costituita da migliaia di server in-the-cloud.
Tuttavia, nonostante la relativa semplicità con cui si può avere uno di questi elementi nel
proprio datacenter o in un sede aziendale secondaria, gestito e aggiornato a livello centralizzato da parte del vendor in-the-cloud, i principali svantaggi sono rappresentati dal fatto
che, essenzialmente, si tratta sempre di un servizio in-the-cloud e come tale presenta ai
responsabili IT molti dei rischi tipici della prima soluzione.

Permangono i rischi connessi alla mancanza di visibilità dei registri di accesso fisici e/o
amministrativi.

La responsabilità per eventuali negligenze che provochino la perdita di dati aziendali
mission-critical non andrà oltre il rimborso del costo del servizio.

Il servizio può essere attivato o disattivato, ma quando è attivato, il vendor avrà accesso
ai dati di rete e applicativi, per cui è necessario che sia affidabile. Se il vendor è molto
attento alle tematiche della sicurezza e si comporta i modo trasparente per quanto
concerne il livello del servizio (SLA), non dovrebbero esserci motivi di preoccupazione.
Tuttavia, come si è visto, molti vendor generalisti in-the-cloud non tengono nel debito
conto le tematiche della sicurezza nell’ambito della loro value proposition..
Si tratta di prestare attenzione alla differenza fra un protezione “abbastanza buona” e una
protezione “ottimale”. Un servizio e-mail basato su cloud attivato all’interno del perimetro
aziendale da un fornitore di servizi che preveda la gestione della protezione, ad esempio,
probabilmente sarà più affidabile rispetto allo stesso servizio offerto da un vendor
pubblico in-the-cloud.
IV.
MA ALLORA CHI DETIENE LA SICUREZZA IN-THE-CLOUD E DOVE SI
TROVANO LE LACUNE?
La verità spiacevole è che se si pensa di poter chiedere aiuto al vendor in-the-cloud probabilmente si resterà delusi; anzi, i propri compiti potrebbero essere resi ancora più difficili
dalla carenza di visibilità nell’accesso ai registri o dalla sconcertante nebulosità sui criteri
di protezione.

È necessario proteggere i propri server in-the-cloud così come si proteggono i server
interni. Ciò comprende l’adozione di IDS/IPS, strumenti DLP, firewall bidirezionali
e crittografia.

Possono presentarsi problemi per la protezione della rete in ambiente in-the-cloud, dal
momento che ben pochi vendor di cloud pubblico saranno disposti a consentire di
controllare il traffico di rete con la precisione desiderata. Nella rete aziendale, la configurazione e i registri di tutti i router/switch sono disponibili, perciò è possibile controllare
qualsiasi traffico di rete. Al contrario, in-the-cloud questi dati non sono disponibili. Questo
fattore potrebbe causare l’impossibilità da parte del metodo in-the-cloud di conformarsi
alle regole, dunque è essenziale sapere qual è il livello di controllo e accesso di rete
consentito dal vendor.
4 | Punto di vista Trend Micro™ | Chi detiene la sicurezza in-the-cloud?
CHI DETIENE LA SICUREZZA IN-THE-CLOUD?

La crittografia dei dati a riposo e in transito assume una grande importanza, a causa
della carenza di visibilità del traffico di rete e dei registri di accesso amministrativo del
vendor.

Molti vendor in-the-cloud evidenziano inoltre una preoccupante carenza di controlli
sull’accesso basati sui ruoli a livello amministrativo. Ad esempio, con Amazon EC2 un
account è proprietario del servizio, per cui un membro dell’organizzazione con accesso
all’account può effettivamente disporre di un potere assoluto, con la possibilità di
aggiungere ed eliminare servizi a piacimento.

Negli ambienti in-the-cloud privati, la gestione della sicurezza da parte del settore IT
viene messa in discussione dalla velocità con cui vengono creati i server. L’equilibrio
naturale fra la capacità del settore IT di implementare i server e le esigenze aziendali di
utilizzarli vacilla a causa dell’accelerazione del processo stesso. Ciò che interessa alle
aziende, oggi, è di sapere se riusciranno a coprire i costi di una licenza, inoltre in un
ambiente in-the-cloud privato un dipartimento aziendale può disporre di un server
funzionante in 1/2 giorni, non più in 6 settimane.
Tuttavia, ogni richiesta per un nuovo server dev’essere gestita in modo appropriato, poiché
i rischi per la sicurezza aumentano all’aumentare del numero di unità da gestire. È importante
che i responsabili IT mettano a punto un processo centralizzato di autorizzazione che assicuri
che ogni richiesta aziendale passi innanzitutto tramite il settore IT.
V.
APPROFONDIMENTI
Aziende
Si devono crittografare i dati a riposo e in movimento e fare attenzione ad archiviare le
chiavi di crittografia in una posizione separata dai dati, ossia in un punto in cui non siano
facilmente accessibili al vendor in-the-cloud.
Vanno utilizzati tutti gli strumenti di protezione che si adottano per i server fisici anche per
i server in-the-cloud, dal momento che i vendor in-the-cloud vi forniranno un OS privo di
funzioni adeguate per la protezione dei dati.
Vendor in-the-cloud
In qualità di vendor in-the-cloud, occorre adottare una maggiore trasparenza nei criteri
e nelle procedure di protezione, nell’ambito dei controlli dell’accesso e del traffico di rete.
I clienti hanno la necessità di sapere chi fa che cosa, e devono poter accedere ai registri.
Occorre chiarire al meglio il livello del servizio (SLA), in modo che i clienti possano sapere
quali sono le funzioni di protezione offerte e di cosa hanno bisogno per assicurare la protezione dei loro dati secondo i loro e i propri standard di regolamentazione.
5 | Punto di vista Trend Micro™ | Chi detiene la sicurezza in-the-cloud?
CHI DETIENE LA SICUREZZA IN-THE-CLOUD?
Ambienti in-the-cloud privati
È necessario creare un processo centralizzato di autorizzazione per tutti i nuovi server inthe-cloud richiesti dall’azienda, qualora non ne esista già uno. Per ogni richiesta, si dovrà
sapere quali sono le esigenze alla base della richiesta, che cosa andrà in esecuzione sul
server e la quantità di traffico previsto; inoltre si dovranno effettuare controlli periodici su
questi elementi.
Bisogna essere pronti al fatto che il settore IT verrà spinto ad accelerare la propria velocità
operativa. Per il bene dell’azienda, occorre essere pronti a supportare tali esigenze in modo
puntuale, senza compromettere la sicurezza.
6 | Punto di vista Trend Micro™ | Chi detiene la sicurezza in-the-cloud?