Adottare soluzioni cloud in sicurezza si può... (se leggiamo bene le clausole in piccolo)

Quando parliamo di cloud, il primo problema che ci troviamo di fronte è definire con esattezza a cosa ci stiamo riferendo, dal momento che con questo termine si intendono molte cose diverse. Il modello cloud nasce per risolvere due problemi fondamentali: uno riguarda la business continuity e il disaster recovery dei servizi dell’organizzazione, l’altro la fornitura di sufficiente potenza di calcolo, parallelizzato su più macchine fisiche considerate come se fossero una macchina sola, anche solo per periodi limitati di tempo. A questi si aggiunge un terzo aspetto, cioè l’outsourcing: il “segreto del successo” del cloud è, almeno in parte, la possibilità per un’organizzazione di acquistare calcolo, applicazioni, dati e più o meno qualsiasi altra cosa come servizio (il famoso anything as a service) gestito da una terza parte, scaricandosi di tutti i problemi legati alla sua gestione. Ma è proprio vero che adottando una soluzione cloud di terze parti abbiamo risolto tutti i nostri problemi? Per la sicurezza vedremo che non è proprio così.

I servizi cloud sono distinti in tre tipi principali: IaaS (risorse di calcolo, storage e rete su cui dobbiamo installare i sistemi operativi), PaaS (piattaforme che gestiscono per l’utente l’hardware sottostante, per esempio macchine già provviste del sistema operativo, o cluster Kubernetes) e SaaS (il software già pronto per l’uso, ad esempio la posta elettronica Microsoft365, GARR TV o le app di videoconferenza di GARR Meet). A questi si sono aggiunte molte altre tipologie, tra cui il servizio di Desktop as a Service per i PC di studenti o personale, divenuto molto popolare durante la pandemia.

Un’altra distinzione è legata alla proprietà dell’infrastruttura fisica: parliamo di cloud privato quando hardware e rete sono di proprietà dell’organizzazione, pubblico quando sono proprietà del fornitore e consorziato, federato o di comunità quando sono in comune fra varie organizzazioni. In strutture di grandi dimensioni, sia enterprise che di ricerca, tipicamente troviamo cloud di tutti i tipi (il cosiddetto MultiCloud).

Pur con tutte queste differenze, possiamo approcciare il problema della sicurezza dei cloud (il plurale non è per caso) attraverso l’analisi del rischio, andando cioè a vedere quali siano le minacce più probabili e stilando un Threat Model generale, che dovrà poi essere personalizzato da ciascuna organizzazione sulla base delle specifiche risorse gestite (infrastruttura, software, dati...).

Il primo aspetto da valutare è che la sicurezza dei sistemi in cloud non può essere separata dalla sicurezza dei sistemi “normali”. Anche le macchine in cloud hanno una ubicazione fisica, hanno sistemi operativi noti, applicativi da installare e configurare, utenti che accedono, privilegiati e non. Per ognuno di questi aspetti dovremo dunque considerare anche le minacce “tradizionali” , che andranno gestite secondo i criteri canonici della sicurezza: per esempio tenere il software aggiornato e assicurarsi che gli ambienti fisici siano chiusi ai non autorizzati restano comunque best practice valide anche per il cloud.

Con il secondo aspetto entriamo invece nel merito del cloud in senso stretto: la complessità e l’astrazione introdotta dal software di gestione del cloud necessita di configurazioni sicure e manutenzione. Ci saranno quindi ulteriori applicazioni (ad esempio software di virtualizzazione, container, script automatici machine- 2machine) da monitorare e mantenere aggiornati.
Purtroppo, oggi si riscontra ancora diffusa immaturità nella gestione del cloud e nel controllo della sicurezza, soprattutto per quanto riguarda le console di gestione e degli accessi all’amministrazione del cloud. Facciamo un esempio pratico: gestendo un IaaS, dovrò occuparmi di tutto a partire dal sistema operativo. L’unica cosa di cui non mi dovrò occupare, se l’hardware è fornito o ospitato da una terza parte, è la sicurezza fisica dei sistemi; invece per sistemi PaaS incaricherò il gestore anche della manutenzione del sistema operativo e della piattaforma di virtualizzazione sovrastante (ad esempio container).

Spesso per carenza di risorse si ricorre all’utilizzo di cloud pubblici, che presentando tutti gli aspetti positivi del cloud, sgravano l’organizzazione dalla gestione delle problematiche relative all’hardware e, in parte, al software. Ma le cose non sono esattamente così: avvalersi di un cloud pubblico comporta in realtà la suddivisione degli ambiti di responsabilità fra il gestore e l’organizzazione. A seguito di incidenti di sicurezza, anche gravi, su piattaforme cloud commerciali, recentemente i due maggiori fornitori di servizi cloud, AWS e Microsoft Azure, propongono dei contratti con schemi ben definiti sulla divisione dei compiti e degli ambiti di pertinenza, soprattutto per quanto riguarda gli aspetti di sicurezza. Da questi schemi si evince chiaramente che a seconda del servizio che acquistiamo, è comunque onere dell’organizzazione occuparsi degli aspetti che non sono previsti dal contratto. Per esempio se si acquista una piattaforma PaaS, il gestore si occupa di blindare l’hardware e il software di propria competenza e di monitorarli, secondo un proprio schema di analisi del rischio condiviso con l’organizzazione; ma, per essere sicuro, l’ente deve controllare che il proprio applicativo installato sia ragionevolmente protetto.

