Skip to content

GovWay v3.3.15
Compare
Choose a tag to compare
@andreapoli andreapoli released this 05 Aug 06:36
· 57 commits to master since this release
3.3.15
07ecc8c

Nuova funzionalità di cifratura delle informazioni confidenziali

È stato aggiunto il supporto alla gestione delle informazioni confidenziali memorizzate su database e delle chiavi/keystore presenti su filesystem attraverso la cifratura/decifratura dei dati mediante una master key, utilizzando uno dei seguenti approcci:

  • HYOK (Hold Your Own Key): le operazioni di cifratura e decifratura avvengono utilizzando una master key presente in un keystore memorizzato su filesystem o all'interno di un HSM.

  • BYOK (Bring Your Own Key): la master key viene depositata su un servizio remoto (es. in cloud). In questo caso, le operazioni di wrap-key e unwrap-key delle informazioni confidenziali vengono gestite tramite chiamate API esposte dal servizio remoto.

La console di gestione è stata modificata per:

  • assicurare la cifratura dei campi contenenti informazioni confidenziali;

  • consentire l'indicazione di una modalità 'unwrap' di un keystore cifrato riferito nella configurazione di un connettore https o nella sicurezza messaggio (es. token ModI);

  • consentire la registrazione di proprietà definite con un valore cifrato nei seguenti elementi di registro:

    • API erogata o fruita
    • soggetto
    • applicativo
    • configurazione globale

