GithubHelp home page GithubHelp logo

Comments (6)

AndreaPiccoliDTD avatar AndreaPiccoliDTD commented on July 18, 2024

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 ?

from protocollo-comunicazione-aoo.

marco-deligios avatar marco-deligios commented on July 18, 2024

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.

from protocollo-comunicazione-aoo.

AndreaPiccoliDTD avatar AndreaPiccoliDTD commented on July 18, 2024

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.

from protocollo-comunicazione-aoo.

franthemanIT avatar franthemanIT commented on July 18, 2024

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...

from protocollo-comunicazione-aoo.

marco-deligios avatar marco-deligios commented on July 18, 2024

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

from protocollo-comunicazione-aoo.

AndreaTironi1 avatar AndreaTironi1 commented on July 18, 2024

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

from protocollo-comunicazione-aoo.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.