Minacce e vulnerabilità del cloud computing: come proteggersi

Quasi tutte le organizzazioni pubbliche e private hanno adottato il cloud come processo principale per la transizione digitale. Spesso, ciò è avvenuto perché lo prevede una normativa, oppure per fruire di un determinato finanziamento o, peggio ancora, per inseguire una tendenza tecnologica del momento, mentre non si è tenuto conto concretamente delle peculiarità e dei rischi che ciò potrebbe comportare.

In molte realtà i fornitori di servizi ICT hanno semplicemente provveduto a spostato i sistemi informativi on-premise su servizi in cloud senza effettuare alcun assesment di sicurezza o adottare nessuna misura aggiuntiva in grado di ridurre il cyber risk, rendendo maggiormente vulnerabili le banche dati e i servizi digitali esposte sul cloud, come confermato dai recenti incidenti cyber. Cerchiamo di individuare quindi quali siano le peculiarità connesse al passaggio in cloud, i principali rischi e le best practices per tendere a un cloud sicuro.

Il passaggio al Cloud

Il passaggio dai sistemi informativi on-premise ai servizi cloud rappresenta un diverso, e talvolta scomodo, modo di lavorare. In particolare, occorre affrontare due sfide: la definizione degli accordi sul livello di servizio (SLA) e il monitoraggio delle performance di sicurezza dei cloud service provider. Cerchiamo di comprendere un approccio in grado di limitare queste criticità e, contemporaneamente, produrre SLA che riducano i rischi e aumentino la trasparenza.

Il National Institute of Standards and Technology (NIST) definisce il cloud computing come “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources.” Esistono diverse varianti di cloud computing che si differenziano tra loro fondamentalmente per il livello di controllo sulle risorse mantenuto dall’organizzazione. Pertanto, variano le competenze necessarie in base al tipo di architettura cloud, alla gestione del rischio e alla gestione del rischio di fornitura. Uno studio di Citrix ha rilevato una mancanza generalizzata di conoscenza specifiche del cloud tra i responsabili delle decisioni aziendali.

I Service Level Agreement: strumenti per la sicurezza

In questo nuovo modello, sfruttato per l’erogazione dei servizi ICT, è necessario evolvere le aspettative e le tecniche per la gestione della sicurezza delle informazioni. In tal senso, gli accordi sul livello di servizio (SLA) ricoprono un ruolo importante in questo dominio della sicurezza. Infatti, gli SLA sono divenuti oggetto di diverse ricerche sulla sicurezza del cloud perchè rappresentano lo strumento di monitoraggio più pratico e disponibile per la maggior parte degli utenti dei servizi cloud. Il NIST definisce un Service Level Agreement come “a binding agreement between the provider and customer of a cloud service” (SP 500-307), quindi un accordo vincolante tra il fornitore e il cliente. Il ciclo di vita del contratto di servizio è comunemente descritto in cinque fasi: la negoziazione, l’implementazione, il monitoraggio, l’aggiornamento e la rinegoziazione. Ogni fase presenta sfide per l’utente dei servizi cloud.

La negoziazione degli SLA può essere un compito difficile, in particolar modo per le organizzazioni più piccole nei confronti dei grandi fornitori di servizi cloud. Per risolvere questa criticità si fa ricorso agli SLA standard, cd. non negoziati, che non sono sorprendentemente vantaggiosi per il fornitore, ma tutelano il cliente e riducono al minimo le sanzioni in caso di non conformità. Sono stati proposti i Security Service Level Agreement (SSLA), ma non sono stati ancora accettati da alcuni fornitori.

Affidare le informazioni vitali e le risorse di un’organizzazione ad una terza parte può essere fonte di nuovi rischi. Spesso di commette l’errore di presumere che i fornitori di servizi cloud soddisfino le aspettative di sicurezza in base alle loro dimensioni e alla loro reputazione. Gli SLA sono il metodo più efficace con cui i security manager possono controllare il cloud, ma non va fatta confusione tra la gestione degli SLA e la gestione della sicurezza dell’informazioni. L’obiettivo è quello di migliorare gli SLA per dimostrare risultati tangibili in termini di performance.

