IT Bimodale/Hybrid e Sicurezza

Bimodale, hybrid-cloud, o addirittura multi-cloud, sono le diverse “sfaccettature” che sta assumendo la nuova Information Technology. E la sicurezza gioca sicuramente un ruolo strategico.

Come consulente strategico in ambito OpenStack e Private Cloud, ho la fortuna di incontrare molti CIO e CEO in tutta Europa. Posso dire che oramai, il Cloud Computing –sia Private sia Public- inizia ad essere apprezzato nelle aziende, ma spesso con le motivazioni sbagliate.

Di frequente, infatti, il fattore trainante nella scelta di soluzioni Cloud è il risparmio: ad esempio diminuire i costi di licenza dei software di virtualizzazione (VMWare, …) o trovare una forma di storage più conveniente rispetto alle SAN tradizionali, soprattutto in contesti in cui i dati si moltiplicano a dismisura (Big Data).

Mentre l’adozione di tecnologie come OpenStack comporta sicuramente un risparmio economico, le maggiori evidenze si riscontrano nell’agilità del business e nello snellimento dei processi interni, che aiutano a semplificare il lavoro quotidiano e consentire la focalizzazione sul core business dell’azienda.

E’ questa la chiave per interpretare il Cloud nella giusta direzione, ma è necessario porre estrema attenzione alla sicurezza perché in un ottica Cloud o, come vedremo in seguito Bimodale, possono cambiane radicalmente gli approcci e le soluzioni da applicare.

Vi faccio un esempio che può aiutarci a chiarire meglio questo concetto. Una società bancaria inglese impiegava circa 120 giorni per mettere in produzione una singola virtual machine aziendale. In Italia le aziende impiegano mediamente 60-80 giorni per effettuare la stessa attività. Il motivo è presto detto: i processi interni erano così intricati che per ogni operazione era necessario aprire un ticket. Sommando quindi al tempo di creazione della virtual machine anche i tempi di installazione dei sistemi operativi, configurazione delle reti, compliance, sicurezza, installazione dell’applicativo e del relativo database si arrivava facilmente a quel numero spropositato di giornate lavorative.

Una standardizzazione dell’infrastruttura comporta numerosi vantaggi. Accoppiando l’uso di sistemi cloud e sistemi di automazione con tools quali Ansible[1], Puppet[2] e Chef[3], per fare degli esempi ormai “industry standards”, aiuta a snellire e portare sia il provisioning sia il change management all’integrazione automatica con il resto dei tools IT, quali ad esempio CMDB e monitoring. La security può trarre sicuramente un vantaggio dall’automazione dei servizi, ad esempio consentendo una “automatic compliance” dei sistemi.

E’ tuttavia improbabile che si possa fare un cambiamento di paradigma ICT dall’oggi al domani. Quasi tutti i miei clienti chiedono di impostare un “percorso” di cambiamento, in generale più a lungo termine che a breve.

E’ sulla base di tali esperienze e richieste che possiamo introdurre il concetto di “Dual-Mode IT” o “IT Bimodale”, ovvero affiancare in maniera efficace ed efficiente il mondo IT preesistente con il nuovo. Tipicamente il mio approccio in un progetto di trasformazione IT è quello di partire dai sistemi di Test e Sviluppo, in genere perche’ non sono critici e quindi il cliente e’ piu’ predisposto nell’inserire nuove tecnologie e ad adottare gradualmente nuove procedure più “agili”.

Vi faccio un esempio piuttosto complesso relativo ad un mio cliente, che aveva tra l’altro un approccio molto conservativo, al quale Microsoft aveva dato la possibilità di usare servizi Azure all’interno del contratto. Tramite l’uso di un Cloud Management Portal e di procedure di automation, l’azienda poteva gestire un’area di produzione interna su VMWare in cui aveva configurato i workload tradizionali (tipicamente Oracle e SAP), un’area OpenStack interna dove effettuava il test, sviluppo e produzione web “semplice”, un’area con Azure dove gestiva i siti pubblici istituzionali in cui era necessario disporre di molta banda. In questo scenario, in cui si unisce e uniforma l’uso di un datacenter interno con uno esterno/Cloud non viene quindi cambiato minimamente il modo in cui l’IT opera. OpenStack è nato affrontando già da subito le tematiche di disaster recovery e business continuity, e potrebbe anche consentire (con le applicazioni specifiche) di raggiungere uno zero downtime su ridondanza geografica. Altre funzionalità built-in di snapshotting geografico, di object storage e nuovi progetti come Freezer[4] (backup dei dati interni alle VM) vanno in questa direzione, rendendo la sicurezza del dato e la sicurezza di continuita’ del business al centro della nuova IT.

Questa “maggiore” sicurezza richiede però una profonda rivisitazione dell’approccio alla sicurezza. Ripartiamo quindi da un approccio multilivello. Il primo livello è quello della infrastruttura OpenStack stessa in cui è molto importante proteggere gli Endpoint dei singoli servizi Open- Stack da attacchi di tipo Denial of Service (DoS) e da attacchi conosciuti utilizzando Intrusion Prevention Systems (IPS) e Firewall che espongano soltanto le Application Programming Interface (API) della piattaforma. E’ importante che questo tipo di protezione lavori ad alte prestazioni con un traffico particolarmente elevato (quasi wire-speed).

Un secondo importante livello di protezione è quello del Tenant e dei progetti sviluppati sulla piattaforma OpenStack. Sviluppando sempre più spesso con Web Services è necessario attivare sistemi di ispezione del traffico HTTP e HTTPS in modo da bloccare eventuali abusi all’applicativo stesso. Nella suite OpenStack è incluso un servizio di “Firewall as a Service” [5] (FWaaS), da attivare e configurare con il supporto di uno specialista di sicurezza, magari con esperienze su prodotti di mercato. OpenStack, di base, offre anche la possibilità di attivare un firewall attraverso i security groups[6] a protezione di ogni singola macchina, sia sul traffico proveniente dall’esterno, sia sul traffico tra macchine appartenenti allo stesso segmento di rete. Un altro livello di protezione importante , in particolare per un ambiente “cloud oriented”, è la sicurezza implementata nell’applicativo, soprattutto se espone delle API pubbliche. Mentre in ambienti più tradizionali può essere sufficiente un Firewall o la funzionalità Deep Protocol Inspection (DPI), ora è importante segregare l’accesso ai dati a livello applicativo ed attivare i dovuti audit. Inoltre, in un’ottica cloud è importante che anche i concetti di resilienza siano spostati sempre di più nell’applicativo[7].

E’ indubbio che i service provider e gli outsourcer siano stati i primi ad aver capito che l’adozione di standard aperti e metodologie agili quali DevOps 8 comportano innumerevoli vantaggi. Tuttavia anche le Aziende, dalla piccola alla grande impresa, potranno trarne vantaggio sia in ambito business sia nella sicurezza.

1 www.ansible.com
2 www.puppet.com
3 www.chef.io
4 https://wiki.openstack.org/wiki/Freezer
5 wiki.openstack.org/wiki/Neutron/FWaaS
6 https://wiki.openstack.org/wiki/Neutron/SecurityGroups
7 come indicato anche dalle best practices del 12 factors (ref: http://12factor.net/).
8 https://it.wikipedia.org/wiki/Devops

A cura di: Giuseppe Paternò

Articolo pubblicato sulla rivista ICT Security – Maggio 2016