No results found
La forte diffusione che il Cloud ha avuto e che avrà ancor più negli anni a venire porta con sè una serie di problematiche per tutti gli attori del settore; dal lato dell’utente, le problematiche riguardanti l’affidamento al Cloud e la scelta di Provider e infrastrutture consistono non solo nella conformità dell’offerta alle proprie esigenze e alla portabilità dei propri sistemi on-premise o Cloud, ma anche nella sicurezza garantita dalla migrazione e dalla permanenza in un ambiente virtuale remotizzato come è quello “della nuvola”.
In questo tutorial spiegheremo quali elementi considerare inerentemente all’aspetto della sicurezza nel Cloud, andando oltre il concetto comune di sicurezza associato alla tutela dalle effrazioni.
Partiamo dalla premessa che generalmente tutti i Cloud provider o buona parte di essi dispone di sistemi di sicurezza che superano il livello di quelli adottati nella media delle aziende, però ci sono degli elementi attinenti ad alcuni argomenti che sono quelli che bisogna valutare per confrontare le offerte commerciali sul web e per scegliere uno o l’altro provider.
Iniziamo a a vedere quali sono alcuni di questi elementi che, come vedrete, attengono alla capacità del Provider di garantire la conservazione dei dati, la tutela dal “disastro” informatico, la disponibilità di risorse a supporto dell’operatività del cliente ecc. Elementi che non sempre vengono chiariti nelle offerte commerciali e nei contratti.
Proviamo quindi a capire che cosa determina la sicurezza di un’infrastruttura o un’applicazione nel Cloud, ossia:
Esistono poi altri aspetti, secondari ma non meno interessanti, che sono:
Prima di entrare nel merito dei singoli punti dell’elenco è opportuna una premessa: i servizi Cloud si dividono in tre tipi: IaaS, PaaS e SaaS.
IaaS, ovvero Infrastructure as a Service significa che dal provider si affitta un’infrastruttura virtualizzata nuda e cruda (il cosiddetto Bare Metal), quindi:
In sostanza IaaS significa disporre di un’infrastruttura, ossia di un hardware virtualizzato dove il cliente può installare i propri sistemi operativi e le applicazioni di cui necessita, le cui licenze deve però acquistarle. A carico del cliente c’è anche la manutenzione della piattaforma e di quello che ne consegue.
Il secondo tipo, il PaaS (Platform as a Service) è qualcosa di orientato agli sviluppatori perché il cliente va ad acquistare una piattaforma, quindi l’hardware virtualizzato, l’hypervisor per le macchine virtuali, il sistema operativo, e qui deve installare le proprie applicazioni e gestirle.
L’ultimo tipo di servizio Cloud è il cosiddetto SaaS (Software as a Service) che consiste nell’utilizzare software e applicazioni am consumo; in pratica consente di utilizzare delle applicazioni senza averle sulle proprie macchine, ma attingendo a server remoti in Cloud.
Saas è qualsiasi servizio Cloud tramite il quale gli utenti possono accedere ad applicazioni software tramite Internet ed offre il vantaggio di utilizzare dei programmi pagandone l’utilizzo ma non il costo delle licenze, perché di queste si fa carico il provider, il quale si occupa anche dell’aggiornamento, della manutenzione ecc. garantendo, almeno in teoria, la fruizione del servizo da parte del cliente.
I tre modelli sono schematizzati nell’immagine seguente.
In questo tutorial ci focalizzeremo sui due modelli estremi, ossia Infrastructure as a Service e Software as a Service.
Diamo quindi uno sguardo a quali sono i servizi più utilizzati in Cloud, attraverso l’immagine seguente.
Il prospetto permette di comprendere quali sono i servizi che vanno per la maggiore, vale a dire quelli che hanno le più alte percentuali, perché da qui si possono fare varie considerazioni.
Andiamo avanti ed esaminiamo il primo punto dell’elenco fatto poc’anzi, ossia le garanzie fornite dal Provider; queste sono contenute nel cosiddetto SLA (Service Level Agreement) che in sostanza attiene a quello che è l'accordo che si prende con il fornitore ed è il livello minimo di servizio che il fornitore Cloud contrattualmente deve garantire.
Nella scelta di un Cloud Provider bisogna sempre valutare SLA e assistenza, perché fanno la differenza da chi fornisce l’infrastruttura e poi il cliente deve occuparsi di tutto il resto e chi invece presta assistenza tecnica continuativa, trasparenza ecc.
Lo SLA descrive anche le garanzie e le penali applicabili al provider in caso di mancato rispetto del contratto, quindi tenete sempre presente che uno SLA senza penali non fornisce un elevato livello di garanzie al cliente.
Sempre nello SLA, dovrebbe essere descritta la exit strategy, ossia come potete uscire da un contratto e dal Cloud del provider in caso di disservizio da parte del provider stesso.
Il prospetto seguente ci mostra un esempio di availability, ossia disponibilità del servizio considerando il complesso degli elementi che possono pregiudicarlo, ossia connettività, infrastruttura, applicativo.
È convenzione indicare quello che è l'uptime (disponibilità) e il downtime (indisponibilità) utilizzando per il primo dei nove, che rappresentano le percentuali: per esempio un nove corrisponde al 90%, due nove al 99%, tre nove al 99,9%. Purtroppo molti provider forniscono numeri che abbondano nell’utilizzo dei 9, ma ciò non corrisponde all’effettivo uptime, nel senso che i numeri che i provider pubblicizzano nelle loro offerte offrono uno scenario che non è sempre vero. Per quale ragione? Perché ogni sistema ha delle dipendenze da ciò che c'è sotto, quindi un servizio SaaS deve tenere conto di un possibile problema a livello applicativo, a livello database o a livello di di infrastrutture di rete.
Ciò significa che commercialmente si tende a mettere più 9 possibile, quindi a livello pratico quello che bisogna andare a verificare è se nel contratto c'è un indicatore SLA e se il suo mancato rispetto è connesso una penale, perché indicare uno SLA anche del 100% senza che ci sia una sanzione per il provider in caso di mancata corrispondenza del livello qualitativo reale con quello atteso, non ci garantisce.
Per avere un’idea dell’availability e degli SLA ottenibili diamo uno sguardo all’offerta dei maggiori Cloud provider: Azure, Aws e Google. Lo facciamo però dall’ottica di un interessante tool web in grado di darci informazioni su quella che è la loro availability, ossia un sito che si chiama downdetector (ma ce ne sono anche altri in rete). L’immagine seguente propone tre analisi effettuate, appunto, su detti Cloud Provider.
I picchi nei grafici corrispondono ai periori dove si vede che effettivamente ci sono stati dei down significativi dei servizi; quindi anche i principali provider hanno i loro problemi e tutti i servizi possono andare in down.
Per fare un esempio, Amazon Route 53 che è un servizio DNS di Amazon tra i più conosciuti al mondo, viene definito con il 100% di availability (disponibilità); peccato che, come documentato, in ottobre 2019 fu vittima di un attacco DDOS e il servizio andò giù per diverse ore. Andando giù il servizio AWS Route 53, andarono giù anche tutti i servizi legati a tale servizio DNS e quindi S3 storage e tutti quelli connessi come servizi di Object Storage, quindi anche Netflix e altri provider che utilizzano quei servizi.
Adesso parliamo del Data Center perché qui in qualche modo andiamo analizzare dove possono originare dei problemi di sicurezza: ci sono tantissimi Data Center e tanti anche in Italia.
La loro categorizzazione riguardo all’affidabilità si basa su un parametro chiamato TIER, che generalmente attiene a due elementi: l'elettricità e il raffreddamento; parliamo quindi di tiering ossia di ridondanze che consentono di garantire la funzionalità.
Il prospetto seguente riporta i vari ordini di TIER con le relative caratteristiche.
Quindi quello che viene garantito dal livello è che il Data Center può avere più o meno sistemi ridondanti riguardo alla capacità di continuità elettrica e raffreddamento; i livelli sono 4, ognuno dei quali fornisce una reliability che va da un minimo di 99,671% nel caso di Data Center con TIER 1 (nessuna ridondanza) a 99,995 in corrispondenza del TIER 4, che fornisce continuità anche in caso di gravi guasti tecnici o “disastro”.
Il problema della disponibilità dell’elettricità non è cosa da poco e il Data Center deve essere collocato anche in funzione della qualità della rete elettrica; non meno importante è lo smaltimento del calore, perché un Data Center ben fatto non può essere composto da una serie di rack posti in un ambiente dove sono stati installati dei ventilatori, ma deve disporre di un sistema integrato progettato per smaltire il calore prodotto. Va infatti considerato che nei grandi Data Center la concentrazione di unità di calcolo per unità di volume e quindi di potenza dissipata dalle CPU per unità di volume, è elevatissima!
Bisogna però stare attenti al fatto che il TIER si calcola sulla disponibilità dell’energia elettrica e refrigerazione ma non ad altri parametri che possono “minare” il servizio; quindi sicuramente un Data Center collocato in una nazione e in una regione dove non si verificano blackout frequernti è sicuro sotto l’aspetto dell’indice TIER, ma nulla ci garantisce riguardo alla caduta della connessione dati per raggiungerlo, sia essa nella regione di locazione geografica o nella zona in cui si trova il cliente che fruisce del servizio. Questo fa capire l'importanza di conoscere dove risiede il Data Center cui sono appoggiati i propri servizi Cloud.
Nell’immagine seguente vedete un Data Center Switch: in Italia ce n’è uno identico che si chiama Supernap; quello nuovo di Aruba, a Bergamo è un TIER 4, il Data4 è anch’esso un TIER 4 e ce ne sono sicuramente degli altri simili. Questi sono strutture progettate e costruite per ospitare un Data center e quindi con le tecnologie del caso e le infrastrutture elettriche scelte per continuità.
Purtroppo non tutti i Data Center sono così, perché molti sono edifici generici (per esempio capannoni) che hanno adibito a ospitare dei rack e avere dei gruppi di continuità e dei sistemi di refrigerazione che però non sono comparabili a quelli suaccennati, perché un conto è traformare un fabbricato in un Data Center, un altro è costruire un Data Center con tutti i suoi sottosistemi.
Un elemento non indifferente nella scelta del Cloud Provider è la responsabilità condivisa, ossia un concetto che è stato definito ad esempio anche dal CISPE (Cloud Infrastructure Services Providers in Europe) nel Codice di condotta. Esso attiene alla responsabilità in comune fra provider e cliente relativamente ad alcuni aspetti come quelli riguardanti il GDPR; quindi se è vero che sistono degli obblighi in capo al provider e altri incombenti sul cliente, alcuni aspetti chiamano in causa la responsabilità di entrambi.
Relativamente al GDPR, il provider è tenuto a fornire le informazioni al cliente su quali sono le sue competenze e qu quali responsabilità incombano, invece, sul cliente. L’immagine seguente riepiloga il prospetto di tale schema relativamente al Cloud Stellar offerto da Coretech. Questa è una pagina del sito Coretech dove è ben delineato lo spartiacque tra cosa deve fare il provider e cosa deve fare il cliente.
Quindi in linea generale deve essere indicato per ogni servizio cosa fa il Cloud provider e che cosa spetta al cliente.
Lo schema della responsabilità condivisa trova un'altra biforcazione al momento in cui ci sono degli intermediari, perché se il servizio coinvolge non solo il provider il suo cliente ma anche terzi, occorre definire, nei limiti del possibile, chi deve fare cosa; quindi se in mezzo ci sono degli altri interlocutori come dei System Integrator, delle Software House o altri operatori, chiaramente c'è una corresponsabilità.
Un altro elemento molto importante nella scelta del servizio Cloud è decidere se si stanno “comprando” macchine di test o macchine produzione. Per comprenderne l’importanza passiamo attraverso alcuni esempi, il primo di quali riguarda Microsoft: nell'offerta delle istanze riassunta nell’immagine seguente, le stesse si dividono per tipo e nomenclatura (tipo A, B e D).
Vedete cerchiato come le offerte tipo A e B siano consigliate a macchine di sviluppo e test, mentre per la serie D2 viene specificato nello storage l’utilizzo di dischi locali, ma null’altro, quindi è una VPS? O cos’altro? E la memoria di cui si fa riferimento nell’offerta è volatile o permanente?
Quanti prima di comprare delle macchine da Microsoft che sono nella fascia A e B probabilmente non vanno a prendere in considerazione il fatto che siano delle macchine adibite a sviluppo e test e non siano intese come macchine di produzione?
Sembra un dettaglio, ma fa una grande differenza ed è determinante che il provider fornisca questa informazione, perché alle macchine per test e sviluppo si riservano risorse differenti e la loro connettività non è così critica come invece lo è per macchine di produzione, come critico è il supporto tecnico fornito.
Questo è un elemento che attiene alla sicurezza perché un conto è avere una macchina di produzione, che se si ferma può creare problemi da risolvere nel minore tempo possibile, mentre ben altro è destinare una macchina al test e sviluppo. Se abbiamo bisogno di supporto è necessario aver chiaro cosa prevede il contratto stipulato con il vostro provider, ossia come quest’ultimo vi supporta.
Per fare un esempio diamo uno sguardo a un’offerta di Amazon, dalla cui pagina web vediamo ad esempio “accesso 24 ore su 24 e 7 giorni su 7 per le domande relativamente alla fatturazione”. Chiaramente è facile fare una promessa simile, perché è un’evenienza facilmente gestibile, ma mediamente a un cliente interessa più sapere se, a fronte di una promessa nello SLA di un uptime del 99,9% cosa accade in quello 0,1% rimanente, ossia nel momento in cui si verifica un problema in che tempi riceverà supporto. E a quale costo.
Quindi bisogna informarsi anche su quelli che sono diciamo i costi, perché scoprire solo quando avete un problema che in realtà il servizio che sembrava costasse pochissimo in realtà ogni volta che capita un problema diventa costosissimo, non è un buon affare.
Più il Cloud provider è chiaro e fornisce informazioni facilmente disponibili e pubbliche, più il cliente è sicuro del servizio che sta acquistando.
Coretech, per ogni servizio ha definito una scheda descrittiva secondo quello che è lo standard ISO 27.000; nell’immagine seguente trovate quella on-line del servizio 1Backup con la relativa SLA.
Tante aziende certificate ISO, però non pubblicano le informazioni relativamente alle schede prodotto riguardo a quelli che sono gli SLA, le penali il Data Center per quello specifico servizio; ad esempio per il servizio di backup non chiariscono se i dati sono replicati, l’esistenza di servizi opzionali, se è possibile richiedere un restore o meno, la tolleranza ai problemi per ogni singolo servizio che viene offerto. Il supporto è standard o non lo è? Quali sono le politiche di cancellazione dei dati? Quest’ultimo dettaglio rileva relativamente al GDPR, perché dà delle informazioni generiche ma non precisa dopo quanto tempo vengono cancellati dati (nel caso di 1Backup, gli stessi vengono conservati per 30 giorni seguenti la risoluzione del contratto).
Per esempio de disdite un contratto con un Cloud Provider e un paio di giorni dopo vi accorgete di esservi scordati di salvare i vostri dati, chi vi garantisce che il provider sia tenuto a conservare i vostri dati per un periodo ragionevole? Lo avete verificato nel contratto?
Anche questo aspetto è sicurezza del Cloud.
E qui torniamo allo SLA, dove deve essere indicata chiaramente la penale che graverà sul provider in caso di inadempienza; ma attenzione che l’entità della penale non è casuale ma deve essere commisurata al danno che il cliente subirebbe in caso di indisponibilità del servizio, proporzionalmente al periodo di interruzione rapportato alla durata del periodo che paga contrattualmente. Se non è indicata chiaramente non saprete mai se il vostro Provider Cloud vi tutela a sufficienza.
Nel caso del servizio 1Backup (che è un SaaS) la relativa pagina chiarisce le condizioni con un esempio di facile comprensione.
Chiaramente mon è pensabile che per un servizio da 100 euro, il provider nel momento in cui ha un down paga 100.000 euro di danni all’azienda cliente perché essa subisce un danno di tale misura; la penale deve essere rapportata a ciò che il provider ha ricevuto e a ciò che non ha mantenuto.
Chiarito quali sono le penali, dopo dovrete verificare se quelle penali sono attinenti al livello di servizio che voi volete ottenere ossia al livello di reliability che volete.
Nel nostro caso abbiamo distinto le penali in funzione del tipo di servizi, vale a dire SaaS e IaaS; questo perché chiaramente un servizio SaaS non può, salvo che non sia stato realizzato in un’ottica veramente Cloud in cui c'è un sistema distribuito, avere uno SLA maggiore di un servizio IaaS.
Ultimo ma non importante è “leggere tra le righe” ossia stare bene attenti alla definizione che il provider dà di concetti e condizioni; l’immagine seguente, relativa a servizi di Amazon, aiuta a comprendere il concetto.
Si riferisce alla definizione di una condizione che può dar luogo a penale e, nello specifico, del downtime, che qui è a interpretazione del provider e cambia in base al tipo di istanza; questo, se da un lato può avere motivazioni tecniche, dall’altro è difficilmente comprensibile ai più.
Nella legenda vediamo che per le istanze EC2 il downtime si concretizza nella perdita di accesso quando le istanze sono piazzate tra due o più zone della stessa regione cioè; tradotto, significa che Amazon vi rimborsa solo se la relativa istanza si trova almeno su due regioni, altrimenti poco gli importa se non riuscite a utilizzare il servizio. Si tratta di una clausola che in apparenza esiste ma che mediamente all’utente non porta alcuna certezza.
Ne deriva che il fatto di appoggiarsi a un major provider non implica automaticamente che il servizio sia ridondato, garantito e tutelato. E alcuni provider tra cui i Big Player giocano sul fatto di avere più regioni e infrastrutture per imporre al cliente, come condizioni per avere rimborsi in caso di inadempienza, di realizzare infrastrutture Cloud in High Availability con più macchine su regioni diverse, perché questo significa per loro essere più tranquilli che il servizio non sarà interrotto; ma per il cliente significa spendere più soldi a fronte della stessa garanzia.
Adesso andiamo a quella che è la sicurezza intesa ad esempio come scalabilità della propria infrastruttura: i Cloud Provider non possono, a meno di non poter contare su ampie risorse, garantire a un cliente di poter scalare, fare l’upgrade della propria infrastruttura, in qualsiasi momento e utilizzando quante risorse desidera. Altri permettono di scalare le risorse ma passando a pacchetti superiori e non aggiungendo solo la risorsa desiderata: CPU, storage, interfacce di rete, per esempio.
Quindi con molti provider se vogliamo aggiungere delle singole risorse siamo obbligati, ad esempio, a raddoppiare tutte le risorse e il costo, praticamente…
Questa è una strategia a blocchi che non offre flessibilità e talvolta lim ita la crescita dell’infrastruttura remotizzata o la rimanda, per timore dell’incremento dei costi, pregiudicando a volte la sicurezza, perché spesso più risorse come quelle di storage servono a creare ridondanza dei dati.
Però il concetto di scalabilità nel Cloud consiste sostanzialmente nella possibilità di modificare qualsiasi parametro liberamente: ad esempio poter incrementare la CPU, la RAM o la dimensione dello storage a piacimento e in qualsiasi momento, senza dover aumentare anche le altre componenti. Questo non sempre è permesso, perché, come accennato, sovente i provider vendono le soluzioni a pacchetti rigidi e obbligano il cliente a passare a un’altra fascia di server anche solo per aumentare lo storage.
Per dare qualche numero ed esemplificare tali concetti prendiamo l’offerta di Microsoft relativamente alle istanze D2-64, riportata nell’immagine seguente e riferita al 2020.
Si vede che i prezzi delle soluzioni D2, D4, D8 ecc. differiscono per il numero di CPU e per i GigaByte di RAM e che RAM e storage temporaneo raddoppiano al moltiplicarsi delle CPU richieste.
Questo, ripetiamo, può costituire un problema di sicurezza, se non altro per chi non vuole stravolgere il proprio budget e per chi è andato in Cloud per risparmiare e tutto a un tratto si accorge di spendere di più che ad avere un’infrastruttura on premise.
Questa tariffazione delle risorse a blocchi o scalini vale anche per i servizi Cloud SaaS
Un altro aspetto che coinvolge la sicurezza è anche il limite di scalabilità supportato dal provider, ossia fino a quale ammontare di risorse si può arrivare? Illimitato o limitato? E i limiti sono e saranno compatibili con le proprie applicazioni? Se lo storage acquistabile tutt’a un tratto raggiunge il limite che cosa succede, per esempio, a un backup o a un database che sta lavorando? Anche questo coinvolge la sicurezza.
Un ulteriore elemento da valutare è la sicurezza architetturale, ossia come è strutturato il servizio che state acquistando? Ad esempio, nel caso di un IaaS state acquistando delle VM che sono su singolo hypervisor ho sono in una configurazione cluster. Generalmente tanti Cloud provider non riportano queste informazioni.
E nel caso di un'applicazione SaaS, è un’ applicazione messa su singolo server o è un'applicazione nativa per il Cloud e quindi appoggiata a un’infrastruttura resiliente che permette di dividere l’applicativo e il database distribuiti su più macchine virtuali? Cercando un po’ attentamente si scopre che pochissimi Cloud Provider hanno implementato architetture distribuite dove se va giù un nodo è garantita la continuità del servizio.
Per concludere, proviamo a ricapitolare quanto esposto delineando i 10 punti principali da prendere in considerazione per poter andare su cloud al sicuro; li riportiamo qui di seguito.
Bene, fatto questo recap, basandovi sulle informazioni qui fornite avrete uno strumento in più per districarvi nell’offerta Cloud, che oggi è davvero nutrita e fatta, purtroppo, non sempre da provider capaci di soddisfare le esigenze di tutto il pubblico.