-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
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:
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 ? |
L'obbligo di utilizzo del protocollo informatico è sancito dal'art. 50 del TUDA
e nell'allegato 6 alle LGG del documento informatico:
È 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)
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. |
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. |
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 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... |
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. |
Direi che ora questo tema è centrale oltre che esponenzialmente non gestibile. |
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:
Situazione attuale di IndicePA
Su IndicePA nei metadati delle Aree Organizzative Omogenee (AOO) si legge:
Analizzando il dataset delle AOO si ottengono i seguenti risultati:
Considerazioni
Vincoli
Osservazioni
The text was updated successfully, but these errors were encountered: