Il numero crescente di incidenti informatici che hanno coinvolto aziende private di carattere strategico e istituzioni pubbliche, soprattutto del settore sanitario, hanno riacceso la discussione di media e politica sulla necessità di un cloud nazionale al fine di proteggere adeguatamente i dati personali dei cittadini e delle istituzioni stesse.

Sembra tuttavia che l’argomento principale sia limitato all’infrastruttura fisica, ossia datacenter, server e reti di connessione, mentre poco o nulla si è detto riguardo ciò che su tali infrastrutture deve girare, ossia il software.

In effetti qualche parola si è spesa, parlando in particolare di crittografia e di chiavi di criptazione, ma l’argomento è stato trattato in modo alquanto naïf.

Quando si parla di cloud, occorre considerare che tutti i sistemi che lo costituiscono oltre a interagire tra loro interagiscono con sistemi esterni, sia direttamente ad esempio tramite servizi erogati da terzi (mappe, risorse grafiche, risoluzione di domini) sia indirettamente (ad esempio tramite servizi che sincronizzano l’orologio-calendario interno alla macchina).

Tutte queste interazioni costituiscono la superficie d’attacco che va considerata quando si fa la valutazione del livello di rischio del sistema cloud.

E’ evidente che già a questo livello di discussione il concetto di “cloud sovrano” sia da ridimensionare.

Dal punto di vista funzionale, il cloud è un sistema dinamico che permette di adeguare l’offerta di infrastruttura sulla domanda di servizio in un dato istante e in un dato luogo. Per questo nella stragrande maggioranza dei casi le macchine su cui girano i servizi sono macchine “virtuali” che possono essere spostate e moltiplicate a seconda della necessità, anche senza preavviso: la domanda di un dato servizio sono maggiori durante un click-day (eventualità che comunque ci auguriamo di vedere il meno possibile in futuro) che, per esempio, durante ferragosto. Le istanze di una CDN vengono spostate nei datacenter più geograficamente vicini agli utenti che le richiedono; per questo, sommato al fatto che l’utente di una pubblica amministrazione non è necessariamente ubicato sul suolo nazionale, potrebbe essere controproducente avere tutte le istanze raggruppate sul territorio nazionale o, peggio, in un unico datacenter. Turisti e connazionali ubicati all’estero avranno probabilmente frequente necessità di accedere a tale cloud.

Dunque riunire esclusivamente su infrastrutture nazionali tutti i servizi non solo è utopico, ma potrebbe essere anche poco efficiente, se non altro per questioni legale alla geografia.

Dal punto di vista della sicurezza, intesa come robustezza agli attacchi, una sola infrastruttura nazionale potrebbe essere un grandissimo punto debole: il concetto di ridondanza va applicato a tutte le risorse coinvolte in modo da non creare il “Single point of failure” che è di solito il più ghiotto tra i bocconi di un ipotetico avversario.

Come detto, l’argomento relativo alle risorse non hardware è stato limitato al discorso relativo alla crittografia. Questo è secondo me senza senso e fuorviante.

La crittografia moderna funziona perché si è abbandonato il concetto di nascondere l’algoritmo di cifratura; in realtà da secoli si è capito che una buona crittografia funziona se e solo se sono le chiavi ad essere segrete, mentre, viceversa, il consenso nel considerare l’algoritmo come robusto è un requisito fondamentale. Non ha quindi senso parlare di “Crittografia nazionale”, se non nel senso di inquadrare il tutto in un concetto che coinvolge non tanto gli algoritmi quanto piuttosto le procedure dietro la gestione di accessi alle risorse confidenziali. Gestire correttamente sottochiavi, accessi, credenziali e soprattutto la revoca delle stesse, è un punto critico di tutta la discussione.

Resta un punto dolente e assolutamente prioritario in tutta questa discussione.

Il software

Oggi il software di server e client è costituito a volte da centinaia di micro-componenti la cui natura e provenienza è la più disparata. Un meme assai famoso nel settore dell’infosec mostra una costruzione fatta di numerosi blocchi che poggiano su un singolo mattone “mantenuto gratuitamente da un ignoto sviluppatore in Illinois”. Esso descrive benissimo la situazione di software e sistemi in tutto il mondo.

L’incidente con il componente Log4j lo dimostra pienamente. Ci vorranno probabilmente anni prima che tutti i componenti critici che ne fanno uso siano aggiornati, e di qui ad allora si moltiplicheranno i casi di violazione attraverso questa vulnerabilità.

E’ dunque prioritario, prima ancora che discutere di infrastrutture, che la pubblica amministrazione si doti di un framework di lavoro costituito da procedure, prassi, linee guida, e infine anche moduli software che garantiscano una corretta gestione dei sistemi e delle infrastrutture su tutti i livelli; ed è prioritario anche che siano ridotte sensibilmente le migliaia di componenti utilizzate nelle varie amministrazioni con un set di moduli software comuni che siano analizzati, censiti, monitorati e soprattutto mantenuti, fin dalla loro introduzione nel framework, al fine di gestire correttamente il loro uso e il loro ciclo di vita, identificando e correggendo le eventuali vulnerabilità prima che esse vengano sfruttate per violare i sistemi del cloud nazionale.

Questi punti sono, secondo il mio parere e la mia esperienza acquista negli anni sul campo, molto più critici. Abbiamo una PA che risulta spesso anni luce indietro rispetto ai privati, sia dal punto di vista tecnologico che ancor più dal punto di vista della gestione. E’ molto più grave avere servizi gestiti con orario da sportellista o con procedure mutuate dal mondo analogico che avere i server ubicati in un’area geografica rispetto ad un’altra.