Molti sistemi complessi, a prima vista con andamenti prevedibili, possono tuttavia, al mutare delle condizioni esterne, cambiare repentinamente il loro comportamento, per poi stabilizzarsi nuovamente in qualcosa di diverso. In Fisica, fanno parte di questi fenomeni le “transizioni di fase,” come ad esempio la sublimazione: il cambio repentino dallo stato solido a quello gassoso quando parametri ambientali quali temperatura e pressione superano dei valori di soglia. Tali “rotture di simmetria,” o “sport evolutivi,” accadono anche nei modelli economici.
L’adozione massiccia del cloud computing è una sublimazione che, nel trasferire in nuvola i tantissimi mini- e micro-CED pieni di cavi e rumorose ventole (il cosiddetto “vil metallo”, o bare metal), crea anche nuovi modelli di business che accorciano le distanze, economiche e fisiche, tra fornitori e fruitori di servizi professionali. Purtroppo le vulnerabilità sfruttate durante incidenti di sicurezza legati al cloud sono sovente dovute (più o meno involontariamente) al disegno di servizi che portano l’utente, professionale o consumer che sia, ad una fruizione intuitiva, rapida ed economica, nel perenne braccio di ferro tra sicurezza e user experience (‘UX’). Tale rapidità ed economia si raggiungono grazie alla capacità di misurare con precisione molti più aspetti del servizio (metrics), analizzarli automaticamente (analytics) e imputare sempre di più a tali risultati le decisioni evolutive e di mercato.
In questo senso il rischio d’impresa nei cloud business model è cambiato in quanto affidato sempre più a metriche oggettive e precise (data science) piuttosto che a “intuizioni” o analisi di mercato. Per lo stesso motivo l’approccio alla sicurezza amministrativa (in quanto gestione del rischio informatico) può essere adeguata solo se evolve di pari passo con il modello di business, “sublimando” anch’essa ed evolvendo in misure di sicurezza quali, ad esempio, le polizze assicurative che coprano anche il rischio cloud.
Indice degli argomenti
L’importanza della security by design (mantenere al sicuro i dati sensibili)
Le stesse tecnologie che abilitano comunicazioni efficaci e operazioni delocalizzate con pochi clic, qualora non ingegnerizzate in un’ottica di security by design, contribuiscono a creare canali di comunicazione potenzialmente molto più vulnerabili ad attacchi informatici (condotti da umani o meno) dei loro omologhi più “tradizionali” ― particolarmente nelle fasi di scalata dei privilegi e di infiltrazione/esfiltrazione dei dati.
Senza contare che le minacce alla “nuvola” sono solo in parte mutuate da quelle tradizionali: ad esse si aggiungono infatti tutte quelle tipiche della Cyber Security, cioè legate alla sua intrinseca natura re-industrializzata su larga scala. Anche in questo senso, quindi, l’aspetto più tecnico della sicurezza deve “sublimare” nel cloud; l’approccio metodologico, l’insieme delle tecnologie utilizzate e, soprattutto, le competenze necessarie all’architettura e alla messa in opera della sicurezza logica, andrebbero adattate alla specifica architettura utilizzata.
Ad esempio, nel sublimare la propria infrastruttura tradizionale nel cloud, non basta migrare la medesima topologia di rete (inclusi gli apparati di sicurezza) e replicarne tout court le policy. Così facendo, si rischia di mantenere attivi controlli di sicurezza non più rilevanti a causa della natura virtuale dell’infrastruttura (si legga più avanti), mantenendo invece potenziali e non più giustificabili rallentamenti. Viceversa, le aree non definite o logicamente segregate del nuovo ambiente potrebbero rimanere senza adeguata sorveglianza.
L’errore opposto (in agguato soprattutto qualora si disegni un’architettura cloud-native) consiste nel trascurare l’intrinseca natura infrastrutturale del cloud, delegando al CSP (Cloud Service Provider) la gestione di controlli che non siano espressamente indicati nei contratti di fornitura (SLA), ovvero affidandosi eccessivamente a controlli previsti ma che, all’atto pratico, il CSP non potrebbe tecnicamente imporre in maniera efficace sul tier del cliente ― quantomeno non senza un’adeguata pianificazione ad hoc.
GDPR e la doppia anima del cloud computing
L’aspetto più peculiare del cloud risiede proprio in questa sua duplice natura: da una parte quello che ho chiamato “sublimazione” delle risorse, cioè la dematerializzazione dell’impalcatura IT tradizionale e la conseguente virtualizzazione della capacità di calcolo (VM e container), delle reti informatiche (SDN) e dello storage (SDS). Dall’altra la fondamentale natura fisica dell’infrastruttura cloud, che in realtà tutto fa salvo che sublimare. Non va dimenticato che, a basso livello, dire “cloud” implica sempre la presenza di uno o più data center ove persiste il bare metal ― di proprietà di qualcun altro nel caso dei cloud privati ― che resta per qualcuno una spesa capitale e come tale va gestita.
La segmentazione in microservizi produce un’effettiva riduzione dei costi di “affitto” delle risorse cloud e un miglioramento dell’efficienza complessiva solo se i container e le VM sono ingegnerizzate per rispondere elasticamente ai requisiti. I microservizi vanno sviluppati per interagire ad hoc fra di loro, non più come una semplice catena di montaggio lineare fatta da pochi server, bensì come uno “sciame” delocalizzato su moltissimi nodi fisici o virtuali, con tempi di risposta differenti, alle volte imprevedibili.
Anche la sicurezza tecnica di queste architetture dovrebbe adattarsi a tali scenari potenzialmente molto dinamici. Ancora una volta, servono competenze specializzate nell’orchestrare tecnologie e sicurezza distribuita in sciami, piuttosto che in segmenti di rete di pochi computer fisici. In un contesto, ad esempio, ove diverse istanze di un microservizio possono essere create e distrutte rapidamente a seconda del carico di lavoro, coesisteranno probabilmente diversi segmenti di rete virtuale (VLAN) ove tali microservizi dialogano ― per semplicità all’interno del medesimo tier fornito da un CSP.
L’hardening (cioè l’irrigidimento delle policy di sicurezza) delle singole VM e, in molti casi, dei container stessi, dovrebbe anche tenere conto della dinamicità di questo contesto, prevedere la presenza di canali di comunicazione aggiuntivi e temporanei tra i nodi di calcolo, ciascuno dei quali andrebbe messo in sicurezza in maniera il più possibile indipendente dagli altri, soprattutto nel caso nodi esposti su internet pubblica, direttamente oppure indirettamente ma senza una forte segregazione.
A seconda dell’analisi del rischio, potrebbe convenire introdurre microservizi aggiuntivi per assolvere a controlli di sicurezza sui nodi e sorvegliare la conformità delle reti virtuali sottostanti (software-defined networking, o SDN), allo scopo di rilevare tentativi di intrusione o di “movimento laterale” offuscato da questa fluidità topologica. Così come si può, in maniera centralizzata e automatica, controllare a intervalli regolari anche serrati, all’interno di ogni nodo, la presenza e l’integrità di file di sistema (e dei loro permessi) e il persistere, anche per dispositivi di rete come switch e gateway, di configurazioni di sicurezza e routing conformi ad una determinata procedura tecnica, in ambiente cloud tali controlli andrebbero effettuati al livello delle reti virtuali e degli “ipervisori.” Questo significa che è possibile monitorare che in un cluster a microservizi vi sia il numero giusto di istanze di nodi fondamentali per il funzionamento generale, mentre non siano presenti nodi non identificati o non internamente convalidati.
Un esempio fra tutti è costituito da Netflix, che ospita nel cloud (Amazon AWS) tanto i suoi motori di transcodifica video parallelizzata, che quelli dedicati allo streaming nei dispositivi dei suoi utenti. Nell’autunno 2015, a seguito di un blackout del database interno di AWS nella zona statunitense della costa orientale, i servizi cloud di diversi clienti di Amazon sono “andati giù,” per 6-8 ore. Netflix già da anni conduceva test di resilienza automatizzata dei suoi nodi, usando un tool distribuito e open source che spegne o rompe a caso microservizi e altri nodi di produzione, verificando i punti deboli della “flotta” di VM e che può, in caso di problemi gravi come quello citato poc’anzi, effettuare un failover completo su altre zone geografiche. In questo caso i controlli di sicurezza di Netflix ― agendo sull’intera infrastruttura anziché sui singoli nodi ― hanno compensato dirottando tutto il carico di lavoro interessato dall’ammanco verso istanze AWS nella costa occidentale, senza alcun impatto significativo sul servizio.
GDPR e rischio privacy / sicurezza per i servizi cloud
Vulnerabilità peculiari del cloud e potenzialmente molto disastrose sono quelle che propagano se stesse o la capacità di penetrazione di un terzo attore (ad es. un hacker) da una VM o container governati dalla stessa macchina fisica, addirittura “sconfinando” nell’ipervisore stesso. Il rischio per il CSP è innanzitutto di privacy, in quanto i sistemi compromessi fra di loro potrebbero essere gestiti da (o trattare dati per conto di) clienti diversi, ciascuno con procedure amministrative distinte. A seguito di tutte le considerazioni fatte (in particolar modo la connettività dinamica di dispositivi smart con i segmenti di rete di un’organizzazione) il concetto stesso di “perimetro di sicurezza” va ridefinito ― tanto per il cloud quanto per l’IoT. Se prima era costituito da un limite abbastanza rigido, sebbene virtuale, entro cui confinare lo spazio cibernetico di un’organizzazione, oggi tale perimetro sublima anch’esso, rendendo difficile valutare, ad esempio, tutti i punti esposti a infiltrazione/esfiltrazione.
Ancora una volta il disegno di reti sicure, che tratta ormai sempre più spesso indirizzamenti gestiti da infrastruttura virtuale con topologia variabile (SDN) non può prescindere dall’analisi delle minacce “cyber” più sofisticate e di vasta scala, come ad esempio gli attacchi DDoS (distributed denial of service) “da amplificazione,” contro i quali la miglior difesa consiste nel reindirizzare ― principalmente a livello dell’ISP ma non solo ― la valanga di richieste in sottoreti preposte prive di servizi critici. Analogamente l’uso di tecniche SDS (software-defined storage) in cloud aiuta a mitigare attacchi ransomware grazie alla possibilità di riportare un file system di rete ad uno stato precedente sostituendo le LUN virtuali con delle “istantanee” del medesimo volume o file system, che siano state catturate antecedentemente, e da lì sublimate.
Servizi cloud e obblighi previsti dal GDPR
Il rischio legato alla perdita del dato (in tutte le accezioni di integrità, confidenzialità e disponibilità) permane e anzi diventa ancor più centrale nell’ambito cloud, traghettandoci verso il mondo della compliance normativa. È oggi ben consolidato come la mancanza di una conoscenza completa del ciclo vita dei propri dati aziendali (dal momento della loro creazione o acquisizione, durante tutto lo sfruttamento, sino all’inevitabile dismissione) sia un fattore di rischio cruciale: «come posso proteggere qualcosa che non conosco, o non so esattamente dove sia ubicata?».
Tale ciclo non consiste soltanto nel tracciare il dato a livello di file system, ma anche di conoscere, nel contesto aziendale, la sua classificazione, veridicità, validità temporale e, soprattutto, la sua monetizzabilità. Altro fattore potenzialmente rilevante è la reperibilità dei dati, incluso il controllo sui territori ove si trova il bare metal che li contiene, alla cui giurisdizione essi diventano dunque soggetti.
I nuovi obblighi per il trattamento dei dati personali (in particolar modo a tutela della privacy dei cittadini europei) sono da poco in vigore ai sensi del regolamento UE №679/2016 denominato “GDPR”, che tra le altre cose pone in capo al responsabile e al titolare del trattamento dei dati nuovi obblighi di controllo. A lungo termine, ciò potrebbe contribuire a ridurre la cosiddetta data gravity della nuvola, cioè la tendenza dei grandi data lake ad attrarre esponenzialmente sempre più dati al loro interno (si pensi a quelli prodotti in tempo reale dai dispositivi mobile e IoT).
Ne può conseguire una difficile gestione, con conseguente inefficacia, di dati che, sempre più abbondanti e meno strutturati, difficilmente si prestano ad analytics e conservazioni efficaci, rischiando anche di uscire da qualunque finalità di trattamento pratica e normativa (data minimization).
Gestire una nuvola piena di dati fuori controllo non è soltanto rischioso in termini di compliance GDPR e sicuramente antieconomico (sia per i costi di esercizio o affitto dello storage, sia per il mancato ritorno d’investimento dalla loro analisi); può indicare anche la presenza di vulnerabilità di sicurezza, laddove vi siano data silo con molteplici porte di ingresso/uscita e basse capacità di controllare sia gli uni che le altre.
Ancora una volta, quindi, l’invito è quello di pianificare una tattica di “go to cloud,” con annessa analisi del rischio “cyber”, che tenga conto degli specifici requisiti funzionali e commerciali, ma anche alle tecnologie impiegate. Per questo ci si dovrebbe affidare a professionisti del settore cloud, che inquadrino tutti i processi di business all’interno delle specifiche tecnologie, disegnando o sublimando l’architettura tecnologica integrandola sin da subito con controlli di sicurezza a supporto delle procedure amministrative.
