Article. What i write

Minacce e vulnerabilità del cloud computing: come proteggersi

Pubblicato il 7 febbraio 2024 su AgendaDigitale.eu

Il passaggio al Cloud

I Service Level Agreement: strumenti per la sicurezza

La necessità di fiducia nelle relazioni cloud

• 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.

• 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.

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

• 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

Minacce e rischi specifici del cloud

• 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

• 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.

• 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

Eseguire la due diligence

• 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

• 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

• 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

• 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