Concetti Preliminari¶

Il Modello di Interoperabilità mantiene sostanzialmente invariato il concetto di dominio di un’amministrazione rispetto a quanto prevedeva il precedente modello SPCoop. Resta quindi fondamentale individuare il perimetro d’azione delle interfacce dei servizi rispetto al sistema informativo dell’ente e i propri interlocutori.

Il concetto di dominio, che riveste particolare importanza nella gestione degli aspetti di sicurezza, si sposa perfettamente con i modelli di configurazione di GovWay dove è possibile attivare:

• erogazioni di API: richieste che provengono da amministrazioni esterne al dominio e sono dirette ad applicativi interni.

• fruizioni di API: richieste che provengono dagli applicativi interni del dominio e sono dirette verso altre amministrazioni.

La govwayConsole, all’atto della registrazione di Soggetti (Enti/Organizzazioni) e Applicativi (Sistemi/Applicazioni di un ente), consente di specificarne il Dominio, interno o esterno, al fine della corretta rappresentazione degli scenari di configurazione dei servizi.

Il profilo ModI prevede che i servizi siano basati su SOAP o REST fornendo sempre un descrittore formale delle interfacce basato su uno specifico IDL (Interface Description Language):

• WSDL 1.1 e successivi, per la descrizione delle interfacce SOAP

• OpenAPI 3.0 e successivi, per la descrizione delle interfacce REST

Nel processo di configurazione, tramite la govwayConsole, sono inoltre tenuti in considerazione tutti gli aspetti previsti dalle Linee Guida:

• Pattern di Interazione: definiscono la modalità con cui fruitore ed erogatore di un servizio interagiscono. Sono previsti i seguenti pattern:

  • Bloccante: il fruitore invia la richiesta è resta bloccato in attesa di ricevere la risposta, completa dei dati attesi, dall’erogatore

  • Non Bloccante: il fruitore non resta bloccato dopo aver inviato la richiesta, se non per ricevere una notifica di presa in carico. Per ottenere la risposta sarà necessario effettuare una distinta interazione, prevista nello scenario del servizio.

  • Accesso CRUD: pattern orientato alle risorse, utilizzabile solo su tecnologia REST, dove le API vengono utilizzate per eseguire operazioni di tipo CRUD - Create, Read, Update, Delete su risorse del dominio di interesse.

• Sicurezza Canale: gestione della sicurezza inerente il canale di comunicazione tra i domini fruitore ed erogatore. La specifica prevede i seguenti due pattern:

  • ID_AUTH_CHANNEL_01 - Direct Trust Transport-Level Security: comunicazione basata sul canale TLS dopo aver effettuato il trust del certificato X509 fornito dal dominio erogatore.

  • ID_AUTH_CHANNEL_02 - Direct Trust mutual Transport-Level Security: comunicazione basata sul canale TLS dopo aver effettuato il trust dei certificati X509, del fruitore e dell’erogatore, nella modalità di mutua autenticazione.

• Sicurezza Messaggio: gestione della sicurezza inerente lo scambio di informazioni tra le applicazioni agli estremi del flusso di comunicazione. I pattern di sicurezza previsti si distinguono per il caso SOAP e per quello REST:

  • ID_AUTH_SOAP_01 o ID_AUTH_REST_01 - Direct Trust con certificato X.509 su SOAP o REST: Tramite la validazione del certificato X509, inserito dall’applicazione mittente nel token di sicurezza della richiesta, l’applicativo destinatario verifica la corrispondenza delle identità e la validità del messaggio, prima di procedere con la produzione della risposta attraverso un trust tra fruitore e erogatore basato su certificati x509.

  • ID_AUTH_REST_01 tramite la Piattaforma Digitale Nazionale Dati (PDND): con l’aggiornamento delle linee guida nella “Determinazione n. 128 del 23 maggio 2023”, viene indicato di utilizzare la PDND per ottenere un token conforme al pattern ID_AUTH_REST_01; la costituzione del trust avviene attraverso il materiale crittografico depositato sulla PDND applicando i profili di emissione dei voucher previsti.

  • ID_AUTH_SOAP_02 o ID_AUTH_REST_02 - Direct Trust con certificato X.509 su SOAP o REST con unicità del messaggio/token: estensione dei pattern precedenti con l’aggiunta di un meccanismo di filtro che impedisce il processamento di un messaggio duplicato.

  • INTEGRITY_SOAP_01 o INTEGRITY_REST_01 - Integrità del payload del messaggio SOAP o REST: pattern che estende i precedenti aggiungendo la gestione della firma del payload come verifica di integrità del messaggio ricevuto.

  • INTEGRITY_REST_02 - Integrità del payload delle request REST in PDND: simile al precedente pattern INTEGRITY_REST_01, assume che il trust avvenga tramite il materiale crittografico depositato sulla PDND applicando i profili di emissione dei voucher previsti. All’interno del token viene indicato l’identificativo della chiave pubblica (kid) associata alla chiave privata utilizzata dal client per firmare il token di integrità; identificativo kid generato dalla PDND e recuperabile dall’erogatore tramite le API messe a disposizione dalla PDND stessa.

  • PROFILE_NON_REPUDIATION_01 - Profilo per la non ripudiabilità della trasmissione: estende i pattern di integrità allo scopo di fornire una conferma al fruitore da parte dell’erogatore della ricezione del contenuto della richiesta. Descrive inoltre la necessità di definire un arco temporale di persistenza dei messaggi utile per soddisfare l opponibilità ai terzi.

• Sicurezza Audit: consente all’erogatore di identificare la specifica provenienza di ogni singola richiesta di accesso ai dati effettuta dal fruitore. Le Linee Guida definiscono 2 pattern utilizzabili sia per API REST che per API SOAP:

  • AUDIT_REST_01- Inoltro dati tracciati nel dominio del Fruitore: definisce la struttura del token di audit utilizzabile in alternativa o tramite un criterio di trust realizzato tramite il materiale crittografico depositato sulla PDND o tramite il trust diretto fruitore-erogatore attraverso l’utilizzo di certificati X509. Le Linee Guida indicano che l’erogatore e il fruitore devono individuare i claim da includere nel JWT di audit e suggeriscono i seguenti dati che dovranno essere presenti nel token generato dal fruitore, per ogni richiesta effettuata:

    • userID, un identificativo univoco dell’utente interno al dominio del fruitore che ha determinato l’esigenza della request di accesso all’e-service dell’erogatore;

    • userLocation, un identificativo univoco della postazione interna al dominio del fruitore da cui è avviata l’esigenza della request di accesso all’e-service dell’erogatore;

    • LoA, livello di sicurezza o di garanzia adottato nel processo di autenticazione informatica nel dominio del fruitore.

  • AUDIT_REST_02 - Inoltro dati tracciati nel dominio del Fruitore con correlazione: pattern che estende il precedente aggiungendo la correlazione tra il token di autenticazione e il token di audit. Il pattern richiede un trust realizzato tramite il materiale crittografico depositato sulla PDND.

• URL di Invocazione API: le linee guida richiedono una indicazione esplicita della tecnologia utilizzata (REST o SOAP) e la versione. Le url con cui vengono esposte le API su GovWay soddisfano entrambi i requisiti.

Tutti questi concetti sono stati recepiti e gestiti nelle maschere di configurazione della govwayConsole, adottando il profilo ModI. Le sezioni seguenti illustrano in dettaglio gli elementi di configurazione integrativi rispetto al profilo API Gateway.