Comunicazione alla Camera della Ministra del Lavoro e delle politiche sociali, Nunzia Catalfo in merito al disservizio del portale www.inps.it.

 

Alle ore 9 del 1° aprile erano già pervenute oltre 300 mila domande di indennità di 600 euro. A questo punto, in accordo con i tecnici Microsoft, che nel frattempo avevano effettuato il troubleshooting con i loro laboratori sulle cause che avevano portato al rollback del giorno precedente, l’INPS ha optato per riattivare il servizio CDN, questa volta su tecnologia Akamai, anche in considerazione del fatto che il servizio stava degradando a livelli non accettabili. Gli stessi tecnici del fornitore hanno configurato la soluzione predisponendo il sistema al servizio Akamai, che è stato attivato alle ore 10,20 del 1° aprile. Al momento dell’attivazione, come illustrato sempre dalla relazione INPS, si è palesato l’anomalo funzionamento del meccanismo di caching che di fatto ha provocato la replica di alcune schede anagrafiche presenti nel portale INPS, l’unico sottoposto a cache. Le applicazioni invece, risiedendo su altri domini non sottoposti a cache, non hanno risentito del problema di cache dei propri contenuti dinamici. Non appena sono emersi i primi segnali di un potenziale data breach, e per l’esattezza alle ore 10,30, è stato inviato il rollback della soluzione.

Alzi la mano chi ha capito!

Lavoro da parecchi anni nel settore dell’informatica ma devo ammettere che ho serie difficoltà a farmi un’idea di quello che è realmente successo durante il disservizio del sito web dell’INPS. Potrebbe essere una mia mancanza, non voglio e non posso parlare a nome di tutti gli informatici italiani. Una cosa posso dirla con certezza: sicuramente i non addetti ai lavori non avranno capito nulla.

Ho dovuto fare qualche ricerca online per farmi un’ idea vaga di quello che è accaduto. Dico vaga perché la certezza ce l’ha solo chi può leggere i log dei sistemi coinvolti. Mi scuseranno i puristi tecnici ma cercherò di dare una spiegazione la meno tecnica possibile ma che dia comunque l’evidenza della superficialità di come sia stata gestita la messa online del sito e la successiva emergenza.

Cominciamo con alcuni concetti base — scontati per molti — ma fondamentali per capire il senso generale del problema. Il sito web è un insieme di directory e file che sono i contenuti del portale e questi contenuti sono disponibili grazie ad una applicazione che risiede su uno o più server. Il client è il fruitore del servizio, e cioè l’utente che con il suo portatile apre il suo browser e digita il nome del sito. Il server — come ho scritto — rende visibili i suoi contenuti verso l’esterno. Il nome DNS di un sito è una traduzione “umana” di un numero chiamato indirizzo IP. Serve per facilitare la navigazione in quanto è più facile da ricordare www.sito.it invece di 10.10.20.20. La cache è banalmente un sistema per velocizzare l’accesso ai dati. In un sistema esistono vari livelli di memoria dove possono essere recuperati i dati e non tutti hanno la stessa velocità. Tipicamente nel mondo del web la cache viene fortemente usata per minimizzare l’accesso al server e massimizzare la rapidità con cui una pagina viene caricata. Nel cloud esiste il sistema CDN che utilizza questo meccanismo anche a livello geografico.