La necessità di fiducia nelle relazioni cloud

La conseguenza di una definizione di SLA negoziati è la creazione di una relazione di Trust tra fornitori e clienti. La fiducia consiste nel ritenere che il fornitore gestirà in modo proattivo la sicurezza nell’interesse del cliente. In caso di crisi, i rischi saranno identificati e mitigati senza la necessità di dover rivedere gli SLA. In pratica, il fornitore dovrà operare in totale trasparenza e fornirà le informazioni che potrebbero indicare il non raggiungimento dei livelli di servizio contrattualizzati.

Le relazioni di trust non escludono la necessità di prevedere comunque SLA di alta qualità. In effetti, gli SLA sono essenziali per creare le condizioni per la fiducia, ma devono persistere per affrontare al meglio il rapporto tra utenti e fornitori. I fornitori di servizi cloud dovrebbero facilitare la fiducia, mostrando competenza, buona volontà e coerenza e, di conseguenza, migliorerebbero gli SLA di sicurezza.

A riguardo, un framework per la creazione e la gestione degli SLA contribuirebbe a garantire un livello coerente di qualità e utilità negli SLA. Un framework del genere si potrebbe basare sul concetto di capability maturity, in quanto una progressione di attività misurabili si tradurrebbe in uno stato finale desiderato (ad esempio: SLA di sicurezza che riducono il rischio e aumentano la trasparenza). Prendendo a modello quello elaborato dal Software Engineering Institute, Carnegie Mellon University, possiamo identificare due fasi fondamentali: la Formazione delle relazioni e la Gestione delle relazioni. Ogni fase contiene processi discreti e le fasi sono collegate tra loro (l’output di una fase funge da input per la successiva).

Framework per la formazione e gestione degli SLA (fonte: SEI – Carnegie Mellon University)

La fase di formazione delle relazioni comprende:

• la creazione di una descrizione dettagliata del servizio,
• la traduzione dei requisiti di sicurezza interni in requisiti del provider di servizi cloud,
• la selezione di metriche per SLA specifiche,
• la negoziazione e l’accordo su SLA specifici con il provider di servizi cloud.

La fase di gestione continua contiene i seguenti processi:

• monitoraggio e verifica delle prestazioni di sicurezza del provider di servizi cloud,
• esecuzione di revisioni periodiche del servizio con il provider utilizzando gli SLA,
• conduzione di analisi delle cause principali sui problemi di sicurezza del servizio,
• richiamo di sanzioni per le violazioni degli SLA,
• gestione delle azioni correttive per la risoluzione come specificato negli SLA,
• l’acquisizione delle lezioni apprese per informare le revisioni degli SLA.

In sintesi, l’utilizzo del cloud richiede l’acquisizione di nuove competenze e metodologie. La definizione di SLA specifici e il monitoraggio delle prestazioni di sicurezza del provider di servizi cloud sono due sfide significative. Un approccio basato sui processi e sui dati contribuirebbe ad alleviare queste preoccupazioni e a produrre SLA di alta qualità destinati a ridurre i rischi e aumentare la trasparenza.

I principali rischi, minacce e vulnerabilità nel passaggio al cloud

Le organizzazioni continuano a sviluppare nuove applicazioni o a migrare quelle esistenti sul cloud, basti pensare alla misura PNRR da 1.000.000.000 di euro per l’abilitazione e la facilitazione alla migrazione al Cloud destinata agli enti pubblici, senza effettuare un attento risk assesment. Un’organizzazione, che adotta tecnologie cloud e/o sceglie fornitori di servizi cloud (CSP) senza essere pienamente informata dei rischi connessi, si espone ad una miriade di vulnerabilità commerciali, finanziarie, tecniche, legali e di conformità. In questo paragrafo proviamo ad elencare i principali rischi, minacce e vulnerabilità che le organizzazioni dovrebbero affrontare nel momento in cui spostano le applicazioni o i dati nel cloud. Ovviamente le minacce e le vulnerabilità coinvolte nella migrazione al cloud sono in continua evoluzione, per tanto quelle elencate non sono affatto esaustive, ma possono servire a tracciare una strategia di seguire.

