Il cloud è sicuro o insicuro? Le “scuole di pensiero” sono, in entrambe le direzioni, ricche di esponenti pronti a sostenere la propria tesi con elementi spesso tutt’altro che opinabili o ambigui. La nostra opinione? Con chi ci schieriamo?
Per noi non c’è niente di più corretto e niente di più sbagliato in entrambe le “correnti”. Vediamo perché.
Se è vero che l’adozione del cloud da parte delle aziende impone riflessioni estese (del resto si parla di migrazione dai sistemi privati ai sistemi di terzi…), dal punto di vista della sicurezza dei dati non è necessariamente una transizione pericolosa, anzi.
In questo processo entrano però in gioco diverse problematiche, tra le quali la governance della compliance aziendale, della security e della data protection, ed essendo il Cloud un paradigma ancora nuovo si fanno i conti con la mancanza di esperienza, soprattutto rispetto agli scenari meno tradizionali. In ultimo ma non di certo meno importante e spesso collegato ai precedenti, c’è la gestione dei costi relativi all’uso del cloud, che non è raro vedere subire disattese e oscillazioni preoccupanti a causa di usi impropri o non ottimizzati da parte dell’azienda stessa ma anche e soprattutto a causa di eventi cybersecurity.
Come abbiamo visto nelle puntate precedenti, il cloud è sia un modello di business che un ambiente che offre servizi di computing, storage e networking. Per comprendere quali sono effettivamente i rischi nell’uso del cloud e stabilire quali possono essere le strategie di protezione e governance è fondamentale innanzitutto comprendere il cloud journey di un’azienda, esaminando gli scenari di adoption del cloud che l’azienda ha scelto di approcciare. Il concetto dal quale è consigliato partire è quello di Shared Responsibility: vediamo di seguito come viene suddivisa tra l’azienda e gli hyperscaler.
Shared Responsibility nei modelli IaaS, SaaS, PaaS
Abbiamo tutti sicuramente visto, in una delle molteplici forme in cui viene presentata, la matrice relativa alla Shared Responsability, nei diversi modelli On-Premises, IaaS, SaaS e PaaS. Fermo restando che è possibile un’adoption ibrida, abilitando più subscription con usi e obiettivi differenti, cosa può aspettarsi l’azienda dal provider, in termini di gestione della sicurezza dei dati?
Possiamo sicuramente affermare che IaaS e SaaS hanno in comune scenari di adoption ormai consolidati, quindi, almeno in ambito security, le riflessioni possono confrontarsi con iniziative, riferimenti ed esperienze ormai mature.
In ambito IaaS, nello specifico, i paradigmi restano simili a quelli da sempre definiti per i Data Center privati, seppur sia indispensabile innalzare al massimo i livelli di diffidenza, in linea con i principi dell’approccio Zero Trust. Quando si parla di IaaS si tocca con mano la transizione tra Private e Public, soprattutto quando l’adoption deriva dal Lift and Shift, l’approccio al cloud più rapido e meno elaborato, ma che nasconde maggiori criticità di sicurezza, sia in termini di tecnologie implementate che di processi applicati.
È chiaro che i Data Center diventano esposti a internet per definizione: ogni utente/entità si può connettere a una molteplicità di servizi con qualsiasi dispositivo, da qualsiasi area geografica e in qualsiasi momento della giornata. Negli scenari IaaS come in nessun altro è fondamentale applicare i principi del least priviledge attraverso segmentazione, regolamentazione dei livelli di accesso, implementazione di motori di ispezione delle connessioni e del traffico, oltre alla protezione dei servizi esposti: pillar fondamentali e nemmeno esclusivi.
Negli scenari SaaS, alcune problematiche per le aziende si semplificano, restando in capo agli hyperscaler, con vantaggi immediati e palesi. Da questo punto di vista, infatti, possiamo affermare che i CSP (Coordinatori Sicurezza Progettazione) effettuano investimenti ben più corposi e implementano strategie di sicurezza sicuramente più efficaci di quelli che un’azienda tipo possa riuscire a implementare con il proprio budget dedicato alla protezione degli asset. Restano comunque in capo alle aziende le iniziative orientate alla gestione dei profili di accesso e le policy di data governance, per citarne due tra le più importanti.
Come abbiamo visto nelle puntate precedenti, lo scenario di adoption più strategico per le aziende è il Refactoring, che prevede la riscrittura delle applicazioni in modalità Cloud Native: è qui che si innestano vere innovazioni. Parlare di Cloud Native Security ci aiuterà anche a comprendere gli scenari PaaS e FaaS (Function as a Service) illustrati nel chart.
Cloud Native Security: il paradigma Left Shift
Abbiamo visto nelle puntate precedenti che il Refactoring in ottica Cloud Native comporta la creazione delle applicazioni basate sui Microservizi. Da monolitiche, le applicazioni diventano composte da micro componenti software indipendenti, che possono essere eseguiti in qualsiasi ambiente, racchiudono tutte le componenti e dipendenze di cui hanno bisogno per svolgere il proprio compito e comunicano tra loro attraverso traffici specifici, nella maggior parte dei casi sfruttando le API che ciascun componente espone. Chi sviluppa software può, quindi, facilmente integrare componenti scritte da altri: un fattore che si lega perfettamente al concetto di open source.
Il buon funzionamento dell’applicazione, la resilienza e le performance sono garantite da un layer di governance: gli orchestrator che gli hyperscaler mettono a disposizione con le componenti PaaS fanno la differenza. Con il modello PaaS gli hyperscaler cercano di facilitare ulteriormente lo sviluppo delle applicazioni, erogando funzionalità FaaS che potremmo annoverare a Container as a Service, perfette quando l’obiettivo è l’esecuzione di una porzione di codice che realizza un compito puntuale e specifico.
Il paradigma del Cloud si è sin da subito distinto per semplicità e velocità sia in caso di prima adoption, sia per update e/o fix, andando a soddisfare l’aspettativa di veloci e frequenti rilasci di funzionalità da parte di chi utilizza le applicazioni. Del resto è con il cloud che ha trovato terreno fertile il modello DevOps.
Garantire sicurezza negli scenari Cloud Native è ciò che ha portato all’affermazione del Shift Left, il paradigma con il quale si sposta l’attenzione a sinistra nelle pipeline di sviluppo e rilascio del software, con l’obiettivo di impedire l’introduzione di vulnerabilità già nelle fasi di scrittura del codice.
Chi si occupa di programmazione ha notato un evidente cambio di mission in termini di coinvolgimento e responsabilizzazione del programmatore in ambito sicurezza. Del resto, riflettendoci, le vulnerabilità in buona parte dei casi derivano da inesattezze introdotte già durante la scrittura del codice.
Negli ambienti Public Cloud, nello specifico, se pensiamo al modo in cui vengono definite le risorse necessarie a un’applicazione, il problema sicurezza è accentuato perché anche la definizione dell’ambiente di Deploy & Run è definito da codice, in linea con i paradigmi dell’Infrastructure as a Code.
Se in un template Infrastructure as a Code non viene implementata una strategia di hardening o addirittura non verifichiamo un’esposizione di secrets, anche in questo caso si presenterà un problema di sicurezza dei dati. Del resto, il codice è presente in repository online… memorizzare lì i dettagli dell’infrastruttura rende più facili le azioni di attacco!
Cloud Security Journey: problematiche e rischi
Probabilmente quasi nessuna azienda ha implementato un cloud journey che prevede un solo e unico modello di adoption, a meno che non sia in una fase di sperimentazione, ma è ormai altamente improbabile. Al contrario, è molto probabile che, anche inconsapevolmente, sia diventata un’azienda multicloud, con l’attivazione di servizi erogati da hyperscaler differenti e con diverse caratteristiche.
E questo senza tenere conto dello Shadow Cloud che spesso può derivare dalle iniziative incontrollate dei propri dipendenti, ma non solo: basti infatti pensare a componenti cloud in uso sulle applicazioni installate on-prem, di cui si potrebbe non avere completa evidenza e consapevolezza dei rischi. Da questo punto di vista, l’azienda deve sicuramente distinguere le varie tipologie di uso del cloud e avere una visibility il più completa possibile, per governare la sicurezza del cloud, ridurre il più possibile lo Shadow Cloud e rispettare eventuali policy aziendali in merito.
È vero che ciascun hyperscaler promuove funzionalità orientate alla governance della cloud security, tuttavia il CISO di un’azienda avrà enorme difficoltà ad avere e soprattutto mantenere aggiornata la fotografia dei rischi con le diverse priorità di intervento, senza dimenticare che gli staff IT dovranno conoscere le funzionalità di assessment e governance di ciascun hyperscaler in dettaglio, considerando che saranno differenti da provider a provider.
Insomma, governare “manualmente” la superficie d’attacco è letteralmente impossibile, considerando che l’azienda non può avere, senza apposita automation:
- contezza di quanti entitlement (asset quali VM o Container o funzioni Serverless, così come utenti, profili, dati, ecc… ha distribuito sugli hyperscaler adottati;
- evidenza di quali flussi di traffico sono attivi e discriminare quali sono leciti e quali no;
- completa visibilità delle vulnerabilità sui vari componenti software.
Il Cloud beneficia di automation, Cloud Security non può che fare altrettanto.
Cloud Native Application Protection Platform (CNAPP)
L’automation in ambito Cloud Security porta il nome di CNAPP (Cloud Native Application Protection Platform), che risponde all’esigenza di gestire in maniera unificata le problematiche di security, cybersecurity e compliance in ambiente multicloud, con una visibility completa sui rischi e sulle priorità di intervento, abbracciando di fatto tutti gli scenari di adoption.
Le piattaforme CNAPP hanno in comune le funzionalità di:
– Risk Prevention, per evitare che rischi e misconfiguration nelle fasi di Build possano entrare in produzione;
– Visibility & Control, mediante monitoraggio continuo delle risorse in cloud;
– Runtime Protection, dedicate alla protezione real time dei servizi esposti.
Queste funzionalità garantiscono protezione sia per gli aspetti infrastrutturali nel caso di applicazioni in essere che in tutte le fasi di Build, Deploy e Run nel caso di refactoring.
Sarà interessante nelle prossime puntate entrare nel dettaglio delle funzionalità che queste piattaforme mettono a disposizione per rendere il percorso di Cloud Security più easy e smart. Può sembrare che l’adoption del cloud complichi la governance della security aziendale; in realtà oggi esistono diverse iniziative, best practices ed esperienze dalle quali trarre spunto per mettere in sicurezza i dati. E poi del resto… chi potrà mai fare a meno del cloud?
Fonte immagini:
wmware.com
dgtlinfra.com
