Public cloud e security. La terra di mezzo della responsabilità condivisa

Modelli e shared responsibility alla prova del mercato. La migrazione in cloud non è mai completamente trasparente dal punto di vista della sicurezza. Meglio definire confini e contenuti subito e senza ambiguità, prima di migrare dati e applicazioni

Altri tempi, quando andare sul cloud produceva di norma la battuta: «E la sicurezza»? Oggi, il refrain pare logoratosi grazie all’azione congiunta delle strategie del marketing e della maggiore dose di maturità di chi consuma cloud. L’impressione è che il cloud faccia meno paura. O perlomeno, si è molto più riluttanti ad associarlo a sentimenti negativi. «Le problematiche di sicurezza relativamente al cloud vengono citate in misura via via decrescente» – conferma a Data Manager Fabio Rizzotto, associate VP, head of research and consulting di IDC Italia. Già negli ultimi tre anni – «la percentuale di aziende europee che ha rallentato i processi di migrazione in cloud a causa di timori per la sicurezza è scesa dal 40 al 28 per cento». I servizi basati su cloud stanno rivoluzionando i modelli di distribuzione dei sistemi IT. Da un lato i cloud provider hanno dimostrato che i loro sistemi possono superare soluzioni onsite in termini di efficacia, efficienza, e sicurezza. Dall’altro Business e IT sembrano avere preso le misure dei rischi che si corrono sulla nuvola. Sarà anche per questo che la prassi corrente è decidere di andare in cloud e – solo dopo – affrontare la questione tecnologica. Peccato però che rincorrere non è mai la strategia migliore. Come insegnava la proverbiale nonna, mettere le “toppe” quando il “buco” si è allargato troppo non funziona.

L’ormai consolidata casistica di aziende che via via nel tempo si sono dimenticate di piazzare un firewall è lì a dimostrarlo. «Dopo la migrazione – infatti – le problematiche di sicurezza si mescolano ad altri aspetti della relazione e della gestione del servizio» – spiega Rizzotto. Aspetti della relazione che tutti i principali cloud provider cercano di appianare da subito, fornendo ai potenziali clienti la documentazione relativa ai rispettivi shared responsibility models, nuove fattispecie contrattuali, per i servizi cloud che si stanno sperimentando sul mercato, articolate – come si legge nello studio dedicato al cloud edito da CLUSIT – in tre macrocomponenti: attori responsabili, domini di controllo, livello di maturità. Il contratto prevede la condivisione fra fornitore e cliente di ruoli e responsabilità rispettivamente nella erogazione e nell’accesso ai servizi. Semplificando al massimo, il provider è responsabile della security del cloud, mentre il cliente è responsabile della security nel cloud. Con Azure, Microsoft sottolinea l’importanza per chi migra sul cloud di comprendere il modello di responsabilità condivisa. “I fornitori di servizi in cloud – si legge nel documento – rappresentano un partner importante per quanto riguarda sicurezza e compliance, ma questi innegabili vantaggi non assolvono il cliente dalla protezione di user, applicazioni e offerta di servizi”.

Detto in altri termini, cliente e fornitore sono titolari di specifici oneri a cui adempiere. Ed entrambi si impegnano a collaborare per raggiungere gli obiettivi di security in cloud. Certo, ci sono responsabilità di sicurezza che possono essere gestite solo dal cliente. Per esempio, la sicurezza dei device utilizzati per connettersi al cloud. Mentre altre sono indubbiamente in carico al fornitore di servizi, come restringere al solo personale autorizzato l’accesso fisico al datacenter. Altre aree della security – invece – sono più soggette a incomprensioni o comunque a difficoltà di attribuzione a seconda del servizio acquistato (IaaS, PaaS, SaaS). «Le “aree grigie” sono proprie di ogni contratto tra due o più parti, sia che si parli di cloud computing, outsourcing o di tutte le altre forme di contratto note nell’era pre-cloud» – afferma Stefano Testoni, senior cyber security expert di Sartec. E le “aree grigie” dipendono – «non solo dal tipo di servizio acquistato, ma anche dallo specifico fornitore, dal momento storico, dalle tecnologie offerte e da molti altri fattori». Meglio perciò avere subito chiaro che la difficolta di attribuzione è un rischio e come tale deve essere gestito. In questo senso, l’aspetto più importante da considerare in tema di responsabilità riguarda la scelta del corretto cloud provider. «Una delle poche responsabilità che il fruitore del servizio non può trascurare poiché spetta unicamente a lui» – avverte Testoni. «Molte delle incomprensioni e delle complessità di relazione tra cloud provider e cliente derivano proprio dalla scarsa due diligence posta in questa primissima fase proprio dal cliente».

