Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Esposizione dei servizi di interoperabilità tra protocolli informatici #64

Open
marco-deligios opened this issue Jun 5, 2023 · 6 comments

Comments

@marco-deligios
Copy link

Premessa

Il CAD, art. 6-ter impone l’obbligo di aggiornamento dell’Indice dei domicili digitali delle pubbliche amministrazioni e dei gestori di pubblici servizi
Dalle LLGG documento informatico: Allegato 6 – Cap. 3:

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.

Situazione attuale di IndicePA

Su IndicePA nei metadati delle Aree Organizzative Omogenee (AOO) si legge:

"COLUMN_NAME": "Protocollo_informatico"
"COLUMN_COMMENT": "Flag che indica la presenza/assenza di un protocollo informatico (valori S/N/null)"
"COLUMN_NAME": "URI_Protocollo_informatico"
"COLUMN_COMMENT": "URI del protocollo informatico in caso di sua presenza"

Analizzando il dataset delle AOO si ottengono i seguenti risultati:

  1. Su 37.715 AOO censite:
  • 3.643 dichiarano di non avere il protocollo informatico (sic!)
  • 479 dichiarano di avere il protocollo informatico
  • 33.593 lasciano il campo vuoto
  1. Delle 479 AOO che dichiarano di avere il protocollo informatico:
  • 478 compilano il campo URI_Protocollo_informatico
  1. Analizzando i 478 valori del campo URI_Protocollo_informatico si individuano le seguenti casistiche:
  • 251 sono indirizzi e-mail
  • 107 sono url del sito web dell’ente
  • 93 sono url dell’accesso web (si presume alla consultazione)
  • 27 sono privi di senso

Considerazioni

Vincoli

  1. Le Pubbliche Amministrazioni DEVONO adottare il protocollo informatico (dal 2015)
  2. Il sistema di protocollo informatico DEVE esporre le interfacce di servizio definite dalle LLGG
  3. Gli endpoint delle interfacce di servizio DEVONO essere pubblicati e mantenuti aggiornati su IndicePA

Osservazioni

  1. Le Linee guida dovrebbero chiarire, anche con esempi, come devono essere compilati i campi Protocollo_informatico e URI_Protocollo_informatico su IndicePA.
  2. IndicePA dovrebbe:
  • rendere obbligatoria la compilazione dei campi Protocollo_informatico e URI_Protocollo_informatico al momento del popolamento/aggiornamento dei dati della AOO
  • validare formalmente gli indirizzi degli endpoint
  • verificare che i servizi rispondano alle chiamate (SOAP/REST)
  1. Non è pensabile che i servizi di interoperabilità tra i protocolli informatici siano esposti sulla PDND per i seguenti motivi:
  • I servizi di interoperabilità tra i protocolli informatici devono (per loro natura) essere pubblici
  • La registrazione delle 37.715 AOO della PA come erogatori e fruitori di servizi su PDND comporterebbe 1.422.421.225 accordi di fruizione
@AndreaPiccoliDTD
Copy link

Sono del parere che si lascia il governo della interoperabilità legato a dei campi compilati in IPA dalle singole amministrazioni senza un controllo massivo e automatico di validazione si generi semplicemente una metodologia che non sarà utilizzata a causa dei troppi errori in invio che poterà le amministrazioni a utilizzare il vecchio (nuovo) sistema di interoperabilità via REM. Sono quindi due le strade possibili:

  • si validano i dati presenti in IPA e si tengono monitorati i servizi di interoperabilità e i solo SLA
  • si lavora su una parte del PDND gestita centralmente che riconosce gli end point delle singole amministrazioni, ed essendo un canale qualificato potrebbe non richiedere la firma Xades della segnatura.

Non mi è chiaro perchè si afferma che il servizio di interoperabilità tra AOO debba essere pubblico. Anzi deve essere un canale sicuro, affidabile e certo. Quanti attacchi di sicurezza si potrebbero fare agli end point pubblici di interoperabilità tra AOO ?

@marco-deligios
Copy link
Author

L'obbligo di utilizzo del protocollo informatico è sancito dal'art. 50 del TUDA
L'obbligo della pubblicazione su IPA è definito dall'art. 6-ter del CAD

Al fine di assicurare la pubblicità dei riferimenti telematici delle pubbliche amministrazioni e dei gestori dei pubblici servizi è istituito il pubblico elenco di fiducia denominato "Indice dei domicili digitali della pubblica amministrazione e dei gestori di pubblici servizi", nel quale sono indicati i domicili digitali da utilizzare per le comunicazioni e per lo scambio di informazioni e per l'invio di documenti a tutti gli effetti di legge tra le pubbliche amministrazioni, i gestori di pubblici servizi e i privati.

