So.Re.Sa. S.p.A.

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

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

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

FASCICOLO SANITARIO ELETTRONICO - Servizi

dell’infrastruttura nazionale di interoperabilità (INI) ad

uso delle regioni in sussidiarietà

Versione del 14.05.2018

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

Successivamente, personale autorizzato potrà accedere a dashboard offerte da Xxxxxx 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.

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 XXX0 XXX0x, 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 xxxxx://xxxxxx.xx. 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

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.

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 Xxxxxxxxxx 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 xxxxxx Xxxxxx 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

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

Xxxxxx è 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, Xxxxxx permette di creare in maniera, semplice e intuitiva, grafici e dashboard per l’analisi di big-data. Xxxxxx 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

trasformare ogni nuova riga di log ed infine memorizzare il risultato all’interno di un indice Elasticsearch.

5.4.3. XXXXXX

Xxxxxx è 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 Xxxxxx (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	000	00	0000	1.5

Document Metadata

Table of Contents

So.Re.Sa. S.p.A.

Document Metadata