Il NIST identifica i seguenti modelli di cloud computing:

• Essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service,
• Service Models: software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS),
• Deployment Models: private cloud, community cloud, public cloud, and hybrid cloud.

Minacce, rischi e vulnerabilità del cloud computing

Se ragionassimo in senso generale, l’ambiente cloud subirebbe le stesse minacce di un data center tradizionale perché il quadro delle minacce è lo stesso. In pratica, il cloud computing esegue software, il software presenta delle vulnerabilità e gli avversari tentano di sfruttarle. Quello che cambia nel cloud computing è la responsabilità, nel cloud è condivisa tra il CSP e il cliente e, pertanto, si deve innanzitutto comprendere questa divisione e avere fiducia che il CSP adempia alle proprie responsabilità. Sulla base della letteratura, è stato identificato il seguente elenco di vulnerabilità e minacce.

Minacce e rischi specifici del cloud

Le seguenti vulnerabilità sono specifiche del cloud computing.

• Ridotta visibilità e controllo. Quando si trasferiscono risorse e operations nel cloud, le organizzazioni perdono la visibilità e il controllo. Se si utilizzano servizi cloud esterni, la responsabilità di alcune policy e infrastrutture passa al CSP. L’effettivo spostamento di responsabilità dipende dai modelli di servizio cloud utilizzati. Le organizzazioni non possono eseguire il monitoraggio e l’analisi delle informazioni sulle applicazioni, i servizi, i dati e gli utenti con i propri strumenti, ma devono sfruttare quelli del CSP.
• Self-service on-demand. I CSP semplificano la fornitura di nuovi servizi. Le funzionalità di provisioning self-service del cloud consentono di fruire di servizi aggiuntivi senza il consenso dell’IT. L’utilizzo di servizi cloud non autorizzati potrebbe comportare un aumento delle infezioni da malware o dell’esfiltrazione di dati poiché l’organizzazione non è in grado di proteggere le risorse di cui non è a conoscenza. L’utilizzo di servizi cloud non autorizzati riduce inoltre la visibilità e il controllo di un’organizzazione sulla propria rete e sui propri dati.
• Internet-Accessible Management API. I CSP espongono una serie di interfacce di programmazione delle applicazioni (API) che i clienti utilizzano per gestire e interagire con i servizi cloud (noti anche come management plane). Queste API possono contenere le stesse vulnerabilità software di un’API per un sistema operativo, una libreria, ecc. A differenza delle API di gestione per l’elaborazione locale, le API CSP sono accessibili tramite Internet ed esposte in maniera più ampia a potenziali sfruttamenti. Gli attaccanti cercano le vulnerabilità nelle API di gestione e quando le scoprono li sfruttano per perpetrare attacchi verso le altre risorse cloud.
• Multi-tenancy. Per ridurre i costi di gestione i CPS configurano il multi-tenancy. Ma non è detto che si ottenga una separazione netta tra più clienti, per cui lo sfruttamento di vulnerabilità all’interno dell’infrastruttura, delle piattaforme o delle applicazioni di un CSP che supporta il multi-tenant può portare al mancato mantenimento della separazione tra i tenants. Se questa falla fosse presente, potrebbe essere utilizzata da un attaccante per ottenere l’accesso dalla risorsa di un’utente alle risorse o ai dati di un altro utente. La multi-tenancy aumenta la superficie di attacco, portando a una maggiore possibilità di perdita di dati. Questo attacco può essere realizzato sfruttando le vulnerabilità nelle applicazioni, nell’hypervisor o nell’hardware del CSP, sovvertendo i controlli di isolamento logico.
• Cancellazione incompleta. Le minacce associate all’eliminazione dei dati si possono verificare perché il cliente ha una ridotta visibilità su dove siano fisicamente archiviati i propri dati e una ridotta capacità per verificare l’eliminazione sicura dei propri dati. Questo rischio aumenta in proporzione all’ampiezza con cui sono distribuiti i dati all’interno dell’infrastruttura del CSP in un ambiente multi-tenancy. Inoltre, le procedure di cancellazione possono differire da fornitore a fornitore. Le organizzazioni potrebbero non essere in grado di verificare che i propri dati siano stati eliminati in modo sicuro e che i dati rimanenti non siano disponibili agli aggressori.

