Interoperabilità dei protocolli informatici: a che punto è la notte?

lentepubblica.it

Marco Deligios esplora le potenzialità dell’interoperabilità dei protocolli informatici: tra criticità attuali e opportunità concrete per il futuro digitale della PA.

Mi gridano da Seir: «Sentinella, quanto resta della notte? Sentinella, quanto resta della notte?».  La sentinella risponde: «Viene il mattino, poi anche la notte; se volete domandare, domandate, convertitevi, venite!».
(Isaia,  21, 11-12)

Senza avere l’ardire di paragonarmi alla biblica sentinella, a cui da millenni si rivolge chi attende lo spuntare dell’alba, vale la pena di chiedersi, dopo più di vent’anni da quando si iniziò a parlare di interoperabilità tra i sistemi di protocollo informatico a che punto sia la sua attuazione.

Un po’ di storia

La storia dell’interoperabilità tra i protocolli informatici ha radici lontane: l’art 55 appariva nell’attuale formulazione già nella prima stesura del TUDA.

Le prime specifiche di interoperabilità furono quelle contenute nella Circolare AIPA 07-05-2001, n. 28  Standard, modalità di trasmissione, formato e definizioni dei tipi di informazioni minime ed accessorie comunemente scambiate tra le pubbliche amministrazioni e associate ai documenti protocollati.

La Circolare AgID 23-01-2013, n.60 Formato e definizioni dei tipi di informazioni minime ed accessorie associate ai messaggi scambiati tra le pubbliche amministrazioni intervenne a abrogare e sostituire la Circolare AIPA 28/2001.

Con l’adozione delle Linee guida sul documento informatico, la circolare AgID n. 60 venne abrogata e sostituita dall’allegato 6 alle LLGG Comunicazione tra AOO di documenti amministrativi protocollati. Recependo numerose richieste di modifica di associazioni di categoria e amministrazioni, AgID aggiornò – con Determinazione n. 371/2021 – l’Allegato 6 fissando al 1° gennaio 2022 l’obbligo di adozione.

Il messaggio di protocollo

A partire dalle specifiche contenute nella circolare AIPA n. 28 l’interoperabilità tra i sistemi di protocollo si è sempre fondata sulla trasmissione di un messaggio di protocollo, costituito da un documento principale, da un numero qualsiasi di allegati e da una segnatura.

La segnatura è costituita da un file xml contenente i metadati riguardanti il messaggio e funzionali alla registrazione da parte del destinatario. Nel tempo la struttura del file di segnatura si è evoluta e semplificata, restando però concettualmente invariata.

I cambiamenti più importanti hanno riguardato il canale di trasmissione del messaggio:

• La circolare AIPA 28 prevedeva la sola trasmissione tramite posta elettronica.
• La circolare AgID 60 ha affiancato alla posta elettronica la facoltà di scambiare messaggi tramite cooperazione applicativa basata sul Sistema Pubblico di Connettività e sul Sistema Pubblico di Cooperazione utilizzando le Porte di Dominio per trasmettere le cosiddette Buste di e-Gov.
• Prendendo atto dell’abbandono delle porte di dominio, sancito dalle Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni, l’allegato 6 alle LLGG ha previsto che lo scambio di messaggi protocollati avvenga tramite cooperazione applicativa preservando l’inoltro tramite posta elettronica sino al completamento dell’infrastruttura di cooperazione.

Gli obblighi per le amministrazioni

Come dicevamo, le pubbliche amministrazioni sono tenute al rispetto delle LLGG dal 1° gennaio 2022. L’allegato 6 alle LLGG al capitolo 3 prevede l’esposizione obbligatoria dei servizi di interoperabilità:

Per dare seguito alla comunicazione tra AOO mittente e AOO destinataria, le stesse adottano la modalità previste dalla norma basata sulla cooperazione applicativa, utilizzando il Simple Object Access Protocol assicurando l’implementazione delle interfacce di servizio riportate nell’Appendice B.

Per assicurare la comunicazione tra AOO le Amministrazioni DEVONO registrare e mantenere aggiornato, per ogni AOO individuata nella propria organizzazione, l’Indice dei domicili digitali delle pubbliche amministrazioni e dei gestori di pubblici servizi (IPA) con il prefisso condiviso dagli endpoint di esposizione dei servizi indicati nell’Appendice B.

Ne consegue che oggi un software di protocollo, per essere definito a norma, deve rendere disponibili i servizi (SOAP) e pubblicare il loro endpoint su IPA.

Quante sono le AOO che espongono gli endpoint su IPA?

Per farci un’idea dello stato di attuazione di quanto previsto dall’allegato 6 alle LLGG possiamo consultare il dataset delle Aree Organizzative Omogenee disponibile nella sezione OpenData di IPA.

Il file contiene i dati di 38.440 AOO, ma i contenuti dell’attributo URI_Protocollo_informatico, che dovrebbe obbligatoriamente contenere l’endpoint dei servizi previsti dall’allegato 6, è desolante:

• 37.816 AOO (98,38%) lasciano il campo vuoto
• 617 AOO (1,60%) popolano il campo con informazioni non pertinenti
• 7 AOO (0,02%) inseriscono l’URI di un WSDL (che, anche se non conforme alle indicazioni dell’allegato 6, almeno risponde)

Di fronte a questa drammatica situazione sarebbe bene ricordare cosa prevede l’ art. 6-ter del CAD:

La mancata comunicazione degli elementi necessari al completamento dell’Indice e del loro aggiornamento è valutata ai fini della responsabilità dirigenziale e dell’attribuzione della retribuzione di risultato ai dirigenti responsabili.

L’interoperabilità su PDND

