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





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





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





INDICE DELLE TABELLE

Table 1 - Acronimi ............................................................................................................................. 13 Table 2 – Sizing Ambiente di Produzione ......................................................................................... 63

Table 3 – Sizing Ambiente di Collaudo – Frontend .......................................................................... 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





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





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





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





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





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





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





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





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.





• 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





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





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:





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);





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





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.





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.





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





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





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.





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.





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.





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:





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





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





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.





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





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





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.





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.





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.





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





• 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





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:





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,





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.





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





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





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.





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.





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:





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





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





• 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





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.





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.





• 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

https://www.docker.com/





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.

https://www.redhat.com/it/topics/containers/whats-a-linux-container

https://www.redhat.com/it/topics/data-storage

http://www.projectatomic.io/

http://openvswitch.org/

https://github.com/kubernetes/heapster

https://oauth.net/

https://selinuxproject.org/page/Main_Page





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.





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;





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





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





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





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.





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.





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.





• 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)





• 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





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)





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

Indra Italia S.p.A., Pwc Advisory S.p.A.

Documents

Transcript of Indra Italia S.p.A., Pwc Advisory S.p.A.