Concentrare nel cloud le risorse di elaborazione e i dati di un’organizzazione significa creare un target molto interessante agli occhi di potenziali hacker. Ricordiamo che le difese di sicurezza specifiche per il cloud possano essere considerate robuste, scalabili ed economiche se implementate correttamente, tuttavia la sicurezza rimane una delle preoccupazioni maggiori per le organizzazioni che valutano i servizi basati su cloud.
La scelta di un modello di fornitura e deployment di servizi cloud influirà direttamente sulla funzionalità delle organizzazioni. La pianificazione per i servizi IT basati su cloud pone tutta una serie di sfide che sarà necessario affrontare e risolvere se si vogliono ottenere i vantaggi prospettati dall’architettura riducendo i costi e, al tempo stesso, i rischi.
Sicurezza del modello di fornitura
Il modello architetturale più comune utilizzato per organizzare i servizi che un provider di servizi cloud (CSP, Cloud Service Provider) è in grado di fornire alle organizzazioni (alias, al consumatore di servizi cloud) è il modello SPI. L’acronimo SPI si riferisce alla fornitura di servizi software, di piattaforma e di infrastruttura nel cloud; queste offerte di servizi cloud vengono comunemente chiamate SaaS (Software-as-a-Service), PaaS (Platform-as-a-Service) e IaaS (Infrastructure-as-a-Service).
Il modello SPI è un modello “a stack”, dove IaaS risiede nella parte inferiore dello stack, SaaS nella parte superiore e PaaS nel mezzo. Più si sale nello stack SPI, più responsabilità e controllo vengono detenuti dal provider di servizi cloud e meno responsabilità, controllo e flessibilità vengono detenuti dal consumatore del servizio. Questa stessa regola vale anche per la sicurezza.
SaaS. Con il modello SaaS le organizzazioni acquistano applicazioni o software cloud-based da un provider di servizi cloud. Anziché acquistare applicazioni software e installarle, configurarle e gestirle, le organizzazioni le noleggiano da un provider di servizi cloud SaaS, che si occupa anche della gestione e del controllo dell’infrastruttura cloud sottostante le applicazioni (compresi componenti come i sistemi operativi, i server, lo storage e le reti), oltre che dell’installazione e della configurazione delle applicazioni in generale.
Solitamente i consumatori SaaS svolgono solo attività di gestione dell’identità e configurazione delle applicazioni specifiche degli utenti. Di tutti i modelli di fornitura di servizi cloud, SaaS è quello che fornisce i servizi di sicurezza più integrati, inseriti direttamente nell’offerta cloud, con il minor livello di estendibilità per il consumatore. Un esempio di modello SaaS è l’utilizzo dei servizi di posta elettronica di Microsoft Exchange Server con Microsoft Office 365.
PaaS. I provider di servizi cloud PaaS offrono un ambiente di sviluppo basato su cloud che consente alle organizzazioni di realizzare e distribuire applicazioni al di sopra di una piattaforma cloud. Come nel caso del modello SaaS, il provider di servizi cloud PaaS controlla l’infrastruttura cloud sottostante la piattaforma PaaS.
Occupando la parte inferiore dello stack SPI, il modello PaaS è più estendibile rispetto a SaaS e le funzionalità di sicurezza integrate sono meno complete e i consumatori godono di una maggiore flessibilità per quanto riguarda la possibilità di includere ulteriori servizi di sicurezza. Un esempio del modello PaaS è la piattaforma Microsoft Azure.
IaaS. Quando si utilizza il modello IaaS, si noleggiano le risorse di elaborazioni fondamentali, come la potenza di elaborazione, lo spazio di storage e i segmenti di rete, e si ottiene il controllo sui sistemi operativi e sulle applicazioni che sono distribuite al di sopra delle risorse di elaborazione noleggiate. Di tutti i modelli, IaaS è quello che offre il livello di estendibilità maggiore; dal punto di vista della sicurezza questo significa che il provider di servizi cloud IaaS include solo servizi di protezione di infrastruttura di base e il consumatore dovrà poi occuparsi di proteggere i sistemi operativi, le applicazioni e i contenuti. Un esempio di modello IaaS è l’offerta EC2 (Elastic Compute Cloud) di Amazon.
Il modello SPI mostra come nel cloud la sicurezza sia solitamente una responsabilità condivisa tra il consumatore e il provider di servizi cloud, di conseguenza è fondamentale disporre di accordi sui livelli di servizio (SLA, Service Level Agreement) chiari e ben definiti tra il consumatore e il provider di servizi cloud.
In qualità di consumatore potreste anche richiedere dei controlli di sicurezza dell’ambiente del provider o qualche altro tipo di prova che dimostri che il provider ha implementato controlli di sicurezza efficaci e sufficienti.
La necessità di disporre di accordi sui livelli di servizio e controlli di sicurezza nel cloud dipende ovviamente dalla parte dell’azienda che si vuole mettere al sicuro nel cloud. Come per qualunque altro investimento nella sicurezza, è importante per prima cosa svolgere un’accurata analisi dei requisiti e un’approfondita valutazione dei rischi.
Sicurezza del modello di deployment
Indipendentemente dal modello di fornitura dei servizi cloud (SaaS, PaaS o IaaS), i servizi cloud possono essere distribuiti in un cloud pubblico (o esterno), privato (o interno) o ibrido. Questi tre modelli di deployment cloud influiscono sul modo in cui un’organizzazione gestisce ed esegue i controlli di sicurezza, ma anche sulle operazioni di sicurezza di cui l’organizzazione è responsabile in ultima analisi.
Pubblico. Un cloud pubblico fornisce servizi cloud alle organizzazioni tramite Internet. Questo modello è ospitato, fatto funzionare e gestito da un vendor di servizi cloud di terze parti che fornisce i servizi da un data center rivolto a Internet. In un cloud pubblico, la gestione della sicurezza è delegata al vendor di servizi cloud di terze parti.
Poiché i consumatori di servizi cloud non dispongono di informazioni dirette sul modo in cui il vendor implementa, fa funzionare e gestisce la sicurezza, consumatore e vendor potrebbero dover definire rigorosi accordi sui livelli di servizi, ma si tratta ovviamente di un requisito che dipende dal grado di importanza che rivestono per l’azienda le applicazioni e i dati resi disponibili nel cloud pubblico. Analogamente, i consumatori possono richiedere controlli periodici volti ad assicurare che il vendor svolga controlli di sicurezza appropriati.
I cloud pubblici offrono solitamente i propri servizi a organizzazioni diverse utilizzando un’infrastruttura IT comune o condivisa. Questo fenomeno è chiamato multi-tenancy e pone una serie di sfide di sicurezza molto interessanti per garantire che i dati dei diversi tenant (ossia delle organizzazioni) siano isolati quando vengono elaborati, trasmessi o archiviati nel cloud a infrastruttura pubblica condivisa.
Privato. Un cloud privato fornisce i servizi cloud a reti private, si tratta di un cloud che serve pertanto un’unica organizzazione. Le risorse di rete, di elaborazione e di storage sottostanti un cloud privato sono dedicate a quella organizzazione. Per organizzazioni che utilizzano spesso dati riservati, questo è un aspetto della sicurezza molto importante. Un cloud privato consente alle organizzazioni di sfruttare funzionalità del cloud, quali l’elasticità e la flessibilità, mantenendo al tempo stesso un grado di controllo e sicurezza sufficienti sui dati dell’organizzazione.
I cloud privati non escludono la possibilità di outsourcing, un cloud privato può essere gestito interamente o parzialmente da terze parti. In questo contesto, un’organizzazione potrebbe decidere di mantenere all’interno del proprio reparto IT la responsabilità del funzionamento e della gestione della sicurezza del proprio cloud privato oppure di assegnare all’esterno certe funzioni di sicurezza a un provider di terze parti.
Un cloud privato può essere ospitato internamente (in un data center di proprietà del cliente), esternamente (in un data center di terze parti) oppure parte internamente e parte esternamente. Sebbene il ricorso ad accordi sui livelli di servizio non sia una pratica particolarmente diffusa nei cloud pubblici, lo è invece nell’outsourcing di cloud privati.
Gli accordi sui livelli di servizio (SLA) offrono al consumatore di un cloud privato un maggior controllo e una maggiore visibilità sulle operazioni di sicurezza del proprio cloud privato in outsourcing, rendendo più semplice garantire la conformità a standard, criteri e regolamenti. Come per i cloud pubblici, i cloud privati possono prevedere requisiti di sicurezza multi-tenancy. In un cloud privato un’organizzazione potrebbe richiedere uno rigoroso isolamento tra i dati delle proprie unità aziendali interne.
Ibrido. Un cloud ibrido è un mix di cloud privato e di uno o più componenti di cloud pubblico, che mette insieme il meglio dei due mondi. Le organizzazioni potrebbero preferire un approccio di cloud ibrido in modo da eseguire applicazioni secondarie in un cloud pubblico, conservando invece le applicazioni chiave e i dati riservati in un cloud privato interno. Grazie alla sua flessibilità, esistono ottime possibilità che il modello a cloud ibrido diventi il modello di deployment di cloud preferito dalle organizzazioni.
Priorità nell’adozione del cloud.
Le priorità di sicurezza principali da tenere presente quando un’organizzazione valuta l’adozione del cloud computing possono essere classificate nelle seguenti aree di sicurezza: Governance, Rischio e Conformità (GRC); Gestione dell’identità e dell’accesso (IAM, Identity and Access Management); sicurezza dell’infrastruttura e protezione dei dati.
Governance, rischio e conformità. L’ambito di sicurezza probabilmente più importante ma anche più spinoso quando si parla di cloud è l’ambito GRC, che riunisce governance, rischio e conformità. L’obiettivo ultimo di questo ambito è migliorare la postura di sicurezza generale di una soluzione cloud utilizzando metodi formali per la gestione dei rischi, la valutazione dei controlli di sicurezza e il monitoraggio della conformità.
Un programma GRC si articola in varie fasi. Ha inizio con una valutazione dei rischi volta a identificare i rischi per la sicurezza che la soluzione cloud dovrà affrontare e individuare i regolamenti applicabili. Il passaggio successivo consiste nell’identificare i controlli di sicurezza in grado di affrontare i rischi identificati e assicurare la conformità normativa.
Il provider e il consumatore di servizi cloud devono quindi decidersi per un sistema di monitoraggio e reporting che controlli e informi se i controlli soddisfano in maniera efficace i requisiti di sicurezza. Infine, i risultati del monitoraggio potrebbero condurre a dei miglioramenti o delle modifiche ai controlli di sicurezza.
Sicuramente un programma GRC per il cloud non è un’attività da svolgere una volta e basta, quanto piuttosto un processo continuo sempre alla ricerca di nuove minacce e di miglioramenti alla sicurezza. Potrebbe essere difficile nel cloud allineare i processi GRC della propria organizzazione con quelli del provider di servizi cloud e assicurare la conformità normativa di cloud di infrastruttura geograficamente diversi.
Gestione dell’identità e dell’accesso (IAM). L’ambito della gestione dell’identità e dell’accesso (IAM) incorpora servizi quali il provisioning dell’identità, l’autenticazione, l’autorizzazione e il controllo. Dal punto di vista del processo IAM, la sfida principale è costituita dai diversi limiti di attendibilità. Nella maggior parte dei casi, il limite di attendibilità in una soluzione cloud va al di là del controllo del reparto IT di un’organizzazione, in quanto si estende all’interno dell’infrastruttura del provider di servizi cloud. Questo significa che l’ambito dei sistemi IAM interni va esteso all’ambiente del provider di servizi cloud. Se ciò risulta difficile, si dovrà compensare con controlli di autenticazione e autorizzazione più rigorosi nei punti di ingresso e uscita della soluzione cloud.
Per quanto riguarda l’autenticazione e l’autorizzazione basate su cloud, si dovrebbero valutare soluzioni di federazione basate sullo standard SAML (Security Assertion Markup Language). Per il provisioning cloud-based si dovrebbero considerare soluzioni che supportano lo standard SPML (Service Provisioning Markup Language).
Infine bisogna disporre di sistemi IAM interni ben funzionanti prima di valutare di associare il vostro sistema IAM al cloud. Molte organizzazioni dispongono di complessi sistemi IAM composti da diverse soluzioni di directory, gestione dell’accesso e provisioning. A meno di non semplificare l’infrastruttura IAM interna, associarla al cloud non farà altro che renderla ancora più complessa.
Sicurezza dell’infrastruttura. La sicurezza dell’infrastruttura incorpora la sicurezza nei livelli host, rete, applicazione e virtualizzazione di una soluzione cloud. Se la soluzione cloud va oltre i confini dell’organizzazione, le responsabilità in termini di sicurezza dell’infrastruttura vengono suddivise tra provider e consumatore di servizi cloud. È cruciale che i consumatori comprendano e siano d’accordo sui servizi di sicurezza di infrastruttura che il provider di servizi cloud fornirà e su quali servizi di sicurezza di infrastruttura security dovranno ancora fornire a se stessi.
Per quanto riguarda il livello di rete, è particolarmente importante proteggere la riservatezza e l’integrità dei dati mentre questi sono in transito sulle reti pubbliche. È anche necessario fare attenzione a possibili attacchi che sfruttino i punti di ingresso della soluzione cloud rivolti a Internet.
A livello di host è necessario assicurare che siano implementate le soluzioni di protezione da malware e patch di sicurezza appropriate sia a livello di punti di accesso client (ossia, laptop, desktop, PDA, terminali) sia a livello di infrastruttura server di back-end nel data center cloud. La sicurezza degli host include anche il livello di virtualizzazione, che pone una serie di nuove sfide alla sicurezza. È necessario che provider e consumatore di servizi cloud forniscano servizi di sicurezza sufficienti a tutti i livelli di virtualizzazione, compresi i sistemi operativi padre, il sistema operativo guest e l’hypervisor.
Sebbene la sicurezza delle applicazioni sia spesso tralasciata, studi dimostrano che la maggior parte delle vulnerabilità vengono rilevate a livello di applicazioni. Una priorità di sicurezza molto importante per le applicazioni cloud è assicurare che il software venga sviluppato utilizzando un ciclo di vita di sviluppo software sicuro.
Nel cloud, l’organizzazione o il provider di servizi cloud deve anche fornire protezione di sicurezza a livello di applicazione (ossia, tramite firewall applicazioni), applicazione di patch, rilevamento di vulnerabilità, registrazione e reporting, e integrazione con l’infrastruttura IAM. Se l’organizzazione dispone già di un programma di sicurezza delle applicazioni, potrebbe essere necessario aggiornarlo per far fronte agli ulteriori rischi posti dai modelli di fornitura dei servizi cloud.
Protezione dei dati. La protezione dei dati copre sia la sicurezza dei dati (riservatezza, integrità e protezione della disponibilità) che la protezione della privacy dei dati. Lo strumento principale per garantire la riservatezza e l’integrità dei dati nel cloud è la crittografia. Crittografare i dati introduce ulteriori sfide correlate alla gestione delle chiavi di sicurezza e all’elaborazione sicura di dati crittografati in un ambiente cloud multi-tenant. Per quanto riguarda la disponibilità dei dati, meccanismi di backup e ripristino funzionanti e testati regolarmente rimangono gli strumenti di sicurezza fondamentali.
Le soluzioni DLP (Data Loss Prevention) sono un tipo sempre più diffuso di soluzione di protezione dei dati per il cloud. Le organizzazioni possono utilizzare queste soluzioni per proteggere dati business-critical nel cloud e impedire perdite, distribuzione o utilizzo non autorizzato di dati. Nel cloud è utile anche prestare particolare attenzione ai dati residui, ossia quelle rappresentazioni di dati rimaste dopo la cancellazione, la rimozione o l’eliminazione di dati dai provider di storage di un provider di servizi cloud. Per assicurarsi che i propri dati non lascino tracce, si potrebbe richiedere l’utilizzo di soluzioni di pulitura di dischi e dati avanzate.
Infine, la protezione della privacy dei dati nel cloud pone sfide significative se le organizzazioni e i provider di servizi cloud devono garantire la conformità a regolamenti in fatto di privacy. Il cloud attualmente è privo di strumenti tecnici che consentano ai singoli di controllare in maniera efficace dove vengono utilizzate, salvate e trasferite le informazioni PII (Personally Identifiable Information). Molto rimane ancora da fare sul fronte privacy.
Rischi e benefici
Il cloud computing può fornire servizi IT estremamente scalabili e flessibili tramite protocolli basati su Internet. Importanti sfide di sicurezza per le organizzazioni che valutano l’adozione del cloud computing includono le modifiche ai tradizionali limiti di sicurezza e di attendibilità e la relativa perdita di controllo. Implementare controlli di sicurezza è relativamente facile se si può accedere fisicamente ad applicazioni e sistemi, ma nel cloud è necessario lasciare questa responsabilità al provider di servizi cloud.
Per far fronte a queste sfide, le organizzazioni devono estendere al cloud o associare al cloud parti fondamentali dell’attuale infrastruttura di sicurezza interna e devono affidarsi a rigorosi accordi sui livelli di servizio per quanto riguarda il livello di sicurezza che il provider di servizi cloud è chiamato a fornire.
I clienti che hanno esperienza con l’IT outsourcing potranno trarre beneficio dalla passata esperienza per definire a chi spettano le varie responsabilità di sicurezza.
Le organizzazioni dovrebbero anche essere estremamente caute quando migrano e salvano dati preziosi nel cloud; è assolutamente fondamentale controllare i controlli di sicurezza del provider di servizi cloud per essere sicuri che venga garantito il livello di sicurezza dei dati appropriato. Infine, ricordate che qualsiasi esercizio di sicurezza legato al cloud deve iniziare con una valutazione dei rischi e con la creazione di un adeguato programma GRC personalizzato per il cloud.
