Migliorare la teoria del tutto della cloud governance

Poco più di un anno fa ho scritto la Teoria del tutto della cloud governance. È un concetto su cui lavoro da circa 5 o 6 anni per cercare di sintetizzare la causa profonda delle difficoltà che le aziende incontrano nell'adattarsi al cloud. Certo, il titolo è un po' egocentrico, ma sono stato un analista Gartner, quindi... pazienza.

Come ogni buona teoria (si spera), continuo a farla evolvere nel tempo man mano che lavoro con più aziende e parlo con più persone. L'ho usata moltissimo negli ultimi due anni nei miei interventi e nelle mie sessioni di formazione, soprattutto da quando vengo coinvolto in un numero crescente di scenari di governance. Di volta in volta, i problemi principali in cui mi imbatto non sono tanto tecnici, quanto organizzativi. Sì, la sicurezza del cloud presenta MOLTE complessità tecniche, che possono causare e causano violazioni, ma per la mia esperienza le questioni di governance pesano molto più di quelle tecniche.

Una buona governance non può correggere uno zero day, ma una cattiva governance fa sì che all'attaccante non ne serva nemmeno uno.

Il nucleo della teoria non è davvero cambiato, continuo solo a cercare modi migliori per spiegarla. Ho anche deciso di snellirla leggermente. Ecco come la riporto attualmente nelle mie slide:

• Il cloud decentralizza operazioni e infrastruttura
• Ma il cloud unifica tutte le interfacce amministrative
• E mette tutti i portali di amministrazione e le risorse su Internet, protetti da un nome utente e una password

Rispetto alla versione precedente le modifiche sono piccole ma anche grandi:

• Tutte le funzioni di amministrazione e gestione sono unificate in un'unica interfaccia utente che si trova su Internet.
• Protetta da un nome utente, una password e, forse, l'MFA.
• La tecnologia evolve più rapidamente della governance.

Uso ancora l'espressione "niente punti di strozzatura e guardiani" nei miei interventi, ma ho scoperto che è un modo più lungo per dire "decentralizzato". La questione fondamentale è il controllo indipendente dell'intero stack al di fuori dell'infrastruttura centralizzata. Il fatto che un team di sviluppo o applicativo possa costruire e gestire tutta la propria infrastruttura nel proprio ambiente con una semplice carta di credito. Ora, esistono ancora alcune dipendenze e controlli, soprattutto nel data plane o quando occorre ricollegarsi alle reti, ma questo non cambia il punto principale.

Tentare di ricentralizzare completamente funziona raramente.

In secondo luogo, non ho modificato granché l'unificazione delle interfacce amministrative. Per approfondire: abbiamo decentralizzato tutta l'infrastruttura e il controllo a livello di deployment, ma tutti, nel mondo, usano la stessa console web e gli stessi endpoint API.

Gli attaccanti hanno un unico varco verso infiniti bersagli.

Poi ho preso il sotto-punto della prima versione e ne ho fatto il punto 3. Questi portali di amministrazione sono tutti su Internet e, per impostazione predefinita, usano poco più di un nome utente e una password. Anche tutte le risorse sono a una sola impostazione di distanza dall'essere su Internet: basta chiederlo a tutti quei bucket S3 e a quei cluster ElasticSearch.

È davvero così semplice. I team gestiscono le proprie risorse in autonomia. Tutti, in tutto il mondo, usano gli stessi portali web e gli stessi endpoint API. E qualsiasi sprovveduto con le credenziali giuste può curiosare e intervenire sul back end del vostro "datacenter".

Ora la parte assurda: tutto questo era già illustrato nel 2011 nel NIST 800-145, le 2 pagine della NIST Definition of Cloud Computing. Vi si definivano le cinque caratteristiche essenziali del cloud computing:

• Self service on demand
• Ampio accesso alla rete
• Pooling delle risorse
• Elasticità rapida
• Servizio misurato

Prendendo i primi tre punti, otteniamo:

• I team gestiscono le proprie risorse
• È tutto su Internet
• E tutto si basa su pool di risorse condivise

Bene, e quindi che cosa significa tutto questo e che cosa facciamo?

Accettatelo.

Questo è il primo passo. Comprendere il problema e usarlo come lente per elaborare le nostre soluzioni. Come ho scritto di recente nel mio articolo sulla Strong Authorization:

Perché non sono abituati al fatto che tutto sia (potenzialmente) su Internet. L'intero management plane è su Internet, quindi se un attaccante ottiene le credenziali non potete fermarlo con un firewall o bloccando l'accesso a un server.

Partite da qui. Accettate la realtà di base. Che cosa possiamo fare per ridurre quel rischio? Per ridurre quegli attacchi? Credo che la scelta di maggiore impatto sia concentrarsi sull'IAM e sull'intersezione tra governance e IAM. Chi gestisce i permessi? E gli accessi? Quali controlli di sicurezza possono prevenire, rilevare e correggere gli attacchi legati all'IAM? Quali sono i vostri processi relativi all'IAM? I vostri incident responder conoscono a fondo i dettagli dell'IAM dei vostri cloud provider? Usate la JIT/Strong Authorization? Come gestite l'IAM per i collaboratori esterni e i servizi di terze parti?

Iniziate dalla vostra governance e dai vostri processi IAM. Poi scegliete e utilizzate le tecnologie che li supportano. Questo è il modo in assoluto più efficace per migliorare la sicurezza del vostro cloud. Spero davvero di non essere il primo a dirvelo.