L’avviso Misura 1.3.1 “Piattaforma Digitale Nazionale Dati” Comuni Ottobre 2022 ha finanziato, tra gli altri, l’esposizione su PDND dei servizi di interoperabilità tra i protocolli informatici.

Il 30 marzo 2023 AgID ha annunciato l’adozione della tecnologia REST per l’interoperabilità tra i protocolli delle PA con il conseguente aggiornamento “nelle prossime settimane (sic!)” dell’allegato 6 alle LLGG.

Nell’ambito del progetto sono state rilasciate le specifiche OpenAPI delle interfacce applicative in tecnologia REST, che troviamo pubblicate nel repository Github di AgID protocollo-comunicazione-aoo nel branch update-05-2023.

L’utilizzo della PDND per gestire l’interoperabilità tra i protocolli informatici presenta alcune criticità, che devono essere affrontate e risolte se non vogliamo continuare a usare la PEC come canale di trasmissione dei messaggi per altri vent’anni.

Un miliardo e mezzo di accordi di fruizione

La prima e più importante criticità sta nel meccanismo di fruizione dei servizi su PDND: attualmente una AOO di un’amministrazione dovrebbe stipulare (manualmente) un accordo di servizio con ciascuna delle possibili AOO destinatarie dei suoi messaggi. La stipula dell’accordo dovrebbe ovviamente avvenire preliminarmente all’invio, pena l’impossibilità per il mittente di trasmettere il messaggio.

Come ho avuto modo di osservare con una issue su github, la registrazione delle 37.816 AOO della PA come erogatori e fruitori di servizi su PDND comporterebbe 1.477.633.600 accordi di fruizione. È palese che si tratta di un’attività impossibile da gestire manualmente.

Le analoghe issues inserite sul repository github di AgID non hanno avuto ad oggi alcuna risposta.

La risoluzione di questo problema richiederebbe una importante revisione del modello autorizzativo della PDND. Questo potrebbe comportare ulteriori ritardi nel processo di integrazione.

È necessario rivedere l’allegato 6 e la documentazione di IPA

L’adozione del modello organizzativo proposto richiede di mettere mano all’allegato 6 delle LLGG del documento informatico e alla corrispondente documentazione di IPA.

Il 2,2% di amministrazioni interoperabili

Il 10% dei comuni italiani su PDND

Consultando gli opendata del catalogo della PDND scopriamo che, nonostante i finanziamenti erogati, le amministrazioni che hanno attivato servizi di interoperabilità del protocollo informatico sono 832, il 2,2% delle AOO presenti su IPA.

L’elaborazione degli opendata conferma l’estrema difficoltà di gestire automaticamente le stipule degli accordi di servizio.

I 1272 e-services che contengono la stringa “protocoll” devono essere depurati dai servizi di consultazione del protocollo. In seguito, devono essere depurati dai duplicati (33 comuni hanno registrato due e-service di integrazione, quale usare?). Al termine di questo lavoro si perviene a un elenco di 832 amministrazioni con venticinque descrizioni diverse: la libertà lasciata nella denominazione ha lasciato ampio spazio alla fantasia e ai refusi tipografici, una selezione automatica è impensabile.

Una conferma della difficile praticabilità del modello attuale viene dalla consultazione degli opendata relativi agli aderenti: dal dataset e_service_piu_utilizzati_from_the_beginning si evince che la palma del servizio Interoperabilità protocollo tra AOO con più sottoscrittori va, pari merito, ai comuni di Borgocarbonara e di Solofra con un sottoscrittore ciascuno!

Ripartire dal rispetto delle norme esistenti!

Come si usa dire: “il meglio è nemico del bene”. In attesa che si risolvano i problemi esposti è bene osservare che le attuali LLGG definiscono un modello di interoperabilità che potrebbe essere messo in funzione da domani mattina. In particolare:

• Definiscono le specifiche dei Webservices: in attesa del rilascio ufficiale delle specifiche REST, cosa proibisce di utilizzare l’architettura SOAP?
• Definiscono un modello di comunicazione sicura, basato su canale TLS nel rispetto delle specifiche WS-Security.
• Impongono l’obbligo di pubblicazione su IPA del prefisso comune degli endpoint (attributo URI_Protocollo_informatico dell’entità Area Organizzativa Omogenea dell’IPA). Non dimentichiamo che il mancato aggiornamento di IPA è sanzionato dall’art 6-ter, c. 3 del CAD!

Le obiezioni relative al fatto che gli endpoint pubblici potrebbero essere oggetto di attacchi informatici sono superate proprio dal fatto che la pubblicazione su IPA costituisce una garanzia di affidabilità del servizio. I servizi di protocollo-destinatario, al momento della ricezione di una chiamata possono verificare che il servizio protocollo-mittente sia censito su IPA, che fungerebbe anche da whitelist.

Il piano triennale e il protocollo informatico

Il piano triennale per l’informatica 2024-2026 ha lodevolmente inserito tra gli obiettivi la Formazione, gestione e conservazione dei documenti informatici.

Nell’ambito delle sue funzioni di vigilanza, verifica, controllo e monitoraggio, e conformemente a quanto stabilito dall’articolo 18-bis del Codice dell’Amministrazione Digitale – CAD, l’Agenzia per l’Italia Digitale ha pianificato di avviare un’attività di monitoraggio riguardante l’adempimento degli obblighi specificati dalle Linee guida.

Un’attività di monitoraggio che potrebbe essere svolta con estrema facilità è il controllo sistematico della presenza degli endpoint su IPA e della disponibilità dei relativi servizi.

L’esecuzione di questa semplice attività sarebbe un vero punto di svolta per una rapida attivazione dei servizi di interoperabilità.

Leggi anche: La segnatura di protocollo, tra analogico e digitale

The post Interoperabilità dei protocolli informatici: a che punto è la notte? appeared first on lentepubblica.it.