twitterlinkedinmail

Davvero il Cloud è più sicuro?

Come spesso capita, quando si affrontano questioni “di principio”, la passione dialettica cede il posto alla ragionevolezza (per non parlare della razionalità).

Quella della “sicurezza del/nel Cloud Computing” rischia di trasformarsi in una di queste, con tanto di fazioni pronte a dividersi in “sicuristi” (sostenitori della maggiore sicurezza del cloud computing, a prescindere), contrapposti agli “insicuristi” (sostenitori della tesi opposta).

Purtroppo quando si affrontano questioni complesse (quali la Cybersecurity) non è sempre possibile dirimere “con l’accetta” le questioni spinose, separando in maniera netta il “bianco” da una parte, e il “nero” dall’altra.

Come sa bene chi si occupa quotidianamente di sicurezza, il “colore” che caratterizza la Cybersecurity raramente è il “bianco” o il “nero” assoluti, ma sempre più spesso è il “grigio” (e le sfumature, ahimè, non si limitano a cinquanta…)

Vediamo perchè.

Analizzare la “Cloud Computing Security”

Per poter affrontare quindi la questione “Cloud Computing Security” in maniera adeguata, è opportuno partire dalle basi della sicurezza informatica, e uno dei principi fondamentali sostiene che:

“La Sicurezza di una catena è costituita dal suo anello più debole”

Questo vuol dire che non basta “hardenizzare” (com’è doveroso) i sistemi critici, trascurando di mettere in sicurezza i restanti apparati, sistemi, applicazioni, ecc.

In caso contrario, si rischia di proteggere l’accesso principale con la porta blindata, lasciando tuttavia aperte le finestre!

È la Complessità, Bellezza!

Il problema che si pone nel Cloud Computing, rispetto alle tradizionali perimetrali di sicurezza, è che gli anelli della catena (per rimanere alla metafora) crescono a dismisura, in maniera tendenzialmente esponenziale, anzichè lineare.

Questo comporta una crescita potenzialmente incontrollata della cosiddetta attack surface (superficie d’attacco), che può dar luogo ad esiti imprevedibili ex-ante in termini di sicurezza.

Se già è difficile in un “contesto tradizionale” definire il perimetro di sicurezza, ancora più complicato è farlo in ambito distribuito, qual è il Cloud Computing.

Ogni nuovo “bucket” che viene aggiunto (per non parlare delle applicazioni, sistemi, apparati, sensori, ecc., che vi possono risiedere) aumenta in maniera più che proporzionale la complessità del “sistema cloud” nel suo insieme.

E, sempre stando ai principi fondamentali di sicurezza,

“La Complessità è il nemico giurato della Sicurezza”

Non basta, quindi, ridurre il problema alla scelta del prodotto/soluzione migliore (se questo prodotto esistesse realmente, lo sceglieremmo tutti!), ma occorre sempre più affrontare la “questione sicurezza” adottando un approccio “olistico”, che tenga conto appunto, della complessità del sistema nella sua globalità.

Alla ricerca del tool perfetto…

D’altra parte, è così da sempre:

“La Sicurezza è un processo, non un Prodotto”

come non mancano di ripetere ad ogni occasione “quelli bravi”.

Quindi la questione della crescita non lineare della potenziale attack surface costituisce il PROBLEMA del Cloud Computing!

Problema che non è derubricabile ad un semplice aspetto secondario.

La “maledizione della dimensionalità”

Gli effetti imprevedibili della complessità sono noti da tempo:

in buona sostanza, un sistema complesso è caratterizzato dal fatto di manifestare comportamenti imprevedibili (se non addirittura caotici) al crescere del numero di “gradi di libertà” che lo caratterizzano.

L’effetto più appariscente di tale imprevedibilità è noto come “effetto farfalla”.

Tale imprevedibilità, ovviamente, può essere controllata riducendo (e mantenendo costantemente) la complessità del sistema al di sotto della sua “soglia critica”.

Il punto è che individuare tale soglia critica non è affatto semplice.

Affidarsi agli algoritmi e al Machine Learning conviene?

Ad oggi, neanche gli algoritmi di machine learning sono in grado di gestire la cosiddetta “maledizione della dimensionalità” (“the curse of dimensionality”, vale a dire l’esplosione combinatoriale legata alla complessità derivante dal numero crescente di gradi di libertà di un sistema, corrispondenti nel nostro caso, al numero di bucket, apparati, sistemi, applicazioni, ecc. che possono liberamente interagire tra loro) e la complessità che da essa ne deriva.

In altri termini, un’eventuale vulnerabilità afferente il Cloud potrebbe essere sfruttata su “larga scala”, determinando un “effetto dòmino” con evidenti danni a cascata, semplicemente a causa delle caratteristiche topologiche che caratterizzano il Cloud.

Anche ammesso (e non concesso) che si riesca a garantire la “messa in sicurezza” dei singoli apparati, sistemi, applicazioni, ecc. che risiedono all’interno del Cloud, tali sistemi potrebbero comunque interagire tra loro in maniera imprevedibile ex-ante, in virtù appunto dei loro “gradi di libertà”, di cui non siamo in grado di stabilire in maniera deterministica (e in anticipo) il loro numero, qualità e natura.

Paradossalmente, un tradizionale perimetro di sicurezza “locale”, costituito da apparati e applicazioni “eterogenee” tra loro, è in grado di “spezzare” meglio la catena del contaggio, a prescindere dal livello di sicurezza dei singoli apparati/sistemi che vi risiedono.

Cosa fare?

In conclusione, la risposta più onesta che è possibile dare al problema “Cloud Computing Security” è che, ad oggi, non siamo in grado di stabilire “a priori” la maggiore/minore sicurezza delle “soluzioni cloud”, rispetto alle soluzioni “tradizionali” (e occorre pertanto condurre un’analisi caso per caso delle singole situazioni).

Dobbiamo quindi ricorrere anche in questo caso alle “best practices”.

La decisione più sensata rimane quindi quella di “non mettere tutte le uova nello stesso paniere” (ah, le best practices di sicurezza…), effettuando e conservando ad es. i backup dei dati critici (vale a dire, quelli essenziali a garantire la Business Continuity) al di fuori del cloud, rispettando anche i questo caso, le buone pratiche di Disaster Recovery, magari facendosi assistere da un Security Analyst (anzichè limitarsi a farsi consigliare dal proprio vendor di fiducia…)