Minacce e rischi comuni a cloud e on-premise

Di seguito sono riportati i rischi che si applicano sia ai data center on-premise che in cloud.

• Furto di credenziali. Se un utente malintenzionato ottenesse l’accesso alle credenziali cloud di un utente, potrebbe avere accesso ai servizi del CSP per fornire risorse aggiuntive (se le credenziali consentono l’accesso al provisioning), nonché prendere di mira le risorse dell’organizzazione. L’aggressore potrebbe sfruttare le risorse del cloud computing per prendere di mira gli utenti amministrativi, altre organizzazioni che utilizzano lo stesso CSP o gli amministratori del CSP. Solitamente i ruoli di amministratore variano tra un CSP e i clienti. L’amministratore CSP ha accesso alla rete, ai sistemi e alle applicazioni CSP (a seconda del servizio) dell’infrastruttura del CSP, mentre gli amministratori del cliente hanno accesso solo alle implementazioni cloud dell’organizzazione.
• Vincoli impostati dal fornitore. Un vincolo del fornitore diventa un problema quando un’organizzazione valuta la possibilità di spostare le proprie risorse da un CSP ad un altro. L’organizzazione scopre che il costo necessario per lo spostamento è molto più elevato di quanto inizialmente considerato a causa di fattori quali: l’utilizzo di formati di dati non standard, API non standard e la dipendenza da strumenti proprietari e API univoche di un determinato CSP. Questo problema aumenta nei modelli di servizio in cui il CSP si assume maggiori responsabilità. Se un CSP selezionato fallisse, diventerebbe un grosso problema poiché i dati potrebbero andare persi o non essere trasferiti a un altro CSP in modo tempestivo.
• Maggiore complessità. La migrazione al cloud può introdurre complessità nelle operazioni IT. La gestione, l’integrazione e il funzionamento nel cloud richiede l’apprendimento di un nuovo modello da parte del personale IT, poiché deve avere la capacità e il livello di competenza necessario per gestire, integrare e manutenere la migrazione di risorse e dati nel cloud. I servizi di management delle chiavi e della crittografia diventano più complessi. I servizi, le tecniche e gli strumenti disponibili per registrare e monitorare i servizi cloud, generalmente, variano tra i CSP, aumentando ulteriormente la complessità. Questa maggiore complessità comporta un aumento del potenziale di bug di sicurezza nelle implementazioni cloud e on-premise.
• Accesso autorizzato. Gli addetti ai lavori, come il personale e gli amministratori, sia delle organizzazioni che dei CSP, abusano del loro accesso autorizzato alle reti, ai sistemi e ai dati dell’organizzazione o del CSP e si trovano spesso nella posizione di essere gli autori di incidenti o sottrazioni di informazioni. L’impatto peggiora quando si utilizza il modello IaaS, perché il loro rilevamento richiederebbe tool di analisi forensi, ma queste funzionalità potrebbero non essere disponibili con le risorse cloud.
• Perdita dei dati. I dati archiviati nel cloud possono andare persi per motivi diversi dagli attacchi malevoli. La cancellazione accidentale dei dati da parte del fornitore di servizi cloud o un incidente fisico, come un incendio o un terremoto, possono portare alla perdita permanente dei dati del cliente. L’onere di evitare la perdita di dati non ricade esclusivamente sulle spalle del provider. Per esempio, se un cliente crittografasse i propri dati prima di caricarli nel cloud, ma perdesse la chiave di crittografia, i dati andrebbero persi. Inoltre, una comprensione inadeguata del modello di archiviazione di un CSP può comportare la perdita di dati. Gli utenti del cloud devono prendere in considerazione la criticità connessa al recupero dei dati ed essere preparati alla possibilità che il loro CSP venga acquisito, cambi l’offerta di servizi o fallisca.
• Compromissione della supply chain. Se il CSP esternalizzasse parti della propria infrastruttura o attività, le terze parti potrebbero non soddisfare e/o supportare i requisiti che il CSP ha contrattualizzato con il cliente. Un’organizzazione deve valutare in che modo il CSP applica la conformità, ovvero se trasmette i propri requisiti, alle terze parti. In assenza di imposizione di tali requisiti alla supply chain, aumenteranno le minacce.
• Due diligence. Le organizzazioni che migrano al cloud spesso non eseguono una due diligence approfondita. Spostano i dati nel cloud senza comprendere l’intera portata di tale operazione, le misure di sicurezza utilizzate dal CSP e il grado di responsabilità nel fornire misure di sicurezza.

