Indra Italia S.p.A., Pwc Advisory S.p.A.
Transcript of Indra Italia S.p.A., Pwc Advisory S.p.A.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 1 di 64
So.Re.Sa. S.p.A.
Società Regionale per la Sanità
Servizi di interoperabilità per i dati e di cooperazione applicativa per l’attivazione del Fascicolo Sanitario Elettronico
Servizi di realizzazione e gestione di Portali e Servizi on-line per l’attivazione del Fascicolo Sanitario Elettronico
Progetto Esecutivo
Sistema Pubblico di Connettività - Lotto 3 & Lotto 4
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 2 di 64
SOMMARIO
1. Introduzione .................................................................................................................................. 8
1.1. Scopo del progetto ................................................................................................................. 8
1.2. Scopo del documento .......................................................................................................... 11
1.3. Assunzioni ........................................................................................................................... 11
1.4. Riferimenti........................................................................................................................... 11
1.5. Definizioni e Acronimi ........................................................................................................ 12
2. Contesto di Riferimento .............................................................................................................. 14
3. Architettura funzionale ............................................................................................................... 17
3.1. Autenticazione e autorizzazione .......................................................................................... 18
3.2. Sistema notifiche ................................................................................................................. 20
3.3. Ricerca Documenti .............................................................................................................. 20
3.4. Consultazione documenti .................................................................................................... 20
3.5. Gestione Consenso e Privacy .............................................................................................. 21
3.6. Gestione anagrafica pazienti, medici e strutture sanitarie ................................................... 21
3.7. Analisi ontologica e semantica ............................................................................................ 22
3.8. algoritmi per la valorizzazione ............................................................................................ 22
3.9. Analisi geo spaziale ............................................................................................................. 22
3.10. Gestione taccuino ............................................................................................................. 23
3.11. Prodotti UI ....................................................................................................................... 23
3.11.1. Portale del cittadino .................................................................................................. 24
3.11.2. Mobile APP .............................................................................................................. 24
3.12. Sicurezza .......................................................................................................................... 25
4. Architettura Logica ..................................................................................................................... 27
4.1. High Level Design............................................................................................................... 27
4.2. Struttura generale ................................................................................................................ 28
4.3. Data layer ............................................................................................................................ 28
4.4. Specifiche di integrazione ................................................................................................... 29
4.5. Anagrafiche e codifiche....................................................................................................... 30
4.6. Sistema notifiche ................................................................................................................. 30
4.7. Tracing e logging................................................................................................................. 31
4.8. Portali e APP mobile ........................................................................................................... 32
4.8.1. Portale al cittadino ....................................................................................................... 32
4.8.2. Portale FSE+ ................................................................................................................ 33
4.8.3. APP mobile .................................................................................................................. 33
4.9. Sicurezza ............................................................................................................................. 33
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 3 di 64
4.9.1. Accesso e tracciabilità .................................................................................................. 33
5. Architettura tecnologica .............................................................................................................. 35
5.1. Scelta Open Source ............................................................................................................. 35
5.2. Api Governance e enterprise integration con WSO 2 ......................................................... 37
5.2.1. API Manager ................................................................................................................ 40
5.2.2. API Gateway ................................................................................................................ 41
5.2.3. Key Manager ................................................................................................................ 42
5.2.4. Identity Server .............................................................................................................. 45
5.2.5. Publisher Portal ............................................................................................................ 46
5.2.6. Store Portal ................................................................................................................... 47
5.2.7. Enterprise Integrator .................................................................................................... 48
5.2.8. Data Analytics Server .................................................................................................. 49
5.3. Processi applicativi .............................................................................................................. 50
5.3.1. Containers .................................................................................................................... 50
5.3.2. Docker .......................................................................................................................... 51
5.3.3. Kubernetes ................................................................................................................... 52
5.3.4. Rancher ........................................................................................................................ 55
5.4. Data layer ............................................................................................................................ 56
5.4.1. PostgreSQL .................................................................................................................. 56
5.4.2. Stack ELK .................................................................................................................... 57
5.4.3. Zipkin ........................................................................................................................... 58
5.5. Portale .................................................................................................................................. 58
5.5.1. React JS ........................................................................................................................ 58
5.5.2. Express JS .................................................................................................................... 58
5.6. App mobile .......................................................................................................................... 58
5.6.1. React Native ................................................................................................................. 58
6. Architettura Fisica e deployment ................................................................................................ 59
6.1. Specifiche generali .............................................................................................................. 59
6.2. Sizing ................................................................................................................................... 59
6.3. Networking .......................................................................................................................... 60
6.4. API Manager ....................................................................................................................... 60
6.5. Monitoraggio e gestione ...................................................................................................... 62
6.6. Architettura fisica ................................................................................................................ 62
6.7. Predisposizioni ambienti di installazione ............................................................................ 63
6.7.1. Ambiente di PROduzione ............................................................................................ 63
6.7.2. Ambiente di collaudo ................................................................................................... 63
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 4 di 64
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 5 di 64
INDICE DELLE TABELLE
Table 1 - Acronimi ............................................................................................................................. 13 Table 2 – Sizing Ambiente di Produzione ......................................................................................... 63
Table 3 – Sizing Ambiente di Collaudo – Frontend .......................................................................... 64
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 6 di 64
INDICE DELLE FIGURE
Figura 1 Architettura Funzionale ....................................................................................................... 18 Figura 2 Architettura di alto livello della soluzione .......................................................................... 28
Figura 3 FLusso dati nella piattaforma .............................................................................................. 29 Figura 4 Architettura logica sistema notifiche ................................................................................... 31 Figura 5 Tracciamento transazioni distribuite Figura 6 Tracciamento in Zipkin............................ 31 Figura 7 Architettura logica portali e APP mobile ............................................................................ 32 Figura 8 Api Manager ........................................................................................................................ 39
Figura 9 Api Gateway ........................................................................................................................ 41 Figura 10 Flusso OAuth2 ................................................................................................................... 44 Figura 11 OAuth2 Client Credentials ................................................................................................ 45
Figura 12 Ciclo di vita dell'API ......................................................................................................... 47 Figura 13 Schema logico Kubernetes ................................................................................................ 52 Figura 14 Stack ELK.......................................................................................................................... 57 Figura 15 WSO2 API Manager deployment pattern n°2 ................................................................... 61
Figura 16 Architettura fisica .............................................................................................................. 62
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 7 di 64
STORICO REVISIONI
Ver. Elabora Verifica Approva Data emissione Descrizione delle modifiche
1.0 Cortesini Ivano Parlato Paolo De Maio Ettore 20/05/2019 Prima stesura del documento
2.0 Cortesini Ivano Parlato Paolo De Maio Ettore 18/12/2019 Adeguamento interoperabilità
con FSE-INI
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 8 di 64
1. INTRODUZIONE
1.1. SCOPO DEL PROGETTO
Il ruolo dell'Information Technology in ambito sanitario è diventato ormai centrale, vero punto di
riferimento per il governo e per il monitoraggio dell'attività sociosanitaria e amministrativa delle
Aziende Sanitarie Locali e Ospedaliere. È altrettanto inconfutabile che i livelli di progettazione dei
sistemi informativi, di pianificazione degli investimenti e di monitoraggio dei risultati raggiunti
trovino la loro dimensione ottimale nel livello regionale, scala di riferimento più opportuna per la
valutazione globale dei progetti.
Anche le normative nazionali fanno ampio riferimento all’utilizzo dei sistemi informativi come
fattore abilitante per migliorare i livelli di servizio in ambito sanitario.
L’innovazione digitale dei processi sanitari è un passaggio fondamentale per migliorare il rapporto
costo-qualità dei servizi sanitari, limitare sprechi e inefficienze, ridurre le differenze tra i territori,
nonché innovare le relazioni di front-end per migliorare la qualità percepita dal cittadino.
In regione Campania è particolarmente evidente la frammentazione dei software presenti all'interno
delle Aziende Sanitarie Locali e Ospedaliere, tanto che risulta indispensabile attuare interventi
strutturali e radicali, al fine di uniformare la risposta informativa, di garantire idonei livelli di "data
protection" e di disponibilità dei servizi sia all'interno dell'infrastruttura dei datacenter delle Aziende
Sanitarie che dei servizi a livello regionale, attraverso un potenziamento dei livelli di sicurezza e
resilienza dei sistemi.
La parcellizzazione dei sistemi software, delle banche dati, dei fornitori e, non ultimo, dei modelli
organizzativi adottati dalle singole aziende, determina un panorama quanto mai affastellato, con
ricadute molto negative anche e soprattutto sul livello regionale, che non ha la possibilità di essere il
catalizzatore naturale dei flussi informativi e dei processi produttivi clinici e amministrativi che
dovrebbero contribuire a generare conoscenza sul livello di qualità e quantità dei servizi sanitari
disponibili ed erogati.
SINFONIA, Sistema INFOrmativo saNità CampanIA, è il sistema informativo sanitario regionale al
servizio degli utenti e degli operatori (in coerenza col piano 2017-2019 per l’informatica nella
Pubblica Amministrazione) progettato per supportare l’intero governo del SSR campano, aumentare
l’efficienza, contenere i costi e al tempo stesso rendere uniformi e potenziare la risposta ai bisogni di
tutti i protagonisti del sistema, operatori, cittadini, strutture, referenti dell’ente regionale e
dell’amministrazione centrale.
Nell’ambito di tale intervento è prevista l’implementazione di un modello che, mediante l’uso delle
tecnologie dell’informazione, consenta lo sviluppo di interventi di Sanità Digitale rivolti ai cittadini
della Regione Campania (in particolare rivolti all’attuazione del Fascicolo Sanitario Elettronico
Regionale), in coerenza con gli obiettivi regionali, con il Piano Triennale per l’Informatica nella
Pubblica Amministrazione 2017-2019 predisposto da AgID avendo a riferimento quanto delineato
nella “Strategia per la crescita digitale”, con le azioni, la definizione dei fabbisogni finanziari e gli
indicatori ivi rappresentati, con l’obiettivo di indirizzare gli investimenti in ICT del settore pubblico
secondo le linee guida del Governo e in coerenza con gli obiettivi e i programmi europei. Le linee di
attività da prevedersi per il triennio 2017-2019, da un lato garantiranno l’ottemperanza alle nuove
disposizioni nazionali in materia di Fascicolo Sanitario Elettronico (FSE) e dall’altro l’attivazione ed
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 9 di 64
il mantenimento di applicazioni WEB e mobile che introdurranno nuovi metodi di fruizione
dell’informazione sanitaria e che saranno integrate con i servizi offerti dal sistema regionale di FSE
in regime di sussidiarietà totale.
Il presente progetto, nell’ambito del più ampio progetto Regionale denominato SINFONIA, prevede
la realizzazione dei servizi di interoperabilità per i dati e di cooperazione applicativa (SPC Lotto 3) e
dei servizi di realizzazione e gestione di Portali e Servizi on-line (SPC Lotto 4) necessari al
potenziamento del Fascicolo Sanitario Elettronico in Regione Campania. Nell’ecosistema Sanità, un
ruolo centrale è infatti ricoperto dal Fascicolo Sanitario Elettronico (FSE) che è lo strumento
attraverso il quale il cittadino può tracciare, consultare e condividere la propria storia sanitaria. La
norma stabilisce che l’infrastruttura del FSE gestisca l’insieme dei dati e dei documenti digitali di
tipo sanitario e socio-sanitario generati da eventi clinici presenti e trascorsi riguardanti l’assistito.
Il progetto denominato Sistema INFOrmativo saNità CampanIA – SINFONIA prevede inoltre la
costituzione dei seguenti sistemi:
1. Anagrafe Unica Regionale Assistiti che si basa, come tutti i modelli di sanità elettronica,
sul concetto di “paziente al centro”. L’Anagrafe Unica Regionale degli Assistiti
rappresenta uno snodo centrale di tutte le informazioni di carattere anagrafico-sanitario
dei cittadini su cui si appoggiano i servizi gestionali e di riconoscimento dell’assistito,
rilascio TS, scelta e revoca del medico, di esenzione, ecc.
2. Anagrafe delle Strutture Sanitarie e Socio-Sanitarie che contiene l’anagrafica di tutte le
strutture sanitarie, pubbliche e private accreditate della Regione. Essa consente di
assolvere agli adempimenti della legge 326/2003 – articolo 50 e di catalogare in modo
strutturato, tutte le strutture sanitarie regionali, i servizi disponibili, nonché tutte le
informazioni utili per i cittadini e per gli operatori della sanità. L’archivio può essere
agganciato anche ai sistemi regionali di georeferenziazione e svolge le seguenti funzioni:
- viene referenziato dai servizi applicativi sanitari e socio-sanitarie e dalle
applicazioni che gestiscono dati relativi alle strutture sanitarie regionali;
- costituisce la fonte delle informazioni per la programmazione sanitaria regionale,
grazie alle informazioni presenti sull’offerta dei servizi (posti letto, tipologie di
prestazioni erogate, ecc.);
- risponde a quanto previsto dal sistema nazionale di Monitoraggio della Rete di
Assistenza (MRA);
- fornisce i contenuti per la gestione dinamica di un portale sanitario regionale
dedicato.
3. Anagrafe degli operatori sanitari che comprende tutti gli operatori sanitari che
interagiscono nel sistema e che appartengono al sistema sanitario regionale, sia che essi
lavorino in ambito pubblico, sia che essi lavorino in ambito privato.L’anagrafe deve
fornire un insieme di servizi di identificazione del ruolo e dell’incarico che l’operatore
svolge in una determinata azienda/struttura (anche ambulatoriale) e contestualmente al
tempo a cui la richiesta di tale informazione si riferisce. Tali informazioni possono essere
usate per profilare gli operatori sui diritti di accesso in lettura e scrittura ai sistemi in uso
e per fornire un attributo di ruolo da associare ai certificati per la firma digitale. L’anagrafe
deve contenere informazioni relative alla persona fisica ed alla struttura di competenza ed
altre informazioni utili che saranno meglio declinate nella fase di progetto operativo.
Le linee Guida definite per la presentazione dei Piani di progetto regionale per il (FSE), predisposte
dall’Agenzia per l’Italia Digitale (AgID) ai sensi dell’art. 12 del D.L. 179/2012, hanno infatti
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 10 di 64
richiesto, quale componente abilitante per la realizzazione del FSE, la presenza di anagrafi degli
assistiti, degli operatori e delle strutture di livello centrale regionale.
In ottemperanza a quanto richiesto dalle linee guida, la Giunta Regionale ha approvato la
deliberazione n° 25 del 23/01/2018 con cui, tra l’altro, si prevede la razionalizzazione dei sistemi
informativi sanitari regionali, attraverso l’unificazione e centralizzazione delle anagrafi di tutte le
aziende sanitarie, al fine di rendere certificata ogni singola posizione anagrafica nel sistema regionale.
Il sistema regionale dovrà inoltre allinearsi con il sistema nazionale di controllo della spesa
farmaceutica e specialistica (Sistema TS) gestito dal Ministero delle Entrate e delle Finanze e con le
nascenti Anagrafe Nazionale della Popolazione Residente (ANPR) e Anagrafe Nazionale degli
Assistiti (ANA).
Nell’ambito del presente progetto, che mira all’attivazione del Fascicolo Sanitario Elettronico in
Regione Campania, saranno quindi – tra le altre attività previste – integrate le Anagrafiche regionali
la cui realizzazione è prevista dal Progetto SINFONIA.
All’esito degli incontri congiunti tenuti nel periodo giugno-luglio 2019 dal Gruppo di Lavoro di
Regione Campania, MEF, Ministero Salute, Sogei, AGID relativi alle modalità di interoperabilità con
FSE-INI si è resa necessaria una rimodulazione architetturale complessiva del sistema. Si è quindi
lavorato, congiuntamente con il Gruppo di Lavoro Regione Campania/Sogei per identificare nuovi
scenari di interoperabilità che potessero essere condivisi da tutti i soggetti coinvolti (tra cui MEF e
Sogei). In particolare, è stato prodotto il documento SPCL3&4-FSECampania-SoReSa-Scenari-
Integrazione_vers1.0, rev. 1.0 del 01/08/2019, che è stato discusso durante l’incontro al MEF del 9
Settembre. In tale sede MEF/Sogei hanno espresso parere favorevole sullo scenario 2.a indicato ne
documento di cui sopra, rimandando però a degli incontri tecnici successivi di approfondimento, al
fine di verificare la fattibilità e la tempistica delle realizzazioni lato Sogei previste in tale scenario.
Nelle settimane seguenti si è lavorato per produrre materiale a supporto degli incontri successivi con
il MEF, al fine di fornire ulteriori elementi utili a Sogei per valutare fattibilità e tempistica delle
realizzazioni. In particolare, è stato prodotto il documento SPCL3&4-FSECampania-SoReSa-
RequisitiServiziBackend_v1.0, rev. 1.0 del 17/09/2019.
Durante l’incontro tenutosi al MEF il giorno 9 Ottobre, MEF/Sogei/Agid hanno comunicato che
l’implementazione dei servizi lato Sogei avverrà in due fasi temporali distinte denominate “Fase 1”
e “Fase 2”: il primo rilascio prevederà un primo nucleo base di funzionalità necessarie per avviare un
rilascio iniziale lato Portale della Sanità di Regione Campania; il secondo rilascio dovrà mettere a
disposizione invece tutte le funzionalità richieste nel documento SPCL3&4-FSECampania-SoReSa-
RequisitiServiziBackend_v1.0 di cui sopra.
In data 29/10/2019 – avendo avuto rassicurazioni da parte di MEF/Sogei della realizzabilità in tempi
compatibili con il progetto di regione Campania almeno per i servizi di Fase 1 (descritti nel verbale
dell’incontro del 15/10/2019 tenutosi presso la sede di Regione Campania con il MEF e Sogei) -
viene decisa una ripresa parziale delle attività, relativa al Portale ed alle componenti di EAI
(quest’ultima necessaria alla implementazione delle componenti utili alla esposizione dei servizi
messi a disposizione da Sogei verso il Portale del Cittadino, oltre alle funzionalità di autenticazione,
notifiche ed API Management).
La ripresa delle attività passa quindi attraverso la riprogettazione dei servizi e dell’architettura del
sistema, sulla base dello scenario concordato con MEF/Sogei; saranno pertanto rilasciate le nuove
specifiche (interfacce del portale disponibile in Fase 1, progetto esecutivo, sizing infrastrutturale).
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 11 di 64
La presente revisione del progetto Esecutivo recepisce le modalità di interoperabilità con FSE-INI.
Tuttavia, è in corso una attività di service design che porterà alla definizione di ulteriori servizi e
componenti che saranno realizzati nell’ambito del progetto, Pertanto, al completamento del service
design, sarà emessa una ulteriore revisione del Progetto Esecutivo e del sizing infrastrutturale per
contemplare l’aggiunta di tali funzionalità / componenti.
1.2. SCOPO DEL DOCUMENTO
Il presente documento si inserisce nell’ambito della documentazione relativa ai progetti di
realizzazione dei servizi di interoperabilità per i dati e di cooperazione applicativa e di realizzazione
e gestione di Portali e applicazioni mobile per l’attivazione del Fascicolo Sanitario Elettronico e
costituisce la specifica degli elementi strutturali costituenti i componenti della piattaforma. Obiettivo
del presente documento è quello di individuare gli elementi strutturali della soluzione specificandone
le interfacce e le modalità di collaborazione fornendo, inoltre, una panoramica dell'architettura
complessiva del sistema, utilizzando un insieme di differenti viste architetturali.
1.3. ASSUNZIONI
Regione Campania opera in regime di sussidiarietà totale tramite FSE-INI.
L’Infrastruttura ospitante gli ambienti di Collaudo e di Produzione saranno messi a disposizione dal
cliente secondo quanto ipotizzato nel Piano di Progetto e nel presente documento (Rif. 6.7 -
Predisposizioni ambienti di installazione), al fine di completare il progetto secondo i tempi
contrattualmente previsti.
L’effettiva erogabilità dei servizi del portale dipende dalla messa a disposizione e dal corretto
funzionamento dei servizi di Fase 1 e 2 da parte di Sogei (descritti nel verbale dell’incontro del
15/10/2019 tenutosi presso la sede di Regione Campania con il MEF e Sogei).
L’invio di notifiche a mezzo SMS prevede la messa a disposizione di un SMS Gateway da parte di
Regione Campania. La sezione news sarà popolata attraverso l’alimentazione da un Feed RSS messo
a disposizione da Regione Campania.
1.4. RIFERIMENTI
Rif. Titolo/Descrizione Identificativo
1
Contratto Quadro relativo all’Appalto dei servizi di
interoperabilità per i dati e di cooperazione applicativa
(lotto 3) in favore delle PA.
Contratto Quadro del 31/03/2017 e relativi Allegati
2
Contratto Quadro relativo all’Appalto dei servizi di
realizzazione e gestione di Portali e Servizi on-line (lotto 4)
in favore delle PA.
Contratto Quadro del 04/08/2017 e relativi Allegati
3
FASCICOLO SANITARIO ELETTRONICO - Servizi
dell’infrastruttura nazionale di interoperabilità (INI) ad
uso delle regioni in sussidiarietà
Versione del 14.05.2018
4
Linee d’indirizzo per l’implementazione del sistema
informativo sanitario regionale e relativi allegati. In
particolare: Allegato 2 - Fascicolo Sanitario Elettronico
“linee guida di interoperabilità
Consultazione pubblica per la progettazione del
sistema SINFONIA
Versione 1.0 del Novembre 2018
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 12 di 64
Rif. Titolo/Descrizione Identificativo
5 Piano dei Fabbisogni (Lotto 3) SPCL3-TMP-PianoFabbisogni-1.0, versione 1.0 del
24/10/2018
6 Progetto dei Fabbisogni (Lotto 3) SPCL3-RegioneCampania_FSE-ProgettoFabbisogni-
1.0, versione 1.0 del 30/11/2018
7 Contratto Esecutivo (Lotto 3) CIG Derivato 78198990CD
Stipulato il 25/03/2019
8 Piano dei Fabbisogni (Lotto 4) SPCL4-TMP-PianoFabbisogni-1.0, Versione 1.0
del 24/10/2018
9 Progetto dei Fabbisogni (Lotto 4) SPCL4-RegioneCampania_FSE-ProgettoFabbisogni-
1.0, versione 1.0 del 30/11/2018
10 Contratto Esecutivo (Lotto 4) CIG Derivato 7819991CB5
Stipulato il 25/03/2019
11 Specifiche Funzionali e Grafiche del Portale del Cittadino
SPCL4-FSECampania-Portale-
SpecificheFunzionali&Grafiche versione 1.0 del
16/05/2019
12 Scenari di integrazione con FSE-INI SPCL3&4-FSECampania-SoReSa-Scenari-
Integrazione_vers1.0, rev 1.0 del 01/08/2019
13 Requisiti Funzionali dei servizi di Backend
SPCL3&4-FSECampania-SoReSa-
RequisitiServiziBackend_v1.0, rev 1.0 del
17/09/2019
14 Verbale di riunione del 15/10/2019
15 Sizing Sizing_ApiGovernace_Portal_v.2.0 del 20/11/2019
16 Specifiche Funzionali e Grafiche del Portale del Cittadino
di Fase 1
SPCL4-FSECampania-Portale-
SpecificheFunzionali&GraficheFase1 rev. 1.0 del
03/12/2019
Table 1 - Acronimi
1.5. DEFINIZIONI E ACRONIMI
Termine Descrizione
AgID Agenzia per l’Italia Digitale
API Application Programming Interface
BU Business Unit
Cliente SoReSa
CNS Carta Nazionale dei Servizi
Consip Consip S.p.a.
DoS Denial of Service
EAP Enterprise Application Pattern
ESB Enterprise Service Bus
FSE Fascicolo Sanitario Elettronico
FSE-INI Implementazione del FSE (in regime di sussidiarietà) e dei relativi servizi di interoperabilità
con le strutture sanitarie locali e con il portale di FSE oggetto del presente progetto.
GUI Graphical User Interface
HL7 Health Level Seven International
HTTP HyperText Transfer Protocol
ICT Information and Communication Technologies
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 13 di 64
IP Internet Protocol address
IT Information Technology
IoT Internet of Things
IWA Integrated Windows Authentication
JWT JSON Web Token
OSGi Open Service Gateway initiative
PA Pubblica Amministrazione
PEP Policy Enforcement Point
PSD2 Payment Services Directive 2
QoS Quality of Service
REST REpresentational State Transfer
RTI Raggruppamento Temporaneo d’Impresa
SaaS Software as a Service
SAML Security Assertion Markup Language
SINFONIA Sistema INFOrmativo saNità CampanIA
SOA Service Oriented Architecture
SoReSa Società Regionale per la Sanità S.p.A.
SPC Servizio Pubblico di Connettività
SPID Sistema Pubblico per la gestione dell'Identità Digitale
SSR Servizio Sanitario Regionale
TS Tessera Sanitaria
XACML eXtensible Access Control Markup Language
XDS Cross-Enterprise Document Sharing
WS Web Services
Table 1 - Acronimi
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 14 di 64
2. CONTESTO DI RIFERIMENTO
“La Legge di Bilancio 2017 al fine di assicurare, un’omogenea diffusione nazionale del FSE ha
variato il quadro di riferimento per gli scenari di evoluzione e diffusione del FSE con l’introduzione
dell’Infrastruttura Nazionale per l’Interoperabilità (INI) dei Fascicoli Sanitari Elettronici regionali,
nonché con la revisione di adempimenti e scadenze previsti per la realizzazione dei progetti di FSE
da parte delle Regioni. Fermo restando quanto già previsto nell’ambito del D.P.C.M. n. 178 del
29/9/2015 “Regolamento in materia di fascicolo sanitario elettronico” e dalle specifiche AgID per
l’interoperabilità tra i sistemi regionali di FSE, l’INI ha il compito di garantire l’interoperabilità dei
FSE regionali e mette a disposizione una serie di funzionalità per l’alimentazione e la consultazione
del FSE. L’infrastruttura nazionale, oltre a garantire i processi operativi per sistemi regionali di FSE
esistenti, dovrà assicurare funzioni, nella loro interezza o in maniera modulare, per la realizzazione e
gestione di un sistema di FSE per le regioni e province autonome che non hanno sviluppato
completamente proprie soluzioni di FSE. (regime di sussidiarietà)1”
INI espone dei servizi che si possono suddividere nelle seguenti macrocategorie:
• servizi di gestione e comunicazione dei consensi;
• servizi di gestione e comunicazione delle informative regionali;
• servizi di recupero dei metadati dei documenti che compongono il FSE;
• servizi di recupero dei documenti del FSE, compatibilmente con le politiche di accesso
da parte di un assistito, un operatore o un professionista sanitario;
• servizi di comunicazione o di aggiornamento dei metadati relativi ad un documento o di
cancellazione dei metadati di un documento invalidato;
• servizio di trasferimento dell’indice a seguito del cambio della regione di assistenza di un
assistito.
In relazione allo stato di avanzamento dei propri FSE, le Regioni hanno aderito in toto o in parte al
progetto INI. La Regione Campania, insieme alla Calabria e alla Sicilia, ha aderito in toto
all’infrastruttura nazionale di sussidiarietà. INI ha messo a disposizione di queste Regioni le principali
componenti di storage dell’infrastruttura (repository e registry) e alcuni servizi tra cui:
• Autenticazione cittadini e professionisti sanitari;
• Gestione del consenso e oscuramenti documenti;
• Comunicazione dell’informativa;
• Consultazione FSE;
• Indicizzazione documenti;
• Archiviazione documenti;
• Consultazione accessi;
1 Conferenza Stato regioni, Contributo sullo stato di attuazione del FSE, 26 ottobre 2017.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 15 di 64
• Gestione e indicizzazione dei patient summary
Inoltre, ad integrazione dei contenuti minimi previsti dal DPCM 178/2015 (dati identificativi e
amministrativi dell’assistito, referti, verbali pronto soccorso, lettere di dimissione, profilo sanitario
sintetico, dossier farmaceutico, consenso o diniego alla donazione degli organi e tessuti), nell’ambito
delle attività del Tavolo di monitoraggio FSE sono stati individuati come prioritari anche i seguenti
contenuti:
• prescrizioni (specialistiche, farmaceutiche, ecc.);
• bilanci di salute;
• dossier farmaceutico;
• vaccinazioni;
• prestazioni di assistenza specialistica;
• certificati medici;
• esenzioni;
• prestazioni di assistenza protesica;
• promemoria ricetta.
I documenti e le informazioni cliniche di cui sopra dovranno prevedere i contenuti minimi ed essere
resi disponibili in formato CDA2 secondo le specifiche che saranno prodotte dai gruppi di lavoro ad
hoc recentemente costituiti nell’ambito dei tavoli tecnici nazionali (GDL).
Dal quadro di contesto sintetizzato in precedenza, discendono per le Regioni una serie di attività da
attuare che sono sistematicamente monitorate dal livello nazionale.
Anche la Regione Campania, pur avendo aderito al regime di sussidiarietà, dovrà realizzare un
complesso coordinato di attività propedeutiche per adempiere alla normativa e popolare il FSE-INI.
Tali attività dovranno essere volte a:
• creare le condizioni perché il FSE possa essere alimentato in modo completo, corretto e
continuativo dalle strutture che producono i documenti, gestendo in modo coordinato il
percorso di adeguamento tecnico ed organizzativo delle strutture stesse, pubbliche e
private.
• organizzare in modo strutturato la fase di raccolta dei consensi presso i propri assistiti,
individuando modalità e soluzioni organizzative efficaci;
• definire le strategie di coinvolgimento degli operatori in senso lato (MMG, PLS,
farmacie) nel percorso di attivazione del fascicolo;
• coordinare le attività di promozione e formazione rivolte a cittadini e operatori.
Tali attività risultano per altro necessarie non solo ai fini dell’alimentazione del fascicolo in regime
di sussidiarietà, ma sono necessarie anche nel caso in cui la Regione decida di dotarsi di una propria
infrastruttura di FSE adottando INI solo per l’interoperabilità.
La costruzione dell’ecosistema del FSE dovrà quindi necessariamente avvenire per fasi successive
avendo cura di gestire non solo l’adeguamento dei sistemi informatici affinché cooperino e
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 16 di 64
conferiscano le informazioni in maniera corretta al Repository secondo le specifiche tecniche e gli
standard attuali, ma anche l’intero processo di change management con l’attuazione di opportune
iniziative di comunicazione e formazione. Si richiede quindi di progettare un percorso di costruzione
dell’ecosistema fascicolo che:
• si fonda su un modello di governance strutturato;
• include la creazione di un sistema di engagement che utilizza i dati disponibili nel FSE
per realizzare servizi digitali a valore aggiunto per cittadini ed operatori e che sia basato
su una architettura applicativa modulare e scalabile.
• supporta la Regione nell’adempimento degli obblighi previsti a livello nazionale.
Sulla base di quanto convenuto nei Tavoli di Lavoro con Regione Campania, MEF, Ministero Salute,
Sogei, AGID, FSE-INI metterà a disposizione di Regione Campania ulteriori servizi (rispetto a quelli
previsti nella sussidiarietà totale), che consentiranno la realizzazione della verticalizzazione FSE+ del
portale al cittadino di Regione Campania, secondo quanto indicato nei documenti citati in Riferimento
(Rif. [12], [13] e [14]).
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 17 di 64
3. ARCHITETTURA FUNZIONALE
L’infrastruttura della Piattaforma di Cooperazione del Fascicolo Sanitario Campano si comporrà di
moduli e interfacce efficaci in grado di combinarsi, sulla base delle strategie di integrazione e
allineamento tra software per la produzione di documenti e sistema cooperativistico, con FSE-INI
(ovvero la corrente implementazione di FSE in regime di sussidiarietà).
La flessibilità e potenzialità dell’infrastruttura, è funzione delle logiche funzionali demandate a livelli
applicativi a loro volta in grado di dialogare a valle con i servizi del FSE in regime di sussidiarietà.
Il modello architetturale funzionale prevede i seguenti layer:
• Access Layer: rappresenta il punto di accesso alla soluzione. Attraverso questo layer, utenti
e amministratori della piattaforma potranno accedere ai diversi moduli, per fruire delle
funzionalità offerte.
• Application Layer: rappresenta lo strato in cui sono collocate le Applicazioni, contenenti la
logica di controllo del sistema e fruibili mediante un’architettura orientata ai servizi. Per alcuni
di questi servizi è disponibile, in aggiunta all’accesso attraverso la logica SOA, l’esperienza
d’uso mediante un’interfaccia utente semplice e intuitiva. Le applicazioni sono utilizzabili da
parte di tutti i soggetti interessati a conoscerne, testarne e utilizzarne i servizi e le API.
• Integration Layer: rappresenta lo strato di gestione delle interazioni basata su servizi tra i
moduli funzionali della soluzione, i moduli che gestiscono il flusso di lavoro ed i moduli
disponibiloi in FSE-INI. È grazie a questo strato che vengono gestiti i flussi di integrazione
principali previsti dai profili di interoperabilità concordati nell’ambito della evoluzione della
piattaforma FSE-INI.
• Data Layer: rappresenta l’impianto di gestione dei dati. A questo livello si situano tutti i
moduli che garantiscono la persistenza dei dati in grado di garantire l’operatività delle
applicazioni WEB e mobile ad eccezione dei documenti CDA2 ai quali invece si può eccedere
tramite FSE-INI. A questi si affiancano i moduli di gestione dei dati di configurazione e di
natura amministrativa.
A ciascuno dei livelli dell’architettura funzionale sono associati i moduli funzionali facenti parte
dell’offerta di piattaforma, che indirizzano i requisiti di business grazie al contributo preminente di
componenti applicative distribuite a quello stesso livello. Questa associazione tra livelli e moduli
consente di comprendere quali siano le responsabilità ed il valore aggiunto, in termini funzionali, di
ciascun livello, nonché di stabilire una denominazione comune per i diversi insiemi logici di
funzionalità.
La relazione tra livelli architetturali e moduli funzionali, dato l’elevato numero di moduli presenti, è
rappresentata in una serie di diagrammi. Il primo di questi ha il compito di inquadrare l’architettura
a livello generale ed introdurre le funzionalità comuni all’intera soluzione, mentre i seguenti
approfondiscono l’architettura di ciascuno dei sistemi oggetto di fornitura, presentandone i moduli
funzionali specifici. L’architettura funzionale generale è schematizzata nel seguente diagramma:
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 18 di 64
Figura 1 Architettura Funzionale
Il sistema proposto adotta soluzioni atte ad impedire l’alterazione diretta o indiretta delle
informazioni, sia da parte di utenti e processi non autorizzati che a seguito di eventi accidentali. Il
livello Access garantisce un accesso sicuro a tutti i moduli funzionali del sottostante livello
Application, il quale offre funzionalità fruibili mediante interfaccia grafica o servizi.
3.1. AUTENTICAZIONE E AUTORIZZAZIONE
La soluzione proposta in fornitura pone particolare attenzione al trattamento dei dati sensibili
garantendo un elevato grado di riservatezza e di sicurezza come previsto dalle norme sulla privacy
(in conformità alla normativa GDPR). La soluzione è conforme alla normativa vigente, anche rispetto
alle recenti emanazioni del Garante in merito al tracciamento degli accessi degli amministratori.
Sono previste funzioni ed utilità ad uso amministrativo di sistema volte ad agevolare la gestione
operativa ed il controllo del rispetto delle normative:
▪ i sistemi consentono un accesso tramite credenziali assegnate ad ogni singolo utente e
verificate tramite l’Identity Server di sistema (a sua volta federato con l’Identity Server
Regionale);
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 19 di 64
▪ Assegnare credenziali in modo univoco con la possibilità di rilascio e revoca dei diritti di
accesso agli account nelle situazioni di urgenza/emergenza;
▪ identificare la persona assegnataria delle credenziali per impedirne il riutilizzo delle
medesime;
▪ gestire policies di accesso e visibilità sui contenuti degli utenti abilitati;
▪ sono previsti profili di accesso ai dati ed alle funzionalità rese disponibili per singoli utenti o
a gruppi di essi.
La soluzione proposta per la gestione dell’autenticazione sarà conforme alla circolare AgID n. 3 del
2 settembre 2019 supportando l’accesso unificato in single sign-on attraverso il portale FSE
nazionale.
Gli accessi ai servizi di piattaforma e tutte le operazioni effettuate dagli utenti, ad esempio login e
consultazioni, sono tracciati e registrati in appositi log di sistema. Tali log saranno accentrati in un
apposito storage per facilitarne la consultazione, l’analisi e la tracciatura delle transazioni distribuite
sui vari componenti applicativi.
La piattaforma, inoltre, fa uso di tecnologie di crittografia a protezione delle informazioni scambiate
come previsto dalle norme vigenti per i sistemi che trattano dati sensibili. In particolare, per la
comunicazione sia tra browser e server che tra componenti back-end (anche sulla stessa infrastruttura)
viene usato il tunneling SSL del protocollo HTTP (HTTPS).
Il modulo di Autenticazione e autorizzazione sovrintende e governa il processo di autenticazione di
tutti gli operatori che intendono avvalersi di servizi esposti dagli altri moduli secondo i criteri descritti
poc’anzi, consentendo la gestione sicura dell’intero ciclo di vita delle identità digitali.
Le informazioni relative alle persone fisiche e alle strutture coinvolte saranno rese disponibili tramite
l’integrazione con i sistemi centrali preposti per il trattamento delle medesime anagrafiche regionali.
La soluzione di autenticazione e autorizzazione proposta consente la gestione sicura dell’intero ciclo
di vita delle identità digitali.
Le principali funzioni offerte sono:
• Capacità di sincronizzazione delle identità detenute dal servizio verso le applicazioni del
dominio;
• Gestione centralizzata dei profili autorizzativi e dei ruoli/privilegi associati a ciascun utente;
• Tracciatura e auditing delle operazioni, che include la registrazione degli eventi centralizzata
ed adeguate funzioni di aggregazione del dato attraverso sistemi evoluti di ricerca e relativo
reporting assicurando la tracciabilità di tutte le registrazioni informatiche effettuate.
La componente di sicurezza viene garantita dall’utilizzo di strumenti di autenticazione basati su
standard internazionali (LoA2 – user / pwd -, LoA3 – OTP - e LoA4 – certificati digitali e SAML
2.0).
Tali standard consentono l’intercambiabilità delle componenti, rendendo la soluzione portabile su
architetture conformi allo SPID, senza la necessità di dover cambiare il sistema di gestione degli
accessi per rispondere alle esigenze di integrazione con altri sistemi regionali o nazionali.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 20 di 64
Come meglio discusso nel seguito, per l'autenticazione del cittadino e degli operatori sanitari è
prevista l’integrazione con l'Identity Server/l’applicativo GEL di Regione Campania, che si occuperà
della autenticazione degli stessi anche tramite SPID.
3.2. SISTEMA NOTIFICHE
La piattaforma mette a disposizione un apposito sistema per la gestione centralizzata e l’inoltro di
messaggi di notifica ai canali di delivery tramite e-mail, SMS e notifiche push.
La centralizzazione delle funzionalità di notifica consentirà di semplificare le attività di monitoraggio
e di integrazione con eventuali service provider messi a disposizione dall’azienda.
I provider utili alla piattaforma per abilitare i necessari canali di delivery delle notifiche devono essere
messi a disposizione dalla Regione Campania e sono i seguenti:
- SMS Gateway
- SMTP Server
- Push Notification service
Le notifiche saranno inoltrate agli attori interessati sulla base delle preferenze che gli stessi esprimono
tramite una apposita interfaccia. Gli eventi che occorrono nell’ambito della piattaforma e di FSE-INI
e che comportano l’inoltro di una notifica appartengono ad un set di opzioni predefinito. Alcune
tipologie di evento (come la ricezione di un nuovo documento) prevedono l’inoltro di un messaggio
alla piattaforma da parte di FSE-INI tramite l’adozione di un opportuno profilo di interoperabilità.
3.3. RICERCA DOCUMENTI
La piattaforma darà la possibilità di ricercare e filtrare i documenti e le informazioni in essi contenute
sfruttando le capacità offerte dal sistema FSE-INI.
In tale ambito, FSE-INI metterà a disposizione funzionalità avanzate di indicizzazione, di analisi
ontologica e semantica specializzata nell’ambito sanitario e algoritmi di tagging avanzato realizzati
anche tramite ML forniranno gli strumenti per usufruire di funzioni di ricerca tramite linguaggio
naturale. In questo modo sarà possibile trarre vantaggio anche dal dominio informativo derivante
dalla analisi delle informazioni non strutturate che occorrono frequentemente nei documenti
processati.
I contenuti dei documenti saranno anch’essi indicizzati e resi fruibili da FSE-INI per successive
attività di ricerca. Oltre ai documenti, sarà quindi possibile ricercare direttamente riferimenti a eventi
clinici, esiti di esami e altri elementi desumibili dai contenuti dei documenti inclusi nel FSE.
3.4. CONSULTAZIONE DOCUMENTI
A livello regionale la piattaforma si occuperà di consentire la consultazione dei documenti e delle
informazioni sanitarie tramite i servizi di gestione avanzata dell’informazione sanitaria messi a
disposizione da FSE-INI.
Questo livello di integrazione rappresenta il principale canale di accesso al patrimonio informativo
gestito dalla piattaforma. Le richieste di consultazione dell’informazione sanitaria inoltrate verso
FSE-INI contengono un riferimento all’attore che intende visionare tale materiale così da consentirne
il tracciamento e l’adempimento delle normative legate alla gestione del consenso.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 21 di 64
L’area di consultazione dei documenti e dei contenuti include le componenti abilitanti alla
realizzazione di una interfaccia utente avanzata per la consultazione dei documenti e dei contenuti
indicizzati dalla piattaforma. I documenti e le informazioni in essa contenuti saranno filtrati dai servizi
di FSE-INI sulla base delle preferenze specificate dal paziente nell’ambito della gestione del
consenso.
Oltre al documento FSE la piattaforma sarà in grado di rappresentare i diversi possibili contenuti del
documento stesso. Saranno implementate interfacce utente in grado di offrire nuovi modi di osservare
e navigare eventi, azioni, misure e fenomeni in generale osservabili all’interno dei documenti.
Saranno tenuti in considerazione legami tra i contenuti e la loro distribuzione nello spazio e nel tempo
precedentemente individuati in FSE-INI utilizzando appositi algoritmi di processamento dei
documenti.
3.5. GESTIONE CONSENSO E PRIVACY
Nell’ambito del processo di gestione della privacy del cittadino, il sistema proposto è pienamente
integrato con il modulo funzionale di gestione consensi di FSE-INI per risolvere le problematiche
legate alla raccolta e gestione dei documenti di consenso del Cittadino, secondo le norme in vigore
(GDPR) garantendo l’accesso ai dati clinici del singolo paziente esclusivamente agli operatori aventi
tale autorizzazione.
Questa funzione affianca e completa le funzionalità generali di autenticazione, autorizzazione e single
sign-on con la raccolta e indicizzazione dei consensi e preferenze di privacy espressi dal paziente,
siano essi riferiti ai propri dati anagrafici o a determinati episodi di cura, così come mediante regole
di accesso basate sui consensi stessi, che permettono di filtrare le richieste di fruizione dei dati protetti.
Tramite questo modulo il paziente potrà in ogni momento consultare il registro degli accessi
contenente tutte le informazioni di dettaglio sugli accessi alle informazioni del proprio FSE da parte
di altri attori. Sarà sempre disponibile anche l’accettazione, la consultazione e il download
dell’informativa sulla privacy.
3.6. GESTIONE ANAGRAFICA PAZIENTI, MEDICI E STRUTTURE
SANITARIE
La gestione centralizzata delle informazioni sul paziente all’interno dell’organizzazione garantisce
l’identificazione univoca del soggetto di cura, un pilastro imprescindibile per ottenere elevati livelli
di qualità del dato, raggiungendo così l’obiettivo di offrire un sistema fortemente orientato
all’accessibilità ed all’interoperabilità, alla tracciabilità delle operazioni ed all’unicità
dell’informazione.
Ovviamente anche la trattazione delle informazioni relative alle strutture sanitarie, agli operatori
sanitari ed ai ruoli ricoperti da tali attori nell’ambito delle strutture stesse assume un ruolo centrale
per la corretta gestione e consultazione dei contenuti dei documenti FSE.
Sarà quindi presente un modulo dedicato che a monte espone servizi e strutture per l’accesso
ottimizzato alle informazioni e a valle garantisce la corretta integrazione e sincronizzazione con i
servizi regionali ufficialmente dedicati alla gestione delle anagrafiche di cui sopra.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 22 di 64
3.7. ANALISI ONTOLOGICA E SEMANTICA
Grazie all’applicazione di algoritmi specifici per l’analisi del linguaggio naturale FSE-INI includerà
funzionalità avanzate in grado di lavorare interpretando il significato di gran parte delle informazioni
contenute nei documenti FSE.
Attraverso i servizi messi a disposizione da FSE-INI si potranno ricercare informazioni in modo
coerente ed efficace tramite linguaggio naturale, interpretando sia la tipologia che il perimetro delle
informazioni che una persona sta cercando.
Il campo d’azione per l’applicazione di questa tecnologia si estende a ogni forma di contenuto
testuale sia strutturato che non. Gli algoritmi saranno opportunamente contestualizzati analizzando il
linguaggio specifico dell’ambito sanitario e in particolare quello utilizzato nel contesto del FSE.
Questo lavoro, in parte manuale, prenderà spunto dalla terminologia specifica di settore che può
essere acquisita sfruttando le codifiche e i vocabolari ufficialmente riconosciuti a livello nazionale.
Appositi algoritmi saranno poi in grado di esaminare testi campione definendo al meglio le
connessioni concettuali nell’ambito della terminologia e nella struttura del testo.
3.8. ALGORITMI PER LA VALORIZZAZIONE
Gran parte della valorizzazione del documento FSE è legata alla efficacia di appositi algoritmi di
analisi dei dati inclusi in FSE-INI. I contenuti estratti dal documento processato possono portare un
grande valore aggiunto suggerendo previsioni, catalogando e creando interconnessioni logiche tra
contenuti.
Proprio l’interconnessione, a vario titolo, tra i contenuti estratti dai documenti del paziente consente
la definizione concettuale di un grafo dei contenuti alla base dell’implementazione di funzioni di
navigazione intelligente del fascicolo sanitario stesso.
Le relazioni tra i contenuti dei documenti posso essere di diversa tipologia a seconda del fenomeno
che si sta osservando. Alcune relazioni di dipendenza tra documenti possono essere determinate
considerando i relativi contenuti (sia codificati che testuali) ed altre informazioni contestuali ovvero
l’ambito nel quale il documento stesso è stato creato.
Alcuni algoritmi avanzati messi a disposizione da FSE-INI consentiranno il tagging dei contenuti
profilando le informazioni per successive attività di ricerca, analisi statistica e filtering anche in base
ai consensi specificati dal paziente. Tale attività potrebbe godere in parte della supervisione
semplificata da parte di specifici operatori sanitari abilitati e/o il paziente.
3.9. ANALISI GEO SPAZIALE
I documenti del FSE vengono sempre prodotti nell’ambito di strutture sanitarie autorizzate e censite.
Ne consegue che ogni prestazione sanitaria per la quale viene prodotto un documento può essere
collocata nello spazio sfruttando sia la posizione della residenza del paziente che la posizione della
struttura in cui la prestazione stessa è stata condotta.
Sfruttando questa importante risorsa informativa e aggregando opportunamente i dati disponibili nella
finestra temporale selezionata, la piattaforma offrirà la possibilità di osservare e comparare la
distribuzione geografica di determinati fenomeni desumibili analizzando i contenuti dei documenti.
Le funzionalità offerte in questo ambito saranno utili sia in campo statistico che decisionale per tutti
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 23 di 64
i tecnici di settore autorizzati dalla Regione Campania. Nell’ambito di FSE-INI sarà predisposto un
cruscotto applicativo a disposizione di tali operatori e che consentirà l’analisi geospaziale
dell’informazione sanitaria anonimizzata e aggregata.
3.10. GESTIONE TACCUINO
Il taccuino è un’area di storage a disposizione del paziente destinato al salvataggio di documenti
sanitari che attualmente non vengono inviati al FSE dalle strutture sanitarie pubbliche (ad esempio i
documenti prodotti da strutture sanitarie private non integrate o prodotti prima della integrazione con
il FSE).
In questo spazio il paziente potrà immagazzinare documenti in diversi formati (tipicamente binari)
corredati da alcune meta informazioni che ne facilitano la gestione, così come potrà inserire alcune
informazioni relative al proprio stile di vita. Sarà possibile impostare opportuni limiti nell’uso di
questo servizio da parte del paziente con l’obiettivo di garantire la piena operatività della piattaforma
ed il rispetto dei limiti infrastrutturali dell’ambiente di produzione.
Una volta inserite le informazioni necessarie, il documento caricato dal paziente viene inviato a FSE-
INI per essere salvato e gestito nelle modalità e nel formato previsti dalle specifiche e normative
vigenti in materia di fascicolo sanitario.
3.11. PRODOTTI UI
I diversi attori potranno usufruire di interfacce utente specifiche appositamente realizzate o
predisposte nell’ambito della piattaforma per supportare al meglio l’esperienza di utilizzo e gestione
della piattaforma. I principali moduli UI introdotti sono:
- Portale del cittadino per la sanità: il portale del cittadino rappresenta il portale
principale per consentire al cittadino ed agli operatori sanitari di usufruire dei
servizi dispositivi e di consumo di livello regionale legati al mondo della sanità.
- Portale FSE+: verticale funzionale dedicata al FSE destinata ad essere inclusa nel
portale del cittadino. Con differenti livelli di accesso offre la possibilità di usufruire
di tutte le capacità e funzionalità offerte dalla piattaforma a pazienti, operatori
sanitari e tecnici sanitari.
- APP mobile FSE: APP mobile che consentirà a cittadini e operatori sanitari di
usufruire dei vantaggi e di alcune delle capacità della piattaforma FSE+.
- Sistemi di gestione della piattaforma: si tratta dell’insieme di interfacce di gestione
esposte dai diversi prodotti integrati nell’ambito della piattaforma oltre che di
prodotti appositamente aggiunti con lo scopo di monitorare l’attività di attori e
sistemi (vedi paragrafo 6.5 - Monitoraggio e gestione). A questo livello potranno
accedere i diversi amministratori del sistema.
Nella realizzazione dei prodotti appena introdotti (ad esclusione dei sistemi di gestione) deve essere
preso in considerazione un certo insieme di specifiche atte a garantire una corretta esperienza di
utilizzo:
- Il portale FSE+ e gli altri prodotti inclusi nel portale al cittadino dovranno offrire
una esperienza di utilizzo omogenea sia in termini di aspetto che di modalità di
interazione. Nella realizzazione del portale del cittadino si dovrà definire un design
che semplifichi al massimo l’integrabilità dei diversi prodotti che la Regione
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 24 di 64
Campania vuole man mano introdurre. La produzione di adeguata documentazione
delle specifiche di integrazione consentirà ad altri gruppi di lavoro di realizzare
agevolmente l’embedding della propria soluzione nell’ambito del portale.
- Tutti i prodotti dovranno essere agevolmente internazionalizzabili. La copertura
deve essere completa a meno del dato sanitario. Inizialmente i prodotti saranno
“tradotti” solamente in lingua italiana. Non viene fornito il supporto a variazioni
di layout e orientamento del testo in funzione della localizzazione.
- Tutte le interfacce WEB devono essere sviluppate seguendo il paradigma delle
Single Page Application.
- Per tutti i prodotti front-end deve essere previsto un disaccoppiamento della
componente User Interface dalle logiche che determinano la User Experience
dedicata agli utilizzatori della piattaforma. Questa suddivisione è determinante per
promuovere il riutilizzo e l’uniformità dell’esperienza utente nell’ambito dei
diversi prodotti UI che si vogliono realizzare.
- La raccolta dei dati di audit in merito alle attività degli attori nell’ambito delle
diverse UI offerte sarà determinante per analizzare e comprendere al meglio le loro
crescenti necessità, le loro abitudini e le difficoltà riscontrate nell’utilizzo dei
diversi prodotti. Gli early adopter contribuiranno in modo sostanziale al fine tuning
delle funzionalità offerte ed all’accrescimento delle attuali capacità della
piattaforma. La produzione di eventi di audit deve essere il più possibile granulare
soprattutto nei primi periodi di utilizzo.
- Le componenti UI di tipo WEB devono essere realizzate mediante una interfaccia
altamente responsive, accessibile quindi anche da dispositivi mobili, e conforme ai
requisiti della pubblica amministrazione secondo le linee guida di design dei
servizi digitali della PA rilasciate dall’Agenzia per l’Italia digitale AGID.
Oltre alle sopracitate esigenze trasversali su tutti i prodotti UI che dovranno essere realizzati, esistono
esigenze e caratteristiche specifiche del singolo prodotto che devono essere prese in considerazione.
3.11.1. PORTALE DEL CITTADINO
Il portale al cittadino ha il compito principale di ospitare le diverse verticali funzionali in ambito
sanitario che la Regione Campania vuole offrire ai propri cittadini e operatori sanitari. A tale scopo
il portale offrirà le caratteristiche e i moduli applicativi a servizio di prodotti come il portale FSE+
per abilitare efficacemente l’embedding e l’integrazione a livello front-end anche verso altri prodotti
dello stesso tipo.
Il portale deve supportare le forme di autenticazione forte suggerite nel presente documento e che in
base alla normativa devono essere supportate dalla piattaforma per autorizzare attività sia di consumo
che dispositive in ambito sanitario.
Personale preposto dalla Regione Campania deve poter accedere a funzionalità di gestione del portale
tramite le quali sia possibile portare avanti attività editoriali dei contenuti di testo e multimediali
pubblicabili in specifiche aree delle pagine incluse nel portale stesso.
3.11.2. MOBILE APP
Indipendentemente dalla piattaforma tecnologica sulla quale viene rilasciata l’APP, si dovrà garantire
una esperienza di utilizzo uniforme. Dovranno essere supportate le piattaforme iOS e Android.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 25 di 64
Il design della UI sarà ridefinito appositamente, rispetto a quello realizzato per i portali, in funzione
delle differenti caratteristiche fisiche dei dispositivi e le relative modalità tipiche di interazione da
parte degli utilizzatori.
Anche per le APP mobile dovrà essere incluso un sistema di autenticazione forte in grado di garantire
al meglio l’identità dell’utilizzatore. In questo caso un’autenticazione dell'attore basata sull’uso di
due o più credenziali, classificate nella categoria della conoscenza (qualcosa che l'attore conosce
come un codice PIN), del possesso (qualcosa che l'attore possiede ovvero il dispositivo) e
dell’inerenza (qualcosa che caratterizza l'attore come l'impronta digitale), che sono indipendenti, in
quanto la violazione di uno non compromette l’affidabilità degli altri, e che è concepita in modo tale
da tutelare la riservatezza dei dati di autenticazione.
Sarà incluso anche il supporto alla ricezione di notifiche push.
3.12. SICUREZZA
La gestione della sicurezza applicativa, strutturale e infrastrutturale è un argomento di assoluta
importanza nel contesto operativo attuale data l’elevata riservatezza dei contenuti trattati dalla
piattaforma. Le specifiche ed il design architetturale sono stati sviluppati tenendo in considerazione
le necessità in termini di protezione dei dati e della privacy applicando il concetto di security by
design. Sarà garantito un adeguato livello di protezione dei dati sensibili gestendo opportunamente le
politiche di accesso e il mascheramento delle informazioni riservate in conformità con le direttive
attinenti il GDPR. Saranno adottati standard e appositi middleware con lo scopo di predisporre la
migliore protezione della piattaforma dai diversi possibili attacchi esterni tesi sia alla violazione della
privacy che a compromettere il corretto funzionamento dei servizi offerti.
Tutti i moduli della piattaforma, ad ogni livello, sono protetti con soluzioni specifiche studiate sulla
base dello stack tecnologico di riferimento e delle caratteristiche operative quali la natura
dell’informazione trattata, il livello di isolamento ottenibile, il retention time ed ogni altro elemento
rilevante.
In merito all’identificazione delle persone fisiche che accederanno alla piattaforma tramite portale o
mobile app, saranno disponibili diverse modalità di autenticazione e autorizzazione per servire al
meglio le necessità delle diverse tipologie di attore che necessitano di operare con la piattaforma:
- I pazienti devono poter accedere sia al portale che all’app mobile tramite lo
standard SPID messo a disposizione da AgID.
- Gli operatori sanitari devono autenticarsi al sistema tramite TS/CNS.
- Per altre tipologie di attore e attività da condurre nell’ambito della piattaforma,
l’autorizzazione delle richieste può avvenire attraverso l’utilizzo uno o più
protocolli di autenticazione/autorizzazione quali OPENID, SAML, OAuth2, Basic
Authentication.
Saranno monitorabili centralmente tutte le attività di tutti gli individui che accedono alla piattaforma
e tracciate tutte le transazioni (anche distribuite) eseguite nel sistema. Le informazioni di audit
saranno affiancate dai dati estraibili dai log di sistema di tutti i moduli coinvolti nell’ambito della
piattaforma e dalle informazioni accessibili a specifici agent opportunamente configurati sulle
macchine e sui container. Questo semplificherà l’analisi di dettaglio sull’attività dei processi interni
ed il raffronto con le attività degli utilizzatori mettendo in evidenza eventuali anomalie.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 26 di 64
Il codice prodotto per l’implementazione dei processi applicativi della piattaforma sarà analizzato in
modo automatico ad ogni rilascio con lo scopo di aumentare la qualità e la stabilità del codice e la
conformità dello stesso ad adeguati standard di sicurezza. In fase di pre-collaudo, saranno condotti
test massivi per verificare la stabilità del prodotto e penetration test per validarne il livello di
protezione.
Gli strumenti BI e di analisi geo-spaziale dei dati trattati dalla piattaforma – messi a disposizione da
FSE-INI – saranno fruibili solamente da personale autorizzato. La sorgente dati sulla quale questi
strumenti operano è un insieme di aggregazioni appositamente create e sincronizzate tramite
l’applicazione di appositi processi applicativi. Tali aggregazioni non consentono mai di derivare in
modo diretto o indiretto informazioni sanitarie alla granularità del singolo documento FSE e/o di
identificare persone o strutture sanitarie di riferimento. Inoltre, la granularità massima della
georeferenziazione di residenza dei pazienti e strutture sanitarie arriva al livello dei territori dei
comuni di appartenenza.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 27 di 64
4. ARCHITETTURA LOGICA
Nel presente capitolo vengono definite le specifiche architetturali relative alla struttura applicativa e
operativa della piattaforma proposta.
4.1. HIGH LEVEL DESIGN
Da un punto di vista architetturale l’Infrastruttura di Interoperabilità messa a disposizione
dall’Amministrazione si declina logicamente in tre aree a supporto della realizzazione dei servizi che
ruotano intorno al tema del Fascicolo Sanitario Elettronico:
1. Api Governance: L’esposizione dei servizi ai vari stakeholders interessati alla vita del FSE
è mediata tramite uno strato di Api Management che consenta di gestire ed orchestrare le
richieste per accedere alle API ed ai WS da parte di applicazioni e partner. Le funzionalità
che dovrà rendere disponibile tale componente sono Progettazione e prototipazione di Api,
API Analysis
2. Persistence & Services: Rappresenta lo strato di gestione delle interazioni basate su servizi
tra i moduli funzionali della soluzione, i moduli che gestiscono il flusso di lavoro ed i moduli
funzionali presenti nel resto del sistema informativo aziendale. È grazie a questo strato –
implementato da FSE-INI – che vengono gestiti i flussi di integrazione principali previsti dai
profili di interoperabilità supportati, nonché alcune integrazioni basate su altri standard, come
messaggi HL7. Al fine di gestire le logiche UX e le informazioni legate a auditing e
monitoraggio, viene predisposto un apposito data layer.
3. Orchestration Layer: A questo livello afferiscono tutti i componenti in grado di mettere in
opera la rete di integrazione tra i sistemi locali, regionali e nazionali specificamente dedicati
alla trattazione dei contenuti afferenti il FSE. Tutti i sistemi in questione sono inclusi nella
soluzione FSE-INI e seguono profili di integrazione dedicati.
L’architettura complessiva della Piattaforma del Fascicolo Sanitario Elettronico è evidenziata nel
seguente figura:
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 28 di 64
Figura 2 Architettura di alto livello della soluzione
4.2. STRUTTURA GENERALE
Data la complessità e la dimensione della soluzione proposta, la piattaforma è stata segmentata da un
punto di vista logico in un insieme di sistemi locali integrati. I componenti previsti possono essere
logicamente raggruppati in moduli tematici caratterizzati da competenze specifiche e a volte legati ad
un ambito tecnologico particolare. Complessivamente, nella piattaforma, si possono distinguere i
seguenti sotto-sistemi principali:
- Ingestion e orchestrazione: aggregazione dei documenti FSE prodotti dalle
strutture sanitarie locali operata da FSE-INI e condivisione del flusso con altri
moduli della piattaforma e integrazione con l’infrastruttura nazionale per
l’interoperabilità.
- Logica di business e integrazione: insieme dei servizi di interoperabilità con FSE-
INI, gestione delle notifiche, monitoraggio e auditing.
- Sicurezza: autenticazione su comunicazioni server to server, monitoraggio e
allarmistica.
- Portale e app mobile: front-end
I moduli inclusi nella presente architettura si riferiscono alla trattazione di tematiche specifiche che
spesso richiedono la distribuzione di componenti dedicati nell’ambito di molteplici sistemi interni
alla piattaforma.
4.3. DATA LAYER
Le informazioni legate alla gestione delle logiche UX (incluse le preferenze utente in merito all’invio
di notifiche), al master data, al monitoraggio e all’auditing verranno immagazzinate e
opportunamente indicizzate in un data layer dedicato. Nello stesso, saranno conservate
temporaneamente anche le informazioni legate ai documenti di taccuino in attesa di essere inviate
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 29 di 64
verso FSE-INI per la pubblicazione sul fascicolo sanitario ad uso del paziente. La struttura del data
layer sarà definita sulla base di specifiche caratteristiche sia strutturali che funzionali.
In questo caso il master data management si riferisce al trattamento di alcune tipologie di
informazione:
- Gestione delle codifiche e delle terminologie utilizzate in alcune sezioni strutturate
dei documenti FSE.
- Gestione di alcune anagrafiche interne come il catalogo dei tag.
- Integrazione e gestione del caching e della distribuzione interna delle informazioni.
4.4. SPECIFICHE DI INTEGRAZIONE
Nello schema seguente si può osservare una rappresentazione semplificata dei principali flussi di
informazione gestiti dalla piattaforma.
Figura 3 FLusso dati nella piattaforma
Sicuramente il flusso di maggior interesse che possiamo riconoscere nel precedente schema riguarda
i documenti FSE prodotti dalle strutture sanitarie locali che vengono in prima istanza gestiti da FSE-
INI per poi essere consumati tramite applicazione mobile e portale.
Considerata la natura innovativa dei business case implementati, un altro flusso di particolare
interesse riguarda l’auditing molto granulare in merito alle attività di tutti gli attori previsti (pazienti,
operatori sanitari, tecnici sanitari, amministratori) per la piattaforma. L’analisi che può essere
condotta su questo tipo di informazione consente il calcolo di importanti indicatori che possono
aiutare nella definizione di una roadmap si sviluppo di nuove capabilities e di tuning di quelle
esistenti.
L’invio di notifiche verso gli attori coinvolti, a vari livelli, nell’utilizzo della piattaforma, sarà
realizzato centralizzando la gestione dei canali di delivery. Il flusso dei messaggi di notifica
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 30 di 64
provenienti dai diversi componenti della piattaforma e da FSE-INI sarà canalizzato in una apposita
coda di messaggi.
L’integrazione tra FSE-INI e la piattaforma avverrà tramite l’implementazione di profili di
interoperabilità dedicati e implementati in forma di API SOAP o REST con un formato di
interscambio dei dati che sarà definito nel dettaglio durante il corso del progetto. Il formato di
interscambio dei documenti di FSE sarà invece HL7-CDA2 compatibile con le specifiche incluse
nell’affinity domain rilasciato da AGID.
L’integrazione con i servizi di FSE-INI prevede la propagazione dell’identificazione dell’attore che
ha originato la transazione tramite l’inclusione del suo codice fiscale in una opportuna sezione del
corpo della richiesta.
4.5. ANAGRAFICHE E CODIFICHE
Nel dominio dati legato al fascicolo sanitario possiamo includere uno specifico insieme di codifiche
e anagrafiche che devono essere utilizzate per caratterizzare i contenuti di un documento FSE. In
particolare, le anagrafiche dei pazienti, delle strutture sanitarie e dei medici e le codifiche già descritte
nei precedenti paragrafi.
Dando priorità alla protezione dei dati sensibili dei pazienti nel rispetto dei vincoli imposti dal GDPR,
le informazioni anagrafiche saranno acquisite dall’anagrafica unica regionale per essere poi salvate e
criptate su database. L’accesso a tale cache sarà applicativo tramite una API che richiede
l’autenticazione dell’attore richiedente e che accetta connessioni solo da specifiche sorgenti.
A seconda delle caratteristiche della sorgente di informazione e delle funzionalità di gestione
necessarie, saranno implementate le logiche di servizio più adatte alla sincronizzazione dei dati nel
suddetto livello di cache o, dove possibile, nel data-lake. In particolare:
- Per le anagrafiche relative a pazienti, strutture sanitarie e operatori sanitari si farà
riferimento ad un sistema esterno realizzato nell’ambito del progetto SINFONIA.
Per il recupero e la sincronizzazione delle informazioni di interesse sarà
implementato il profilo di interoperabilità appositamente definito per il suddetto
sistema.
- La gestione delle codifiche ufficialmente utilizzate per esprimere molte delle
informazioni contenute in un documento FSE avviene totalmente all’interno della
piattaforma. Di conseguenza saranno realizzati dei microservizi per la gestione
delle informazioni nel data-lake e per la sincronizzazione in cache.
4.6. SISTEMA NOTIFICHE
La piattaforma utilizzerà un apposito sistema per la gestione centralizzata e l’inoltro di messaggi di
notifica ai canali di delivery tramite e-mail, SMS e notifiche push.
Il sistema per la gestione delle notifiche prevede un livello di configurabilità e la gestione delle
preferenze utente legate all’abilitazione ed ai canali di ricezione delle diverse tipologie di notifiche
previste. L’accettazione delle notifiche prodotte dai processi sorgente è disaccoppiata dal delivery
delle notifiche tramite un message broker.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 31 di 64
Figura 4 Architettura logica sistema notifiche
4.7. TRACING E LOGGING
Ognuno dei componenti appartenenti alla piattaforma dovrebbe essere in grado di produrre log di
differente tipologia in funzione dell’aspetto operativo o funzionale che viene osservato. I log prodotti
dovranno essere instradati come log stream verso storage dedicati. Questo include anche le
informazioni di audit ed il log di sistema.
Appositi connettori instraderanno il traffico di log verso un apposito cluster Elasticsearch ed in parte
anche verso Zipkin. Quest’ultimo consentirà una più semplice gestione dei log di tracciamento delle
attività per transazioni distribuite su più componenti. La tecnica di base per il tracciamento è l’utilizzo
di un tracing id ed il prodotto indicato include API per la produzione di dati di tracciatura compatibili
con le più comuni piattaforme e linguaggi di programmazione.
Gli schemi riportati sotto esplicitano al meglio l’architettura che si intende implementare in merito al
tracciamento delle transazioni tra processi applicativi distribuiti.
Figura 5 Tracciamento transazioni distribuite Figura 6 Tracciamento in Zipkin
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 32 di 64
Successivamente, personale autorizzato potrà accedere a dashboard offerte da Zipkin e altri prodotti
come Kibana ad uso interno dei tecnici della Regione Campania.
4.8. PORTALI E APP MOBILE
Nell’ambito della piattaforma devono essere realizzati i seguenti prodotti:
- Portale al cittadino
- Portale FSE+
- APP mobile per iOS e Android
Di seguito è rappresentato uno schema che riassume il design generale della soluzione per tutti i
prodotti in elenco.
Figura 7 Architettura logica portali e APP mobile
4.8.1. PORTALE AL CITTADINO
Per il portale al cittadino è prevista la realizzazione di un modulo core che offre un set di funzionalità
Javascript ad uso delle verticali funzionali come il portale FSE+. La capacità primaria di un portale
di poter includere in una interfaccia unica diversi prodotti avviene quindi a monte, al livello del front-
end, semplificando in modo sostanziale l’integrazione di prodotti e sistemi eterogenei e/o
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 33 di 64
incompatibili sia in merito allo stack tecnologico di riferimento che alle specifiche esigenze
infrastrutturali.
Per ottenere trasversalmente uniformità nell’aspetto dei diversi prodotti inclusi nel portale, sarà
predisposto un insieme strutturato di fogli di stile nell’ambito dei quali definire le classi che
determineranno globalmente l’aspetto dei componenti grafici inclusi in tutte le funzionalità.
Il modulo core e i fogli di stile appena descritti dovranno essere disegnati per essere integrati in una
soluzione CMS adeguata alle esigenze di editoria dei contenuti specifici del portale al cittadino. La
componente CMS dovrà offrire capacità di gestione dei profili di autorizzazione per consentire
l’accesso solamente al personale autorizzato dall’amministrazione. Deve anche essere supportato
l’editing dei contenuti in molteplici lingue, l’inclusione di elementi in apposite gallerie multimediali,
la realizzazione di nuove pagine (che non contengano interfacce applicative di altri prodotti), la
pubblicazione di contenuti (file) scaricabili e news.
4.8.2. PORTALE FSE+
In merito al portale FSE+, il modulo UI sarà realizzato per essere compatibile con le specifiche di
integrazione con il portale al cittadino e l’embedding dell’interfaccia in specifiche sezioni (elementi
HTML) di una pagina ospitante. Per la realizzazione della logica di controllo sarà utilizzato il pattern
reactive.
Le componenti back-end che costituiranno il modulo UX della soluzione andranno ad ampliare il set
di micro-servizi applicativi inclusi nella piattaforma. Lo scopo di questi micro-servizi è di supportare
l’operatività del portale implementando tutte le funzionalità specificamente inerenti all’esperienza
utente.
4.8.3. APP MOBILE
L’APP mobile sarà realizzata come APP ibrida con lo scopo di creare una esperienza utente uniforme
ed ottimizzare il costo della soluzione.
La tecnologia scelta per l’implementazione consentirà di implementare la soluzione utilizzando il
pattern reactive, di supportare le piattaforme iOS e Android e tutte le altre caratteristiche richieste per
questa tipologia di prodotto già presentate nel capitolo di architettura funzionale.
In merito alla forma di autenticazione forte che deve essere implementata, dovrà essere concordata e
definita nel dettaglio la strategia più adatta alle esigenze della amministrazione durante i momenti
iniziali della fase di delivery del prodotto.
4.9. SICUREZZA
Per garantire un corretto livello di sicurezza per la protezione dei dati dell’amministrazione e della
privacy dei pazienti è necessario adottare specifiche precauzioni che richiedono scelte di design
dedicate descritte nel dettaglio nel presente paragrafo.
4.9.1. ACCESSO E TRACCIABILITÀ
In generale un primo livello di protezione risiede nell’utilizzo di SSL e autenticazione per qualunque
trasmissione dati sia server to server (anche tra componenti nella medesima infrastruttura) che client
to server.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 34 di 64
Il portale, le applicazioni mobile ed i sistemi di monitoraggio e auditing saranno accessibili a tre
categorie principali di attori (come già descritto nel paragrafo 3.1 - Autenticazione e autorizzazione):
assistiti, personale sanitario, tecnici di settore. L’autenticazione per l’accesso alle API da front-end
viene gestita tramite un apposito Identity Server federato con l’Identity Provider regionale. A
quest’ultimo viene completamente demandata la gestione dell’anagrafica di riferimento di tutti gli
attori che hanno accesso alla piattaforma.
L’integrazione con i servizi di FSE-INI prevede la propagazione dell’identificazione dell’attore che
ha originato la transazione tramite l’inclusione del suo codice fiscale in una opportuna sezione del
corpo della richiesta.
Per le connessioni server to server con sistemi interni (come i database) o esterni (come l’anagrafe
regionale sanitaria) che pur non necessitando dell’identificazione dell’attore fisico coinvolto nella
transazione in corso ma comunque richiedono una forma di autenticazione (per garantire l’accesso
solamente a determinati processi) si può gestire l’autenticazione tramite OAuth2 (creando appositi
service account) o preferibilmente tramite PKI (Public Key Infrastructure) utilizzando appositi
certificati.
Per favorire il monitoraggio e l’analisi delle attività nell’ambito della piattaforma saranno utilizzate
tecniche di tracciamento delle transazioni distribuite. In questo caso, la tecnica di riferimento prevede
la propagazione di un transaction id nelle connessioni server to server e l’introduzione di un prodotto
specifico per l’analisi delle transazioni distribuite come già scritto nel paragrafo 4.7 - Tracing e
logging.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 35 di 64
5. ARCHITETTURA TECNOLOGICA
5.1. SCELTA OPEN SOURCE
La scelta dei prodotti da utilizzare per la piattaforma è stata guidata da un processo di software
selection.
La selezione ha visto emergere la suite WSO2 come preferred vendor per la parte di middleware,
mentre per le altre componenti sono stati valutati anche altri prodotti.
Molteplici sono stati i fattori che hanno portato a questa conclusione. Tra questi citiamo:
- Copertura dei requisiti funzionali
- Copertura dei requisiti non funzionali
- Valutazione dei costi
La scelta di privilegiare prodotti open source è stata dettata non solo dalla software recommendation,
ma anche da un indirizzo generale della pubblica amministrazione, ed è avvalorata da ulteriori
caratteristiche di tali prodotti e del loro ciclo di sviluppo.
Il nocciolo della filosofia open source, ovvero la possibilità di far evolvere il software in maniera
trasparente da parte di una comunità aperta di sviluppatori, ha scardinato i principi e le motivazioni
tradizionali alla base dell'evoluzione del software.
Dal punto di vista della pura manutenzione evolutiva, una base di utenti e collaboratori
sufficientemente ampia assicura pronta individuazione e correzione di difetti software, più o meno
evidenti. È come avere a disposizione una squadra di tester costantemente in azione, con un team di
bug fix in grado di rilasciare le patch rapidamente e indipendentemente da cicli di rilascio di prodotto
prestabiliti, e a porre particolare attenzione anche a temi di sicurezza: ad esempio, il protocollo
OpenSSL è nato proprio in ambito open source. Tali considerazioni trovano conferma anche in un
sondaggio di Forrester (2008), che ha rilevato che il 92% degli utilizzatori enterprise di software open
source in Europa ritiene che questi prodotti siano stati all’altezza, o abbiano addirittura superato, le
loro aspettative.
La costituzione di comunità di sviluppatori interessati incoraggia la discussione e il confronto
pubblico, se necessario anche impietoso, di ogni punto di forza e di debolezza del prodotto
nell'utilizzo effettivo. Ciò consente di far emergere spontaneamente le aree di miglioramento, e
feature realmente utili e necessarie, rilasciate con tempi potenzialmente inferiori a quelli dei prodotti
commerciali standard, che devono programmare le roadmap di prodotto anche in base alla presunta
richiesta di mercato delle nuove funzionalità da introdurre. È importante sottolineare questo aspetto,
che assicura alle imprese e agli enti che adottano prodotti open source un’estrema reattività e agilità
rispetto alle esigenze di business: è possibile creare liberamente nuove feature, anche innovative, il
cui effettivo valore sarà poi determinato dall’adozione o meno da parte della comunità. Inoltre, dal
momento che un’attiva comunità di sviluppatori assicura la risoluzione dei problemi più “facili”,
alcuni vendor sfruttano questa base consolidata per concentrare i propri sforzi sul prodotto in attività
creative e ad alto valore, piuttosto che nell’iterativa manutenzione ordinaria del software, dando
vigore all’innovazione.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 36 di 64
Guardando alla storia recente del software, si possono riscontrare numerosi esempi di ambiti in cui i
prodotti open source hanno realmente guidato l’innovazione: si pensi ad Android per il mondo
mobile, o alla rivoluzione Big Data, con l’introduzione dei DB NoSQL, e Hadoop ormai standard di
mercato. In effetti, anche tornando indietro nel tempo, lo stesso protocollo http, alla base di Internet,
è nato in ambito open source.
L’assenza di standard proprietari comporta una maggiore interoperabilità tra le soluzioni open source,
offrendo quindi la possibilità di disegnare architetture enterprise modulari, integrando i prodotti più
adatti a supportare il business. Inoltre, è possibile evitare il lock-in ad un produttore specifico, con il
rischio di migrazioni forzate nel caso in cui questi decida di sospendere la manutenzione e il supporto
ad un prodotto, o ad una sua particolare versione.
A fronte dei numerosi vantaggi menzionati, bisogna altresì evidenziare alcuni aspetti solitamente
percepiti come fattori di rischio dell’adozione di prodotti open source nell’ambito di un’azienda o
ente:
- Complessità di gestione
- Certezza di manutenzione del prodotto, sia in termini correttivi (bug fix) che
evolutivi (implementazione di nuove feature)
- Assenza di indicatori di vendita, che rende difficile valutare il grado di adozione
dei prodotti
Il processo di valutazione dei prodotti open source deve essere affrontato in maniera differente
rispetto agli approcci tradizionali di software selection, e avere l’obiettivo di mitigare i rischi sopra
esposti.
Nella valutazione dei prodotti open source diventa importante riuscire a dare una misura, quanto più
possibile quantitativa, della probabilità che il prodotto resti all’altezza degli standard qualitativi
richiesti, e che la community di sviluppatori continui a supportarlo lungo il ciclo di vita del progetto.
Dalla trattazione precedente emerge con chiarezza che il valore dei prodotti open source è
strettamente correlato all’estensione e alla qualità della comunità di sviluppatori che ruota intorno al
prodotto, motivo per cui queste dimensioni sono alla base della maggior parte degli indicatori
considerati. Per questo stesso motivo, e anche data la varietà tecnologica dei prodotti in esame, in
questo processo di selezione si è preferito focalizzarsi su indicatori language-agnostic, piuttosto che
su tecniche basate sull’analisi statica del codice sorgente.
Di seguito le dimensioni considerate:
• Trasparenza della community: misura il grado di accessibilità del codice del prodotto e delle
relative discussioni. Si considerano:
o Repository del codice sorgente e modalità di accesso / contribuzione
o Strumenti di interazione della community, e loro apertura
• Frequenza di aggiornamento: si tratta dell’indicatore più immediato per valutare il grado di vitalità
del prodotto. Per misurarla si considerano le seguenti statistiche:
o Numero di commit complessive
o Frequenza di commit
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 37 di 64
• Dimensione della community: un elevato numero di utenti attivi nella community minimizza il
rischio che il progetto venga abbandonato nel caso di perdita d’interesse da parte di personaggi
chiave, oltre a fornire maggiori garanzie di risoluzione di eventuali problemi. Si propone di
misurarla attraverso:
o Numero di contributors
• Grado di interesse per il prodotto: in assenza di indicatori di vendita precisi, si stima l’adozione
del prodotto in base alle menzioni sul web (tratte da Google), e alle domande poste su forum di
sviluppo non specializzati in una particolare tecnologia (come Stack Overflow). Sono utilizzati:
o Comparazione dei prodotti su Google Trends: per ciascun gruppo di termini di ricerca
esaminati, fornisce dei grafici con l’andamento relativo dei risultati di ricerca nel periodo
di tempo considerato
o Numero di conversazioni taggate con il nome del prodotto su Stack Overflow
In sintesi, la soluzione proposta è stata basata principalmente su tre fattori:
• Software Selection: ha fornito valutazioni specifiche sull’aderenza dei prodotti selezionati
rispetto ai requisiti espressi dal Cliente
• Trend della Pubblica Amministrazione
• Valutazioni sui prodotti Open Source
5.2. API GOVERNANCE E ENTERPRISE INTEGRATION CON WSO 2
La componente di API Governance è implementata attraverso il prodotto WSO2 API Manager,
opportunamente integrato con la componente WSO2 Identity Server.
Le funzionalità fornite dall’API manager sono le seguenti:
• Disegno e prototipazione di API
o Disegno di API e raccolta di feedback da parte degli sviluppatori prima di renderle
operative (API First Design). La progettazione può essere eseguita dall'interfaccia di
pubblicazione o importando una definizione Swagger 2.0 esistente
o Implementazione di API “mock” utilizzando il linguaggio JavaScript
o Supporto alla pubblicazione di servizi REST e SOAP con codifica JSON o XML
o Disponibilità di API di esempio precaricate
• Pubblicazione di API e governo del loro uso
o Pubblicazione di API a consumer e partner esterni, nonché agli utenti interni
o Possibilità di pubblicare API in un set selezionato di gateway in un ambiente multi-
gateway
o Gestione della visibilità dell'API e limitazione dell’accesso a partner o clienti specifici
o Gestione del ciclo di vita dell'API: creazione, pubblicazione, sospensione e gestione
delle API deprecate
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 38 di 64
o Pubblicazione delle chiavi di produzione e sandbox per le API per agevolare il test
degli sviluppatori
o Gestione delle versioni delle API e del loro stato di distribuzione in base alla versione
o Personalizzazione del ciclo di vita dell'API, compresa un eventuale comportamento
personalizzato sulle transizioni del ciclo di vita
• Controllo degli accessi e gestione della sicurezza
o Convalida il contenuto del payload API in base ad uno schema
o Applicazione di policy di sicurezza alle API (autenticazione, autorizzazione)
o Implementazione dello standard OAuth2 per l'accesso alle API
o Collegamento a server esterni come alternativa a quello “embedded” per la
registrazione dell'applicazione e la generazione e la convalida dei token Oauth2
o Blocco di una sottoscrizione e limitazione completa di un'applicazione
o Possibilità di associare alle API livelli di servizio definiti dal sistema
o Generazione di JSON token Web a beneficio dei server di back-end
o Configurazione del Single Sign-On (SSO) utilizzando lo standard SAML 2.0
o Rilevamento di minacce, di bot e di potenziali frodi nell’uso dei token
• Portale per gli sviluppatori
o Fornisce una user experience simile agli store di app
o E’ possibile cercare le API per provider, tag o nome
o Possibilità di gestire le chiavi per le API
o Possibilità di sottoscriversi alle API e di gestire le sottoscrizioni delle singole
applicazioni
o Possibilità di gestire le sottoscrizioni con diversi livelli di servizio
o Console interattiva per il test di API
o Supporto per l'internazionalizzazione
o Possibilità di ricevere notifiche sulla disponibilità di nuove versioni di API per cui è
stata effettuata una sottoscrizione
La piattaforma è stata realizzata mediante la suite WSO2 e nello specifico:
• WSO2 ApiManager
• WSO2 Analitycs
• WSO2 Identity Manager
Tutti prodotti open source con licenza di utilizzo GPL.
Le principali componenti messe a disposizione dalla piattaforma sono rappresentate nella figura
seguente:
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 39 di 64
Figura 8 Api Manager
Lo sviluppo di API è generalmente realizzato da risorse in grado di comprenderne gli aspetti tecnici,
le loro interfacce, la loro documentazione, le loro versioni, ecc… mente la gestione delle API è
tipicamente affidata a qualcuno che ne coglie gli aspetti di business.
In molti contesti lo sviluppo delle API è una responsabilità distinta dalla pubblicazione e dalla
gestione delle stesse.
Il prodotto WSO2 API Manager fornisce una semplice User Interface chiamata WSO2 API Publisher
che serve a questo scopo. È un front-end progettato per consentire agli sviluppatori di API di censirle,
documentarle e versionarle, facilitando al contempo i task relativi alla gestione delle stesse quali la
pubblicazione, la monetizzazione, l’analisi delle statistiche e la promozione delle stesse.
La web application di API Store fornisce invece una interfaccia grafica per chi pubblica API che gli
consente di censire e pubblicizzare le proprie API, e per i consumatori di API di registrarsi e
cercare, valutare e sottoscriversi all’uso di API sicure poiché protette da un sistema di
autenticazione.
La componente di API Gateway è una componente di runtime di backend che agisce API proxy ed è
sviluppata sulla base di WSO2 ESB. Tale componente rende le API sicure, le protegge, le gestisce e
permette di scalare le chiamate alle API. Le richieste alle API vengono intercettate da questo
componente che applica le politiche quale il “throttling” (la limitazione della frequenza delle
chiamate), la sicurezza (attraverso handlers) e gestisce le statistiche. Se la chiamata soddisfa le policy,
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 40 di 64
il Gateway inoltra la chiamata al corrispondente sistema di backend. Se la chiamata si riferisce ad una
richiesta di token, il gateway inoltra la chiamata al Key Manager.
La componente di Key Manager gestisce tutte le operazioni relative alla sicurezza e ai token di
accesso. Il gateway si connette al Key Manager per verificare la validità dei token OAuth e delle
corrette sottoscrizioni alle API. Quando viene creata un’applicazione e viene generato un token
utilizzando l’API Store, questo effettua una chiamata all’API Gateway, che a sua volta si connette al
Key Manager per creare un OAuth client ed ottenere un access token. In modo similare, per validare
un token, l’API Gateway chiama il Key Manager il quale rintraccia e valida il token dal database.
Il Key Manager fornisce anche una specifica API per generare token OAuth che possono essere
acceduti attraverso il gateway. Tutti i token usati per la validazione sono basati sullo standard OAuth
2.0.0. L’API Gateway supporta l’autenticazione con OAuth 2.0 e abilita le organizzazioni a imporre
un limite nella frequenza delle chiamate.
Il Key Manager disaccoppia le operazioni per la creazione di applicazioni OAuth e di validazione
degli access token rendendo possibile la delega del processo di validazione delle chiavi a sistemi terzi.
La componente di Traffic Manager aiuta gli utenti a regolare il traffico delle API, rendendo possibile
la differenziazione dei livelli di servizio tra diversi consumer, prevenendo in questo modo anche
possibili attacchi di sicurezza. Sostanzialmente il Traffic Manager lavora come un engine dinamico
per le politiche di throttling in real-time, inclusa la limitazione del rating delle richieste alle API.
La componente di WSO2 API Manager Analytics fornisce capabilities di monitoraggio e analisi in
grado di fornire statistiche in forma grafica ed analitica, meccanismi di alerting su eventi pre-
determinati e di analisi dei log.
5.2.1. API MANAGER
WSO2 API Manager fornisce gli strumenti necessari per implementare e gestire interfacce di
programmazione delle applicazioni standard per componenti che comunicano tra loro utilizzando
protocolli noti. Oggi quasi tutte le applicazioni software utilizzano un qualche tipo di API per
comunicare con i loro componenti interni, servizi aziendali, sistemi di terze parti, database, ecc.
Anche se le API possono essere utilizzate a questo scopo, la crescita delle imprese digitali e le
complesse esigenze di l'integrazione con vari sistemi può richiedere solo più di API per soddisfare le
esigenze dei consumatori.
Questi requisiti possono includere sull'applicazione di politiche di sicurezza, politiche di utilizzo,
raccolta e analisi delle statistiche, utilizzando specifiche API standard come Swagger e OpenAPI per
la descrizione delle API, fornendo una documentazione API appropriata e, più importante, un portale
API per gli sviluppatori ove le API possono essere fornite con un modello di abbonamento o payment
a consumo. Gli sviluppatori possono anche richiedere l'applicazione di politiche di mediazione per
trasformare messaggi, cambiare protocolli, supportare protocolli legacy, ecc. Quando si espongono i
servizi di backend come API i team di sviluppo API potrebbero richiedere un processo di gestione
del ciclo di vita dell'API adeguato con controllo di versione e funzionalità CI / CD per consentire a
diverse business unit e organizzazioni di terze parti di utilizzare le API in modo efficiente. In alcuni
casi, a seconda della natura dell'attività, le organizzazioni possono anche dover monetizzare l'utilizzo
delle API.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 41 di 64
WSO2 API Manager utilizza WSO2 ESB per il suo runtime gateway, i componenti WSO2 API Key
Manager per l'alimentazione delle funzionalità di sicurezza e componenti del server, WSO2 Data
Analytics per fornire funzionalità di API Analytics. WSO2 API Manager fornisce inoltre un ricco set
di interfacce utente per la gestione del portale API, dell'editor API, del monitoraggio, delle analitiche
e delle funzionalità amministrative.
5.2.2. API GATEWAY
L’API Gateway, cuore della soluzione, ha come finalità essenziale quella di esporre i servizi messi a
disposizione dall’intero sistema in maniera sicura, facilmente fruibile e controllata.
Esso si posiziona davanti ai servizi esposti dal backend, in modo tale che tutti i sistemi esterni debbano
effettuare l’accesso a servizi e risorse attraverso questo componente. Infatti, il Gateway, per ogni
accesso al sistema da parte di un’applicazione esterna, effettua i seguenti passi:
• Riceve le richieste per accedere alle API
• Attua le politiche di controllo di accessi, integrandosi se necessario anche con altre
componenti
• Applica le regole di rate limiting e throttling
• Invia le richieste al backend dell’API (questo step può essere mediato dall’ESB)
• Effettua il routing della risposta al sistema chiamante.
Figura 9 Api Gateway
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 42 di 64
Gli obiettivi principali di tale sistema possono essere riassunti come segue:
• Livello di sicurezza: garantisce l’accesso soltanto agli utenti/sistemi autenticati e autorizzati
ed evita l’uso improprio delle risorse protette. Sono disponibili diversi framework di sicurezza
come OPENID, OAuth2, SAML o Basic Authentication che consentono a diverse
applicazioni di integrarsi in modo sicuro dipendentemente dallo scenario e dalle esigenze
implementative. (in integrazione con il componente Key Manager)
• Performance gestite in maniera puntuale e dinamica per ciascuna API con
o Limitazione del traffico in ingresso (rate limiting)
o Applicazione di politiche di accesso diversificate in base sistema chiamante
(throttling)
o Routing
o Mediazione dei servizi
o Caching dei messaggi
• Filtraggio del traffico in ottica di identificazione e neutralizzazione di minacce
• Gestione del ciclo di vita delle API nelle fasi di sviluppo, test, produzione e dismissione,
nonché versionamento. Questa funzionalità garantisce la coerenza di differenti versioni
dell’API consentendo il suo utilizzo da parte di diverse tipologie di utenti, in ambienti diversi
e con diversi gradi di maturità
• Monitoring e alerting configurabili per verificare lo stato del sistema ed alimentare sistemi di
notifica nel caso in cui si verifichino eventi inattesi (in integrazione con il sistema di
Analytics)
• Flessibilità nei protocolli: supporto di servizi di backend di tipo Web Service o REST e
possibilità di esporre tali servizi modificandone il protocollo. Questo consente di esporre
anche servizi pre-esistenti in nuove modalità senza la necessità di cambiare l’implementazione
del servizio stesso
• Esposizione della API in diverse modalità: di particolare interesse sono le API Rest e Web
Socket
• REST: I servizi che si conformano allo stile REST (REpresentational State Transfer)
espongono interfacce che consentono di manipolare le risorse applicative offerte dal servizio
attraverso l’utilizzo uniforme di un set di operazioni. I servizi REST rispondono alle richieste
inviate dai consumer ritornando opportune rappresentazioni delle risorse, e non conservano
alcuno stato circa le interazioni avvenute. Le risorse sono univocamente determinate dall’URI
e, ove necessario, modificate tramite query parameters e payload delle request, solitamente in
formato JSON
• Web Socket: Le API esposte come websocket forniscono una comunicazione bidirezionale in
tempo reale applicabile a qualunque tipo di applicazione client-server. Permette maggiore
interazione tra un client e un server, facilitando la realizzazione di applicazioni che forniscono
contenuti in tempo reale. Questo è reso possibile fornendo un modo standard per il server di
mandare contenuti al client senza dover essere sollecitato dal client e permettendo ai messaggi
di andare e venire tenendo la connessione aperta.
5.2.3. KEY MANAGER
Il Key Manager, chiamato anche Authorization Server, in integrazione con l’API Gateway, è il
componente deputato alla gestione degli accessi e all’autorizzazione delle richieste attraverso
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 43 di 64
l’utilizzo di diversi protocolli di autenticazione e autorizzazione quali OPENID, SAML, OAuth2,
Basic Authentication.
Framework OAuth2 Tra gli standard messi a disposizione, Open Authorization 2 (OAuth2) è quello che ha avuto una
maggiore affermazione nell’esposizione delle API; esso costituisce un framework di comunicazione
open mediante il quale si può gestire in modo sicuro l’accesso autorizzato a risorse protette.
Al contrario degli approcci tradizionali, offre i seguenti vantaggi:
• Le applicazioni non devono memorizzare in nessuna forma le credenziali degli utenti
• Le risorse vengono fornite alle applicazioni in modo controllato sia in termini di scope che in
termini temporali
• L’utente finale può revocare l’accesso alle proprie risorse limitatamente a determinate
applicazioni, senza la necessità di dover cambiare le credenziali
• La scelta implementativa non è univoca, ma si adatta ai diversi scenari di applicazione; per
esempio lo standard si differenzia in base alla possibilità dei fruitori delle risorse di mantenere
dati in modo sicuro, alla tecnologia impiegata, etc.
Per delineare il funzionamento di OAuth2, si possono definire i seguenti attori:
• Resource Owner: (RO) è il proprietario della risorsa da proteggere.
• Resource Server: (RS) è il server che espone la risorsa protetta, nel nostro caso si tratta
dell’API Gateway che si frappone tra Client e servizio di backend. Riceve le richieste da un
client che si identifica tramite la presentazione di un access_token e fornisce la risorsa
richiesta
• Client: è l’applicazione fruitrice della risorsa. Le applicazioni possono essere di qualsiasi tipo:
web, client/server, mobile, desktop
• Authorization Server: (o Key Manager) è il server che, a fronte di una grant del RO, fornisce
al client gli access token da presentare al RS per accedere alla risorsa.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 44 di 64
Figura 10 Flusso OAuth2
Il flusso sopra illustrato è il flusso logico che il framework si propone di realizzare. Tuttavia,
l’implementazione effettiva dipende dalla natura dei client, dal livello di trust tra resource owner e
client e dalle esigenze di tracciatura di accessi e risorse accedute. Si illustrano di seguito i 4 modelli
implementativi (grant type):
• Authorization Code
• Implicit
• Onwer Credentials
• Client Credentials
Per le esigenze espresse nel progetto, il flusso da prendere in considerazione è il Client Credentials
poiché esso prevede un’interazione server to server e non necessita della partecipazione dell’utente
finale nell’accesso alle risorse protette, ma è il client stesso che, essendo trusted, può effettuare
l’accesso alle API.
Questo flusso prevede che il client si sia precedentemente registrato sull’Authorization Server e che
gli siano stati associati Client ID e Client Secret. Tali dati vengono memorizzati staticamente nel
Client ed utilizzati a runtime per richiedere l’Access Token. Pertanto, il client deve essere in grado di
salvare in modo sicuro le credenziali, tipicamente in scenari server to server.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 45 di 64
Figura 11 OAuth2 Client Credentials
Come conseguenza, il flusso Client Credentials:
• Viene utilizzato nei casi in cui:
• Le risorse oggetto dell’autorizzazione sono limitate alle risorse protette sotto controllo del
client
• Le risorse sono state precedentemente concordate con l’Authorization Server (forte TRUST
sul Client)
• Il Client coincide con il Resource Owner
• Viene utilizzato quando NON c’è esigenza di tracciare l’utilizzatore finale
Ottenuto l’Access Token, il Client può contattare il Resource Server per richiedere le risorse. Allo
scadere dell'access token, il client dovrà richiederne uno nuovo seguendo lo stesso approccio.
5.2.4. IDENTITY SERVER
La soluzione prevede l’utilizzo di un Identity Server (IS) che unifichi la gestione delle utenze e dei
gruppi in maniera cross su tutte le componenti.
Oltre che a garantire un single sign-on su tutti i sistemi e la federazione con altri Identity Provider,
l’Identity Server viene utilizzato come Identity Provider nei flussi autorizzativi OAuth2 fornendo la
parte di autenticazione ed affiancandosi al Key Manager che fornisce invece la parte autorizzativa.
L’Identity Server (IS) fornisce una gestione sicura delle utenze, gestendo identità e ruoli in modo
centralizzato, con la possibilità di federare altri Identity Server in modelli n-n o 1-n. Nel primo caso
i consumer possono interfacciarsi con un unico Identity Provider federato e centralizzato, nel secondo
caso, invece, i consumer possono interfacciarsi con n Identity Provider in modo che sia garantita la
massima flessibilità.
Le funzionalità messe a disposizione dall’Identity Server sono molteplici:
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 46 di 64
• Gestione accessi:
o Supporto XACML - eXtensible Access Control Markup Language: linguaggio
basato su XML per gestire gli accessi in modo puntuale e dettagliata
o Supporto RBAC - Role Based Access Control: controllo basato sui ruoli degli utenti
o Supporto ABAC - Attribute Based Access Contro: controllo basato su policy che
utilizzano combinazioni di attributi dell’utente
• Sicurezza delle API:
o OAuth: standard utilizzato per l’autorizzazione che consente ai client di accedere alle
risorse del server previa autorizzazione del proprietario della risorsa
• Provisioning:
o L’IS fornisce API che supportano la creazione degli utenti protette con Basic
Authentication e OAuth2
o Just-in-time (JIT) provisioning: quando l’utente è accreditato presso Identity
Providers esterni federati, l’IS ridireziona la richiesta di autenticazione su tali IP, nel
momento in cui riceve la risposta positiva, se il JIT provisioning è abilitato, l’utente
e i suoi claim vengono memorizzati nello store interno.
o Outbound Provisioning: l’IS supporta il provisioning delle utenze ad Identity
Provider esterni in tutti i flussi iniziati da un Service Provider. Il provisioning va
abilitato e si applica a SCIM, SPML, SOAP, Google Apps provisioning API,
Salesforce provisioning API.
5.2.5. PUBLISHER PORTAL
Lo sviluppo e la pubblicazione delle API sono permessi da un’interfaccia web messa a disposizione
dall’API Manager chiamata Publisher. Si possono raggruppare le funzionalità che l’API Publisher
mette a disposizione in 4 macrofunzionalità:
• Sviluppo
• Pubblicazione
• Gestione
• Monitoraggio
La creazione di un API è il processo tramite il quale si collega l'implementazione backend di un
servizio con l'API Publisher in modo da gestirne e monitorarne il ciclo di vita, la documentazione, la
sicurezza e le varie sottoscrizioni.
Una volta terminata la creazione, l'API può essere pubblicata. Nel momento in cui un API viene
pubblicata diventa visibile e disponibile per essere sottoscritta, secondo le configurazioni di visibilità
pre-definite.
Le API create nell'API Manager hanno un proprio ciclo di vita formato un insieme di stati. Un'API
ha un ciclo di vita definito dall’API Manager. Un esempio di ciclo di vita è quello riportato in figura
e composto da 6 stati (Creata, Pubblicata, Bloccata, Deprecata, Prototipata e Dismessa) ma diversi
modelli possono essere realizzati.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 47 di 64
Figura 12 Ciclo di vita dell'API
È possibile, inoltre, creare differenti versioni di un API, quando, ad esempio, si modificano alcune
funzionalità dell'API stessa o quando cambiano i meccanismi di autenticazione o livelli di throttling.
Una funzionalità molto importante durante lo sviluppo di un API è la possibilità di aggiungere la
documentazione del servizio offerto per facilitare da una parte i sottoscrittori a capirne le funzionalità,
dall'altra i publisher per promuoverla.
5.2.6. STORE PORTAL
Qualunque ente voglia accedere ai servizi dell’azienda, dovrà effettuare preventivamente un
accreditamento presso l’entità erogante. Questa sarà un’attività di tipo procedurale che prevede:
• Accordi bilaterali sull’utilizzo delle API esposte
• Accordi sul livello di servizio
• Accordi sulle politiche di rate limiting e client throttling per l’utilizzo
• Creazione di utenze tecniche per accedere ai servizi offerti
• A valle dell’espletamento di tale procedura, l’utenza tecnica creata potrà essere utilizzata per
accedere al portale API Store.
Il portale è uno strumento a disposizione degli sviluppatori, che fornisce funzionalità utili al discovery
delle API esistenti e al loro utilizzo.
• Navigazione delle API alle quali l’operatore si può sottoscrivere
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 48 di 64
• Versionamento delle API
• Consultazione della documentazione associata alle API
• Generazione automatica di codice per invocare le API
I consumers (siano essi App esterne o sviluppatori) hanno la possibilità di navigare nello Store per
ricercare quelle di loro interesse, potendo sfruttare anche i commenti e le valutazioni degli altri utenti
presenti nei forum interni. Le ricerche possono essere effettuate per nome, service provider,
descrizione, stato.
È importante sottolineare che NON tutte le API sono pubbliche; esistono, infatti diversi livelli di
visibilità:
• Pubblico: l'API è visibile a tutti gli utenti (registrati e anonimi).
• Visibile nel dominio: l'API è visibile a tutti gli utenti registrati nel dominio dell'API.
• Restrizione per ruolo: l'API è visibile solo a utenti specifici.
Per poter utilizzare un API bisogna, prima di tutto, creare un'applicazione mediante la quale effettuare
la sottoscrizione. Il ruolo principale dell'applicazione è disaccoppiare il consumer dalle APIs e
permette sia di generare e utilizzare una chiave singola per più API che di sottoscriversi più volte ad
una singola API con diversi livelli SLA.
Le applicazioni sono disponibili a diversi livelli di servizio che corrispondono al numero massimo di
chiamate che è possibile fare a un'API durante un determinato periodo di tempo (throttling). Questo
meccanismo risulta utile quando sono presenti limitazioni dell'infrastruttura per fare in modo che
l'applicazione possa effettuare un numero massimo di richieste entro un tempo definito.
La sottoscrizione ad un API consente di richiedere a runtime il token di accesso, una stringa semplice
che viene passata nell'intestazione HTTP di una richiesta per autenticare gli utenti e garantire alti
livelli di protezione. Se un token passato con una richiesta non è valido, la richiesta viene eliminata
nella prima fase di elaborazione.
5.2.7. ENTERPRISE INTEGRATOR
WSO2 Enterprise Integrator (WSO2 EI) è una soluzione di integrazione completa che consente la
comunicazione tra varie e disparate applicazioni. Invece di far comunicare le applicazioni
direttamente tra loro in tutti i loro vari formati, ciascuna applicazione comunica semplicemente con
WSO2 EI, che agisce principalmente come ESB per gestire la trasformazione e il routing dei messaggi
verso le loro destinazioni. Il prodotto WSO2 EI può essere utilizzato per gestire flussi di integrazione
stateless di breve durata (utilizzando il profilo ESB) e processi aziendali a lunga durata di tipo statefull
(utilizzando il profilo Business Process). Il prodotto include anche un profilo Analytics separato per
il monitoraggio completo, un profilo Message Broker (WSO2 MB) strumento affidabile che può
essere utilizzato per la messaggistica, nonché il profilo WSO2 MSF4j, che è possibile utilizzare per
eseguire microservizi per i flussi di integrazione.
Il profilo ESB in WSO2 EI fornisce i suoi servizi fondamentali attraverso un motore di messaggistica
basato su eventi e standard (il bus) di protocollo, che consente agli architetti, dediti a creare strati di
integrazione, di sfruttare il valore della messaggistica senza scrivere codice. Questo profilo ESB è un
passo avanti rispetto alle versioni precedenti di WSO2 Enterprise Service Bus, poiché fornisce
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 49 di 64
funzionalità di integrazione dei dati all'interno dello stesso core runtime. Ciò elimina la necessità di
utilizzare un server di servizi dati separato per i processi di integrazione.
Il profilo del processo di business in WSO2 EI consente agli sviluppatori di implementare facilmente
processi di integrazione e processi di business, scritti utilizzando lo standard BPMN 2.0 o lo standard
WS-BPEL 2.0. Basato sul motore BPEL di Activiti BPMN Engine 5.21.0 e Apache Orchestration
Director Engine (ODE), il profilo del processo di business in WSO2 EI è dotato di una console web
completa che consente agli utenti di distribuire, gestire, visualizzare ed eseguire facilmente i processi
così come i compiti umani. Pertanto, WSO2 EI è essenzialmente una raccolta di modelli di
progettazione di architettura aziendale che possono essere implementati direttamente utilizzando un
singolo prodotto. Questo prodotto è leggero e versatile. È open source al 100% ed è rilasciato con
Apache Software License versione 2.0, una delle licenze più business-friendly disponibili oggi.
Il WSO2 EI supporta diverse modalità d’integrazione, basate sugli ‘Enterprise Integration Patterns’.
I principali pattern, ovvero modelli d’integrazione d’uso comune sono:
• message routing: la capacità dell’integrator di determinare e instradare il messaggio al
destinatario; tale instradamento può anche essere fatto sulla base di specifici contenuti del
messaggio;
• message filtering: la capacità dell’Integrator di filtrare i messaggi, in base al contenuto, per
avviare l’esecuzione di logiche d’elaborazione su distinti flussi di mediazione distinti;
• message transformation: è possibile utilizzare WSO2 Enterprise Integrator per tradurre i
messaggi tra il mittente e il destinatario, quando la sintassi dei messaggi di scambio tra
mittente e destinatario non hanno lo stesso formato;
• content enrichment: è possibile utilizzare lo Enrich Mediator, per modificare un messaggio,
secondo regole pre-determinate, inserendo nel messaggio informazioni aggiuntive non
presenti in origine;
• protocol switching: l’Integrator può gestire il cambio di protocollo ricevendo, ad esempio,
messaggi in un protocollo e inviando il messaggio in un altro protocollo;
• service chaining: l’Integrator consente la concatenazione di più servizi elementari per la
realizzazione di una sequenza che realizza un servizio composito (orchestrazione).
5.2.8. DATA ANALYTICS SERVER
WSO2 Data Analytics Server (DAS) ascolta un flusso costante di eventi che rappresentano le
transazioni e le attività di un'azienda provenienti da fonti diverse, li elabora in tempo reale e comunica
i risultati in una varietà di interfacce. Ciò consente alle organizzazioni di rispondere rapidamente ai
loro ambienti, ottenendo così un vantaggio rispetto ai loro concorrenti. Inoltre, WSO2 DAS combina
analisi in tempo reale con analisi batch (dotata di elaborazione incrementale), interattiva e predittiva
(tramite apprendimento automatico) dei dati in un'unica piattaforma integrata per supportare le
molteplici richieste di soluzioni Internet of Things (IoT), nonché come app mobili e Web.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 50 di 64
5.3. PROCESSI APPLICATIVI
I diversi processi applicativi che si prevede di realizzare nell’ambito della piattaforma saranno
distribuiti su container per favorire la gestione in termini di scalabilità e manutenzione.
5.3.1. CONTAINERS
I container sono un meccanismo di virtualizzazione leggero che non richiede la configurazione di una
macchina virtuale su un'emulazione di hardware fisico. In un certo qual modo, tale tecnologia è
assimilabile ad una Virtual Machine ma, a differenza di quest’ultima che è costituita da un suo sistema
operativo, consente alle applicazioni di condividere lo stesso Kernel. Il tutto, consente, un
significativo aumento di performance e riduce la dimensione delle applicazioni. I containers oltre a
fornire gli stessi vantaggi di una Virtual Machine, per quanto riguarda l’isolamento, la sicurezza,
richiedono molte meno risorse hardware, e l’avvio e la terminazione risulta molto più rapida.
I container consentono inoltre di pacchettizzare e rendere atomica un’applicazione con tutte le sue
librerie, dipendenze, etc. In questo modo, è garantita l’esecuzione dell’applicazione su qualsiasi
piattaforma linux, astraendosi di fatto dalle differenti configurazioni dei server. Il principale
vantaggio derivante dall’utilizzo di questa tecnologia consiste nel poter aggiornare il sistema
operativa senza influenzare l’applicazione in quanto non modifica che librerie che usa l’applicazione.
Le applicazioni che girano in containers sono come una sorta di partizione isolata all’interno di un
sistema operativo.
Containers e kernel Linux Ciascun container all’interno dello stesso sistema operativo Linux ha in comune il Kernel: cgroups,
namespaces (ipc, network, user, pid, mount). I containers sfruttano le funzionalità del Kernel per
creare degli ambienti più sicuri e non privilegiati integrando funzionalità di sicurezza quali ad
esempio SELinux e AppArmor. Di seguito un approfondimento:
• Namespaces: il kernel può raggruppare le risorse che sono normalmente visibili a tutti i
processi all’interno di un namespace. Solo i membri contenuti all’interno dello stesso
namespace possono accedere alle stesse risorse. Per “risorse” si fa riferimento ad interfacce
di rete, mount point, network, users, PID, IPC.
• Control groups (cgroups): consentono di partizionare in gruppi i processi e limitare le risorse
che essi consumano, cioè applicano delle restrizioni sulla quantità di risorse di sistema
consumante da ciascun gruppo di processi o di container. Impedisce ad uno specifico
contenitore di utilizzare troppe risorse.
• Linux Security Modules (LSM): è un framework che consente al kernel Linux di supportare
una varietà di modelli di sicurezza alcuni esempi sono SELinux e AppArmor:
• SELinux è una componente essenziale, in grado di controllare gli accessi ed utilizzato per
proteggere sia i container che il sistema operativo host, dai processi in esecuzione. SELinux
viene installato per impostazione predefinita sulle distribuzioni di Red Hat.
• AppArmor è in grado di offrire una protezione ad un livello di granularità al pari con SELinux.
AppArmor viene installato per impostazione predefinita sulle distribuzioni di Ubuntu.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 51 di 64
• Esistono vari container provider Canonical è lo sponsor principale e Oracle sta investendo
molto su LXC e LXD, mentre Docker, VMware, Amazon, Redhat ed IBM stanno investendo
su Docker.
5.3.2. DOCKER
Docker è il nome utilizzato per definire il progetto di una community open source, gli strumenti del
progetto open source, Docker Inc., la società principale finanziatrice del progetto, e gli strumenti che
la società supporta formalmente. Il software “Docker” è una tecnologia di containerizzazione che
consente la creazione e l'utilizzo dei container Linux. Docker Inc. sviluppa i progetti della community
Docker rendendoli più sicuri e condivide le migliorie apportate con la community più ampia. Inoltre,
offre soluzioni migliorate di livello enterprise.
• Sicurezza - Le modifiche effettuate sul sistema operativo host o le operazioni eseguite sui
container sono completamente separate.
• Condivisione - Non si ha la necessità di preoccuparsi delle dipendenze o di creare i ambienti
individuali, tutto ciò di cui si ha la necessità è il Docker Engine installato;
• Isolamento – Utilizza le funzionalità interne del sistema operativo per creare un ambiente
isolato le cui risorse sono gestite in namespace e cgroups;
• Controllo di versione - garantisce la consistenza tra più cicli di development e release,
standardizzando gli ambienti, in questo modo le incompatibilità sono attenuate perché si
utilizzano le stesse immagini del container;
• Facile deploy/ripristino – poiché non è necessario installare l’intero sistema operativo il
deploy delle applicazioni è molto più rapido, inoltre con Docker si può eseguire il rollback a
una versione precedente in pochi istanti
Le immagini Docker utilizzate per eseguire i container possono essere create dall’amministratore o
dallo sviluppatore o scaricate da un Registry, che può essere pubblico o privato. Nella configurazione
di default Docker, utilizza il Docker Hub della community, accessibile all’url https://docker.io. Da
un punto di vista di sicurezza questa pratica può mettere a rischio sistemi di produzione in quanto le
immagini caricate sul Public Registry non sono sottoposte a controlli accurati sul loro effettivo
contenuto. È sempre una buona pratica utilizzare un Registry Privato per le immagini applicative
customizzate dagli sviluppatori.
Il cuore di Docker è il Docker Engine, l’architettura docker è di tipo client-server, la componente
client cioè una command-line presente nell’installazione pacchettizzata, è in grado di gestire tramite
chiamate RESTful-API la componente server.
La componente server è in esecuzione come linux-daemon, si occupa della creazione e della gestione
di uno o più container docker, scarica le immagini docker e comunica con il client e il sistema
operativo host.
Un'immagine è una rappresentazione statica dell'app o del servizio e la sua configurazione e
dipendenze Le immagini sono usate per creare i container. Il registry è un servizio che memorizza le
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 52 di 64
immagini dei container ed è ospitato da una terza parte o da un registro pubblico / privato come
Docker Hub. I container creati dal server docker girano in ambiente user-space e sono isolati tra di
loro.
5.3.3. KUBERNETES
Kubernetes è una piattaforma open source che automatizza le operazioni dei container Linux.
Consente di eliminare molti dei processi manuali coinvolti nel deployment e nella scalabilità di
applicazioni containerizzate.
Le applicazioni di produzione si espandono su più container, che devono essere distribuiti su più
server host. Kubernetes offre le capacità di orchestrazione e gestione necessarie per distribuire i
container, in modo scalabile, al fine di gestire i carichi di lavoro. L'orchestrazione di Kubernetes
consente di creare servizi applicativi che si estendono su più container, programmare tali container in
un cluster, gestirne la scalabilità e l'integrità nel tempo.
Kubernetes si integra con reti, storage, sicurezza, telemetria ed altri servizi, per fornire
un'infrastruttura container completa.
Figura 13 Schema logico Kubernetes
In un ambiente di produzione o quando sono presenti più applicazioni, sono necessari più container
che cooperano per fornire i singoli servizi. In questo modo, il numero di container si moltiplica,
comportando un aumento della complessità. Kubernetes risolve molti dei noti problemi relativi alla
proliferazione dei container, raggruppandoli in “pod.”. I pod aggiungono un livello di astrazione ai
cluster di container, aiutandoti a programmare i carichi di lavoro e a fornire i servizi necessari, tra cui
rete e storage, ai container stessi. Kubernetes agevola, inoltre, il bilanciamento del carico all'interno
dei pod e garantisce l'utilizzo di un numero di container adeguato a supportare carichi di lavoro.
Grazie all'implementazione corretta di Kubernetes e al contributo di altri progetti open source
come Atomic Registry, Open vSwitch, heapster, OAuth e SELinux si possono orchestrare tutti i
componenti dell’infrastruttura a container.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 53 di 64
Di seguito alcuni dei termini più comuni:
• Manager: la macchina che controlla i nodi worker di Kubernetes, e dalla quale sono assegnate
le policy, le grant. Dalla Manager sono creati i cluster ed attivato il processo di installazione
dei nodi worker;
• Node: queste macchine eseguono le attività assegnate richieste ed eseguono I pod. Sono
controllate dalla Manager;
• Pod: un gruppo di uno o più container distribuiti su un singolo nodo. Tutti i container presenti
in un pod condividono indirizzo IP, IPC, nome host ed altre risorse. I pod astraggono la rete
e lo storage dal container sottostante, consentendoti di spostare i container nei cluster con
maggiore facilità.
In genere si desidera replicare i container per i seguenti motivi:
• Affidabilità: avendo più versioni di un'applicazione, si evitano problemi in caso di crash
isolato;
• Bilanciamento del carico: la presenza di più versioni di un contenitore consente di inviare
facilmente il traffico a istanze diverse per impedire l'overloading di una singola istanza o
nodo;
• Ridimensionamento: quando il carico diventa eccessivo per il numero di istanze esistenti,
Kubernetes consente di adattare facilmente l'applicazione, aggiungendo istanze aggiuntive
secondo necessità.
La replica è applicabile a numerosi casi d'uso, tra cui:
• Applicazioni basate su microservizi;
• Applicazioni native cloud;
• Applicazioni mobile.
Il Controller usa l'utilità di pianificazione di Kubernetes per eseguire un determinato numero di
repliche su ciascun nodo. Questa modalità di deployment è sufficiente su applicazioni “stateless”
(senza stato) ma non per applicazioni che richiedono uno store su cui salvare i dati in modo
permanente. Oppure altri tipi di deployment in cui su ciascun nodo è prevista l’esecuzione di una
replica dell’applicazione. Esistono diverse opzioni di deployment che possono essere sfruttate a
seconda delle necessità: Daemonset, Replication Controller, Replica Set, Deployments, CronJob.
Il monitoraggio dello stato dell’infrastruttura, e, a maggior ragione, dello stato dei nodi, viene
garantito mediante un Daemonset che, colleziona gli stati dei nodi e li segnala all’API Server sotto
forma di eventi. Allo stato attuale, Kubernetes, segnalala semplicemente gli eventi e non garantisce
una soluzione autoconsistente alla risoluzione degli eventi.
È possibile configurare i pod in modo tale che, possano essere in run su particolari nodi del cluster,
applicando delle regole di affinity o di antia-affinity.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 54 di 64
Quando Kubernetes assegna un pod ad un nodo, il kubelet su quel nodo chiede a docker di lanciare i
container specificati. Quindi, il kubelet legge in maniera continua lo stato di quei container da docker
e aggrega le informazioni nel nodo master. Docker invia i container sul nodo, avvia e arresta
normalmente i container. La differenza è che un sistema automatizzato chiede a docker di eseguire
queste operazioni, anziché assegnarle ad un amministratore, il quale dovrebbe eseguirle manualmente
su tutti i nodi, in tutti i container.
Un compito comune che effettua Kubernetes è quello di ridimensionare una distribuzione in risposta
a un carico aggiuntivo. Kubernetes ha la scalabilità automatica, e manuale. Si possono
incrementare/diminuire mediante command line, Kubernetes non ridimensiona al di sotto del
Deployment iniziale.
Un altro modo per utilizzare i Deployment è quello di usare il TAG selector. Se un Deployment,
esegue tutti i pod con un valore di livello “sviluppo” (TAG:SVIL) , cambiando l’etichetta
TAG:<TIER> a “produzione” (TAG: PROD), viene avviato un nuovo deployment di produzione.
Questo meccanismo, consente di sostituire selettivamente i singoli pod, è possibile quindi spostare i
pod da un ambiente di sviluppo in un ambiente di produzione, o eseguire un aggiornamento manuale
a rotazione, aggiornare l'immagine e quindi rimuovere una parte dei pod dal Deployment; quando
sostituiti, partono con la nuova immagine. Se le modifiche vengono confermate, si possono elevare
tutti i pod alla nuova versione.
I pod di Kubernetes seguono un ciclo di vita: quando un worker node muore, anche i pod in
esecuzione sul nodo vengono persi. Un ReplicationController potrebbe quindi dinamicamente
riportare il cluster allo stato desiderato tramite la creazione di nuovi pod per mantenere attiva
l'applicazione. Come altro esempio, si consideri un backend di elaborazione delle immagini con 3
repliche. Il sistema front-end non dovrebbe preoccuparsi delle repliche di backend o anche se un Pod
viene perso e ricreato. Ciascun pod in un cluster Kubernetes ha un indirizzo IP univoco, persino un
pod sullo stesso nodo, quindi è necessario un modo per indirizzare automaticamente le modifiche tra
i pod in modo che le applicazioni continuino a funzionare.
Il “Service” in Kubernetes serve proprio a questo scopo che definisce un set logico di pod e un criterio
con cui accedervi. I “Service” consentono un’aggregazione tra i pod dipendenti. Un “Service” è
definito usando uno YAML (predefinito) o JSON, come tutti gli oggetti di Kubernetes. Il set di pod
dipendente da un Service è in genere determinato da un LabelSelector.
Sebbene ciascun pod abbia un indirizzo IP univoco, questi IP non sono esposti all'esterno del cluster
senza un servizio. I “Service” consentono alle applicazioni di ricevere traffico in ingresso e possono
essere esposti in diversi modi specificando un tipo nel tag ServiceSpec:
• ClusterIP (predefinito): espone il servizio su un IP interno nel cluster. Questo tipo rende il
servizio raggiungibile solo all'interno del cluster;
• NodePort - Espone il servizio sulla stessa porta di ciascun nodo selezionato nel cluster
utilizzando NAT. Rende accessibile un servizio dall'esterno del cluster utilizzando <NodoIP>:
<NodePort>. Superset di ClusterIP;
• LoadBalancer: crea un servizio di bilanciamento del carico esterno nel cloud corrente (se
supportato) e assegna un IP fisso, esterno al servizio. Superset di NodePort;
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 55 di 64
• ExternalName(Ingress): espone il servizio utilizzando un nome arbitrario (specificato da
externalName nella specifica) restituendo un record CNAME con il nome.
I “Service” nell’ambiente kubernetes sono molto importanti in quanto permettono l’astrazione di un
servizio, ed i nodi associati al service possono essere replicati, killati ed anche la comunicazione tra
front-end e back-end resta immutato.
Per raggruppare ed inidirizzare i pod dello stesso gruppo un “Service” utilizza una label / selector. Le
label, sono coppie chiave / valore associate agli oggetti e possono essere utilizzate in diversi modi:
• Assegnare oggetti per sviluppo, test e produzione
• Incorpora i tag di versione
• Classificare un oggetto usando i tag
Le label possono essere applicate agli oggetti al momento della creazione o successivamente. Possono
essere modificate in qualsiasi momento.
L’Ingress service è utilizzato per esporre i servizi all’esterno di kubernetes, consente inoltre di
bilanciare il carico, gestire un endpoint SSL, offrire servizi di VirtualHosting e altro ancora. La
chiamata all’Ingress avviene per messo di un API Server. Un controller Ingress gestisce le chiamate,
solitamente, mediante loadbalancer, un edge router o frontend aggiuntivi al fine di implementare
l’HA.
Affinché la risorsa Ingress funzioni, il cluster deve avere un ingress controller in esecuzione. Un
ingress controller è generalmente uno strato di automazione integrato con un servizio proxy di back-
end e può operare sia a livello 4 che a livello 7.
5.3.4. RANCHER
Rancher è una container management platform open-source per il deployment, la gestione ed
esecuzione dei container in produzione. Rancher coordina tutti i servizi di infrastruttura necessari:
networking, storage, host, bilanciamento del carico e molto altro.
Tutti questi servizi funzionano su un numero elevato di infrastrutture e semplificano
l'implementazione e la gestione delle applicazioni.
Lo sviluppo di Rancher si articola in due distinti prodotti:
• Una piattaforma per la distribuzione e l'esecuzione di container, proposta nel presente
documento.
• Un Sistema operativo Linux ottimizzato per l'esecuzione di container Docker RancherOS
La componente di Management Rancher Server e la componente worker che gira sui Nodes Rancher
Agent girano all’interno del servizio Docker. Una volta installato il Rancher Server si può scegliere
la modalità di installazione su Cloud, nei quali sono supportati i più diffusi provider Cloud pubblici
quali Azure AWS, AZURE che cloud Privato quali VMware, Openstack, ecc.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 56 di 64
È possibile anche installare manualmente l’Agent Rancher su di un qualsiasi nodo “host” compute
con il Servizio Docker installato. Il Rancher Server fornirà una comando Docker da eseguire sugli
“host”, che scarica, configura ed esegue in automatico il docker Racher Agent e provvedendo anche
alla registrazione dell’host all’interno del Rancher Server.
Rancher offre anche un Catalog di applicazioni supportate contenente applicazioni e database che
costituiranno la base per le applicazioni più complesse e mantenute in alta affidabilità ad esempio
Postgres, Mysql, ecc.
Rancher fa offre anche la possibilità per gli amministratori di creare un proprio Catalog. È sufficiente
pubblicare aggiungere un progetto Git definito dall'utente.
Rancher offre molte funzioni per l’amministrazione dei Docker, da più utenti e da più ambienti
(Separazione da Prod a Svil). Rancher offre anche un’interfaccia a riga di comando (CLI), la Rancher
CLI funziona in modo efficace come il docker-compose, ed offre alcune funzionalità aggiuntive come
lo scaling.
5.4. DATA LAYER
Nell’ambito del data layer sono presenti i diversi prodotti utilizzati per la storicizzazione e
l’indicizzazione. Più in particolare, viene evidenziata la scelta tecnologica effettuata in merito alla
composizione dei database e degli eventuali livelli di cache.
5.4.1. POSTGRESQL
PostgreSQL è un database relazionale che usa ed estende il linguaggio SQL con molte features che
permettono la lavorazione ed il trattamento di workload complessi.
Mette a disposizione funzionalità volte a gestire qualunque tipo di dato, fornendo la possibilità di
definire data type custom ed utilizzare diversi linguaggi di programmazione. Riserva grande
attenzione all’integrità del dato ed è fault-tolerant nel caso di errori nel sistema.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 57 di 64
5.4.2. STACK ELK
Basato sulla libreria open source Apache Lucene, Elasticsearch è un server di ricerca con supporto
ad architetture distribuite che fornisce funzionalità di ricerca full-text con un’interfaccia agnostica
rispetto ai linguaggi di programmazione, ossia utilizzando JSON per la rappresentazione dei dati e
HTTP con protocollo di comunicazione. Elasticsearch può essere usato per cercare qualsiasi tipo di
documento e fornisce un sistema di ricerca scalabile, quasi di tipo real-time, con supporto al
multitenancy.
Kibana è lo strumento della suite che permette di navigare e visualizzare i dati contenuti in un indice
Elasticsearch. Sfruttando le capacità e la velocità di ricerca ed aggregazione dei dati offerti da
Elasticsearch, Kibana permette di creare in maniera, semplice e intuitiva, grafici e dashboard per
l’analisi di big-data. Kibana si collega ad un’istanza di Elasticsearch e permette di effettuare query
anche molto complesse, visualizzare nel dettaglio i valori più frequenti all’interno dell’indice,
aggregare dati su diverse dimensioni e creare grafici sui dati, in particolare serie temporali.
I Beats sono dei microcomponenti molto leggeri che permettono di catturare i log e dati strutturati e
non da diverse fonti ed inviarle a LogStash o direttamente ad Elasticsearch. I beats sono ottimi per
la raccolta di dati. Risiedono nei server, nei containers o sono distribuiti come funzioni e centralizzano
i dati in Elasticsearch. Beats possono anche spedire a Logstash per la trasformazione e l'analisi. Beats
raccolgono i log e le metriche dagli ambienti in cui sono installati e li integrano con metadati che
riguardano gli host, le piattaforme container come Docker e Kubernetes oppure provider cloud prima
di inviarli allo stack elastic.
Logstash permette di recuperare i dati da varie sorgenti eterogenee, trasformarli e indicizzarli
all’interno di un’istanza di Elasticsearch in maniera automatica. Grazie alla sua architettura a plugin,
Logstash supporta diverse modalità di input con le quali sarà possibile configurare in pochi passi un
sistema automatico di trasferimento di dati. Tramite un plugin specifico, ad esempio, si potrà
monitorare una directory nella quale un’applicazione scrive i propri log, processare ed eventualmente
Figura 14 Stack ELK
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 58 di 64
trasformare ogni nuova riga di log ed infine memorizzare il risultato all’interno di un indice
Elasticsearch.
5.4.3. ZIPKIN
Zipkin è un sistema di tracciamento distribuito. Aiuta a raccogliere i dati temporali necessari per la
risoluzione dei problemi di latenza nelle architetture distribuite ed in particolare quelle che prevedono
l'uso di microservizi. Gestisce sia la raccolta che la ricerca di questi dati.
5.5. PORTALE
5.5.1. REACT JS
Lo sviluppo delle componenti applicative di livello controller dei moduli UI sarà basato sul
framework ReactJS. La forza di React rispetto ad altre librerie è quella di consentire l’uso di un
approccio dichiarativo simile all’HTML, quindi molto familiare, per definire i componenti che
rappresentano parti significative e logiche dell’interfaccia utente, ad esempio un commento a un
articolo, o la lista degli stessi commenti. Benché dichiarativa, la rappresentazione del componente in
realtà si traduce in chiamate all’API di React che intervengono – nel modo più veloce e performante
possibile – sul DOM della pagina per creare gli elementi necessari.
5.5.2. EXPRESS JS
Lo sviluppo dei micro-servizi dei moduli UX dei portali sarà basato su framework ExpressJS (e
container NodeJS). Express è un framework per applicazioni web Node.js flessibile e leggero che
fornisce una serie di funzioni avanzate per le applicazioni web e per dispositivi mobili.
5.6. APP MOBILE
5.6.1. REACT NATIVE
React Native consente di creare APP mobile utilizzando solo JavaScript. Usa lo stesso design di
React, permettendo di comporre un'interfaccia utente mobile ricca da componenti dichiarativi.
Con React Native, non si crea una "APP WEB mobile", una "APP HTML5" o una "APP ibrida con
WEB View". Si crea piuttosto una vera APP per dispositivi mobili che è indistinguibile da un'APP
realizzata con Objective-C o Java. React Native utilizza gli stessi blocchi fondamentali
dell'interfaccia utente delle normali APP iOS e Android, che vengono, però, composti utilizzando
JavaScript e React.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 59 di 64
6. ARCHITETTURA FISICA E DEPLOYMENT
L’architettura fisica del prodotto include la descrizione dell’infrastruttura più adatta per garantire la
migliore operatività, affidabilità e sicurezza alla piattaforma. Nel paragrafo 6.6 è stato incluso uno
schema globale delle VM e dei prodotti o processi applicativi di cui le stesse ospiteranno il deploy.
Nell’ambito dello schema viene data evidenza della suddivisione logica della piattaforma nelle sue
principali sezioni funzionali e tecnologiche. Viene anche indicato quali delle macchine prevedono il
deployment delle componenti su container.
6.1. SPECIFICHE GENERALI
Tutti i componenti dei vari moduli della piattaforma e tutti i prodotti “vitali” inclusi nell’offerta
saranno messi in opera rispettando uno schema di alta affidabilità mentre eventuali meccanismi di
disaster recovery saranno messi in campo a livello infrastrutturale e quindi a monte rispetto al lavoro
di messa in opera ed alle funzionalità della piattaforma.
Il sistema operativo di riferimento per le VM sarà CentOS versione 7.6. I dati gestiti dai prodotti che
costituiscono in data layer richiedono l’utilizzo di dischi con specifici e certificati livelli di affidabilità
e performance. Ogni VM sarà dotata di firewall per filtrare il traffico da e verso la VM stessa in
funzione delle esigenze di protezione dei dati e dei processi ospitati.
L’infrastruttura che il cliente metterà a diposizione per la piattaforma sarà parte integrante di un
contesto ed un progetto più ampio che la Regione Campania porta avanti per meglio gestire le
esigenze infrastrutturali delle piattaforme e dei prodotti di livello appunto regionale. Tale progetto
prevede, quindi, la realizzazione di una piattaforma cloud ready e multi-tenant detta i.TER che sia in
grado di ospitare efficacemente i prodotti ed i servizi (in logica PaaS) abilitanti per le capacità
tecnologiche che i prodotti regionali necessitano.
6.2. SIZING
Il dimensionamento dell’infrastruttura in ambiente di produzione è stato pensato prendendo in
considerazione le seguenti assunzioni:
- La Regione Campania ha una popolazione di circa 4.800.000 abitanti.
- Circa il 10% della popolazione attiva il proprio fascicolo sanitario.
- I documenti che appartengono ad un fascicolo sanitario non ancora attivo non
verranno indicizzati nella piattaforma ma verranno comunque trattati per l’invio
verso l’attuale implementazione di FSE in sussidiarietà.
- Per ogni assistito vengono prodotti circa 7 documenti che possono essere inclusi
nel fascicolo sanitario.
- Ogni documento ha un peso di circa 30 KB.
In merito all’ambiente di collaudo è stata proposta una infrastruttura con le medesime caratteristiche
dell’ambiente di produzione ad eccezione del dimensionamento delle risorse allocate per le singole
macchine. Questa scelta consentirà di allestire un ambiente di collaudo pienamente compatibile
riducendo le possibilità di incorrere in anomalie.
Nel paragrafo 6.7 del presente documento viene incluso il dimensionamento di tutte le macchine
definite nello schema di architettura fisica e utilizzate dalla piattaforma con differenziazione per gli
ambienti di produzione e di collaudo.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 60 di 64
Si segnala tuttavia che è in corso una attività di service design che porterà alla definizione di ulteriori
servizi e componenti che saranno realizzati nell’ambito del progetto. Pertanto, al completamento del
service design, sarà emessa una ulteriore revisione del Progetto Esecutivo e del sizing infrastrutturale
per contemplare l’aggiunta di tali funzionalità / componenti.
6.3. NETWORKING
Il traffico di rete sia all’interno della piattaforma che da e verso sistemi esterni avviene sempre
utilizzando crypting SSL. Per tutte le connessioni da e verso sistemi esterni e anche per alcune
trasmissioni interne è necessaria una specifica tipologia di autenticazione (vedi il paragrafo 3.1 -
Autenticazione e autorizzazione).
L’utilizzo di protocolli sicuri basati su SSL richiede una corretta gestione dei necessari certificati.
Una opportuna segmentazione del traffico di rete consente di ottenere vantaggi molto importanti:
- Semplifica la gestione delle misure di protezione ed il monitoraggio del traffico.
- Rappresenta una migliore protezione della piattaforma da attacchi informatici
(inclusi quelli detti di “movimento laterale”) costituendo di fatto un certo numero
di barriere interne oltre alla sola protezione della rete di frontiera verso i sistemi
esterni.
- Aumenta le prestazioni generali razionalizzando al meglio il consumo delle risorse
di rete.
Gli accessi ai servizi da rete pubblica, siano essi a servizio di utilizzatori quali portale o app mobile
oppure una implementazione di un profilo di iteroperabilità, saranno sempre gestiti tramite WSO2
Identity Server per l’autenticazione ed il cluster HAProxy per il load balancing.
6.4. API MANAGER
Tra i vari prodotti inclusi nell’ambito della piattaforma il WSO2 API Manager richiede di esplicitare
alcune ulteriori specifiche in termini di deployment.
L’API Manager (nella versione 2.1.0) include cinque elementi principali: un Publisher (che consente
di pubblicare facilmente le API, condividere la documentazione, fornire le API key e raccogliere
feedback sulle funzionalità, la qualità e l'utilizzo delle API), uno Store (che permette la registrazione
degli utenti per scoprire funzionalità delle API disponibili, di iscriversi alle API e di valutarle), un
Gateway (responsabile della sicurezza, protezione, gestione e scaling delle call API), una
componente di Key Management (responsabile di tutte le operazioni di sicurezza e di quelle correlate
ai token di accesso) ed un Traffic Manager (utilizzato per prendere decisioni sul throttling). In un
ambiente ideale di produzione questi componenti devono essere installati in maniera distribuita;
prima di effettuare il set up del cluster dell’API Manager è necessario, quindi, creare un ambiente di
deploy distribuito di Publisher, Store, Gateway, Key Management e Traffic Manager.
Inoltre, l’API Manager utilizza cinque database distribuiti tra i nodi:
• User Manager Database – sul quale sono memorizzate i dati relativi agli utenti e ai ruoli utente
(informazioni condivise tra Key Manager, Store e Publisher); gli utenti possono accedere al
Publisher per la creazione delle API e allo Store per il consumo delle API.
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 61 di 64
• API Manager Database – utilizzato per memorizzare le informazioni relative alle API con i
dettagli dell’abbonamento API. Il Key Manager utilizza questo database per memorizzare i
token di accesso utente utilizzati per la verifica delle chiamate API.
• Registry Database – Condivide le informazioni tra il Publisher e lo Store. Quando un'API
viene pubblicata tramite il Publisher, viene resa disponibile all’interno dello Store tramite
questo database. Sebbene normalmente si condividano le informazioni solo tra i componenti
Publisher e Store, nel caso in cui si preveda di creare questa configurazione per un ambiente
multi-tenant, è necessario condividere le informazioni in questo database anche con il
Gateway il Key Manager.
• Statistics Database – Contiene le informazioni relative alle statistiche delle API; dopo aver
configurato APIM analytics, è possibile scrivere i dati riepilogati all’interno di questo
database. Publisher e Store possono quindi interrogare questo DB per visualizzare i dati
statistici.
• Message Broker Database – Il Traffic Manager utilizza questo database come archivio
messaggi per il broker quando viene utilizzato il throttling avanzato.
L’immagine che segue riporta il pattern di deployment scelto tra quelli raccomandati da WSO2:
Figura 15 WSO2 API Manager deployment pattern n°2
Come illustrato in figura, sono presenti le componenti distribuite nel seguente modo:
• 2 POD ospitanti i Gateway;
• 2 POD ospitanti il Developer Portal, il Publisher ed il Traffic Manager;
• 2 POD ospitanti l’Identity Server as Key Manager
• 1 POD ospitante l’Analitycs (Stream Processor)
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 62 di 64
• 1 volume disco condiviso fra i POD necessari a WSO2 per condividere alcuni artefatti
• 5 schemi database PostgreSQL che WSO2 usa per salvare configurazioni e utenti.
6.5. MONITORAGGIO E GESTIONE
Data la natura distribuita ed eterogenea dei processi e dei servizi messi in opera nell’ambito della
piattaforma non verrà sviluppato un sistema di gestione unificato delle configurazioni e dei parametri
operativi necessari per il corretto funzionamento del sistema.
Piuttosto, sono state utilizzate tecniche che possano facilitare la conduzione operativa della
piattaforma raggruppando razionalmente attività di gestione ed evitando ridondanze. In particolare:
• La gestione di tutti i container operativi nella piattaforma avviene tramite il pannello di
amministrazione offerto dal software di orchestrazione (Rancher).
• Le informazioni di audit, gli eventi e i log di sistema prodotti dai vari processi applicativi e
middleware per la gestione dei dati, della sicurezza e altro, confluiscono in un apposito cluster
Elasticsearch e su un server Zipkin (per la consultazione facilitata del tracciamento delle
transazioni).
6.6. ARCHITETTURA FISICA
Il seguente schema rappresenta l’architettura fisica della piattaforma:
Figura 16 Architettura fisica
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 63 di 64
6.7. PREDISPOSIZIONI AMBIENTI DI INSTALLAZIONE
Di seguito sono illustrate i dimensionamenti degli ambienti di Produzione e Collaudo da predisporre
a cura del cliente.
Si fa presente che:
- tutte le Virtual Machine (VM) devono essere predisposte con l'OS CentOS 7x64, ultima
build disponibile
- tutte le VM devono tutte potersi collegare verso Internet per scaricare aggiornamenti
dell’OS e poter uscire in HTTP/HTTPS verso Internet per scaricare ulteriori pacchetti
applicativi
- deve essere possibile collegarsi direttamente alla shell di ciascuna VM in SSH
- deve esserci visibilità di rete con i sistemi Iter di Regione Campania (CRED per l’ambiente
di test e cloud per l’ambiente di produzione)
- per alcune VM sussistono dei requisiti specifici sul tipo di spazio di disco locale/esterno (in
termini prestazionali)
6.7.1. AMBIENTE DI PRODUZIONE
FSE - Portal & Service – Ambiente di Produzione
Scenario #VM vRAM (GB) vCPU Internal Storage
(GB)
External Storage
(TB) Note
Ext Load Balancer 1 4 2 50 VIP active / active (Firewall / Load Balancing)
Ext Load Balancer (Fail Over) 1 4 2 50
Int Load Balancer 1 4 2 50 VIP active / active (Firewall / Load Balancing)
Int Load Balancer (Failover) 1 4 2 50
Container workers 8 16 4 150
DB Notificatore 2 16 8 200
CDN 2 64 8 500
Elasticsearch 3 32 8 200 3
Cache anagrafiche 2 24 6 300
Orchestratore container 3 16 4 200
Totale 24 496 120 4600 9
Table 2 – Sizing Ambiente di Produzione
6.7.2. AMBIENTE DI COLLAUDO
FSE - Portal & Service – Ambiente di Collaudo
Scenario #VM vRAM (GB)
vCPU Internal Storage
(GB)
External Storage
(TB) Note
Ext Load Balancer 1 4 2 50 VIP active / active (Firewall / Load Balancing)
Ext Load Balancer (Fail Over) 1 4 2 50
Int Load Balancer 1 4 2 50 VIP active / active (Firewall / Load Balancing)
R.T.I. Almaviva S.p.A., Almawave S.r.l.,
Indra Italia S.p.A., Pwc Advisory S.p.A. Sistema Pubblico di Connettività - LOTTO 3 & Lotto 4
Progetto Esecutivo SPCL3&4-FSECampania-SoReSa-ProgettoEsecutivo
Versione 2.0 del 18/12/2019 Non classificato – Confidenziale RTI Almaviva S.p.A. Pagina 64 di 64
Int Load Balancer (Failover) 1 4 2 50
Container workers 6 16 4 150
DB Notificatore 2 16 4 200
CDN 2 8 2 200
Elasticsearch 3 16 4 100 0.5
Cache anagrafiche 1 24 6 100
Orchestratore container 3 16 4 200
Totale 21 280 74 2900 1.5
Table 3 – Sizing Ambiente di Collaudo – Frontend