La fase due del mercato aspetta la grande scossa. Accelera la corsa all’integrazione tra tecnologie e sistemi. Da operatività, gestione e ownership, le sfide maggiori per l’IT. Il cantiere aperto della security e il nodo delle API ancora tutto da sciogliere
Per una parte dei manager italiani potenzialità e criticità del cloud ibrido non sono più un segreto. Parola di IDC. «CIO e IT manager sono ben consci che il cloud in modalità ibrida consente loro di creare un ambiente elastico, flessibile e scalabile, in grado di gestire in modo automatico o manuale picchi di lavoro stagionali» – ci dice Sergio Patano, associate research director di IDC Italia.
«Inoltre, in un contesto in cui l’IT aziendale è ridotto all’osso e agli IT manager viene chiesto un sempre maggior coinvolgimento nello sviluppo del business, demandare la gestione e l’aggiornamento di una parte dell’infrastruttura al service provider è sicuramente un vantaggio». Costi a parte, l’aspetto in assoluto più dibattuto, la sicurezza, rimane l’altro argomento divisivo tra i decisori aziendali. «Da una parte rappresenta un driver verso l’adozione del cloud, anche in modalità ibrida, in quanto garantisce un livello di aggiornamento e sofisticazione irraggiungibile dagli investimenti della maggior parte delle aziende. Dall’altra però continua a essere un freno all’adozione del cloud ibrido – continua Patano – in termini di ownership e governance dei processi, in gran parte nelle mani dei service provider».
ORCHESTRATORI DI AFFIDABILITÀ
Il successo del cloud ibrido passa dall’integrazione delle tecnologie anche di sicurezza tra sistemi on premise e nel cloud pubblico. Orchestrator, connettori che abilitano l’infrastruttura on premises a interfacciarsi con quella in cloud; API (application programming interfaces); autenticazione; networking evoluto. Ognuna di queste tecnologie presenta aspetti di operatività, gestione e ownership nei confronti dei fornitori di servizi cloud da considerare attentamente.
Una delle difficoltà maggiori per le aziende è la complessità alimentata dalla proliferazione e dalla frammentazione degli strumenti di sicurezza. Accentuata se possibile nelle architetture multicloud ibride. Ambienti nei quali le soluzioni tradizionali, basate sulla centralizzazione degli eventi, sono difficilmente integrabili. «Uno dei maggiori punti deboli delle architetture cloud ibride è rappresentato dall’oggettiva difficoltà a integrare, dal punto di vista della gestione degli incidenti di sicurezza, dati e processi di sicurezza degli ambienti cloud» – spiega Gianni Rossi, sales manager di Gruppo Daman. «Spesso le informazioni devono essere gestite con strumenti diversi da quelli adottati per gli ambienti on premise. Il risultato è la proliferazione di strumenti e interfacce cyber. Un limite – continua Rossi – superabile con l’aggiunta di funzionalità di orchestrazione che favoriscano i processi di integrazione e capaci di valorizzare e armonizzare le attività degli specialisti di sicurezza, anche dal punto di vista organizzativo».
L’orchestration layer è lo strato di software che gestisce tutte le risorse disponibili nei due ambienti secondo determinati criteri (coerenza, uniformità, ottimizzazione) e una serie di regole, comprese quelle relative alla gestione della riservatezza e della disponibilità dei servizi, interfacciandosi attraverso apposite API con tanti attori differenti, quanti sono i cloud provider e soprattutto le loro tecnologie con le quali si opera. L’orchestrator automatizza decisioni, come accendere un certo numero di server nel cloud, pubblico o privato, oppure spostare dove si renda necessario un pool di macchine virtuali. Strumenti che in prospettiva consentiranno ai responsabili IT di far evolvere le architetture cloud ibride. Trasformando – come già si ipotizza – l’infrastruttura sottostante in una sorta di utility modellata e controllata dell’intelligenza del software. Al momento però queste tecnologie sono ancora lontane dalla piena maturità. Spesso open source e soggetti a continui aggiornamenti, gli orchestrator – non sempre adeguatamente supportati – sono ancora lontani dalla stabilità raggiunta da altri middleware. Come dimostra la possibilità che a fronte di una certa architettura possono arrivare a operare sino a tre orchestrator. Uno alla regia del cloud pubblico, l’altro per il cloud privato e un terzo a integrarli tra loro. Un private cloud basato su OpenStack potrebbe – per esempio – utilizzare come orchestrator Heat, mentre una piattaforma cloud pubblica come Microsoft Azure potrebbe disporre di propri tool di orchestrazione nativi. Non è detto che template, workflow, plug-in e altre componenti di orchestrazione tra questi due ambienti lavorino insieme nativamente. Al contrario, l’azienda potrebbe avere la necessità di utilizzare una piattaforma di terze parti come Cloudify oppure OPEN-Orchestrator.
IL RUOLO DEL CLOUD PROVIDER
La fase espansiva del cloud traina la crescita del cloud ibrido, anzi del multicloud ibrido. Compresi e ottenuti i vantaggi offerti dal cloud computing per le aziende, lo step successivo è la progettazione di soluzioni ibride che consentano loro sia di utilizzare le risorse IT esistenti per svolgere attività di routine sia di trasferire il lavoro aggiuntivo sulla nuvola. I carichi di lavoro con il cloud possono essere gestiti in maniera efficiente e flessibile. «La migrazione verso il cloud permette di spostare le applicazioni in sedi più convenienti, decise dalle singole business unit in base ai requisiti delle applicazioni» – spiega Fabio Cipolat, regional sales manager Italy di Zscaler. Non solo. La security intesa non come prevenzione delle intrusioni ma nel suo concetto più esteso di garanzia di alta disponibilità e disaster recovery, grazie al cloud pubblico ha permesso alle aziende di implementare soluzioni di disaster recovery adeguate alle esigenze del proprio business. «Un risultato prima non raggiungibile per una questione di costi e di personale dedicato, oggi demandata al cloud service provider» – sottolinea Patano di IDC Italia. Driver questi che ampliano la platea di aziende di tutti i settori interessate all’ibrido, in procinto di partire con almeno un progetto, anche solo pilota.
«Limitata conoscenza, scarsa connettività, dubbi sui fornitori e sulla sicurezza sono stati fattori che ne hanno in passato frenato l’adozione» – rileva Davide Raggi, product manager IT Services di Konica Minolta Italia. «Oggi però, possiamo affermare che il cloud, nelle sue diverse declinazioni, rappresenta l’alternativa che ogni azienda valuta per lo sviluppo di progetti IT». Anzi, con l’aumentare del livello di conoscenza delle possibilità offerte dal cloud computing e della quantità di dati aziendali e workload trasferita sulla nuvola, le aziende sono spinte a progettare e realizzare nuove soluzioni. La crescita delle infrastrutture aziendali virtualizzate, unita all’esigenza di gestire tutte le capacità hardware aziendali trasformandole in servizi utilizzabili, contribuisce a fare il resto. In questo mutato scenario, anche metodologie e best practice cambiano. Mentre in passato l’IT metteva a dura prova il nuovo hardware prima di acquistarlo, in questa fase di migrazione al cloud, informazioni importanti come l’hardware del processore, la topologia della rete e la larghezza di banda, le protezioni di sicurezza, sono spesso nascoste dietro a descrizioni generiche dei servizi offerti dal cloud provider. La difficoltà oggettiva è data dal fatto che per molte aziende diventa quasi proibitivo analizzare in modo adeguato la parte pubblica dell’ambiente cloud. Una situazione potenzialmente gravida di conseguenze.
«L’usability deve essere un principio da tenere ben presente nella relazione che le aziende, specie le PMI, hanno con la sicurezza su cloud» – afferma Luca Borio, team leader Cloud Services di EOS Solutions. Pur in un contesto di estesa omogeneità nell’offerta – soprattutto nella fascia alta dei grandi cloud provider come IBM, Amazon e Microsoft – il grado di maturità dei vendor cloud in termini di trasparenza varia ancora parecchio. A partire dalla loro disponibilità di fornire ai clienti gli strumenti adeguati per effettuare una serie di analisi.
«La trasparenza, la sicurezza e l’assenza di lock-in sono per IBM gli elementi a cui non è possibile rinunciare quando si decide di spostare i propri ambienti in cloud» – ci dice Alessandro La Volpe, VP IBM Cloud & Cognitive Software, Italia. «Si esce dai confini dei propri data center per acquisire flessibilità, ma in nessun caso si può rinunciare alla sicurezza di sempre per i propri servizi. L’approccio al cloud non deve essere per i clienti un vincolo “per la vita”, ma un elemento di flessibilità, non solo in termini di scalabilità delle risorse ma – e soprattutto – nella possibilità di muoversi con libertà sul cloud. Tutto questo deve essere reso evidente in modo trasparente all’utente. Anche se – riconosce Alessandro La Volpe – non tutti i cloud provider riescono a fornire in modo onnicomprensivo questi strumenti. Il suggerimento per le imprese è di assicurarsi che ognuno di questi elementi sia disponibile e ben definito prima di affidarsi al cloud».
Rendere l’impiego delle risorse nel cloud o in-house trasparente per gli utenti dovrebbe essere una priorità. Nella prassi però – rileva Alberto Brera, country manager di Stormshield per l’Italia – la definizione a priori delle rispettive responsabilità è un compito di cui gli operatori si fanno carico ben di rado. «Spetta quindi alla clientela dotarsi di funzionalità di networking evoluto (SDWAN) oltre che di un’adeguata segmentazione della rete e tutelare il traffico con VPN IPSEC e cifrare i dati a priori, indipendentemente da dove essi siano ospitati. Meccanismi di doppia autenticazione (OTP) e l’impiego di API – continua Brera – semplificano ulteriormente la fruizione e l’interazione tra i diversi sistemi di sicurezza impiegati dal cliente a tutela del proprio perimetro esteso».
API, IL NODO SICUREZZA
L’accesso a tutti i dati trasferiti in cloud avviene da remoto attraverso delle API, codice che controlla come il software comunica e interagisce con altro software. Allo stesso modo delle sinapsi nel cervello umano, le API mettono in comunicazione tra loro le applicazioni in cloud e abilitano alla condivisione dei dati sulle reti. Si può dire che le API sono alla base di quasi tutto quello che facciamo online, dall’accesso all’home-banking allo shopping. Contribuendo pesantemente allo sviluppo della maggior parte dei trend degli ultimi decenni, cloud computing compreso. Le API però sono esposte a numerose minacce. Le API sono l’interfaccia di accesso ai dati e – per definizione – l’anello debole della catena, il bersaglio principale di attacchi e manomissioni in cloud. Considerando la loro centralità, ci si aspetterebbe attenzione massima in tema di sicurezza. In realtà, le cose non stanno così. Come dimostra il documento di OWASP relativo alle 10 maggiori vulnerabilità e che mette in luce il posto occupato dalle API. Mettere in sicurezza le API significa, in estrema sintesi, limitarne e controllarne l’accesso, l’utilizzo, i comandi, crittare il trasferimento dei dati, utilizzare l’autenticazione forte. Attività per le quali esistono tool ad hoc. Ma non soluzioni semplici. «Il mercato offre ovviamente sistemi progettati per la messa in sicurezza delle API esposte» – rileva Davide Pala, pre-sales engineer di Stormshield Italy. «Tuttavia, si tratta perlopiù di strumenti che offrono sistemi di autenticazione e monitoraggio delle chiamate API con lo scopo di ridurre la superfice di attacco e aiutare i DevOps nello sviluppo di nuove versioni delle stesse. Prodotti assolutamente verticali la cui integrazione con sistemi di security sarebbe a mio avviso poco efficace». In particolare, l’IT lamenta il fatto che buona parte dei prodotti di sicurezza dedicati forniscono semplicemente un controllo accessi, spacciandolo per sicurezza. In realtà, il flusso di dati che attraverso le API alimenta le applicazioni necessita di sicurezza aggiuntiva. Integrità e privacy dei dati, intrusion detection, data leakage sono tutti aspetti importanti della protezione di questi dati.
«Una soluzione per gestire in sicurezza le API necessita di un crescente livello di funzionalità e garanzie. Autenticazione, encryption, throttling, analisi del contesto risk base per prevenire frodi, autorizzazione a grana fine e regole di data loss prevention» – conferma Alessandro Vallega che fa parte del consiglio direttivo di CLUSIT, con responsabilità sul cloud e i gruppi di lavoro. «Ma prima ancora è utile collocare le API in contesti privati o pubblici in funzione dell’effettiva necessità. Se il mio business partner deve usare la mia API in un cloud ibrido, meglio che sia esposta su una rete chiusa a indirizzi noti».
Buona regola è non rinunciare mai a gestire la sicurezza delle proprie API. Lasciare che sia il cloud provider a occuparsene potrebbe pertanto non essere la scelta giusta. Molti cloud provider utilizzano gateway API condivisi tra molti utenti – anche di diverse aziende – e applicazioni multi-tenant per identificare e verificare gli user. In soldoni, un unico punto di accesso per un gran numero di API. Il che rappresenta quasi sempre un problema. C’è chi a tal proposito suggerisce di proteggere i dati presenti nel cloud pubblico integrando al suo interno un gateway sicuro. «In linea generale, è corretto dotarsi di propri strumenti di sicurezza» – afferma Pala di Stormshield Italy. «Tuttavia, quando si parla di cloud è il concetto di possesso a venir meno. Con sistemi distribuiti su diversi data center è quasi impossibile avere la certezza di chi effettivamente può avere accesso ai nostri dati. In una strategia volta a difendere il dato – prosegue Pala – è chiaro che la sicurezza deve seguire questo asset e questo prescinde dal design dell’infrastruttura di accesso». Ancora più marcata la posizione di Vallega di CLUSIT, apertamente favorevole alla logica multi-tenant, che garantisce le economie di scala del cloud provider e costi accessibili dei servizi al cliente. «Naturalmente, bisogna progettare bene il software. Ma a ben vedere, il software malfatto può produrre gravi danni anche sul single tenant». Il vero problema è il grado di maturità ed engagement dell’organizzazione. «Le aziende che espongono API possono essere divise in due grandi gruppi» – spiega Vallega. «Da una parte, i cloud provider e le aziende native digitali. Dall’altra le aziende non IT che faticosamente digitalizzano i loro servizi. Tra i primi, sono in molti che usano le API estensivamente e in maniera cosciente e matura, mentre tra le seconde il livello di maturità è ancora basso». Per mettere in sicurezza le API, occorre intervenire in diversi ambiti. Detto questo, una parte importante della sicurezza delle API dipende dalle API stesse.
«È chiaro che la componente più critica del processo di implementazione di tale tecnologia risiede proprio nel processo di sviluppo» – afferma Pala di Stormshield Italy. «Purtroppo, ancora oggi, le priorità dei team di sviluppo sono perlopiù le funzionalità e l’agilità a discapito della sicurezza». Un aspetto questo che evidenzia quanto ancora si debba fare in termini di sensibilizzazione e cultura. «Esistono – conclude Pala – realtà virtuose dove viene applicato un metodo di security nel contesto dello sviluppo stesso. In cui il codice viene scritto dallo sviluppatore e poi analizzato da un esperto di sicurezza. Tutto questo però richiede risorse aggiuntive e controlli periodici sulle applicazioni». E la scelta oculata delle API rimane centrale.
SICUREZZA CONTINUA
I cyber criminali usano tattiche, tecniche e procedure in costante evoluzione e costringono le organizzazioni ad adattare la loro strategia di difesa. «La sicurezza IT è quindi un processo continuo, in cui occorre prevedere, prevenire e rilevare le cyber minacce e attuare misure efficaci per contrastarle» – spiega Carmen Palumbo, country sales manager Italy di F-Secure. «A questo scopo è possibile utilizzare l’intelligenza delle macchine, ma è necessaria anche la competenza umana. Ecco perché F-Secure combina la potenza del machine learning con la competenza dei suoi professionisti dei Security Labs e del team di Consulenza». F-Secure ha ideato una metodologia che unisce persone, processi e tecnologia, chiamata Continuous Response, che permette di combattere gli attacchi mirati in corso, e può essere utilizzata da qualsiasi azienda, a prescindere dalla sua maturità in fatto di sicurezza. «La “continuous response”, ossia avere le persone giuste nel posto giusto al momento giusto e dotate delle informazioni necessarie per assumere il controllo della situazione, è fondamentale per potenziare le capacità di risposta» – afferma Carmen Palumbo. «Trattare la risposta come un’attività “continua” fa sì che i membri del team siano in costante comunicazione e collaborazione tra di loro, così da discutere eventi sospetti che accadono in qualsiasi punto nell’infrastruttura. Le soluzioni MDR (managed detection and response) possono facilitare questo processo, offrendo a chi difende il vantaggio di cui ha bisogno per fermare, contenere e, in definitiva, espellere un avversario». Countercept, la soluzione di managed detection and response di F-Secure, si basa su questa metodologia di risposta continua. Il risultato qual è? «Una soluzione che può rilevare violazioni di dati basandosi sul comportamento, invece che sui tradizionali segnali di attività malevola, consentendo azioni di risposta rapide ed efficaci, supportate dall’automazione o dall’esperienza umana».
NUOVE COMPETENZE IN AZIENDA
Detto questo, la gestione del cloud ibrido e in particolare della sicurezza, richiede competenze evolute da parte di aziende e organizzazioni. «Il fornitore della piattaforma tipicamente è responsabile per la disponibilità del dato ma non dal punto di vista della sicurezza dello stesso» – osserva David Gubiani, regional director Security Engineering Southern Europe di Check Point Software Technologies. «Chi decide di approcciare il cloud pubblico non può permettersi di esporre dati che possono essere violati sfruttando le vulnerabilità degli applicativi». In un contesto nel quale più di due terzi delle imprese – secondo i dati IBM – si sta rivolgendo a più di un vendor cloud per il proprio business, i ruoli e le competenze richieste per gestire la sicurezza in un ambiente multicloud vanno oltre le normali figure standard quali CISO o security operation manager, che – ci dice Alessandro La Volpe di IBM – in genere non hanno la possibilità di comprendere a fondo le singole soluzioni di cloud security dei diversi vendor. Una situazione solo in parte contenuta dall’ascesa a livello organizzativo della figura del chief digital officer. «Le risorse cruciali di un’azienda sono digitali. Una situazione che ha determinato l’aumento dell’importanza della figura del CDO. Le cui competenze potranno meglio supportare le esigenze delle aziende nei percorsi di trasformazione rispetto alla figura del CIO» – conferma Fabio Cipolat di Zscaler.
Numerosi operatori propongono un modello di sicurezza “condivisa”, con il fornitore garante della sicurezza del cloud ma non nel cloud. «In altre parole – spiega il country manager di Stormshield per l’Italia, Alberto Brera – il vendor demanda al cliente sia la tutela dei dati e delle applicazioni ospitate sia la protezione di quanto transita tra cloud e infrastrutture locali. In questo contesto – continua Brera – adottare il cloud per una parte delle proprie attività collima per la clientela con l’adozione di un’infrastruttura a perimetro esteso, la cui tutela non richiede altro che le figure tecniche dotate delle necessarie competenze in cyber security e networking di infrastrutture SDWAN e/o l’outsourcing di tale compito a managed service provider specializzati». Inoltre come sottolinea Alessandro La Volpe di IBM – «diventa importante rivolgersi a system integrator o consulenti specifici nel campo della sicurezza del cloud per orientarsi nella selva di soluzioni e regolamenti che si devono adattare alla politica di sicurezza aziendale». Il problema è che le aziende hanno sempre meno risorse interne per gestire queste problematiche cloud. Con reparti IT ridotti all’osso, una tendenza solo in parte controbilanciata dall’ascesa della figura del CDO. Il risultato è che alcune realtà scelgono di frenare l’emorragia di personale IT calibrandolo semmai alle nuove competenze richieste. Una scelta che per molti aspetti potrebbe assumere i contorni di una mossa strategica almeno quanto quella di passare al cloud ibrido.