Ad esempio pensiamo ad una pagina con l’immagine del logo di una azienda e la sua organizzazione mentre su una pagina diversa — sempre dello stesso sito — una pagina con la sezione “news” e gli ultimi prodotti della ditta. E’ evidente che l’immagine dell’azienda è fisicamente presente nel server ma che senso ha accedere al server per caricarla ogni volta? Nessuno. Quindi entra in gioco la cache dei servizi cloud che è in pratica un sistema distribuito di “pezzi” di contenuto del sito in questione. L’immagine del logo viene distribuita su una moltitudine di apparati sparsi per il mondo e per l’italia. Pensate ad un utente di Roma che carica la pagina e prende il logo e il contenuto da un apparato situato nella stessa città invece che andare “fisicamente” a prenderlo dal server fisico installato in un CED a Milano. Oppure ad un utente in viaggio che al momento si trova in Cina il quale caricherà sul proprio browser l’immagine e il contenuto da un server situato in una sala macchina cinese invece che viaggiare per continenti fino ad arrivare a Milano. Il server web riceve meno richieste e quindi risparmia risorse e la pagina si carica più velocemente. Diverso invece è il discorso per la sezione “news” della pagina di cui stiamo parlando. Immaginiamo che le news siano date in tempo reale e che quindi il meccanismo di cache sia controproducente. L’utente vuole le notizie di adesso, non di ore fa.

Finita la doverosa premessa, che ammetto risulta molto semplificata ma lo spazio è quello che è, veniamo al punto centrale.

Viene impostata la CDN il giorno prima della partenza della pagina della richiesta dei 600 euro. Se fosse stata configurata bene sarebbe stata anche la scelta giusta. Il server DNS adesso è inps-cdn-a.azureedge.net mentre www.inps.it diventa il CNAME, in poche parole un alias. Si digita il nome del sito www.inps.it e si viene rediretti verso il sistema cloud distribuito di Microsoft Azure.

Il sito www.inps.it diventa un alias di inps-cdn-a.azureedge.net, la pagina “dinamica” per ricevere i famosi 600 euro è pronta sul sito. Dinamica perché — verosimilmente ma non l’ho vista — era una pagina in cui si doveva compilare una form in cui si specificavano alcuni dati tipo: nome, cognome, residenza, occupazione e così via. Questa veniva inviata al server e successivamente copiata nella cache. Tutta la pagina. I suoi contenuti statici e dinamici.

Avete già capito cosa è successo vero?

Mario Rossi compila la form con i suoi dati. La pagina con i suoi dati viene copiata nella cache e distribuita nel globo terracqueo.

Francesco Verdi entra nella pagina dei 600 euro e si ritrova loggato con il profilo di Mario Rossi.

Come scrivevo sopra non tutte le pagine vanno messe in cache. Tecnicamente va usato l’HTTP cache header in cui si configura se una pagina deve essere “memorizzata” per un riutilizzo veloce, per quanto tempo deve rimanere memorizzata nel sistema distribuito oppure se va dinamicamente ricostruita o richiesta sempre al sito originario.

Insomma quando si digitava www.inps.it non si andava sul server “fisico” ma sempre sulla distribuzione CDN. In pratica un alias, e si era diretti verso https://inps-cdn-a.azureedge.net/nuovoportaleinps/home.htm. La pagina caricata al cliente — chiunque accedesse — era sempre quella del primo utente nella propria area geografica.

Panico.

Si capisce subito il casino e si muove il garante della privacy. Cosa decidono di fare i tecnici? Tolgono la CDN. Tutte le richieste non vengono più cachate e vanno direttamente verso un unico server — o batteria di server — e l’applicazione esplode. Inoltre i record DNS ci mettono un po’ ad allinearsi e quindi alcuni utenti continuavano a vedere le pagine cachate, altri si ritrovavano la pagina corretta.

La violazione della privacy è talmente palese che ci saranno sicuramente ripercussioni legali per quanto è successo. Non è stato un attacco hacker o almeno, se lo è stato, è stato auto-inflitto.

Ah, vi state chiedendo il bando di gara per i servizi informatici quanto è costato?

La più recente gara del settore informatico, pubblicata il 26 maggio 2016, è relativa all’acquisizione di Servizi di “Application Development and Maintenance (ADM)”. E’ suddivisa in 7 lotti, per un importo complessivo a base d’asta di circa 360 milioni di euro (IVA esclusa) e durata contrattuale di 4 anni.