Quelle indicate sono solo le principali minacce che le organizzazioni che decidessero di migrare, o attivare nuovi servizi, sul cloud dovranno affrontare. A parere dello scrivente, l’elemento su cui occorre concentrarsi, prima della valutazione degli aspetti tecnici e delle eventuali minacce, è il modello di responsabilità condivisa. Occorre che siano tratteggiati i confini e gli obblighi di responsabilità tra il CSP e il cliente, compresi quelli della sicurezza, tenendo presente che:

• alcuni aspetti legati alla sicurezza restano di esclusiva responsabilità del cliente.
• una sicurezza cloud efficace dipende dalla conoscenza e dal rispetto di tutte le responsabilità da parte del cliente.

L’incapacità del cliente dei servizi cloud di comprendere o di adempiere alle proprie responsabilità è una delle principali cause di incidenti di sicurezza nei sistemi basati su cloud.

Le best practice per la sicurezza nel cloud

In questo paragrafo indicheremo quali potrebbero essere le migliori pratiche per affrontare le vulnerabilità e i rischi connessi allo spostamento di applicazioni e dati nei servizi cloud.

Come sottolineato nel paragrafo precedente, le organizzazioni dovrebbero eseguire la due diligence prima di spostare dati o applicazioni nel cloud. I fornitori di servizi cloud (CSP) devono utilizzare un modello di responsabilità condivisa, dove il CSP si assume la responsabilità di alcuni aspetti della sicurezza, altri aspetti sono condivisi tra il CSP e il cliente, mentre alcuni rimangono di esclusiva responsabilità del cliente.

Vediamo in dettaglio quali attività dovrebbero seguire per assicurare un minimo livello di sicurezza.

Eseguire la due diligence

Gli utenti del cloud devono conoscere appieno le proprie reti e applicazioni per poter fornire funzionalità, resilienza e sicurezza alle applicazioni e ai sistemi distribuiti nel cloud. La due diligence deve essere eseguita su tutto il ciclo di vita delle applicazioni e dei sistemi distribuiti nel cloud, inclusa la pianificazione, lo sviluppo e la distribuzione, la produzione e la dismissione.

