Risultati
205 risultati
-
italia
1.2. Il contesto europeo
Lo European Interoperability Framework (EIF) (in italiano Quadro Europeo di Interoperabilità - QEI [4]) fornisce orientamenti alle PA Europee su come operare le iniziative relative al tema dell’interoperabilità; tutto questo mediante una serie di raccomandazioni atte a stabilire relazioni tra le varie organizzazioni, razionalizzare i processi volti a sostenere i servizi digitali e assicurare che le norme esistenti e quelle nuove non pregiudichino gli sforzi di interoperabilità. L’obiettivo dell’EIF è:. fornire alle PA orientamenti in merito alla progettazione e all’aggiornamento di quadri nazionali di interoperabilità o di politiche nazionali, strategie e orientamenti che promuovano l’interoperabilità;. contribuire all’istituzione del Digital Single Market incoraggiando l’interoperabilità transfrontaliera e intersettoriale per l’erogazione di servizi pubblici europei. . Figura 1 - Ambito di applicazione dell’EIF. L’ambito di applicazione dell’EIF comprende tre tipi di interazioni:. A2B (amministrazione-impresa), ossia le interazioni tra le PA e le imprese;. A2C (amministrazione-cittadino), ossia le comunicazioni tra le PA e i cittadini. Il modello di interoperabilità delineato nell’EIF è applicabile a tutti i servizi pubblici digitali, lo stesso include:. giuridico, per garantire che le organizzazioni che operano nell’ambito di diversi quadri giuridici (nazionali e settoriali), possano lavorare insieme;. organizzativo, per favorire l’allineamento delle procedure e processi delle organizzazioni coinvolte delineando le responsabilità e le aspettative per raggiungere obiettivi comuni concordati e reciprocamente vantaggiosi;. semantico, per assicurare che il formato e il significato delle informazioni e dei dati scambiati siano mantenuti e compresi durante tutti gli scambi che avvengono tra le parti;. tecnico, in cui, attraverso l’adozione di specifiche di interfaccia, di servizi di interconnessione, di servizi di integrazione dei dati, la presentazione e lo scambio dei dati e i protocolli di comunicazione sicuri, si assicuri l’interoperabilità delle applicazioni e delle infrastrutture che collegano sistemi e servizi. una componente trasversale ai quattro livelli, denominata governance dei servizi pubblici integrati, per assicurare il necessario coordinamento e governance delle organizzazioni coinvolte nella erogazione di servizi pubblici in modo integrato;. un livello di base, denominato governance di interoperabilità, per assicurare che le decisioni prese in merito ai quadri di interoperabilità, disposizioni istituzionali, strutture organizzative, ruoli e responsabilità, politiche, accordi e altri aspetti garantiscano e verifichino l’interoperabilità a livello nazionale e di UE. . Figura 2 - Livelli di interoperabilità. Nel suo insieme il modello di interoperabilità delineato nell’EIF è stato disegnato sulla base dei 12 principi di interoperabilità, condivisi dagli Stati membri della Comunità Europea, individuati quali aspetti fondamentali per guidare le azioni tese a garantire l’interoperabilità:. Apertura. Il principio di apertura fa riferimento principalmente ai dati, alle specifiche e al software. Nell’ottica di questo principio occorre: pubblicare i dati che si possiedono come dati aperti, fatta salva l’eventuale applicazione di determinate restrizioni; garantire condizioni di parità per il software open source e prenderne in considerazione l’utilizzo in modo attivo ed equo, tenendo conto del costo totale di proprietà della soluzione; prediligere le specifiche aperte, tenendo debitamente conto delle esigenze funzionali, del livello di maturità e del sostegno e dell’innovazione del mercato. Trasparenza. In ottemperanza a questo principio occorre: conferire visibilità nel contesto amministrativo di una PA; assicurare la disponibilità di interfacce con i sistemi informatici interni e garantire il diritto alla tutela dei dati personali; garantire visibilità interna e fornire interfacce esterne per i servizi pubblici. Riusabilità. Secondo tale principio si deve trarre vantaggio dal lavoro degli altri cercando le informazioni disponibili, valutandone l’utilità o la pertinenza rispetto al problema in questione e, se del caso, decidendo di usare soluzioni che si sono rivelate efficaci in altre situazioni. Neutralità tecnologica e portabilità dei dati. Allorché istituiscono servizi pubblici, le PA devono concentrarsi sulle esigenze funzionali e posporre le decisioni in materia di tecnologia il più a lungo possibile per ridurre al minimo la dipendenza tecnologica, evitare di imporre tecnologie o prodotti specifici ai loro partner ed essere in grado di adattarsi all’ambiente tecnologico in rapida evoluzione. Centralità dell’utente. Nel determinare quali servizi pubblici erogare e come farlo, si deve prendere in considerazione le esigenze degli utenti. Occorre perciò mettere a punto meccanismi per coinvolgere gli utenti nell’analisi, nella progettazione, nella valutazione e nell’ulteriore sviluppo dei servizi pubblici. Inclusione e accessibilità. Inclusione significa permettere a chiunque di approfittare delle opportunità offerte dalle nuove tecnologie per l’accesso e l’utilizzo dei servizi pubblici europei superando gli svantaggi e l’esclusione sociale ed economica. L’accessibilità garantisce che le persone anziane, i disabili e gli altri gruppi svantaggiati possano utilizzare i servizi pubblici alla stregua di tutti gli altri cittadini. Sicurezza e privacy. Le interazioni con le autorità pubbliche devono svolgersi in un ambiente sicuro ed affidabile ed in totale conformità con le norme in materia di protezione dei dati, di identificazione elettronica e dei servizi fiduciari. Multilinguismo. Occorre soddisfare le aspettative di cittadini e imprese che desiderano essere serviti nella loro lingua, o in un’altra lingua di preferenza, e la capacità delle PA di offrire servizi in tutte le lingue ufficiali. Semplificazione Amministrativa. Le PA, laddove possibile, devono razionalizzare e semplificare le loro procedure amministrative migliorandole o eliminando quelle che non hanno utilità pubblica. Conservazione delle informazioni. La legislazione impone che le decisioni e i dati siano conservati e che vi si possa accedere per un determinato periodo di tempo. Occorre pertanto formulare una politica di conservazione a lungo termine per le informazioni relative ai servizi pubblici. Valutazione dell’efficacia e dell’efficienza. Esistono numerosi modi per misurare il valore offerto dall’interoperabilità dei servizi pubblici, quali le considerazioni circa il ritorno sull’investimento, il costo totale di proprietà, il livello di flessibilità e adattabilità, la riduzione degli oneri amministrativi, l’efficienza, la riduzione dei rischi, la trasparenza, la semplificazione, il miglioramento dei metodi di lavoro e il grado di soddisfazione degli utenti. Valutare l’efficacia e l’efficienza di diverse soluzioni di interoperabilità e opzioni tecnologiche, in considerazione delle esigenze dell’utente, della proporzionalità e dell’equilibrio tra costi e benefici. L’EIF delinea uno schema concettuale per i servizi pubblici integrati al fine di orientarne la progettazione, lo sviluppo, la gestione e la manutenzione da parte degli Stati membri. Lo schema concettuale promuove l’idea di interoperability-by-design (interoperabilità fin dalla fase di progettazione). Lo schema promuove la riusabilità come motore per l’interoperabilità, riconoscendo che i servizi pubblici dovrebbero riutilizzare le informazioni e i servizi esistenti e provenienti da varie fonti, sia all’interno che all’esterno dei confini organizzativi delle PA. Le informazioni e i servizi dovrebbero essere recuperabili e resi disponibili in formati interoperabili. . Figura 3 - Schema concettuale per i servizi pubblici integrati. La Commissione Europea ha individuato uno schema concettuale per i servizi pubblici che comprende:. una politica di fornitura del servizio basata sul concetto secondo cui tutte le porte sono buone per offrire opzioni e canali alternativi per l’erogazione dei servizi, garantendo nel contempo la disponibilità di canali digitali (digital first);. il riutilizzo di dati e servizi per ridurre i costi e accrescere la qualità dei servizi e l’interoperabilità;. cataloghi che descrivono i servizi riutilizzabili e le altre risorse per aumentare la loro rintracciabilità e il loro utilizzo;. la governance dei servizi pubblici integrati;. la sicurezza e la tutela della privacy. La funzione di coordinamento garantisce l’individuazione delle esigenze e il ricorso ai servizi coordinati per fornire complessivamente un servizio pubblico. Le fonti di informazioni (base register, portali sui dati aperti e altre fonti autorevoli di informazioni) e i servizi, disponibili non solo all’interno del sistema amministrativo ma anche in un contesto esterno, possono essere utilizzati per creare servizi pubblici integrati. Per favorire questi processi occorre sviluppare un’infrastruttura condivisa di servizi e fonti di informazioni riutilizzabili che possa essere adottata da tutte le amministrazioni pubbliche favorendo il riutilizzo, la pubblicazione e l’aggregazione dei servizi e delle fonti di informazioni. La direttiva relativa al riutilizzo dell’informazione del settore pubblico prevede un quadro giuridico comune per il riutilizzo dei dati (open data); in essa l’accento è posto sulla messa a disposizione di dati machine-readable ad uso di terzi per promuovere la trasparenza, la concorrenza leale, l’innovazione e un’economia basata sui dati. I cataloghi hanno la finalità di consentire la ricerca di servizi, dati, software e modelli di dati. Le PA devono poter fruire dei servizi erogati da terzi al di fuori dei confini delle loro organizzazioni, quali i servizi di pagamento forniti dalle istituzioni finanziarie oppure i servizi di connettività erogati da fornitori di servizi di telecomunicazioni. Esse hanno bisogno anche di utilizzare le fonti esterne di informazioni, quali i dati aperti e i dati delle organizzazioni internazionali, delle camere di commercio, ecc. Nell’EIF è raccomandato:. sviluppare interfacce con i base register, pubblicare i mezzi tecnici e i documenti necessari affinché terze parti possano connettersi e riutilizzare le informazioni disponibili;. abbinare ad ogni base register i metadati appropriati, compresi la descrizione del contenuto, la garanzia del servizio e le responsabilità, le tipologie di master data contenuti, le condizioni di accesso e le licenze, la terminologia, il glossario e le informazioni sugli eventuali master data utilizzati di altri base register;. creare e monitorare piani di garanzia della qualità dei dati per i base register e i relativi master data;. elaborare cataloghi di servizi pubblici, dati pubblici e soluzioni di interoperabilità e utilizzare modelli comuni per descriverli;. adottare e riusare fonti di informazioni e servizi esterni, laddove utile e fattibile, nello sviluppo dei servizi pubblici. La sicurezza e privacy sono aspetti che devono essere definiti in pieno accordo con l”e-Government action plan 2016-2020 della Commissione EU [5]. Per le PA è raccomandato:. utilizzare i servizi fiduciari, in base al regolamento in materia di identificazione elettronica e servizi fiduciari, come meccanismi per garantire lo scambio sicuro e protetto dei dati nei servizi pubblici (Regolamento (UE) 2014/910 [6]). Per perseguire gli obiettivi dell’EIF, la Commissione Europea ha individuato i seguenti obblighi per gli stati membri. L’accesso ai servizi e alle informazioni deve essere realizzato mediante specifiche interfacce e condizioni di accesso preventivamente definite (accordi di interoperabilità). Vanno favorite le politiche di riuso dei dati e dei servizi. Concordare uno schema comune per interconnettere i componenti dei servizi, nonché predisporre e mantenere l’infrastruttura necessaria per istituire e mantenere i servizi pubblici europei. Le PA devono documentare i propri processi lavorativi utilizzando tecniche di modellizzazione comunemente accettate per erogare un servizio pubblico. Percepire i dati e le informazioni come un bene pubblico che deve essere adeguatamente prodotto, raccolto, gestito, condiviso, protetto e preservato, elaborando una strategia di gestione delle informazioni al livello più alto possibile per evitare la frammentazione e la duplicazione. Promuovere l’istituzione di comunità di settore e intersettoriali che mirino a creare specifiche aperte sulle informazioni condividendo i propri risultati sulle piattaforme nazionali ed europee. Utilizzare specifiche aperte, per garantire l’interoperabilità tecnica quando si istituiscono servizi pubblici. . In precedenti documenti a cura di AgID e del Team Digitale, il termine inglese framework è stato sovente tradotto in italiano come modello, ed è questo il termine utilizzato nel presente documento. La dicitura quadro è la traduzione letterale della Commissione Europea. Nel seguito di questo documento verrà preferito il termine modello, pur considerando i termini framework, modello e quadro come sinonimi. Cf. https://ec.europa.eu/digital-single-market/en/news/communication-eu-egovernment-action-plan-2016-2020-accelerating-digital-transformation. Cf. http://eur-lex.europa.eu/legal-content/IT/TXT/HTML/?uri=CELEX%3A32014R0910&from=EN ...
-
italia
1. Presentazione del Modello di Interoperabilità
La visione generale del Modello di Interoperabilità, considerando il contesto Europeo, introduce gli elementi che saranno considerati e le modalità con cui si provvederà al costante aggiornamento dello stesso ...
-
italia
3.3. Concetti di base
Interazione bloccante vs non bloccante. Nell’interazione bloccante un fruitore effettua una chiamata al servente ed attende una risposta prima di continuare l’esecuzione. La chiamata codifica in modo opportuno la richiesta di servizio, anche attraverso il passaggio di dati (sia in input alla chiamata che in output nella risposta). Nell’interazione non bloccante, invece, il fruitore invia un messaggio ma non si blocca in attesa di alcuna risposta (se non una notifica di presa in carico). Il messaggio contiene in modo opportuno la richiesta ed eventuali dati di input. Talvolta il messaggio, proprio ad indicare il fatto che codifica la richiesta e le informazioni necessarie a soddisfarla, viene indicato come documento. La risposta da parte del servente, nei casi in cui ci sia, può apparire significativamente più tardi, ove significativamente va interpretato rispetto al tempo di computazione proprio dell’interazione [2]. Anche la risposta del servente viene inviata tramite un messaggio. Con abuso di nomenclatura, la comunicazione bloccante talvolta viene detta sincrona, ad indicare che client e servente si sono sincronizzati (attesa di uno da parte dell’altro); quella non bloccante viene detta asincrona, proprio a significare l’asincronicità che vi è tra l’invio di un messaggio e la risposta al messaggio stesso. Alonso, G., Casati, F., Kuno, H., Machiraju, V. (2004). Web Services. Concepts, Architectures and Applications. Springer. . Remote Procedure Call. Una Remote Procedure Call (chiamata a procedura remota, RPC) consiste nell’attivazione, da parte di un programma, di una procedura o subroutine attivata su un elaboratore diverso da quello sul quale il programma viene eseguito. Quindi l’RPC consente a un programma di eseguire subroutine «a distanza» su elaboratori remoti, accessibili attraverso una rete. Essenziale al concetto di RPC è l’idea di trasparenza: la chiamata di procedura remota deve essere infatti eseguita in modo il più possibile analogo a quello della chiamata di procedura locale; i dettagli della comunicazione su rete devono essere «nascosti» (resi trasparenti) all’utilizzatore del meccanismo. Se il linguaggio è orientato agli oggetti, l’invocazione della procedura remote è in realtà l’invocazione di un metodo su un oggetto remoto, e si parla di Remote Method Invocation - RMI. RPC/RMI è il meccanismo base con cui realizzare una interazione bloccante. . Façade. È uno schema di organizzazione dei moduli in cui uno, detto appunto façade, maschera l’accesso ad un insieme di moduli sottostanti, ad esempio limitando l’accesso a determinate funzionalità tramite un meccanismo di gestione degli accessi, oppure nascondendo le complessità nell’organizzazione e gestione dei moduli sottostanti. . Idempotenza. Il concetto di idempotenza in matematica è una proprietà delle funzioni per la quale applicando molteplici volte una funzione data, il risultato ottenuto è uguale a quello derivante dall’applicazione della funzione un’unica volta (es. gli operatori di intersezione o unione). Applicato alle interfacce di servizio, questo concetto indica il fatto che una operazione, se eseguita più volte non comporta un risultato diverso sul sistema erogatore. Il caso classico è quello in cui si ha una operazione di creazione. Nel caso di errore di rete, l’operazione potrebbe essere eseguita senza che il fruitore riceva un messaggio di risposta. In questo caso il fruitore può ritentare la stessa operazione, ma il risultato in questo caso non deve essere la creazione di una seconda risorsa. L’erogatore dell’interfaccia di servizio deve invece riconoscere la duplicazione della richiesta ed evitare comportamenti indesiderati. Questo comportamento è solitamente ottenuto tramite l’utilizzo di correlation ID oppure tramite il confronto dati basato su dati che fungono da chiave. . Orchestrazione e coreografia. Per orchestrazione si intende un flusso di esecuzione che coinvolge diverse chiamate a servizi secondo regole prestabilite (ad es., un workflow) al fine di ottenere un servizio composto. La coreografia dei servizi è una forma di specifica della composizione dei servizi in cui il protocollo di interazione tra i diversi servizi componenti è definito da una prospettiva globale. Cioè, in fase di esecuzione della coreografia, ogni partecipante esegue la sua parte (cioè il suo ruolo) in base al comportamento degli altri partecipanti. Il ruolo specifica il comportamento, in termini di scambi di messaggi attesi dai partecipanti, che riproducono il ruolo appunto in termini di sequenziamento e tempistica dei messaggi che possono consumare e produrre. La specifica dei messaggi implica anche la descrizione dei dati scambiati tra due o più partecipanti. La differenza tra i due approcci è meglio compresa attraverso il loro confronto. Da una parte, nelle coreografie, la logica delle interazioni basate sui messaggi tra i partecipanti è specificata da una prospettiva globale. Nell’orchestrazione dei servizi, d’altra parte, la logica viene specificata dal punto di vista locale di un singolo partecipante, chiamato l’orchestratore. Nel linguaggio di orchestrazione BPEL, ad esempio, la specifica dell’orchestrazione del servizio (ad esempio il file del processo BPEL) può essere distribuita sull’infrastruttura (ad esempio un motore di esecuzione BPEL come Apache ODE), e questo costituisce l’implementazione del servizio composto. In un certo senso, le coreografie e le orchestrazioni sono due facce della stessa medaglia. Da un lato, i ruoli di una coreografia possono essere estratti come orchestrazioni attraverso un processo chiamato proiezione; attraverso la proiezione, è possibile realizzare scheletri, ovvero orchestrazioni di servizi incomplete che possono essere utilizzate come linee di base per realizzare i servizi web che partecipano alla coreografia di servizio. D’altra parte, le orchestrazioni già esistenti possono essere composte in coreografie. Chris Peltz (2003): Web Services Orchestration and Choreography. IEEE Computer 36(10):46-52. . Classificazione delle interazioni in A2A, A2C e A2B. A2A : Administration-to-Administration. A2C : Administration-to-Citizen. A2B : Administration-to-Business. In contesti di digital government, è possibile classificare le interazioni tra componenti applicativi in base al soggetto organizzativo sotto la cui responsabilità e nel cui dominio viene eseguito il componente. Si parla di Administration-to-Administration quando sia il componente servente (ad esempio l’interfaccia di servizio) che quello cliente (ad esempio, applicazione Web, applicazione mobile, un altro servizio composto che utilizza il primo come componente all’interno della propria orchestrazione, ecc.) sono nel dominio delle amministrazioni (che probabilmente saranno differenti, ma non necessariamente). Si parla di Administration-to-Citizen quando servente e cliente sono uno nel dominio dell’amministrazione e l’altro su dispositivi del privato cittadino, mentre Administration-to-Business quando servente e cliente sono uno nel dominio dell’amministrazione e l’altro di un’organizzazione privata (azienda, concessionario privato di servizi pubblici, ecc.). La distinzione è utile non tanto dal punto di vista funzionale, ma degli aspetti non funzionali, ad esempio legati al trust, alla reciprocità ed ai livelli di sicurezza che devono essere instaurati nei vari casi. . Impedance mismatch. Derivato dall”impedance mismatch dell’elettrotecnica, si riferisce alle difficoltà concettuali e tecniche che si incontrano spesso quando due paradigmi differenti, spesso implicati da altrettante tecnologie, devono coesistere e mapparsi uno sull’altro durante la progettazione e realizzazione di un sistema. Il più famoso caso di impedance mismatch è quello dell’object-to-relational, noto metaforicamente anche come il Vietnam dell’informatica [4], che si verifica quando un sistema di gestione di database relazionali (RDBMS) è servito da un programma applicativo (o da più programmi applicativi) scritto in un linguaggio di programmazione orientato agli oggetti, in particolare perché gli oggetti o le definizioni di classe devono essere associati a tabelle di database definite da uno schema relazionale. Nel ModI ci sono casi di impedance mismatch quando un’interfaccia di servizio progettata secondo lo stile RPC-like deve essere realizzata in REST. Ad es., se fruitore ed erogatore computano nell’ordine dei secondi, la risposta potrebbe arrivare dopo minuti od ore, quindi significativamente più tardi. Ad es., se fruitore ed erogatore computano nell’ordine dei secondi, la risposta potrebbe arrivare dopo minuti od ore, quindi significativamente più tardi. Cf. http://blogs.tedneward.com/post/the-vietnam-of-computer-science/. Cf. http://blogs.tedneward.com/post/the-vietnam-of-computer-science/. ...
-
italia
2.5. Message Broker
Un message broker è un modulo software che permette l’integrazione asincrona tramite scambio di messaggi. Questo tipo di interazione è fortemente disaccoppiata perché l’invio del messaggio avviene su un canale in cui è responsabilità del message broker consegnare il messaggio ai soggetti interessati. Il compito del message broker non è però solo quello di passare dati, in quanto esso si occupa anche di aspetti legati alla sicurezza, priorità dei messaggi, inoltro ordinato. I middleware focalizzati sul fornire integrazione basata su messaggi vengono detti Message Oriented Middleware - MOM. Un message broker supporta solitamente diverse modalità di interazione:. Queuing. In questo caso un fruitore invia una richiesta su una coda specifica (corrispondente all’erogatore) e l’erogatore invia la risposta sulla medesima coda; di fatto è una realizzazione asincrona della modalità request/reply;. Store/Forward. In questo caso il broker memorizza i messaggi e quindi inoltra agli interessati. Un caso particolare di message broker è costituito dagli integration broker. Rispetto ad un message broker, questi si occupano anche della trasformazione di messaggi dai formati sorgente a quelli manipolabili dai riceventi/sottoscrittori. L’utilizzo di message broker è consigliato in alcuni casi d’uso in cui l’interazione è asincrona o di tipo publish/subscribe (ad es., Internet-of-Things - IoT, aggregatori di dati pubblici). Varie tecnologie e realizzazioni di message broker hanno storicamente supportato svariati protocolli quali STOMP [80], XMPP [81], MQTT [82], OpenWire [83] e AMPQ [84]. Oggigiorno, sebbene in determinati contesti essi vengano attualmente ancora utilizzati (ad es., in contesti intra-dominio o in casi particolari quali l’IoT in cui si preferiscono protocolli binari efficienti come MQTT), si preferiscono, in ambito di integrazione di sistemi, approcci in cui l’interfacciamento con i message broker avviene tramite interfacce di servizio REST. In particolare sono disponibili sia soluzioni native che wrapper per implementazioni di altri protocolli. I vantaggi di questo approccio includono la possibilità di utilizzare le modalità di autenticazione, autorizzazione, throttling ed accounting già discussi riguardo alla tecnologia REST, e la risoluzione di possibili problematiche legate all’attraversamento di firewall e proxy. Sebbene, a seconda delle implementazioni, le diverse interfacce di servizio REST per l’accesso a message broker differiscano per funzionalità offerte e modi di modellare code, topic/sottoscrizioni, si possono astrarre i seguenti comportamenti dei metodi HTTP:. il metodo GET viene utilizzato per consumare messaggi da code e topic/sottoscrizioni;. il metodo DELETE viene utilizzato per l’eliminazione di topic/sottoscrizioni e code ed in alcuni casi per segnalare il fatto che un messaggio è stato consumato. Il metodo PUT viene di solito utilizzato per modificare le proprietà di topic/sottoscrizioni e code. . Cf. https://stomp.github.io/. Cf. https://xmpp.org/. Cf. http://mqtt.org/. Cf. http://activemq.apache.org/openwire.html. Cf. https://www.amqp.org/ ...
-
italia
4. Sicurezza
Il presente documento descrive i profili di sicurezza individuati da AgID che i soggetti erogatori DEVONO utilizzare per soddisfare le necessità espresse attraverso requisiti funzionali e non funzionali. Data la variabilità nel tempo delle esigenze delle amministrazioni e delle tecnologie abilitanti, nonché considerata la natura incremenmtale del ModI, l’elenco dei profili di sicurezza non è da intendersi esaustivo. Nel caso in cui un’amministrazione abbia esigenze non ricoperte nei seguenti profili DEVE informare AGID e PUO” utilizzare soluzioni differenti da quelle prospettate, ma queste DEVONO garantire il medesimo o superiore livello di sicurezza. I profili individuati, coprono gli aspetti di comunicazione “sicura” tra i domini delle singole parti. Le parti mantengono la loro autonomia negli aspetti organizzativi e di sicurezza interni al proprio dominio. I profili di sicurezza. forniscono un comune linguaggio per fruitori ed erogatori utile a trattare le necessità e le caratteristiche delle interfacce di servizio. offrono agli sviluppatori le modalità tecniche supportate da standard tecnologici documentati, revisionati e testati per esporre i servizi digitali. I profili affrontano il tema della sicurezza su due livelli differenti:. Messaggio: definisce le modalità di comunicazione dei messaggi tra componenti interne dei domini delle entità coinvolte. Ogni profilo è strutturato come segue:. Descrizione: rappresentazione in linguaggio naturale del profilo con relativi precondizioni e obiettivi. Dettaglio:. Regole di processamento: elenco dei passi da eseguire per implementare il profilo. Tracciato: ove presente, fornisce un esempio dei messaggi prodotti nell’interazione. I soggetti interessati, a seguito dell’analisi dei requisiti realizzata internamente, per individuare le proprie esigenze funzionali e non funzionali, DOVREBBERO:. individuare tra i profili di sicurezza quelli che soddisfano le proprie esigenze;. implementare le interfacce di servizio attraverso la combinazione dei profili di interazione e di profili di sicurezza. L’individuazione dei profili DEVE ricoprire solamente i requisiti necessari, inoltre la scelta dei profili da implementare risulta necessaria ove l’ente erogatore del servizio non disponga già di tecnologie che garantiscano i requisiti richiesti. Trust. Il Trust è uno dei mezzi più importanti per gestire le problematiche di sicurezza nello scambio di informazione in rete per consentire l’interoperabilità tra i sistemi. Esso si basa sul reciproco riconoscimento delle entità interagenti e sulla fiducia nei rispettivi comportamenti. Nel presente documento, per direct trust, si intende la relazione di fiducia tra fruitore ed erogatore, stabilita in modalità diretta, attraverso accordi che si basano sulla condivisione del reciproco modus operandi. Tipologia di profili di sicurezza. I profili di sicurezza del presente documento sono suddivisi in due tipologie:. Autenticazione Intradominio [IDA]. Il processo di identificazione avviene all’interno del dominio di una delle due parti (fruitore ed erogatore) del direct trust. Autenticazione Extradominio [EDA]. Il processo di identificazione avviene mediante una terza parte esterna alle due parti (fruitore ed erogatore) interessate. Modalità di combinazione dei profili. I profili sono rappresentati con una sequenza di 6 caratteri:. IDA -> Autenticazione Intradominio. EDA -> Autenticazione Extradominio. il quarto carattere definisce l’ambito in cui viene gestita la problematica di sicurezza:. C: Ambito di canale ovvero livello trasporto. S: Ambito applicativo basato su tecnologia SOAP. R: Ambito applicativo basato su tecnologia REST. Gli ultimi 2 caratteri identificano univocamente il profilo. Partendo dai requisiti di sicurezza emersi durante la fase di analisi è possibile individuare il profilo di sicurezza o una combinazione di più profili di sicurezza che ricoprano le esigenze. Di seguito viene mostrata una rappresentazione dei profili attualmente presenti nel documento in cui vengono evidenziate le relazioni. mermaid.initialize({startOnLoad:true});. graph TD B(IDAC02)-->|extend|A[IDAC01] BS(IDAS02)-->|extend|AS[IDAS01] CS(IDAS03)-->|extend|AS CS-->|extend| BS BR(IDAR02)-->|extend|AR[IDAR01] CR(IDAR03)-->|extend| AR[IDAR01] CR-->|extend| BR. Fig. 4.1 Rappresentazione grafica delle dipendenze tra i profili. NOTA BENE. Le parole chiave «DEVE», «DEVONO», «NON DEVE», «NON DEVONO», «E’ RICHIESTO», «DOVREBBE», «NON DOVREBBE», «RACCOMANDATO», «NON RACCOMANDATO» «PUO’» e «OPZIONALE» nel testo del documento debbono essere interpretate come descritto nel seguito, in conformità alle corrispondenti traduzioni contenute nel documento IETF RFC 2119 ...
-
italia
1.1. Introduzione
Il Modello di Interoperabilità [1] (nel seguito in breve ModI) rappresenta il modello di supporto alla strategia di interoperabilità e cooperazione tra le Pubbliche Amministrazioni (di seguito PA), che definendo i contesti di interazione e integrazione tra le PA, i cittadini e le imprese permette di vedere la PA nella sua interezza come un unico sistema informativo (virtuale). La definizione del ModI deve essere coerente con il nuovo European Interoperability Framework (EIF) oggetto della Comunicazione COM (2017)134 [2] della Commissione Europea del 23 marzo 2017, al fine di assicurare anche l’interoperabilità nel contesto Europeo e per l’attuazione del Digital Single Market (Mercato Unico Digitale). Gli obiettivi del nuovo Modello di Interoperabilità sono:. armonizzare le scelte architetturali delle PA;. individuare le scelte tecnologiche che favoriscano lo sviluppo, da parte delle PA, cittadini e imprese, di soluzioni applicative innovative che abilitino l’utilizzo dei servizi individuati nelle Infrastrutture immateriali del Piano triennale per l’informatica nella PA [3];. promuovere, quando applicabile, l’adozione dell’approccio API first, al fine di favorire la separazione dei livelli di back end e front end, con logiche aperte e standard pubblici che garantiscano ad altri attori, pubblici e privati, accessibilità e massima interoperabilità di dati e servizi;. privilegiare standard tecnologici che soddisfino l’esigenza di rendere sicure le interazioni tra le PA e tra queste con i cittadini e le imprese;. semplificare le procedure di scambio di servizi tra le PA e, ove possibile, tra PA e privati, facilitando la realizzazione dei sistemi che le realizzano. . Il ModI è concettualmente la seconda versione (aggiornamento) del framework di interoperabilità della PA che nella prima versione fu definito nel 2005 con il nome di SPCoop - Servizio Pubblico di Cooperazione Applicativa, cf. http://www.agid.gov.it/agenda-digitale/infrastrutture-architetture/sistema-pubblico-connettivita/cooperazione-applicativa Il termine modello trova corrispettivo nel termine inglese framework, e pertanto nel presente documento i due termini verranno considerati sinonimi. Cf. https://ec.europa.eu/transparency/regdoc/rep/1/2017/IT/COM-2017-134-F1-IT-MAIN-PART-1.PDF. Cf. https://pianotriennale-ict.italia.it/assets/pdf/Piano_Triennale_per_l_informatica_nella_Pubblica_Amministrazione.pdf ...
-
italia
3.1. Paradigmi per la progettazione delle interfacce di servizio
Un aspetto che si vuole qui richiamare è la relazione tra l’interno e l’esterno del sistema informativo di una pubblica amministrazione, e come questo confine abbia impatti sulle interfacce di servizio in termini di funzionalità e sicurezza. Nel precedente modello di interoperabilità (il cosiddetto SPCoop del 2005) era stato definito il concetto di dominio di un’amministrazione, o dominio di cooperazione tra più amministrazioni, ad indicare l’insieme delle risorse - tra cui procedure, dati e servizi - e delle politiche di una determinata amministrazione o gruppo di amministrazioni, e rappresentava il confine di responsabilità, in particolar modo per quanto riguardava le politiche relative al sistema informativo della stessa (o gruppo di amministrazioni). Uno specifico elemento architetturale, la Porta di Dominio, istanziava fisicamente tale confine. Nel nuovo framework di interoperabilità, l’istanziazione della Porta di Dominio come punto unico di interfaccia viene meno, tuttavia concettualmente il confine del dominio dell’amministrazione continua ad esistere ed è importante considerarlo nella progettazione delle interfacce di servizio, soprattutto relativamente agli aspetti di sicurezza. Le interfacce di servizio vengono offerte da qualsiasi server applicativo, senza essere vincolate ad essere raggiungibili attraverso un unico gateway. Le figure 3.4 e 3.5 illustrano schematicamente la differenza tra i due framework. Quindi ogni server applicativo offre interfacce di servizio, tuttavia è comunque significativo distinguere se l’interfaccia di servizio viene offerta per interoperare:. all’interno del dominio (da parte di clienti applicativi offerti dalla stessa amministrazione, ad es., un’applicazione Web od una mobile). verso altre amministrazioni o altri soggetti con cui è stabilità una relazione di fiducia. esternamente, da parte di moduli applicativi completamente esterni alle pubbliche amministrazioni, e per i quali non esiste a priori nessuna relazione, né organizzativa né di fiducia. Fig. 3.4 Perimetro delle interfacce in SPCoop. Fig. 3.5 Perimetro delle interfacce in ModI. [1]. (1, 2) SOAP - Simple Object Access Protocol è il protocollo originariamente proposto, e standardizzato dal W3C, per lo sviluppo e dispiegamento di Web service. Al di sopra di esso, sono stati nel tempo proposti vari standard per Web service, ad es., WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security, and WS-Trust solo per nominarne alcuni, che oramai vengono comunemente indicati con l’acronimo WS-*. [2]. Originariamente Swagger (della società SmartBear Software) era un insieme di tool sia per la descrizione delle interfacce che per il loro sviluppo. Nel 2015 un gruppo di aziende, sotto la sponsorizzazione della Linux Foundation, ha dato vita all’iniziativa OpenAPI, a cui SmartBear ha donato il formato di specifica che è stato rinominato da Swagger Specification in OpenAPI Specification. Gli strumenti Swagger, che sono ancora supportati da SmartBear Software, sono tra gli strumenti più popolari per implementare la specifica OpenAPI e continueranno a mantenere il nome Swagger. Esistono molti altri strumenti open source e proprietari, non correlati a Swagger, che supportano la specifica OpenAPI. [3]. Cf. https://www.crummy.com/writing/speaking/2008-QCon/act3.html ...
-
italia
1.4. Scenario pregresso dell’interoperabilità nella PA
Nell’ottobre 2005 il CNIPA (oggi Agenzia per l’Italia digitale - AgID) ha pubblicato un insieme di documenti che costituiscono il riferimento tecnico per l’interoperabilità fra le PA. Tali documenti delineano il quadro tecnico-implementativo del Sistema pubblico di cooperazione (SPCoop), framework di interoperabilità a livello applicativo [8]. SPCoop ha costituito il modello concettuale ed architetturale della cooperazione applicativa tra differenti Amministrazioni e/o soggetti pubblici italiani. Tale sistema era organizzato in modo da:. essere paritetico fra tutti i soggetti cooperanti;. essere indipendente dagli assetti organizzativi dei soggetti cooperanti;. lasciare a ciascun soggetto cooperante la responsabilità dei servizi erogati e dei dati forniti;. garantire a ciascun soggetto autonomia nella gestione dei propri sistemi e nella definizione ed attuazione delle politiche di sicurezza del proprio sistema informativo;. lasciare a ciascun soggetto la responsabilità delle autorizzazioni per l’accesso ai propri dati e/o servizi. In sintesi, alla base di SPCoop vi erano i seguenti principi:. ambito di responsabilità delle singole Amministrazioni dei servizi erogati che costituiscono il Dominio di servizi applicativi della stessa Amministrazione;. accordi di servizio quale rappresentazione formale della cooperazione tra erogatore/i e fruitore/i costituiti sulla base di un fondamento normativo;. tecnologie di cooperazione: i servizi erano erogati come web service basati sugli standard che in quel momento erano consolidati ed in uso (SOAP, WSDL, UDDI). Con l’obiettivo di assicurare agli utenti di avere una visione integrata dei servizi di ogni PA, le tematiche coperte da SPCoop sono state tutte quelle che interessano l’interoperabilità dei sistemi a diversi livelli, ovvero:. catalogazione dei servizi;. semantica dei dati e dei servizi;. identità digitale. Lo scenario normativo di SPCoop è quello inquadrato dal DPCM 1 aprile 2008, recante regole tecniche e di sicurezza del Sistema pubblico di connettività (SPC), di cui SPCoop era un componente fondamentale, poi compiutamente delineato sul piano tecnico-implementativo da una suite di linee guida di seguito richiamate:. Specifiche della busta di e-gov. Specifiche della porta di dominio. Linee guida busta di e-gov. Qualificazione della porta di dominio. Qualificazione porta di dominio con concorso delle regioni. Catalogazione dei servizi. Specifiche dell’accordo di servizio. Specifiche del Registro SICA. Raccomandazioni stesura accordi di servizio. Semantica dei dati e dei servizi. Nomenclatura e semantica. Identità digitale. GFID - Gestione federata delle identità digitali. In particolare SPCoop prevedeva:. I servizi infrastrutturali per la gestione di tutti gli aspetti legati agli accordi di servizio, nel loro insieme denominati Servizi SICA, prevedevano:. Servizi di Registro: la componente, realizzata a partire dallo standard UDDI, entro cui erano registrati gli Accordi di Servizio organizzati in modo distribuito prevedendo due livelli, ovvero Generale, che contiene la totalità degli accordi di servizio, e Secondario, contenente delle viste definite secondo differenti criteri;. Catalogo degli Schemi/Ontologie, che offre gli strumenti per ragionare sulla semantica dei servizi e delle informazioni da essi veicolati;. Servizi di Sicurezza assicuravano le funzionalità per la qualificazione degli elementi del sistema e garantire gli opportuni requisiti di autenticità, riservatezza, integrità, non ripudio e tracciabilità dei messaggi scambiati. Il tempo trascorso dalla definizione del modello e il mutato quadro tecnico, organizzativo e normativo rendono necessario l’aggiornamento del modello, obiettivo appunto della presente iniziativa, come anticipato nel 2017 attraverso la Determinazione 219/2017 - Linee guida per transitare al nuovo modello di interoperabilità [9]. L’esperienza maturata con SPCoop, di seguito sintetizzata, deve essere considerata nella definizione del ModI. Cosa ha funzionato. Il coordinamento, anche delegato ad organi intermedi quali elementi di aggregazione di un insieme omogeneo di Amministrazioni, permette di favorire l’applicazione del modello condiviso. Il sistema di gestione federata delle identità digitali, nonostante si ponesse come un elemento fortemente innovativo, è stato utilizzato a livello regionale e ha consentito di disegnare su tali basi tecniche il futuro SPID. Cosa deve essere cambiato. È necessario un modello di governance che permetta di gestire le specificità dei singoli domini applicativi determinati dalle caratteristiche delle amministrazioni e dei soggetti terzi coinvolti. Cosa deve essere abbandonato. La necessità di componenti infrastrutturali disegnati per la sola Pubblica Amministrazione italiana (come Porta di Dominio e Registro SICA) determina che la spesa per il loro sviluppo ed evoluzione sia totalmente a carico della Pubblica Amministrazione. . Cf. http://www.agid.gov.it/agenda-digitale/infrastrutture-architetture/sistema-pubblico-connettivita/cooperazione-applicativa. Cf. http://www.agid.gov.it/sites/default/files/upload_avvisi/linee_guida_passaggio_nuovo_modello_interoperabilita.pdf ...
-
italia
2.7. Altri approcci e tecnologie di integrazione
Una modalità di integrazione, importante specialmente negli scenari A2B e A2C, è quella basata sull’esposizione da parte delle PA di open data. Gli open data devono essere fruibili, ed essere inseriti ove possibile nel contesto dei Base Register definiti nell”EIF [98], standardizzando gli schemi e le modalità di fruizione. Vista la progressiva crescita dei dataset, gli open data dovrebbero essere erogati in modo da ridurre gli impatti infrastrutturali sull’erogatore. Come indicato nelle linee guida nazionali per la valorizzazione del patrimonio informativo pubblico [99] pubblicate da AgID nel 2014, l’obiettivo è quello di mettere a disposizione i dati aperti in formato Linked Open Data - LOD ai fini dell’integrazione, il che prevede l’esposizione di dati in formato W3C RDF e SPARQL (secondo il cosiddetto modello del Semantic Web). A tal fine gli SPARQL endpoint costituiscono le interfacce di servizio. Le query in formato SPARQL vengono inviate su endpoint HTTP. Un altro approccio possibile, sempre nel rispetto dei dizionari comuni, è quello di utilizzare un approccio ROA basato su interfacce REST [100]. Un’interessante evoluzione dell’approccio REST (di cui eredita molti dei vantaggi, quali ad esempio la leggerezza e l’utilizzo dei verbi HTTP) che può risultare utile nell’esposizione di open data è quello basato su GraphQL [101]. In particolare, mentre per l’estrazione di dati complessi l’approccio basato su interfacce di servizio REST richiede diverse chiamate, GraphQL introduce un linguaggio che permette l’esecuzione di interrogazioni complesse sulle risorse. In tutti i casi presentati, restano valide le indicazioni contenute nelle sezioni precedenti circa la sicurezza nell’esposizione delle interfacce di servizio. [93]. Cf. https://it.wikipedia.org/wiki/Blockchain. [94]. Una rete di calcolatori si definisce peer-to-peer, quando le macchine componenti (i nodi) non sono organizzati gerarchicamente ma svolgono delle funzionalità paritarie. [95]. Cf. https://e-estonia.com/solutions/security-and-safety/ksi-blockchain. [96]. Cf. https://techcrunch.com/2018/04/19/do-you-need-a-blockchain/. [97]. Cf. https://www.multichain.com/blog/2017/05/blockchain-immutability-myth/. [98]. Cf. https://joinup.ec.europa.eu/asset/eia/description. [99]. Cf. http://lg-patrimonio-pubblico.readthedocs.io/it/latest/index.html. [100]. Cf. Massimo Mecella, Francesco Leotta (2017): Migliorare l’accesso agli open data pubblici: tecnologie e approcci, https://www.agendadigitale.eu/cittadinanza-digitale/pa-tecnologie-e-approcci-per-migliorare-laccesso-ai-dati-aperti/. [101]. Cf. https://graphql.org/ ...
-
italia
1.3. Il quadro di riferimento attuale
Il Piano triennale per l’informatica nella PA [7] costituisce il quadro di riferimento entro cui si colloca il ModI all’interno del Modello strategico di evoluzione del sistema informativo della PA. . Figura 4 - Piano triennale per l’informatica nella PA. Il modello strategico, pensato per superare l’approccio a «silos», storicamente adottato dalla PA, mira a favorire la realizzazione di un sistema informativo unitario della PA ed è caratterizzato da:. definiscono regole comuni per la progettazione di interfacce, servizi e contenuti, migliorando e rendendo coerente la navigazione e l’esperienza del cittadino e delle imprese;. facilitano il design, la realizzazione e la diffusione di servizi digitali;. definiscono linee guida e kit di sviluppo;. provvedono alla creazione di community di sviluppatori, di designer e di chiunque voglia scambiare informazioni, collaborare e partecipare. Gli Ecosistemi, sono i settori o le aree omogenee in cui si svolge l’azione da parte delle PA. Ciascun ecosistema coinvolge enti e organismi pubblici, e soggetti privati che operano nella stessa area di interesse e che a vario titolo svolgono funzioni attive all’interno dell’ecosistema stesso. I soggetti interessati interagiscono per il raggiungimento di obiettivi comuni attraverso. la condivisione delle esigenze e delle modalità operative;. la condivisione delle differenti competenze;. la pianificazione e la realizzazione di progetti ICT. Il Modello di Interoperabilità, definisce i meccanismi che facilitano e garantiscono la corretta interazione tra gli attori del sistema (cittadini, imprese e PA), favorendo la condivisione trasparente di dati, informazioni, piattaforme e servizi. Il Modello di Interoperabilità è costituito da linee guida, standard tecnologici e profili di interoperabilità che ciascuna PA dovrà seguire al fine di garantire l’interoperabilità dei propri sistemi con quelli di altri soggetti per l’implementazione complessiva del Sistema informativo della PA. Le Infrastrutture immateriali e il Data & Analytics Framework (DAF) della PA, che incentivano la centralizzazione e la razionalizzazione dei sistemi per la gestione dei processi e dei dati, riducendo la frammentazione degli interventi. In particolare, le Infrastrutture immateriali facilitano, standardizzano e razionalizzano la creazione di servizi ICT e sono composte dalle Piattaforme abilitanti e dai Dati della PA:. nelle piattaforme abilitanti ricadono tutti quei servizi infrastrutturali (eg. servizio di identificazione, servizio di pagamenti, ANPR) che agevolano e riducono i costi per la realizzazione di nuovi servizi uniformando gli strumenti utilizzati dagli utenti finali durante la loro interazione con la PA;. relativamente ai dati della PA si distinguono: le basi di dati di interesse nazionale, gli open data, e i vocabolari controllati. Il Data & Analytics Framework è un ambiente centralizzato che acquisisce e rende più fruibili i dati pubblici di interesse e ha l’obiettivo (i) di rendere più semplice e meno onerosa l’interoperabilità dei dati pubblici tra PA e la distribuzione e standardizzazione dei dati aperti (open data) e (ii) di permettere lo studio dei fenomeni sottostanti ai dati pubblici. Le Infrastrutture fisiche, che perseguono l’obiettivo di aumentare la sicurezza, ridurre il costo delle infrastrutture tecnologiche e migliorare la qualità dei servizi software della PA, attraverso la razionalizzazione dei data center, l’adozione sistematica del paradigma cloud e lo sviluppo della connettività, con particolare riferimento alla rete Internet nei luoghi pubblici e negli uffici della PA. La Sicurezza che comprende:. le attività per la regolazione e regolamentazione della cyber-security nella PA per l”assessment test,. il CERT-PA quale strumento operativo per supportare l’adozione dei corretti livelli di sicurezza presso le PA. La Gestione del cambiamento che è una componente definita per far fronte alle necessità di coordinamento, gestione e monitoraggio delle attività funzionali allo sviluppo del Piano. . Cf. https://pianotriennale-ict.italia.it/ ...
-
italia
3.2. Profili di Interazione
Il profilo di interazione definisce le modalità secondo le quali un fruitore ed un erogatore possono interagire, l’interazione avviene definendo le interfacce di servizio. I profili di interazione quali riferimenti concettuali coniugano, fatto salvo per l’accesso CRUD, message exchange pattern (MEP) per le tecnologie SOAP e REST proposte dal ModI. Di seguito l’attenzione è rivolta agli aspetti funzionali rimandando per gli aspetti di sicurezza all’apposito documento delle linee guida. Per i concetti di bloccante e non bloccante si rimanda alla lettura di «Concetti di base». Ogni interfaccia di servizio deve essere rappresentata mediante un IDL - Interface Description Language standard - che il ModI fissa:. per le interfacce di servizio SOAP, WSDL 1.1 e successive. L’endpoint deve indicare in modo esplicito la tecnologia utilizzata (REST o SOAP) e la versione (versioning su URL). ...
-
italia
3. Profili e Raccomandazioni
La terza sezione del Modello di Interoperabilità, così come introdotto nella sezione relativa alla visione generale, fornisce indicazioni concrete, a livello tecnico, su differenti modalità operative per realizzare l’interoperabilità tra sistemi informativi di differenti pubbliche amministrazioni, tenendo conto delle possibili tecnologie ed approcci disponibili. Data la veloce evoluzione tecnologica, questo documento verrà continuamente aggiornato ed approfondito. Questa versione si focalizza sulle modalità bloccanti e non bloccanti e sulle tecnologie SOAP e REST. La sezione è organizzata nel seguente modo:. 3.2 - Profili di interazione descrive i profili di interoperabilità proposti, adottando uno stile uniforme di presentazione a scheda, in modo da rendere agevole e di immediata fruibilità la consultazione. 3.3 - Concetti di base presenta ulteriori concetti architetturali che vengono richiamati nel documento, insieme alla bibliografia di riferimento, sia per motivi di autocontenimento che di disambiguazione. 3.4 - Riferimenti Bibliografici. NOTA BENE. Le parole chiave «DEVE», «DEVONO», «NON DEVE», «NON DEVONO», «E” RICHIESTO», «DOVREBBE», «NON DOVREBBE», «RACCOMANDATO», «NON RACCOMANDATO» «PUO”» e «OPZIONALE» nel testo del documento debbono essere interpretate come descritto nel seguito, in conformità alle corrispondenti traduzioni contenute nel documento IETF RFC 2119 ...