Ma quale attacco hacker. Quello che ha colpito il sito dell'INPS proprio durante la corsa al bonus previsto dal decreto Cura Italia è solo un altro esempio di gestione approssimativa di un sito web, che in questo caso assume contorni ancora più gravi perché a finire al centro di un problema tecnico – perché di questo si è trattato – sono stati i dati personali degli utenti. Cittadini iscritti al (costoso) sito dell'INPS che hanno visto i propri dati personali finire davanti agli occhi di migliaia di persone. "Violenti attacchi hacker" è stata la spiegazione del presidente dell'Istituto nazionale della previdenza sociale, Pasquale Tridico. Ma se da un lato attacchi di questo tipo possono aver gravato sulle prestazioni dei server, dall'altro è chiaro che il problema relativo all'esposizione dei dati sia stato causato da una gestione approssimativa e scorretta dei server e dei servizi cloud utilizzati dall'Inps per operare.
Cosa sono i CDN (Content Delivery Network)
Facciamo un passo indietro. Per supportare una mole di traffico considerevole, i portali più grandi – compresi quelli della Pubblica Amministrazione – fanno uso di CDN, cioè dei "Content Delivery Network" (rete per la distribuzione di contenuti). In breve, si tratta di servizi in cloud offerti da diversi provider che comprendono la possibilità di utilizzare i server della rete globale per "avvicinare" i dati agli utenti finali, permettendo "di ridurre i tempi di caricamento, risparmiare la larghezza di banda e accelerare i tempi di risposta" si legge sul sito di Microsoft Azure, uno dei provider più utilizzati e quello finito al centro della problematica dello scorso 1 aprile. Ciò significa che chi distribuisce contenuti può farlo utilizzando server posizionati in prossimità degli utenti finali, evitando in questo modo che i dati viaggino, per esempio, da un server degli USA fino a un utente in Giappone.
I CDN sono servizi a pagamento che vengono implementati durante la progettazione del sito web e poi attivati quando necessario, per esempio in previsione di una giornata particolarmente pesante come quella dell'attivazione delle domande per il bonus del decreto. Generalmente questi servizi hanno un costo a consumo, ma per molte aziende – e presumibilmente per la PA – vengono stipulati contratti che ne consentono l'utilizzo a fronte di una spesa unica. Attenzione però: questi servizi vengono solamente forniti alle aziende che poi devono essere in grado di implementarli. In ogni caso, la mattina dell'1 aprile il sito dell'INPS ha attivato il suo CDN sulla rete Microsoft Azure (e basato su data center Akamai): lo sappiamo perché in quel momento il sito web www.ipns.it è diventato un CNAME (cioè un alias attraverso il quale è possibile raggiungere lo stesso indirizzo IP) rimandante a inps-cdn-a.azureedge.net. Qui sono iniziati i problemi.
Cos'è successo al sito dell'Inps
La decisione di attivare il CDN, come spiegavamo poco sopra, viene presa generalmente per avvicinare i dati agli utenti finali e rendere più rapida l'esperienza all'interno di un sito. Ma, come in questo caso, può essere presa anche per distribuire meglio il traffico sulla rete, evitando congestioni causate da migliaia di connessioni simultanee a un sito web. In breve, viene hostato lo stesso portale su più server e, quando ci si collega all'indirizzo www.inps.it, il CDN decide in base a diversi fattori verso quale server fisico indirizzare gli utenti. Non avviene più la connessione diretta all'IP dei server dell'Inps, quindi, ma una connessione all'indirizzo inps-cdn-a.azureedge.net che poi "smista" il traffico sui vari server. Tutto corretto, se non fosse che per poter gestire questo traffico bisogna impostare correttamente il CDN. Cosa che, a quanto pare, non è stata fatta.
Il problema è da ricercare proprio nelle impostazioni degli HTTP Cache Headers, una parte della richiesta/risposta HTTP (quello che chiede il browser/quello che invia il server come risposta) per gestire la cache, cioè il sistema utilizzato per evitare di sovraffollare un server salvando le pagine per un tot tempo. Attraverso questo sistema vengono gestiti diversi elementi della cache, come ad esempio per quanto può essere salvata o se non è possibile mettere quel determinato contenuto in cache. Generalmente, se viene richiamata la stessa pagina entro il tempo previsto dal salvataggio, la richiesta non va al server ma è il browser (o, come in questo caso, il server senza elaborazione) che rimanda la stessa pagina salvata. E nel caso dell'Inps, le pagine salvate in cache erano quelli degli altri utenti.
Il ruolo della cache
È qui che inizia a tornare tutto: non avendo configurato correttamente questo sistema, quando il sito dell'Inps – e quindi il CDN – riceveva una richiesta da un utente, questo veniva inviato su uno dei server meno appesantiti che, a causa di un errore di configurazione, mostrava la cache salvata in quel momento. In uno scenario distribuito, cioè uno stesso sito hostato su più server, è necessaria una differente strategia di gestione della cache che permetta di avere un'esperienza coerente indipendentemente dal server fisico su cui viene fatta la richiesta. Qui è mancato questo meccanismo, quindi la CDN ha iniziato a traghettare le richieste su altri server meno intasati, che però sparavano fuori le cache salvate e, quindi, i profili di altri utenti.
Il risultato? Profili di utenti – ma ricorrenti, come dimostrano le segnalazioni sui social – hanno iniziato ad apparire davanti agli occhi di chi riusciva a effettuare il login. È per questo che tutti inizialmente hanno visto il profilo di Valerio V. ed è per questo che dopo diversi minuti – cioè quando la cache è scaduta e il server ne ha salvata un'altra – è apparso Bruno A. e così via, fino a quando l'Inps ha eliminato il CDN mal configurato ripristinando l'indirizzo IP diretto al suo server. Cioè la situazione per la quale chiaramente la cache è stata progettata: rispondere a un unico server e non a uno scenario distribuito. Che ha mandato in palla l'intero sistema creando e moltiplicando le cache relative ai profili di altri utenti. Altro che attacco hacker.