• Pianificazione. Il primo passo per una distribuzione cloud di successo consiste nel selezionare un sistema o un’applicazione appropriata: un compito impegnativo per una prima distribuzione cloud. Pertanto, è utile approfittare dell’esperienza di chi ha già fatto questa scelta e appoggiarsi ad un framework di scelta dei servizi cloud per consentire un utilizzo efficiente e integrato. Quest’ultimo, solitamente, fornisce un processo di management per identificare le applicazioni, selezionare i fornitori di cloud e gestire le attività operative associate ai servizi di cloud pubblico. Successivamente, occorre istruire tutto il personale coinvolto sulle nozioni di base del CSP selezionato, dell’architettura, dei servizi e degli strumenti disponibili. Infine, occorre assicurarsi che tutti comprendano il modello di responsabilità condivisa del CSP e il suo impatto sul loro ruolo.
• Sviluppo e distribuzione. Il gruppo di sviluppo e distribuzione deve essere ben formato sull’utilizzo corretto dei servizi CSP per implementare le applicazioni da distribuire. Di norma, i CSP forniscono indicazioni e documentazione sulle migliori pratiche per l’utilizzo dei loro servizi e, di conseguenza, chi dovesse sviluppare una nuova applicazione, dovrebbero progettare e sviluppare seguendo le indicazioni del CSP. Se, invece, si stesse eseguendo la migrazione di un’applicazione o di un sistema esistente, sarebbe fondamentale rivederne l’architettura e l’implementazione in base alle indicazioni del CSP per identificare le modifiche necessarie. Il cloud computing si basa sulla fornitura di servizi astratti che spesso somigliano molto all’hardware, alle reti e alle applicazioni esistenti. Per ottenere una sicurezza efficace, tuttavia, è fondamentale che i clienti si rendano conto che si tratta solo di astrazioni costruite per assomigliare alle risorse informatiche attualmente utilizzate dalle organizzazioni. Pertanto, è necessario esaminare le politiche di sicurezza dell’organizzazione e gli attuali approcci all’implementazione del controllo di sicurezza locale. Quindi, verificare se i servizi CSP forniscono un approccio di implementazione migliore che soddisfa comunque gli obiettivi della politica di sicurezza. Il passaggio a un ambiente cloud può presentare rischi che non erano presenti nella distribuzione locale. Verificare la presenza di nuovi rischi e identificare eventuali nuovi controlli di sicurezza necessari per mitigarli.
• Produzione. Una volta che le applicazioni sono state sviluppate e distribuite, devono essere gestite in modo sicuro. A differenza dei server fisici, dei dischi e dei dispositivi di rete, nel cloud è il software che definisce l’infrastruttura virtuale. Di conseguenza, l’infrastruttura può essere trattata come codice, che dovrebbe essere gestito in un sistema di controllo del codice sorgente, per verificare che non avvengano modifiche. Le modifiche alle risorse di produzione dovrebbero richiedere l’approvazione da parte di un responsabile del sistema prima dell’implementazione.
• Dismissione. Nel caso in cui si decidesse di dismettere un’applicazione in cloud, perché ha finito di essere utile oppure perché si è deciso di doverla spostare su un altro CSP, l’operazione potrebbe rappresentare un onere non indifferente (per le considerazioni fatte in precedenza). Pertanto, è fortemente consigliato pianificare l’eventuale disattivazione prima della sua distribuzione. La parte più importante di qualsiasi applicazione o sistema sono i dati archiviati ed elaborati al suo interno. È quindi fondamentale capire come possono essere estratti e spostati in un altro CSP.
• Sviluppare una strategia Multi-CSP. L’esperienza ci insegna che è necessario valutare l’opportunità che il CSP scelto non sarà uno solo o che non sarà sempre lo stesso. Ciò consente di cogliere le migliori opportunità di mercato, cercare CSP più performanti e perseguire la business continuity.

Management degli accessi

La gestione degli accessi in ambiente cloud riveste un ruolo fondamentale per la sicurezza. Come è noto, richiede generalmente tre funzionalità: la capacità di identificare e autenticare gli utenti, la capacità di assegnare diritti di accesso e la capacità di creare e applicare le policy di controllo degli accessi per le risorse:

• Identificare e autenticare gli utenti. È quasi obbligatorio utilizzare l’autenticazione a più fattori, o sistemi alternativi di autenticazioni robusta, per ridurre il rischio di compromissione delle credenziali, in particolar modo quelli con ruoli privilegiati.
• Assegnare i diritti di accesso. È necessario pianificare una serie di ruoli per contemplare sia le responsabilità condivise che quelle specifiche del cliente. Questi ruoli dovrebbero garantire che nessuno possa influire negativamente sull’intero data center virtuale. Il controllo degli accessi basato sui ruoli può essere utilizzato per stabilire privilegi differenziati anche tra sviluppatori e gestori di sistema.
• Creare e applicare policy di accesso. I CSP offrono diversi tipi di servizi di archiviazione e ciascuno di questi servizi può avere policy di accesso univoche che devono essere assegnate per proteggere i dati memorizzati. Gli utenti del cloud devono comprendere e configurare queste policy di accesso.

Protezione dei dati

La protezione dei dati implica tre obiettivi distinti: proteggere i dati da accessi non autorizzati, garantire l’accesso continuo, anche in caso di errori e guasti, ai dati critici e prevenire la divulgazione accidentale dei dati presumibilmente cancellati.