LA LISTA DELLE COSE DA FARE

Identificata una short list di provider in grado di fornire il servizio cercato, si tratta di stabilire quale grado di responsabilità nella gestione della sicurezza trasferire al provider. Semplificando al massimo, molto dipende dalla scelta del tipo di servizio. Ai due estremi, troveremo da una parte il modello IaaS, dove le maggiori responsabilità sono in capo all’utilizzatore, bilanciate dalla possibilità di personalizzare al massimo il servizio erogato; dall’altra il modello SaaS, nel quale il cliente è “l’ospite” di una piattaforma gestita quasi totalmente dal provider. Naturalmente, lungo questo asse le sfumature possibili assumono una valenza importante. «Ogni modello di servizio presenta specifiche aree grigie» – continua Testoni. «Per esempio, nel modello IaaS, la sicurezza nelle comunicazioni di rete è un aspetto di frontiera. L’utilizzatore si aspetta che il traffico sia reso sicuro a livello di infrastruttura del provider, utilizzando tecnologie di cifratura o di tunnelling».

Ma non sempre questo è vero. «L’architettura del provider potrebbe non essere dotata di tali features oppure, in specifici punti della rete, il traffico dati potrebbe non essere adeguatamente protetto, consentendo a un malintenzionato di vedere i dati in transito del cliente finale» – spiega Testoni. Pertanto, sarebbe buona pratica non dare mai per scontata la presa in carico della security da parte del fornitore. «A meno che il provider non dichiari espressamente un servizio di sicurezza, questo è da considerarsi come non incluso» – mette in guardia Testoni. Inoltre, è sempre consigliabile adottare un approccio di defence in depth (DiD), valutando la possibilità di adottare misure di sicurezza aggiuntive. «Riprendendo l’esempio della rete, nulla vieta al cliente di adottare cifratura end-to-end per comunicazioni con alti requisiti di confidenzialità» – spiega Testoni.

Pur in un quadro di sostanziale uniformità, ogni cloud provider adotta policy proprie per quanto riguarda l’attribuzione delle responsabilità di sicurezza, che possono scostarsi anche in maniera significativa da quelle dei concorrenti. In pratica, analizzare nel dettaglio il modello proposto non è mai una perdita di tempo. Meglio mettere subito sul tavolo dubbi e perplessità che trovarsi a rincorrere dopo. Inutile dire che il tutto sarà più agevole in presenza di documentazione chiara e priva di carenze informative. E questo significa che tutto ciò che è essenziale è stato messo nero su bianco nel contratto che si stipula con il fornitore di servizi cloud. Ma l’esperienza insegna che quel “tutto” nella vita reale è così denso e complesso che difficilmente potrà essere davvero esplicito e ricompreso. «I modelli di shared responsibility sono di recente creazione e ancora molto immaturi» – afferma Testoni. «Forniscono indicazioni di massima riguardo le responsabilità ma ci vorrà tempo perché vengano raffinati». In genere, i contratti tendono a essere standard, con pochi – o addirittura inesistenti – margini di negoziazione. «Spesso sono scritti dal cloud provider che ha il problema di essere efficiente in tutte le fasi del ciclo di vita di un servizio, fin dalla fase della contrattazione. In particolare, per i contratti di entità medio-piccola» – conferma Alessandro Vallega, membro del consiglio direttivo di CLUSIT con responsabilità sul cloud e i gruppi di lavoro.