e nell'allegato 6 alle LGG del documento informatico:

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.

È certo che, sulla base delle prescrizioni normative, i campi previsti da IPA devono essere modificati rendendo obbligatorio l'inserimento degli endpoint e la loro validazione. Ricordo che il mancato popolamento dell'IPA è sanzionato (CAD, at 6-ter)

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.

Il servizio di interoperabilità deve essere pubblico perché così come una PA può inviare un messaggio a un'altra PA ottenendo la PEC/REM della AOO da IndicePA senza bisogno di registrazione, lo stesso deve poter fare con il canale Webservices (SOAP/REST)

La firma della segnatura serve a garantire l'immodificabilità di tutti documenti trasmessi, dal momento che nella segnatura sono inserite le impronte.

Gli attacchi di sicurezza si possono impedire utilizzando gli endpoint mittenti censiti su IPA come whitelist.

@AndreaPiccoliDTD
Copy link

La mia proposta è che l'allegato 6 e la realizzazione dell'interoperabilità su canale telematico deve avvenire per mezzo della integrazione della PDND e non con una modalità punto - punto su "url pubbliche" utilizzabili anche non da AOO.

Quindi i recapiti messi nell'IPA relativi alla interoperabilità di protocollo tra AOO (quindi tra soggetti pubblici) sarebbero già popolati con automatismi legati all'attivazione dell'ente sulla PDND, nel rispetto delle prescrizioni normative citate e senza aggravi ulteriori in carico agli enti.

Il servizio di interoperabilità tra AOO è tra enti pubblici (AOO appunto) e non pubblico nel senso ampio. L'adozione della PDND sebbene non obbligatoria dal punto di vista normativo, è in forte espansione sia per le integrazioni SIUS che ANPR/INAD. Non ha quindi senso pensare ad ulteriori canali telematici.

La PDND già garantisce la individuazione sicura del mittente e destinatario del flusso e garantisce l'integrità dei dati trasmessi in modo interoperabile come avviene per le altre API della piattaforma e quindi la sua adozione ai fini della interoperabilità di protocollo semplifica la necessità di firma Xades della segnatura.

@franthemanIT
Copy link

Se la firma XAdES della segnatura si mantiene è più sostenibile gestire il documento mantenendoci associata provenienza certa e integrità. Altrimenti occorre mantenere le varie request e response, più onerose da validare e senza certificatori qualificati (o quasi).
Poi può essere anche una firma (sigillo) non qualificato basato su dati di firma e validazione rilasciati da AgID o chi per lei (come per le PEC).

Poi ci possono essere vari altri modi.

La gestiione degli endpoint, a mio modo di vedere, non può funzionare né col paradigma del client e-service PDND né con l'endpoint pubblicato su IPA accessibile a tutti. Ok l'URL su IPA (poi si esprimano gli esperti di cyber) ma con il sistema di autenticazione previsto dalla PDND: quello c'è, magari a qualcuno ne piacciono di più altri, ma c'è quello (il token) e usiamolo.

Secondo me, già scritto, serve un nodo centrale, esposto, unico, lui solo, come API su PDND. Il nodo conosce gli endpoint delle p.a. (anche presi da IPA, anzi meglio, evitiamo ulteriori iscrizioni a servizi). Con buona pace dei casi d'uso PDND/PNRR per i comuni e il business plan ipotizzato dai fornitori...

Infibe, non ho approfondito, ma non vedo motivo per cui una non-PA debba usare il protocollo interoperabile, soprattutto perché non ha un protocollo informatico...

@marco-deligios
Copy link
Author

Personalmente non ho opposizioni a che i servizi siano raggiungibili dal PDND, ma occorre che si modifichi il meccanismo di sottoscrizione, è impensabile che una PA debba essere fruitore PDND per spedire un messaggio interoperabile.
Ho delle perplessità relativamente all'abbandono di IPA, perché l'obbligo di aggiornamento è normato nel CAD e sanzionato il mancato aggiornamento. Non essendo l'adesione alla PDND un obbligo sarà ancora più difficile indurre le PA a rispettare il vincolo.
Concordo con @franthemanIT circa la difficoltà di gestire i log di PDND come prova dell'invio. La norma sul protocollo (TUDA) specifica con chiarezza l'associazione della segnatura (finalmente firmata) con i documenti al momento della registrazione di protocollo

@AndreaTironi1
Copy link

Direi che ora questo tema è centrale oltre che esponenzialmente non gestibile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants