Cambiamenti di paradigma così ampi come il passaggio al cloud a livello strategico, richiedono un ripensamento di tutta l’organizzazione. Un passaggio inevitabile, che anche tutte le PA dovranno fare, ognuna con le sue specificità, se vorranno essere efficaci ed efficienti nel nuovo scenario.
Vediamo come si è mossa Corte dei conti, una delle Amministrazioni che hanno collaborato alla stesura del Cloud Enablement Program (“il percorso che abilita un’organizzazione a creare, operare e mantenere le proprie infrastrutture digitali utilizzando tecnologie e servizi cloud”), presentato dal Team Digitale durante l’ultimo Forum PA) raccontando agli esperti del Team il proprio percorso evolutivo, i traguardi raggiunti ed i risultati in termini di valore aggiunto per gli utenti, ma anche le difficoltà riscontrate e gli errori fatti.
Nel seguito descriverò la nostra journey to the cloud, approfondendo gli aspetti relativi alla gestione della sicurezza informatica.
Storia breve di un lungo viaggio verso il cloud
L’esperienza nel cloud di Corte dei conti parte alla fine del 2012, stimolata da una serie di fattori che ruotavano intorno alle esigenze e alle aspettative degli utenti. In particolare, nonostante disponessimo di servizi di posta elettronica, collaborazione, documentale e messaggistica unificata di buon livello, con processi di gestione strutturati ed infrastrutture fra le migliori di tutta la PA italiana, la nostra utenza tendeva a soffrire di quella che ho definito “invidia di Gmail”.
In pratica ci si aspettava che i servizi aziendali (in particolare l’e-mail) funzionassero come e meglio dei principali servizi gratuiti (disponibili sempre, disponibili ovunque, senza limiti dimensionali), a maggior ragione perché gli utenti erano consci che i servizi di Corte avevano costi piuttosto sostenuti.
L’analisi dello scenario tecnico e del mercato ha fatto sì che Corte ritenesse improponibile dal punto di vista tecnico ed organizzativo soddisfare le (legittime) aspettative degli utenti continuando ad erogare i servizi in proprio: non eravamo (e non siamo) strutturati come veri Service Provider e le dimensioni dell’Ente non avrebbero in alcun modo giustificato gli investimenti necessari per diventarlo.
L’offerta di servizi in cloud in ambito collaboration (quindi posta, archiviazione remota, piattaforme documentali, videoconferenza, ecc.) stava raggiungendo una maturità sufficiente a rispondere ai nostri requisiti e la presenza, in una convenzione Consip esistente, di una voce di listino dedicata ai servizi cloud ci ha consentito di partire. Da notare che, a sette anni di distanza, non sono ancora del tutto risolti i problemi di procurement per le piattaforme cloud della PA.
Le prime migrazioni e gli effetti del passaggio
Superati i dubbi riguardo la sicurezza e la privacy (tramite un complesso benchmark realizzato da terza parte in cui si dimostrava senza dubbio che i dati erano più al sicuro in cloud che nel nostro datacenter) abbiamo deciso di avviare le prime migrazioni.
Da lì siamo partiti, apprezzando ogni giorno di più la qualità ed elasticità dei servizi: alla posta elettronica abbiamo affiancato il documentale, la videoconferenza, la gestione ITSM (Information Technology Service Management – sull’argomento si veda questa pagina). Nel giro di due anni abbiamo ridotto di un buon 25% il numero dei nostri server, riducendo nel contempo il numero delle risorse umane dedicate al servizio di conduzione dei sistemi e ottenendo accesso gratuito ad una serie di servizi (quali uno storage personale di dimensione sostanzialmente infinita, un sistema di gestione dei gruppi di lavoro, una gestione dei flussi estremamente flessibile, ecc.) ad alto valore aggiunto.
Abbracciare il modello del cloud a livello strategico
Ma la vera scelta “rivoluzionaria” è stata quella di abbracciare il modello del cloud a livello strategico, ripensando il ruolo della Direzione Generale dei Sistemi Informativi Automatizzati di Corte non più come gestori di infrastrutture e sistemi informativi, ma come service broker, vale a dire mediatori (anche culturali!) di servizi ospitati su infrastrutture di terze parti.
Questo ha portato alla scelta di modelli di erogazione SaaS first, usando le piattaforme PaaS per riscrivere completamente le applicazioni di core business arrivate alla fine del ciclo di vita e relegando l’utilizzo dello IaaS solo a quei casi in cui era dimostrabile un reale vantaggio economico e/o gestionale. Il tutto su cloud pubblico (altra scelta decisamente radicale).
Al riguardo, a fronte dell’obsolescenza del parco server, è stato naturale migrare in cloud IaaS prima tutte le infrastrutture dedicate ad ambienti di collaudo, test e manutenzione (ottobre 2016) e poi ridisegnare in cloud il nostro polo di disaster recovery (inizio 2017). Le migrazioni hanno consentito di dismettere un ulteriore 30% del parco server. Circa un mese fa è stato avviato il progetto che, entro fine 2019, consentirà di migrare tutte le architetture legacy di produzione verso il cloud in modalità IaaS.
Un nuovo sport, nuove squadre
L’organizzazione dell’area ICT di Corte dei conti è stata modificata tramite la creazione di tre team di lavoro con compiti complementari fra loro, composti da risorse estremamente specializzate, reperite fra il personale Corte e tramite ricorso al mercato.
- Il primo, battezzato “Comitato architetture” si occupa di definire le architetture dei nuovi sistemi informativi, prendendo in input i requisiti da parte dei responsabili dei servizi e producendo come output schemi architetturali sui quali i fornitori applicativi produrranno il software. Il ruolo del Comitato è di disegnare piattaforme di alto livello tecnologico mantenendo il giusto livello di coerenza fra i vari applicativi, pur favorendo in tutti i modi l’innovazione. Fra le principali direttrici tecniche introdotte dal Comitato vi sono:
- la scelta di non utilizzare la containerizzazione, vista come scelta eccessivamente “conservatrice”, con modelli gestionali fumosi specie in ambito sicurezza e che espone al rischio di frenare il completo ridisegno delle applicazioni a fine ciclo di vita;
- il disegno dell’architettura di rete definita “Branch Office” o “Internet Breakout”, che ha completamente ribaltato la modalità dell’accesso ai servizi da parte di Corte dei conti e delle Amministrazioni ad essa collegate (Avvocatura Generale dello Stato e CNEL). Al riguardo suggerisco di leggere “Diversamente connessi”, a firma di Luca Attias e Michele Melchionda;
- La definizione di uno strato di “utility” destinato ad interfacciare i servizi trasversali (protocollo, firma, PEC, PEO, ecc.) sia con le applicazioni legacy che con le nuove realizzate in modalità PaaS serverless, indipendentemente dal fatto che i servizi stessi fossero on premises o in cloud, con l’obiettivo di garantire astrazione e una transizione più fluida possibile fra i due mondi.
- Il secondo – “Change Support Team” – si occupa di governare il processo di change management e quello di problem management, con particolare attenzione all’implementazione delle nuove piattaforme applicative, fornendo esperienza e competenza ai vari progetti impegnati nelle ristrutturazioni.
- Il terzo – “Team DevOps” – si occupa della gestione e del governo delle piattaforme PaaS, con particolare attenzione all’utilizzo della metodologia omonima e degli strumenti per lo sviluppo agile, altre innovazioni tutt’altro che banali da introdurre, fortemente intrecciate al cloud ed essenziali per rispondere in modo veloce alle esigenze degli utenti dei servizi.
Il cambiamento non è stato certamente indolore, ma il nuovo assetto organizzativo (che ha peraltro integrato nei team anche personale dei principali fornitori e di Sogei) ha permesso di affrontare al meglio il percorso, mettendo a fattor comune le esperienze e le competenze dei vari attori.
Il nodo della sicurezza IT
Veniamo ora a quello che considero forse l’aspetto più critico del percorso verso il cloud, sia per le PA che per le aziende private, vale a dire l’assoluta necessità di cambiare radicalmente il proprio modello di sicurezza IT. Corte aveva (e ha tutt’ora) un’organizzazione di altissimo livello in ambito security, con processi fortemente strutturati e risorse umane e contrattuali di prim’ordine. Eppure, ci siamo scontrati con la totale inadeguatezza del modello classico di difesa rispetto alle infrastrutture cloud.
Quattro gli aspetti primari da tenere a mente:
- Il perimetro: concetto fondamentale nella sicurezza IT “classica”, dove spesso coincide con i firewall perimetrali (e le mura!) del proprio datacenter, nella sicurezza cloud diventa sempre più sfumato a mano a mano che si passa dai modelli IaaS a quelli PaaS, per diventare completamente astratto nei modelli SaaS. Da un perimetro composto di apparati e reti si passa ad un perimetro di servizi esposti, spesso conosciuti solo parzialmente, condiviso con migliaia di altri clienti. Perimetro difeso non più da noi ma dal fornitore di servizi cloud (Cloud Service Provider – CSP) con metodi e processi non banali da conoscere e comprendere, anche se in generale piuttosto efficaci;
- Processi e strumenti: per quanto possiamo aver strutturato correttamente organizzazione e tecniche di risposta agli incidenti, l’impatto con il cloud ci farà ricredere sulla loro efficacia. In generale si tenderà a pensare di poter reagire con i medesimi strumenti ai quali siamo abituati, ma ci si accorgerà (di solito in mezzo ad un attacco) di avere molte armi spuntate. Ad esempio, bloccare i tentativi di accesso ad un servizio SaaS in arrivo da una determinata serie di IP address potrebbe sembrare una banalità (on premises lo è), ma si rivelerebbe sostanzialmente impossibile, dato il diverso modello architetturale usato dal CSP (che in generale è completamente opaco per i clienti). D’altro canto, le architetture cloud più evolute forniscono “di serie” meccanismi e strumenti di audit e logging di altissimo livello, difficilmente impiantabili on premises se non a costi enormi (sia economici che organizzativi). Sono inoltre spesso presenti sistemi di sicurezza basati su Intelligenza Artificiale e analisi big data semplicemente impensabili da realizzare in proprio e concepiti per lavorare su volumi di milioni di utenti;
- Difesa dell’identità: è l’aspetto su cui focalizzare maggiormente l’attenzione, perché la stragrande maggioranza degli attacchi verso le piattaforme cloud sono indirizzati proprio a forzare i meccanismi di autenticazione degli utenti (password spray attack, brute force, dictionary attack ecc.). Ad aggravare la situazione il fatto che la gestione delle identità è quasi sempre realizzata con architetture ibride, dove le directory locali si federano con i rispettivi domini in cloud (si veda l’architettura Active Directory – ADFS – Azure Active Directory come esempio nell’ambito Microsoft Azure). E l’ibridazione richiede di difendersi sia nel modo classico che in quello “cloud compliant”. L’indicazione più importante di tutte è quella di utilizzare l’autenticazione a più fattori ogni qual volta sia possibile e di considerare la gestione classica delle password, basata su complessità e scadenza temporale, come completamente superata (si veda al riguardo la recente posizione di Microsoft).
Anche il disaster recovery diventa un servizio
Nel corso degli anni le previsioni normative hanno a più riprese prima imposto e poi rilassato il vincolo, per ciascuna Pubblica Amministrazione, di avere il cosiddetto “Polo di disaster recovery”, per far fronte a catastrofi più o meno gravi in grado di rendere indisponibile il datacenter primario.
Dando per scontato che avere un “piano B” è sempre un’ottima idea, ad una prima analisi sembrerebbe ovvio che, a fronte di una migrazione completa dei servizi verso il cloud, il problema di garantire il disaster recovery (DR) finisca in capo al Cloud Service Provider. In effetti, tutti i principali CSP consentono di configurare (ovviamente a prezzo maggiorato) macchine virtuali, piattaforme PaaS e servizi SaaS in modo da garantire la continuità operativa anche a fronte di indisponibilità del datacenter primario di erogazione. In pratica il disaster recovery diventa un servizio come un altro acquistabile sul market place del CSP.
Preparandoci a completare la migrazione verso il cloud, in Corte dei conti si è valutato che quanto sopra è sicuramente sufficiente per rispondere alle previsioni normative, ma che probabilmente è opportuno ragionare in termini di scenari di rischio diversi.
In particolare, la nostra analisi ha portato a concludere che ci si debba difendere dal rischio (remoto ma non nullo) di attacchi alle infrastrutture del CSP (in particolare quelle di gestione delle identità). A fronte di una loro indisponibilità generalizzata che si prolunghi oltre i tempi di ripristino massimi individuati dall’Amministrazione, l’impatto sull’organizzazione sarebbe persino peggiore dello scenario classico del “disastro”. La soluzione individuata passa per la realizzazione di un DR “virtuale” ospitato presso un CSP diverso rispetto a quello principale.
Ovviamente la questione è tutt’altro che banale, a cominciare dai problemi di lock-in (più seri per le piattaforme PaaS che per quelli IaaS) e va approfondita con metodi diversi rispetto a quelli usati nella classica redazione del “Piano di continuità operativa”. In particolare, potrebbe non essere possibile garantire la continuità operativa dei servizi in SaaS/PaaS (e occorrerà mettere in campo strumenti che quantomeno permettano di mettere al sicuro “altrove” i dati) e accettare tempi non brevi per il ripristino delle architetture IaaS più complesse. A mitigare lo scenario il fatto che incidenti talmente gravi da rendere indisponibili interi CSP sono estremamente rari (ad esempio l’incidente sull’MFA di Office365 di novembre 2018), abbassando il rischio a livelli tollerabili per molte aziende.
Concludendo, il nostro percorso verso il cloud è stato lungo e complesso. Abbiamo scontato il fatto di essere i primi nella PA italiana ad intraprenderlo, ma è stata una grande occasione per imparare un nuovo modo di erogare i servizi e per ripensare l’organizzazione interna. A breve il percorso sarà completato ed il risultato finale sarà un portafoglio servizi più efficace ed efficiente, nonché un maggior grado di soddisfazione dell’utenza.
