Sicurezza, ICT e altro

Il primo febbraio sono riuscito ad iscrivermi al Registro delle Opposizioni. O meglio, sono sempre in attesa della mail di conferma, ma la mia parte online l’ho completata. Ammetto che per riuscirci ho usato qualche trucco da informatico. Niente di irregolare, capiamoci: semplicemente, immaginando perché il sistema rispondeva male, mi sono comportato di conseguenza e dopo tre o quattro minuti mi sono iscritto (anche perché non avrei avuto tempo di provarci più a lungo). Risulto iscritto, perché se adesso che il sistema è scarico ci riprovo, mi dice che sono già iscritto e che mi serve il PIN per verificare o modificare la mia posizione. Ma io il PIN non l’ho ricevuto (no, non è fra lo spam). Probabilmente, in quel primo giorno di passione il sistema ha avuto problemi anche nell’invio delle mail.

In quegli stessi giorni si è discusso dei sovraccarichi del sistema che deve ricevere i certificati online. Anche questo non ce la fa, soprattutto, pare, nei prevedibili picchi del lunedì. Seppure simili, i due casi sono molto diversi: il picco del Registro è una tantum, e non avrebbe ovviamente senso dimensionare un sistema per sopportare un evento così occasionale, quando a regime probabilmente l’attività sarà quasi nulla, almeno per la componente destinata agli abbonati. Nel caso dell’INPS invece, il picco del lunedì è certamente “sistemico” e dovrà essere gestito.

Però entrambi questi due casi hanno una caratteristica che sembra comune a buona parte dei servizi della Pubblica Amministrazione, ovvero di avere un traffico molto oscillante, con picchi in date precise e prevedibili. C’è stato un problema simile quando hanno cominciato ad essere obbligatori gli F24 online, e immagino che i sistemi utilizzati per il “click day” siano stati anch’essi dimensionati per un picco di traffico pauroso che però si presenta per pochi giorni all’anno (sarei curioso di sapere cosa viene fatto di quei sistemi negli altri giorni).

L’informatica può fare moltissimo per la Pubblica Amministrazione, riducendo il lavoro meccanico e ripetitivo, permettendo di usare meglio le informazioni, e consentendo quindi di concentrarsi sull’attività importante, cioè pensare e decidere. Ci sono però diverse difficoltà. Una, tecnica, è data dalla babele delle procedure, programmi e formati in uso nelle Pubbliche Amministrazioni, complice naturalmente l’elevata autonomia che hanno soprattutto le Amministrazioni Locali nel decidere di fare tutte la stessa cosa, ma ognuna in modo diverso (un esempio tipico sono le anagrafi). Un altro problema è il difficile rapporto fra personale (della PA, nello specifico), informatica e informatici. Ma un altro problema importante, che è quello di cui voglio parlare, è che troppo spesso i servizi innovativi proposti all’utente, proprio nel momento di maggiore attenzione, cioè quello del lancio, falliscono clamorosamente. L’impressione che rimane quindi, anche quando poi le cose vanno a regime, è quella di un’innovazione raffazzonata e inaffidabile, anche quando in realtà i benefici sono notevoli. Entrambi i casi sono rappresentativi. Prendiamo il caso del Registro. Probabilmente centinaia di migliaia di italiani, se non milioni, aspettavano l’attivazione del Registro, per potersi liberare di una cosa che molti, io compreso, non considerano affatto una parte importante della nostra economia ma solo una rottura di scatole, anche un po’ prevaricatrice. Altri strumenti non avevano funzionato, questo ne ha le potenzialità. Se avesse funzionato, si avrebbe avuta la sensazione meravigliosa di liberarsi “con un click” delle telefonate commerciali. Chi lo avesse fatto ne avrebbe parlato con entusiasmo ai suoi amici. Un successo, insomma. Invece, chi ci ha provato ha trovato un sistema piantato. Probabilmente avrà rinviato l’iscrizione “di qualche giorno”, salvo poi eventualmente dimenticarsene almeno fino alla prossima telefonata commerciale, ma nel frattempo raccontando a parenti e amici l’ennesimo fallimento dell’innovazione. Il fatto che al successivo tentativo le cose funzionino non gli toglierà la sensazione di un’innovazione che “funzionicchia”.