D’altro canto – «è proprio l’efficienza, legata alla multitenancy che permette di ridurre i costi per il fornitore e i prezzi per il cliente». La completa trasparenza con il cliente non è un’opzione percorribile per il cloud provider. «Una certa asimmetria informativa è fisiologica in qualsiasi relazione di sourcing e di esternalizzazione di risorse e gestione ICT» – ammette anche Fabio Rizzotto di IDC Italia. «Altri fattori entrano in gioco. A partire dagli elementi formali come il contratto fino a quelli intangibili come trust, percezioni, stili di gestione/comunicazione e così via». Siamo di fronte al filo spinato rappresentato dai piccoli/grandi segreti industriali off-limits per tutti a partire dalla concorrenza, che – tuttavia – rispetto alle misure di sicurezza, si possono facilmente chiarire – «pensando agli aspetti tecnici sottesi al dominio di controllo» – sostiene Vallega di CLUSIT. «In caso di dubbio, è meglio chiedere e ottenere risposta scritta. Forse, non tutto potrà essere appianato ma probabilmente prenderà forma una conversazione istruttiva con il provider». In tutti i casi, una volta stabilito che un evento avverso è attribuibile al cloud provider sulla base dei modelli di responsabilità, è fondamentale identificare quali sono i parametri definiti dallo SLA e le penali associate a tale responsabilità. «Garantire una sicurezza totale è facile, soprattutto se non ci sono penali significative correlate» – sottolinea Stefano Testoni di Sartec. Nella partita a scacchi della “shared responsibility”, il meno che si possa dire è che il cloud provider parte con il vantaggio della prima mossa.

RESPONSABILITÀ CONDIVISA DA CHI?

Le responsabilità dei cloud provider dipendono dal tipo specifico di servizio cloud proposto e vanno da modelli infrastructure as a service (IaaS), a modelli software as a service (SaaS), con le platform as a service (PaaS) che occupano una posizione intermedia. Gli analisti concordano sul fatto che è essenziale che le aziende comprendano pienamente i modelli di responsabilità condivisa per implementare le misure di sicurezza necessarie. Se i cloud provider offrono significativi vantaggi in termini di semplicità, efficienza, scalabilità e riduzione dei costi insieme a un aumento delle garanzie di affidabilità e sicurezza, le più grandi vulnerabilità derivano ancora da errori umani, come mettono in evidenza gli esperti di F-Secure. Ogni area della security contrattualmente è sempre attribuibile a una delle due parti. Nella pratica però i problemi sono spesso in agguato. Anche se non è detto che siano per forza insormontabili.

In sintesi possiamo dire che con il modello IaaS: l’impresa è da sola, più o meno. Con il modello PaaS, i CIO e gli IT manager possono avere qualche grattacapo in meno. Il modello SaaS è il più semplice e in molti casi anche il più sicuro. Partiamo dalla sicurezza di rete. In un ambiente IaaS, è il cloud provider a essere responsabile dell’infrastruttura di rete e quindi della sua sicurezza. Essa incorpora quella fisica del data center (server, router, switch…), delle reti logiche create per connettere le virtual machine, e di queste reti a internet. «Con questo modello di servizio la sicurezza della rete deve essere garantita fino alla macchina virtuale ma da quel punto in poi diventa di responsabilità del cliente» – conferma Alessandro Vallega di CLUSIT. «Detto questo, il cliente dispone di strumenti moderni di configurazione come quelli che implementano la software defined network che facilita l’amministrazione, la configurazione e il monitoraggio della rete». Non solo. Nulla impedisce al cliente di adottare metodi di sicurezza aggiuntivi. «Sappiamo che gli hacker distribuiscono contenuti piratati utilizzando seedbox – un server fisico o virtuale noleggiato e dotato di software di distribuzione per proteggere i dati e impedirne l’ispezione da parte del provider o delle Forze dell’Ordine. Gli stessi hacker adottano anche tecniche di full disk encryption (FDE) per l’archiviazione e di cifratura del canale end-to-end per evitarne l’intercettazione via rete» – spiega Stefano Testoni di Sartec. «Tecniche che possono essere adottate anche da chi si difende».