• Proteggere i dati da accessi non autorizzati. La crittografa dei dati consente di proteggerli dalla divulgazione dovuta ad accessi non autorizzati. In genere i CSP forniscono funzionalità di crittografia. Occorre decidere come gestire correttamente le chiavi per garantire una crittografia efficace. I CSP offrono la possibilità di scegliere tra chiavi gestite dal CSP o gestite da loro. Nel primo caso il CPS non fornisce alcun controllo su dove o come siano archiviate le chiavi, nel secondo caso l’onere è del cliente e acquisisce automaticamente anche il controllo.
• Garantire la disponibilità dei dati critici. I CSP forniscono garanzie significative contro la perdita di dati persistenti. Tuttavia, è necessario garantire che i processi di backup e ripristino dei dati soddisfino le esigenze dell’organizzazione.
• Prevenire la divulgazione dei dati cancellati. I CSP spesso replicano i dati per garantire la persistenza. Pertanto, quando è necessario eliminare dati sensibili o ritirare risorse contenenti dati sensibili, è necessario considerare la replica e la diffusione dei dati derivanti dal normale funzionamento del sistema. Per cui è necessario analizzare attentamente la distribuzione del cloud, per comprendere dove potrebbero essere stati copiati o memorizzati, e determinare cosa dovrebbe essere fatto per garantire che queste copie siano eliminate.

Monitoraggio

L’implementazione del cloud aggiunge complessità al monitoraggio.

• Monitorare le risorse distribuite nel cloud. Il CSP è responsabile del monitoraggio dell’infrastruttura e dei servizi forniti ai clienti, ma non è responsabile del monitoraggio dei sistemi e delle applicazioni che i clienti realizzano utilizzando i propri servizi. Il CSP fornisce informazioni di monitoraggio relativi all’utilizzo dei servizi, ciò consente di realizzare un primo livello di monitoraggio per rilevare l’accesso o l’utilizzo non autorizzato, nonché a individuare comportamenti o utilizzi anomali. Occorre imparare a comprendere il significato dei dati forniti dal CSP, determinare cosa è normale per la distribuzione in cloud e utilizzare gli strumenti forniti dal CSP per rilevare le anomalie. Per quanto possibile, si utilizzano i dati di monitoraggio forniti dal CSP, ma sarebbe opportuno potenziarli con un monitoraggio aggiuntivo e ad-hoc delle risorse.
• Analizzare il monitoraggio on-premise e in cloud. Nel caso in cui si scegliesse una distribuzione cloud ibrida, ovvero che sposta alcune risorse in cloud mentre mantiene altre in locale, sarà necessario combinare le informazioni di monitoraggio fornite dal CSP, con quelle personalizzate e quelle locali, per avere un quadro completo della postura di sicurezza informatica dell’organizzazione.
• Coordinarsi con il CSP. Il CSP è responsabile del monitoraggio dell’infrastruttura utilizzata per fornire servizi cloud, comprese macchine virtuali, reti e storage, per cui è in grado di rilevare eventi che potrebbero influenzare negativamente le applicazioni del cliente. In tal caso, il CSP dovrà informare il cliente e coordinare una risposta. Allo stesso modo, il cliente può rilevare eventi malevoli e aver bisogno di assistenza per analizzarli. Pertanto, è necessario imparare a collaborare per indagare e, eventualmente, rispondere ai potenziali incidenti di sicurezza.

Conclusioni

L’elemento di sintesi di questa lunga disamina sullo sviluppo di applicazioni sicure in cloud è rappresentato da tre fattori: la necessità di sviluppare una profonda comprensione dei servizi che si stanno acquistando, il modello di responsabilità condivisa e l’utilizzo degli strumenti di sicurezza forniti dal CSP. I recenti incidenti di sicurezza nel cloud riportati dalla cronaca molto probabilmente si sarebbero potuti evitati se fossero stati utilizzati correttamente gli strumenti di sicurezza, come il controllo accessi, la crittografia dei dati, l’autenticazione a più fattori, i sistemi di backup/ripristino, offerti dai CSP. Questi suggerimenti non sono esaustivi e dovrebbero essere integrati con le best practices fornite dai fornitori di servizi cloud. Inoltre, vi sono associazioni, come la Cloud Security Alliance, dove è possibile reperire migliori indicazioni di sicurezza informatica o i requisiti di conformità normativa di settore.