L’introduzione del General Data Protection Regulation (GDPR) UE 2016/679, entrato in vigore a maggio 2016 e divenuto definitivamente applicabile ed operativo in tutti stati membri Ue dal 25 maggio 2018, ha cambiato l’impostazione normativa europea e la vision in materia di gestione e protezione dei dati ai fini della privacy.
Si è passati da una visione proprietaria e localizzata del dato, ad un approccio che ne garantisce sempre la libera circolazione purché sicura e protetta, rafforzando i diritti dell’interessato, il quale deve poter sapere se e quando i suoi dati sono usati e come per tutelarsi dai rischi insiti nel trattamento dei dati.
Contemporaneamente il Regolamento è intervenuto sulla responsabilizzazione (accountability) di chi gestisce i dati demandando all’autonomia dei titolari e responsabili del trattamento, per le decisioni, le modalità e i limiti del trattamento dei dati ma anche la loro protezione, secondo misure adeguate alla propria organizzazione e basate su valutazioni risk based.
La data protection è quindi un tema centrale del GDPR che tratta le misure di sicurezza nell’articolo 5 e quelle minime e tecniche nell’articolo 32. Come conseguenza del GDPR tutte le organizzazioni hanno dovuto ripensare la data protection nei loro ambienti digitali siano essi datacenter locali o distribuiti in aree delocalizzate fra loro.
Dall’introduzione del cloud computing e con la crescita delle minacce informatiche e degli attacchi perpetrati anche a questo paradigma e modello di servizi digitali, è necessario ripensare del tutto alla strategia di protezione dei dati considerandoli come un fulcro attorno al quale garantire la sicurezza informatica.
Per capire meglio ogni aspetto legato al cloud, dalle minacce e i rischi, al corretto approccio alla protezione, abbiamo chiesto alcune indicazioni a Rodolfo Rotondo, Senior business solution strategist di VMware per accompagnarci nel viaggio alla protezione dei dati su cloud.
Indice degli argomenti
Data protection, minacce e rischi del cloud computing
Qualsiasi nuova tecnologia apporta benefici per i quali è stata introdotta e qualche rischio per l’estensione della superficie di attacco che rappresenta.
Anche il cloud non sfugge a queste logiche e dalla sua introduzione in poi, ne sono stati studiati i tassi di adozione contemporaneamente all’aumento delle minacce ed effrazioni digitali che pure si sono verificati e che oggi sono soggetti ad aumenti significativi.
Un programma di sicurezza cloud maturo deve garantire non solo data protection ma anche la gestione della configurazione e degli accessi perché le dinamiche degli attacchi hanno mostrato che sono proprio questi gli elementi maggiormente sfruttati per effettuare frodi e sottrarre dati e informazioni dal Cloud (errate configurazioni e mancata rimozione delle credenziali di default degli accessi).
Tutte le precauzioni citate devono essere assicurate senza rallentare l’innovazione ed evitando quell’ingessamento tipico dell’introduzione di elementi di security senza ripensare il processo. A fine 2019 Gartner aveva anticipato per il 2020 che almeno il 95% delle violazioni del cloud sarebbe stato causato da errata configurazione del cliente, credenziali mal gestite o furto di informazioni privilegiate, ovvero da mancate attività di sicurezza lato cliente piuttosto che solo da vulnerabilità del cloud provider (Fonte: Is the cloud secure?).
Rodolfo Rotondo chiarisce che “le cattive configurazioni sono l’inizio di una effrazione ma è mediante i movimenti laterali che i criminali si appropriano di un asset. Come VMware abbiamo un osservatorio sulla condizione delle configurazioni e ci risultano circa 6.9 milioni di errate configurazioni di account su cloud. In realtà si verificano errori comuni: negli object storage non è abilitato l’encription da subito, quando si fanno copie dei volumi disco queste copie non sono criptate sui volumi di arrivo, le policy di Identity Access Management comprendono spesso privilegi illimitati quando invece il least privilege dovrebbe essere la policy di default. Anche la multifactor authentication non è di default e la porta 22 risulta spesso aperta sull’internet pubblico e quindi aperto ad una intrusione”
In effetti da queste evidenze si comprende “non impostare policy restrittive di default” equivale a “lasciare le porte aperte” agli intrusi nel vero senso della parola.
Ma se si cercano le cause all’origine di questa situazione vi sono almeno altre tre concause/sfide secondo Rodolfo Rotondo: “in relazione allo sviluppo per il Cloud si adotta l’approccio DevOps per il continuous improvement e quindi gli sviluppatori cambiano e modificano il codice centinaia di volte al giorno; dunque il problema è che con questo approccio non si ha il tempo di capire gli impatti su policy e politiche di sicurezza.
Come secondo punto è necessario osservare che il personale non è sempre all’altezza perché trovare ingegneri o informatici esperti di sicurezza non è facile. A riprova posso citare il “2020 Cybersecurity Outlook Report” pubblicato da VMware e Carbon Black, secondo cui in tema di skill gap e divario sui talenti, il 79% degli intervistati trova “molto impegnativo” o “estremamente impegnativo” trovare il giusto talento per la sicurezza.
Come terzo punto è necessario prendere consapevolezza che gli approcci di sicurezza tradizionale non siano più appropriati, non solo nell’ambito cloud. La presenza di centinaia di soluzioni di security crea un disallineamento dei controlli di sicurezza, la stessa virtualizzazione non permette di provvedere completamente alle esigenze di sicurezza, dati i tempi rapidi di creazione e cancellazione di risorse. Quindi aumenta il perimetro di attacco. Ad accrescerlo ulteriormente anche l’insieme dei lavoratori in smart working che sono diventati un target ancora più ambito”.
Garantire la data protection prima, durante e dopo la trasformazione in cloud
Dunque, per garantire la protezione dei dati in ambito Cloud, la ricetta suggerita dal Business Strategist di VMware passa per tre step: cultura, formazione e strumenti appropriati.
È necessario come primo passo muovere verso il DevSecOps, quindi serve uno strumento di tutoring per gli sviluppatori, già a livello di codice. VMware in proposito ha acquisito Octarine per dotarsi di sicurezza intrinseca alle applicazioni containerizzate in esecuzione su Kubernetes.
In sostanza si implementa una sicurezza continuativa nel ciclo di sviluppo, fra la secure code review, l’analisi di vulnerabilità, e il controllo configurazioni per realizzare operativamente la security by design e by default, per semplificare l’adozione del DevSecOps e permettere agli ambienti nativi del cloud di essere intrinsecamente sicuri, dalla fase di sviluppo al runtime.
Il secondo passo consiste nella formazione al personale sia per le competenze DevOps sia per la verticalizzazione alla sicurezza.
Il risultato è una migliore collaborazione fra team di sviluppo con una base culturale comune. Infine, ci si deve dotare di strumenti appropriati: per porre la giusta attenzione ai contenuti di log e api che cambiano di contino, sono necessari strumenti che posano aggregare dati e correlarli anche tenendo conto della compliance (Es. PCI-DSS, GDPR, PSD2) con verifiche sulle configurazioni di default.
Qualora l’azienda non abbia già asset in cloud ma voglia trasformare la propria infrastruttura, verso quel paradigma, dovrebbe seguire due approcci tattici guidati dall’IT: un primo approccio è legato allo spegnimento di un qualsiasi datacenter perché implica considerazioni riguardanti la gestione del licensing fra capex e opex, la valutazione dei casi d’uso più frequenti e naturalmente la valutazione dei picchi di carico.
Un approccio più legato al business invece è maggiormente correlato alle applicazioni che abilitano il business.
Quindi, in generale, serve una strategia per scegliere applicazioni sul cloud ma principalmente è necessario capire di cosa si ha bisogno: se solo effettuare scelte innovative o se modernizzare quanto già si possiede.
In VMware possiamo supportare questa trasformazione con i pivotal labs che fanno parte delle business unit VMware per la trasformazione dell’esistente. Questi labs sono nati per modernizzare le app legacy, per analizzare la portabilità di codice e delle applicazioni nel processo di trasformazione. Tipicamente costruiscono un business case “on purpose” considerando nella pianificazione degli obiettivi finali, anche fasi di tipo “quick win” o milestones a maggior RoI (Return of Investment).
Secondo la strategia decisa dal committente è possibile aumentare la percentuale di applicazioni in SaaS, diminuendo le porzioni su mainframe, anche se osserviamo come siano ancora molte le legacy app esistenti e mantenute in vita.
L’altro step fondamentale del processo di trasformazione riguarda proprio l’ambito del dato, per valorizzarlo ma anche per proteggerne la RID (Riservatezza, Integrità e Disponibilità n.d.r.) in tutte le condizioni (dato fermo o in movimento n.d.r.).
A questo proposito Rodolfo Rotondo ci spiega il Six Sevens model legato alla gestione del dato in ambito multicloud. Questo modello consente di analizzare il generale flusso di processo del dato secondo le sei componenti di: descrizione, partizionamento, localizzazione, connettività e accesso, elaborazione e distruzione.
Una volta individuata la granularità del dato da analizzare, si comprende la sua natura (dato necessario o toxic data), la data gravity, ovvero tutte le caratteristiche legate al dato per ogni ambiente in cui risiede, le esigenze di protezione, e di scalabilità delle applicazioni ma anche i costi legati al dato, gli impatti in caso della perdita, e quelli legati alle modalità e costi di distruzione del dato al termine del ciclo di vita.
Questa valutazione a sei step deve essere ripetuta per ogni ambiente cloud in cui il dato può risiedere o transitare.
Per ogni ambiente la seconda dimensione di analisi consta di sette costituenti: classificazione del dato, governance, osservabilità (ovvero come controllo il dato n.d.r.), chi accede al dato (la “networking” del dato n.d.r.), la parte di piattaforma dove il dato atterra, (Paas), la sicurezza del dato e la componente di storage del dato.
La matrice corrispondente permette di comprendere le esigenze e di considerare il modello e tipo di cloud più appropriato per la risoluzione. Infine, se l’azienda già adotta risorse in cloud, si può applicare il Six Sevens Model ai dati in Cloud verificando eventuali gap ed eventualmente inserire le soluzioni prescelte nella trasformazione pianificata.
Qualsiasi sia l’infrastruttura di partenza (a silos o altro), l’approccio data center based consente di restare consistenti e coerenti nel trattamento del dato a livello di operation, pur spaziando fra ambienti multicloud pubblici e/o privati.
Infatti, rompere i silos durante la trasformazione potrebbe comportare rischi di perdita dei dati o di duplicazione inutile con costi correlati anche ingenti.
L’approccio centrato sul dato è cruciale anche in caso di adozione dell’edge computing o del fog computing perché alcune applicazioni di questi ambiti richiedono estrema efficienza operativa, ovvero zero latenza e quindi tutta la gestione sicura del dato fin dalla sua creazione, comporta un sistema più performante ed efficiente.
Protezione dei dati anche mediante le garanzie contrattuali
Un ultimo elemento riguarda l’attenzione alle garanzie contrattuali mediante SLA e penali come accorgimento per impegnare e responsabilizzare il Cloud Provider nel contribuire alla tutela del dato ed alla sua compliance normativa.
In questo particolare frangente Rodolfo Rotondo suggerisce di: approfondire la separazione dei ruoli mediante studio del modello di responsabilità condivisa emesso dalla Cloud Security Alliance (CSA); consultare lo STAR Registry (un registro di Cloud provider detenuto dalla CSA e composto da Coloro che si sono auto-valutati secondo il modello STAR – Security Trust Assurance and Risk. n.d.r.); studiare e verificare il contratto con il Cloud Provider per controllare le policy di security, le esigenze di audit, la componente delle modifiche contrattuali, per capire l’impatto sul modello di governance del dato e per tutte le normative, nomenclature indicate e le certificazioni del Cloud Provider.
Qualora ci siano elementi di rischio, valutare anche la possibilità di trasferire il rischio mediante assicurazione.
Contributo editoriale sviluppato in collaborazione con VMware