Un data center cloud può diventare bersaglio del crimine informatico. Eppure, di rado la sicurezza fisica del data center in cloud diventa parte integrante dei criteri di scelta del provider da parte dell’azienda. Se è sempre opportuno valutare i rischi e le misure di sicurezza offerte prima di acquistare un certo servizio, richiedere un audit prima di acquistarli (possibile con un cloud managed) è molto più difficile con il public cloud. «Budget permettendo, preferisco scegliere un’automobile di un certo costruttore poiché segue i più rigidi standard di sicurezza in grado di proteggermi in caso di incidente» – afferma Testoni. «Non mi verrebbe mai in mente di comprare una automobile a caso e poi farci un audit di sicurezza per capire quanto è sicura. Ma se è il budget che guida la scelta, è quasi certo che non acquisterò la macchina del costruttore attento alla sicurezza». Tuttavia, bisogna dire che nella decisione finale oltre che le ragioni economiche, anche la necessità di stabilire un rapporto più diretto e fiduciario per quanto riguarda applicazioni e dati particolarmente sensibili, appoggiandosi a un provider nazionale o semplicemente più piccolo, è una opzione almeno sulla carta che potrebbe avere il suo peso. Salvo poi constatare che l’offerta non è ancora così ampia per coprire esigenze più specifiche.

Data classification, sicurezza del dato ed endpoint protection impiegati dall’azienda per accedere ai dati sul cloud sono sempre in carico al cliente. Anche la sicurezza del software che gira sulle macchine è in genere responsabilità del cliente. Unica eccezione – negli ambienti SaaS – l’aggiornamento e il patching che sono in carico al provider. Anche nel caso in cui si utilizzi una soluzione di management dei device basata sul cloud come Microsoft Intune, è ancora l’azienda utente a essere responsabile della definizione dei requisiti di sicurezza dei device, anche se il cloud provider è responsabile del rafforzamento dei requisiti configurabili sull’MDM. In tema di data classification, il processo con il quale si organizzano i dati in categorie consentendo all’azienda di applicare livelli di sicurezza differenti a seconda delle tipologie di dati, la responsabilità è sempre in carico al cliente. Il cloud provider non può sapere quali dati dell’azienda necessitano di maggior protezione. Può – però – mettere a disposizione degli strumenti per agevolarne il processo. Microsoft – per esempio – fornisce Azure Information Protection, un tool che consente di definire e implementare gli schemi di classificazione dei propri dati. Salvo poi ribadire – a scanso di equivoci – che ladata classification e l’accountability sono sempre responsabilità del cliente, qualunque sia il computing model (IaaS/SaaS/PaaS?) adottato.

RESPONSABILITÀ ALLA PROVA DEI FATTI

Per raggiungere il livello di sicurezza ottimale conforme al tipo di organizzazione e di industry di appartenenza e al tipo di asset richiesti, è necessario selezionare il tipo appropriato di servizio e comprendere gli oneri derivanti dal modello di responsabilità condivisa di quel servizio. Scelto il provider e ridimensionata l’infrastruttura in house, per l’azienda – parliamo soprattutto dell’IT – si tratta di accettare che su alcune decisioni non si abbia più voce in capitolo. In genere, per quanto riguarda la scelta dell’hardware, questo non rappresenta un problema. Alcune di queste “sottrazioni” però sono meno scontate di altre. Business e IT non hanno difficoltà ad ammettere che i cloud provider sono meglio equipaggiati per far fronte alle questioni di sicurezza, più preparati cioè a proteggere dati e applicazioni di quanto potrebbe fare il 99,99 delle aziende. Ciò premesso, non tutti però si sentono a loro agio quando si tratta di lasciare ad altri le redini su risorse IT e di business.

«La perdita di controllo è una prospettiva che fa paura» – afferma Stefano Testoni di Sartec. «Tenersi i dati in “casa” permette di averne il pieno controllo e quindi poter adottare misure di protezione personalizzate dove e quando necessario. Demandare a un terzo la gestione della sicurezza dei dati e dei processi aziendali non è sempre una prospettiva accettabile» – oppure possibile, se i vincoli normativi – a cui una specifica industry può essere soggetta – non lo consentono. Soprattutto, se non si dispone di una contrattualistica in grado di regolamentare il rapporto tra le parti, ruoli e responsabilità, oneri e doveri. «I cloud provider dovrebbero essere maggiormente accomodanti, trasparenti e flessibili su questo punto» – osserva Testoni. Inoltre, un supporto consulenziale più presente – «aiuterebbe ad acquistare maggiore fiducia da parte degli acquirenti». A loro volta i clienti dovrebbero concentrarsi sulle azioni necessarie per assicurare che le interrelazioni, implicazioni, modalità di utilizzo e i nuovi confini del “proprio IT” siano gestiti al meglio. Un ambito nel quale – come rileva Fabio Rizzotto di IDC Italia – «possono entrare in gioco relazioni anche con altri attori dell’ampio ecosistema della sicurezza in cloud». La perdita di governo dei dati è un tema costantemente sotto la lente del management.