Alcuni software di gestione della console del cloud, ad esempio, promettono che basti installarli perché funzionino. E in effetti è vero. Ma per accedere alla console servono chiavi SSH, possedute solo da chi ne ha diritto. Per far funzionare tutto e subito, questi sistemi arrivano con chiavi SSH già installate di default che sono uguali per tutti coloro che utilizzano quel software e vanno cambiate durante la fase di configurazione. Se questo passaggio non viene fatto, a un attaccante basterà sapere l’IP della console e installarsi in casa il software per entrare nel cuore del nostro cloud senza neanche una password.
Un’altra cosa che succede spesso su questi sistemi riguarda il ciclo DevOps di pubblicazione del proprio software nei passaggi da fase di sviluppo a fase di produzione. Vengono creati dei PaaS di prova, su cui effettuare test, ma una volta terminati, invece di disintegrare quella parte di cloud con il sistema di virtualizzazione, spesso si lascia tutto alla mercè dei curiosi, o peggio. Anche in ambiente container, poiché di default tutto viene rappresentato come un’unica grande LAN, se non viene effettuata un’opportuna microsegmentazione, è possibile per un malintenzionato accedere a posti che non gli competono sfruttando i movimenti laterali da un container all’altro.

Avere quindi uno schema ben chiaro di oneri e responsabilità è molto utile sia per i fornitori che per le organizzazioni: in caso di data breach si va a vedere in quale parte si è sfruttata la vulnerabilità, risalendo alla responsabilità effettiva che ha causato il danno. Detto così sembra il migliore dei mondi possibili, dove ognuno fa la sua parte, ma non tutti i fornitori ancora lo fanno, bisogna quindi leggere bene i contratti.

E ancora non basta: altro aspetto fondamentale da tenere in considerazione quando decidiamo di avvalerci di sistemi cloud, specialmente di terze parti, è il monitoraggio della rete e delle applicazioni. Per stabilire i punti di ingresso e il perimetro, fare un’analisi delle vulnerabilità e del rischio, ma anche semplicemente a posteriori riuscire a capire come sia potuto accadere un incidente, è necessario prevedere e configurare un sistema di monitoraggio della rete e dei servizi che eroghiamo. Anche in questo caso, i vendor ci possono venire in aiuto con piattaforme condivise, sistemi ibridi di gestione incidenti, anche veri e propri SIEM già confezionati, ovviamente con costi aggiuntivi che dipendono dal tipo di contratto. Oppure possiamo occuparcene noi, prevedendo risorse cloud aggiuntive. Ricordiamoci però che ogni volta che aggiungiamo pezzi e aumentiamo la complessità del sistema, aggiungiamo anche vulnerabilità, punti di accesso, siamo più suscettibili di attacchi e possibili falle di sicurezza e che non è il contratto all-inclusive, il cui costo sale esponenzialmente con il numero di feature aggiuntive, che rimuoverà tutti i rischi.

Se, per esempio, non abbiamo letto bene il contratto con il fornitore e non abbiamo fatto caso al fatto che non ci fosse la clausola “dati replicati su diversi data centre”, oppure l’abbiamo eliminata perché troppo costosa, poi se l’edificio dove stanno i dati va a fuoco (ogni riferimento a fatti realmente accaduti è ovviamente voluto), avremo perso sia i dati sia i backup che si trovavano nello stesso data centre.

Credo che, come sempre, dovremmo partire dalla cosa più importante che vogliamo salvaguardare, sia per vocazione che per legge: i dati. Da qua dovremmo stabilire, in base all’impatto di un eventuale blocco o data breach, sia sull’organizzazione che sulle persone, quanto sia più sicuro metterli in cloud e in quale tipo di cloud, secondo un rapporto costo/beneficio che però sia consapevole di tutte le sfaccettature e le problematiche che ci portiamo a casa, o almeno delle più importanti.

Suddivisione degli ambiti di responsabilità in cloud
Fonte: Cloud Security Alliance

Un ultimo pensiero, non strettamente relativo alla sicurezza riguarda il trattamento dei dati da parte del gestore di cloud pubblico. Se per esempio utilizzo il cloud per la posta elettronica dell’organizzazione, ma il gestore “legge” le mail del mio personale per profilarlo, fare analisi di mercato, o altre cose non ben specificate, è necessario saperlo, decidere se si è d’accordo e informare opportunamente quanti utilizzano il servizio. In Europa tutto questo è regolamentato molto meglio che altrove dal GDPR, quindi nella scelta del gestore è bene fare attenzione anche a questo tipo di clausole contrattuali, purtroppo spesso illeggibili (non necessariamente per caso). Concludendo, ricorrere all’utilizzo del cloud è senza dubbio una soluzione che, usata opportunamente, può permettere alle organizzazioni di migliorare i propri servizi e nello stesso tempo risparmiare sia in termini economici che di effort. Spesso, in un mondo che va sempre più verso il Big Data, il cloud è anche l’unica soluzione sensata, perché la mole di dati che trattiamo diventa sempre più grande, corposa, e necessita di accesso sempre più rapido e l’esigenza di espandere i servizi che offriamo in tempi anche assai brevi può essere molto reale. Tuttavia è importante sapere che adottare queste soluzioni non è “gratis” in termini di sicurezza perché introduce nuovi elementi di rischio per la sicurezza dei dati, che vanno attentamente valutati e affrontati, scegliendo il tipo di soluzione e provider più adeguato e le clausole contrattuali che tengano conto dei vari aspetti, secondo il proprio piano di sicurezza e le proprie policy. Tutto questo non si improvvisa e richiede tempo e competenze.

Così, alla fine, potremmo anche scoprire che abbiamo sì risparmiato, ma non così tanto come pensavamo.