Il caso dei certificati è simile. Non dover portare il certificato di persona (da ammalati?) all’INPS è un’enorme comodità. Se il sistema avesse funzionato da subito, un ammalato che veda il proprio medico comunicare “in diretta” la malattia all’INPS ne avrebbe tratto l’impressione di un’innovazione veramente utile. Invece, adesso al centro dell’attenzione c’è il paradosso per cui se il medico non comunica la malattia, ad esempio perché non riesce, le conseguenze se le prende il dipendente (già ho sentito qualcuno dire che se il medico non riesce a contattare l’INPS, il medico stesso verrà “sequestrato” dall’ammalato finché non ci riesce 😉 ). Anche quando il sistema andrà a regime, rimarrà la pessima sensazione.

Dicevo, alla base c’è l’andamento “a picchi” che hanno molte comunicazioni fra cittadino e PA, picchi per la maggior parte ben prevedibili perché di fatto definiti a tavolino da chi stabilisce tempi e scadenze per le diverse pratiche. Ognuno dei sistemi che gestisce questi servizi deve essere dimensionato per gestire questi picchi, e ognuno probabilmente in caso di picchi particolarmente alti può risultare ciononostante inadeguato. Ognuno di questi sistemi deve essere progettato, appaltato (eh, sì…), realizzato e mantenuto, con costi anch’essi sovradimensionati rispetto all’uso normale. È difficile che a un informatico, di fronte a un problema di questo tipo, di questi tempi non venga in mente la parola “cloud”. A me sembra un caso da manuale: il cloud permetterebbe di concentrarsi sul servizio, e permetterebbe di assorbile i picchi dei diversi servizi, che potrebbero per la loro natura essere pianificati per non coincidere. Questo porterebbe a un’affidabilità molto maggiore dei servizi, e gli italiani potrebbero smettere di prevedere con tanta certezza (come tutti hanno fatto per il Registro) che all’avvio i servizi innovativi non funzionino. Sia chiaro che sto parlando di cloud infrastrutturale, l’unico che mi sembra praticabile in tempi e modi ragionevolmente definibili, anche data l’eterogeneità delle applicazioni  e dei servizi delle nostre PA. E sia chiaro anche che sto parlando di un cloud “privato” per le PA, non certo di un servizio acquistato su un cloud pubblico. Le PA hanno tutta la massa critica necessaria per rendere conveniente un cloud privato (certamente enormemente più conveniente dell’attuale galassia di sistemi separati, e tanto mi basta), mentre sono assolutamente certo che l’acquisto di un servizio da terzi si tradurrebbe in una completa perdita di controllo dei dati.

A questo punto però si pone un problema: una buona parte delle informazioni che passano fra Pubblica Amministrazione e cittadino ha una sua bella criticità in termini di riservatezza, e spesso di integrità. Chi, con i precedenti che abbiamo, si sentirebbe tranquillo sapendo che su un unico “sistemone” ci sono, o almeno transitano, dati sanitari, anagrafici, relativi all’attività lavorativa, fiscali, previdenziali, magari anche giudiziari, e chi più ne ha più ne metta? Io, francamente, no. Ritengo che i modi e i criteri con cui verrebbe progettato, appaltato e gestito un tale sistema non mi darebbero, allo stato attuale, nessuna tranquillità di un’effettiva protezione di quei dati. Non mi riferisco necessariamente a malaffare e incompetenze, che comunque possono certamente aggravare la situazione. Mi riferisco al fatto che un sistema di questo genere sarebbe, non per sua natura ma per come verrebbe realizzato e gestito, del tutto non auditabile e non auditato, non in un modo che possa dare tranquillità al cittadino.