Proprio per questo, molte aziende valutano la possibilità di adottare soluzioni di private cloud per gestire l’obsolescenza dei sistemi e sicurezza e al contempo proteggere i dati al proprio interno. In scenari che diventano inevitabilmente “multicloud” o cloud molteplici – le decisioni di “migration” così come di “repatriation” – ovvero di marcia indietro verso ambienti “non cloud-native” o verso altri cloud provider – spettano sempre all’azienda» – osserva Rizzotto. «Sebbene questo non sia un vero e proprio strumento di controllo, è un fattore importante nell’ambito degli elementi di forza che le aziende mantengono, pur nella complessità dei processi che si sedimentano attorno a ogni servizio». Peraltro – secondo i dati in possesso di IDC – la sicurezza (insieme ad altri fattori quali performance, costi, basso controllo…) occupa il primo posto tra i “repatriation drivers” citati dalle aziende che abbandonano i servizi di public cloud.

I servizi basati su cloud hanno cambiato il modo di intendere la sicurezza informatica. I fornitori cloud hanno dimostrato di poter superare le soluzioni on premise in termini di efficacia e sicurezza. Questo passaggio però va gestito. La gestione condivisa delle responsabilità di sicurezza necessita di un cambio di mentalità. Abbinato a uno sforzo di pianificazione prima e monitoraggio continuo poi. Affidare i sistemi IT aziendali a un partner che fornisce cloud comporta per organizzazioni e aziende una migliore focalizzazione sul loro business principale. Ma questo non significa che le aziende non hanno più responsabilità. Non ci siamo ancora arrivati. Per ora, le organizzazioni devono adempiere ai loro obblighi derivanti dal modello di responsabilità condivisa al fine di restare protetti. Migrare dati e applicazioni in cloud non equivale a trasferire tutti gli oneri di sicurezza in capo al cloud provider. Nel cloud, l’azienda deve continuare a esercitare il controllo su alcuni aspetti relativi alla messa in sicurezza delle risorse IT. Controllo esercitato in parte dallo stesso cloud provider. Un cambio di paradigma che richiede uno sforzo di adattamento. Anche perché nel tempo assisteremo sempre di più a uno spostamento sulle piattaforme IaaS e il multicloud diventerà la realtà. E di conseguenza, anche la responsabilità degli incidenti di sicurezza sul cloud sempre di più saranno a carico degli utilizzatori del cloud e non dei provider.

Per uscire dalle sabbie mobili dell’incertezza e dell’ambiguità – come suggerisce Stefano Testoni di Sartec – bisognerebbe considerare l’utilizzatore del cloud computing come un utente finale, a digiuno di competenze tecnologiche specifiche e che quindi necessita di essere guidato verso la salvaguardia dei propri dati e sistemi. Da questo punto di vista, le banche hanno molta esperienza, perché da anni trattano problemi di attribuzione di responsabilità. «Se da un lato è responsabilità dell’utilizzatore del servizio gestire correttamente i propri strumenti e i propri dati, è anche vero che i cloud provider dovrebbero aiutare l’utilizzatore a rendere sicuri i propri sistemi e dati» – perché ne va anche della loro immagine e reputazione. «Un processo – prosegue Testoni – che non si fa con clausole contrattuali di decine di pagine scritte in legalese, ma con pochi e semplici punti, rendendo le soluzioni di sicurezza veramente by default e non come features aggiuntive e di complesso utilizzo». Istanza che non è rimasta lettera morta. Al contrario, la sensazione è che sul tema maturi giorno per giorno una maggiore sensibilità. «Anche perché i cloud provider preferiscono fin dal principio evitare l’ambiguità, cercando di coinvolgere e informare adeguatamente il cliente» – conclude Alessandro Vallega di CLUSIT. Perché un eventuale incidente di sicurezza – «anche quando non ricade nella loro responsabilità, li danneggerebbe comunque».