È stato inoltre realizzato il supporto per inizializzare una serie di variabili Java che potranno essere riferite in qualsiasi file di proprietà di GovWay presente nella 'directory-lavoro' e nelle configurazioni di GovWay (es. all'interno di una trasformazione).

La definizione di una variabile può essere attuata all'interno di due file differenti:

  • govway.map.properties: le variabili definite in questo file verranno caricate all'avvio di tutte le applicazioni GovWay (es. runtime, console, batch ecc.);

  • govway.secrets.properties: a differenza del precedente file, i valori delle variabili potranno essere definiti cifrati e GovWay si occuperà di decifrarli prima del loro caricamento nel sistema.

Miglioramenti alla funzionalità di Tracciamento

Migliorata funzionalità di tracciamento introducendo la possibilità di
personalizzare l'aggiornamento delle tracce su database e/o su file (FileTrace) in
corrispondenza dei 4 eventi principali della gestione di una richiesta:

  • Richiesta ricevuta
  • Richiesta in consegna
  • Risposta in consegna
  • Risposta consegnata

La modalità di tracciamento può essere personalizzata sia a livello di configurazione generale che per le singole erogazioni o fruizioni. Inoltre, per ogni evento, GovWay può essere configurato per far terminare la richiesta con errore in caso di tracciamento fallito o proseguire segnalando l'anomalia solamente nei log.

Per il caso di richiesta terminata con un errore di tracciamento è stato aggiunto il nuovo esito di 'Tracciamento Fallito'.

Sono state introdotte le seguenti nuove funzionalità di tracciamento su file (FileTrace):

  • possibilità di attivare il tracciamento rispetto all'esito di una transazione;

  • è possibile modificare la configurazione di default per ogni singola erogazione o fruizione, nello specifico per:

    • il file di configurazione che definisce il formato del log;
    • l'attivazione o meno del buffer dei messaggi, che consente di registrare gli header HTTP e il contenuto del payload;

  • possibilità di utilizzare una chiave/keystore cifrata e specificare la policy necessaria per decifrarla, prima di utilizzarla per la cifratura dei dati registrati nel log.

Nel menù principale la configurazione a livello globale del tracciamento e della registrazione messaggi è stata suddivisa in due voci distinte.

Infine è stato modificato il comportamento predefinito in modo che il tracciamento delle richieste che violano una politica di RateLimiting sia disabilitato.

Miglioramenti al Profilo di Interoperabilità 'ModI'

È stato introdotta la gestione del 'soggetto intermediario', che consente di autorizzare una richiesta proveniente da un soggetto identificato sul canale e da un applicativo appartenente a un soggetto differente, identificato tramite token di sicurezza.

Nell'occasione, è stato affinato il processo di autenticazione:

  • Il processo di identificazione degli applicativi veniva inutilmente attivato per l'autenticazione MTLS delle erogazioni, anche se con tale profilo gli applicativi possono essere censiti solamente con credenziale di tipo 'token' o con certificato di firma; tale controllo è stato pertanto eliminato.

  • I controlli di esistenza di un applicativo già registrato con lo stesso certificato sono stati affinati al fine di escludere gli applicativi con profilo di interoperabilità 'ModI' di un dominio esterno, poiché tali certificati non si riferiscono a credenziali TLS ma vengono utilizzati solo per firmare token di sicurezza.

Sono stati apportati i seguenti miglioramenti alla funzionalità di integrazione con la PDND:

  • aggiunta, nelle politiche di Rate Limiting, la possibilità di conteggiare per nome dell'organizzazione ottenuta tramite le API di interoperabilità della PDND;

  • aggiunta la possibilità di modificare sulla singola erogazione o fruizione il comportamento di default per far fallire la transazione nel caso in cui il recupero delle informazioni sul client o sull'organizzazione tramite API PDND fallisca;

  • le informazioni sull'organizzazione, recuperate tramite le API PDND, vengono ora propagate al backend tramite gli header di integrazione: GovWay-Token-PDND-OrganizationName, GovWay-Token-PDND-OrganizationCategory e GovWay-Token-PDND-OrganizationExternal.

Sono infine stati apportati i seguenti miglioramenti:

  • (#161) aggiunta validazione dei campi contenenti codici crittografici come ad esempio il clientId o il KID relativo ai token pdnd;

  • in una configurazione che prevedeva un access token PDND (ID_AUTH_REST_01), il claim 'jti' presente all'interno del token non veniva utilizzato come identificativo messaggio della richiesta, alla quale veniva invece associato un identificativo generato da GovWay. L'anomalia comportava:

    • un doppio tracciamento sia del claim 'jti' che dell'identificativo generato da GovWay;
    • una valorizzazione dell'header di integrazione 'GovWay-Message-ID' con l'identificativo generato da GovWay invece del jti.

Miglioramenti alla funzionalità dei Connettori

È adesso possibile specificare il metodo di autenticazione 'Api Key' (#159) consentendo di inviare al backend una chiave di identificazione veicolata in un header http come descritto nella specifica 'OAS3 API Keys' (https://swagger.io/docs/specification/authentication/api-keys/).

Viene supportata anche la modalità 'App ID' che prevede oltre all'ApiKey un identificatore dell'applicazione, modalità denominata 'Multiple API Keys' nella specifica 'OAS3 API Keys'.

La configurazione permette anche di personalizzare il nome degli header http, rispetto a quanto indicato nella specifica 'OAS3 API Keys'.

Inoltre è stata aggiunta la possibilità di abilitare o disabilitare la funzionalità di 'encoded word' per i valori degli header HTTP, oltre alla possibilità di personalizzarne gli aspetti di codifica per singole erogazioni o fruizioni di API attraverso la definizione di proprietà specifiche.

Miglioramenti alla funzionalità di Gestione dei Token

È ora possibile definire una token policy di validazione tramite una 'well-known URL' come descritto nella specifica 'https://swagger.io/docs/specification/authentication/openid-connect-discovery'.

Inoltre, è stata aggiunta la possibilità di definire il keystore contenente le chiavi necessarie per effettuare una 'validazione JWT' del token, anche indicando un endpoint.

È stata aggiunta la possibilità di utilizzare policy OCSP nei connettori HTTPS riferiti nelle token policy di validazione e negoziazione.

Nella configurazione di una token policy di negoziazione, è ora possibile indicare di utilizzare direttamente il payload di risposta HTTP come access token.

Infine, è stato risolto un problema che si presentava selezionando un'autenticazione HTTPS client nella funzionalità specifica di introspection o userinfo, senza abilitare l'endpoint HTTPS nella sezione token. In questo scenario, la gestione personalizzata dei keystore utilizzati per la connessione HTTPS non veniva attivata.

Miglioramenti alla funzionalità di Sicurezza Messaggio

La funzionalità di verifica dei certificati, abilitabile tramite la console di gestione, include adesso anche la validazione dei keystore riferiti nella configurazione della sicurezza dei messaggi.

Inoltre, è stata aggiunta la possibilità di disabilitare la 'Compliance BSP 1.1' nella validazione di un messaggio contenente WS-Security Username Token.

Infine sono state introdotte opzioni aggiuntive che consentono di modificare alcuni aspetti relativi alla sicurezza del messaggio attuata tramite la libreria 'wss4j', al fine di renderlo interoperabile con altre librerie più datate:

  • encoding in base64 dell'attachment prima o dopo aver applicato la sicurezza;

  • gestione dell'elemento 'InclusiveNamespace' in presenza di lista di prefissi vuota e all'interno dell'elemento 'CanonicalizationMethod';

  • gestione dell'elemento 'KeyInfo' presente all'interno dell'elemento 'EncryptedData';

  • aggiunta o meno delle parentesi uncinate ('<' e '>') nei riferimenti agli allegati;

  • aggiunta dell'header di un attachment all'interno del messaggio cifrato;

  • aggiunto il supporto per lo scambio di chiavi simmetriche di cifratura usando un'altra chiave simmetrica condivisa, tramite la gestione di keystore di tipo 'jceks'."

Miglioramenti alla Console e alle API di Monitoraggio

Sono stati apportati i seguenti miglioramenti alle funzionalità di reportistica:

  • il report 'heatmap' fornito con la distribuzione statistica in 3 dimensioni è stato migliorato per:

    • contenere una legenda che descriva la corrispondenza tra tonalità del colore e misura rappresentata;
    • possibilità di visualizzare in ogni quadratino la misura;

  • è ora possibile produrre una distribuzione statistica in 3 dimensioni personalizzata, dove al posto della data è possibile selezionare l'informazione da includere nel report.

Miglioramenti all'Installer

Sono stati apportati i seguenti miglioramenti all'installer binario:

  • aggiunti i seguenti tools command line presenti nella directory dist/tools prodotta dall'installer:

    • govway-vault-cli consente:

      • la cifratura o decifratura di informazioni o chiavi tramite una master key;

      • l'aggiornamento di una base dati esistente, consentendo di cifrare le informazioni confidenziali precedentemente salvate in chiaro o di aggiornarle attraverso l'utilizzo di una differente master key.

    • govway-config-loader dispone delle medesime funzionalità presenti nella sezione 'Importa' della console di gestione, che consentono di importare o eliminare le configurazioni memorizzate in un archivio ottenuto con la funzionalità 'Esporta'.

  • i file relativi ai profili di interoperabilità (es. modipa_local.properties) presenti nella configurazione esterna (es. /etc/govway) non venivano configurati correttamente dall'installer se erano presenti archivi patch al suo interno;

  • gli archivi 'patch' relativi ai profili di interoperabilità (es. openspcoop2_modipa-protocol-.jar) non venivano configurati nel file di proprietà interno (es. modipa.properties) per contenere la proprietà relativa alla directory di configurazione esterna indicata nell'installer (es. 'org.openspcoop2.protocol.modipa.confDirectory=/etc/govway').

Bug Fix

Sono state risolte le seguenti vulnerabilità relative ai jar di terza parte:

  • CVE-2024-32007, CVE-2024-41172:

    • aggiornata libreria 'org.apache.cxf:*' alla versione 3.6.4
    • aggiornata libreria 'org.ow2.asm:asm' alla versione 9.7
    • aggiornata libreria 'com.fasterxml.woodstox:woodstox-core' alla versione 6.6.2

  • CVE-2024-34447, CVE-2024-30172, CVE-2024-30171, CVE-2024-29857:

    • aggiornata libreria 'org.bouncycastle:bcprov-ext-jdk18on' alla versione 1.78.1 (migrazione verso bcprov-jdk18on)
    • aggiornata libreria 'org.bouncycastle:bcpkix-jdk18on' alla versione 1.78.1
    • aggiornata libreria 'org.bouncycastle:bcutil-jdk18on' alla versione 1.78.1

  • CVE-2024-31573: aggiornata libreria 'org.xmlunit:*' alla versione 2.10.0

  • CVE-2024-22262: aggiornata libreria 'org.springframework:*' alla versione 5.3.34

  • CVE-2024-28752:

    • aggiornata libreria 'org.apache.cxf:*' alla versione 3.6.3
    • aggiornata libreria 'org.ow2.asm:asm' alla versione 9.6
    • aggiornata libreria 'org.codehaus.woodstox:stax2-api' alla versione 4.2.2
    • aggiornata libreria 'com.fasterxml.woodstox:woodstox-core' alla versione 6.6.0
    • aggiornata libreria 'org.apache.ws.xmlschema:xmlschema-core' alla versione 2.3.1
    • aggiornata libreria 'org.springframework:*' alla versione 5.3.33

  • CVE-2024-22257: aggiornata libreria 'org.springframework.security:*' alla versione 5.8.11

  • CVE-2024-21742: aggiornata libreria 'org.apache.james:apache-mime4j-*' alla versione 0.8.10

  • CVE-2024-22243: aggiornata libreria 'org.springframework:*' alla versione 5.3.32

  • CVE-2024-25710: aggiornata libreria 'org.apache.commons:commons-compress' alla versione 1.26.0

  • CVE-2023-52428: aggiornata libreria 'com.nimbusds:nimbus-jose-jwt' alla versione 9.37.3

Sono stati risolti i seguenti bug:

  • in caso di violazione della policy di Rate Limiting con raggruppamento per Token Claim, l'evento emesso non conteneva l'informazione puntuale sul valore del claim;

  • (#160) utilizzando un'architettura con database distinti per configurazione e runtime si otteneva un errore non bloccante riportato nei log del database, ad esempio su postgresql: "ERROR: relation "db_info_console" does not exist at character 15 STATEMENT: select * from db_info_console order by id DESC";

  • definendo una trasformazione in cui nella configurazione dell'area di applicabilità veniva impostato "Content-Type: application/json", la trasformazione non veniva applicata se nella richiesta o nella risposta era presente un header "Content-Type" con un valore contenente altre informazioni oltre al tipo base, ad esempio: "application/json; charset=utf-8";

  • nel profilo di interoperabilità 'Fatturazione Elettronica', la disabilitazione della validazione del nome della fattura tramite la proprietà 'org.openspcoop2.protocol.sdi.validazione.nomeFile.enable' causava il seguente errore bloccante se il nome della fattura era conforme a una fatturazione europea che iniziava con il codice 'UB' o 'II': 'Elemento [File] decodifica non riuscita: formato non conosciuto';

  • nella funzionalità di consegna asincrona, in alcuni casi limite con connettori con consegna in errore, lo stato della transazione non veniva aggiornato correttamente.

Per la console di gestione sono stati risolti i seguenti bug:

  • corretta un'anomalia presente durante il salvataggio di una policy di rate limiting con criterio di raggruppamento per Token Claim 'subject': l'impostazione del criterio non consentiva di entrare nuovamente in modifica della policy e nei log si poteva riscontrare un errore simile al seguente: 'Enum with value [TOKEN_ISSUER] not found';

  • è stata risolta una problematica nella gestione degli allegati di una erogazione o API, in cui il pulsante 'cestino' non funzionava correttamente, impedendo la rimozione di un file una volta caricato;

  • la modifica del nome di un soggetto non veniva riflessa correttamente sul nome dell'erogazione: nella denominazione del componente 'porta_applicativa', veniva erroneamente aggiunto un carattere '/' finale, causando l'impossibilità di riconoscere l'erogazione al momento della sua invocazione e generando un errore '404 NotFound' restituito al chiamante;

  • è stato corretto un problema nella funzionalità di export per il profilo di interoperabilità 'SPCoop' che si verificava quando veniva selezionato un soggetto multi-tenant tra quelli disponibili. Il problema si presentava durante l'export di un'API o di una fruizione che faceva riferimento a un'API il cui soggetto era differente da quello selezionato; all'interno dell'archivio zip, l'API non veniva inclusa;

  • corretta anomalia presente durante l'export di una erogazione o fruizione: il plugin riferito per l'autorizzazione dei contenuti non veniva esportato;

  • in presenza di regole di proxy pass, nella maschera di visualizzazione dell'URL di invocazione di una API erogata o fruita, viene ora visualizzata anche l'URL di invocazione interna.

  • apportate alcune migliorie prestazionali.

Infine è stato rivisto l'algoritmo di generazione delle statistiche poiché le transazioni da inserire in un intervallo temporale potrebbero non essere ancora tutte presenti nella base dati nel caso in cui il generatore di statistiche si avvii nell'intervallo prossimo successivo (es. calcolo intervallo orario 16-17 e generatore che si avvia alle 17:00:06). Transazioni che non rientrano nel calcolo dell'intervallo potrebbero essere relative ad eventi di 'readTimeout' (scritte sulla base dati dopo 120 secondi e oltre) o di lettura dello storico delle transazioni su una base dati in replica (ritardo dovuto alla sincronizzazione). Per gestire correttamente queste casistiche, è stato introdotto un parametro di tradeoff per individuare anche le transazioni che vengono registrate sulla base dati in un tempo successivo alla data di avvio del batch. Il generatore continuerà ad aggiornare i dati aggregati fino a quando la data di esecuzione del generatore non supera l'intervallo temporale corrente aumentato del tradeoff. Per default viene utilizzato un tradeoff di 5 minuti. In questo scenario, ad esempio, il generatore continuerà ad aggiornare i dati dell'intervallo 16-17 fino a quando non verrà avviato dopo le 17:05, consentendo così alle transazioni scritte dopo le 17:00 ma facenti parte dell'intervallo 16-17 di essere incluse nel dato aggregato statistico.

Assets 4
Loading