Prima di tutto, la nostra Pubblica Amministrazione è ancora estremamente opaca. Tanto per fare un esempio di quello che intendo, negli Stati Uniti si sente continuamente (tanto che la notizia arriva anche da noi) di commissioni di controllo che verificano l’operato delle pubbliche amministrazioni: come spendono i soldi, quanto sono efficaci ecc. Spesso sono realmente bipartisan (termine che in USA ha ovviamente un significato diverso che in Italia), per quanto mi è dato di capire, e sicuramente rilevano dei problemi con una certa frequenza. Soprattutto, quello che viene scoperto da queste commissioni viene pubblicato e i cittadini vengono informati. Qui un esempio di quello che intendo, ma ce ne sono molti altri.

Ma se passiamo all’informatica e al cloud, la cosa è molto, molto più difficile. Il problema che si pone, nel migliore dei casi, è quello degli “spioni fiscali“, nel peggiore quello di amministratori di sistema corrotti che cedano i dati a terzi o addirittura li modifichino.

Il problema dell’audit di cloud  (o anche di servizi in outsourcing in generale) è quasi sempre visto solo da un punto di vista contrattuale o organizzativo: come faccio a essere sicuro di avere titolo e modo di auditare l’infrastruttura alla quale mi appoggio? Ma il problema più grave, almeno in questo contesto, è che anche avendo pieno accesso ai sistemi, se ci fosse qualcosa di nascosto con un minimo di cura, sarebbe difficile trovarlo. È il problema evidenziato dal Garante quando ha affrontato il ruolo degli amministratori di sistema, e già evidenziato nella pratica da diverse vicende (Laziomatica, lo “scandalo Telecom“, i già citati spioni fiscali, giusto per citare i casi eclatanti e soprattutto noti e pubblici). La mia preoccupazione non è tanto il problema dell’accesso abusivo da una macchina virtuale all’altra, sono abbastanza fiducioso che per quello i meccanismi di controllo si possano trovare e implementare in modo soddisfacente, la mia preoccupazione è la gestione dell’infrastruttura. Con i precedenti che abbiamo, il dubbio sulla custodia dei custodi dovrebbe essere chiaro.

Se c’è una cosa che ho imparato in questi anni è che i problemi di sicurezza informatica non hanno mai impedito che le cose venissero fatte, nel bene e nel male. Il meglio che si può fare quindi è ragionare su come si può realizzare al meglio un cloud governativo che offra delle garanzie ai cittadini sul trattamento dei loro dati. Non credo che sia un problema senza una soluzione praticabile, ma non credo che la soluzione possa scaturire dalle prassi attuali delle nostre PA. Servirebbe un’architettura disegnata fin dall’inizio con l’auditabilità e la possibilità di limitare e monitorare realmente le attività degli amministratori come caratteristiche fondamentali, forse anche principali. Qui si vede di nuovo il senso della scelta di un cloud infrastrutturale: renderebbe certamente più semplice separare il ruolo di amministratore del cloud da quello di amministratore dei dati e servizi di una singola PA, permettendo quindi di limitare, monitorare e auditare meglio le attività dell’amministratore del cloud, decisamente la figura più critica. Per ottenere tutto questo non ci si potrebbe però limitare ad una generica richiesta di “auditabilità e strumenti di monitoraggio” in una gara di appalto, scegliendo poi l’offerta “meno peggio” in una selezione basata comunque principalmente sui costi e fatta secondo i canoni di progettazione abituali. Per di più, l’attività di audit e monitoraggio non dovrebbe essere potenziale o occasionale, ma continua e metodica. Un esercizio molto difficile, ma praticabile, ma solo se ne viene riconosciuta l’importanza.

ENISA ha recentemente pubblicato un rapporto sul tema della sicurezza di cloud governativi. È un ottimo rapporto, che analizza il problema da diverse prospettive, dando delle importanti indicazioni al “decision maker”. Ma naturalmente, alla fine sarà il decision maker al quale si rivolge un tale rapporto a dover valutare nel concreto sia l’entità effettiva dei rischi legati alle diverse scelte che l’efficacia delle soluzioni disponibili.