SPC (Sistema Pubblico di connettività) a cura del Dottor Antonio Guzzo – Responsabile CED – Sistemi Informativi del Comune di Praia a Mare

di Guzzo Antonio

Versione PDF del documento

Condividi con:

SPC (Sistema Pubblico di connettività)


Il Sistema Pubblico di Connettività e Cooperazione consente agli utenti di avere una visione integrata di tutti i servizi di ogni amministrazione pubblica sia centrale che locale ed indipendente dal canale di erogazione. A tal proposito è stato definito un modello comune di interazione on-line che valorizza la specificità di ogni erogatore di servizi ed assicuri al contempo uniformità di interazione e certezza nell’identificazione dell’erogatore e del fruitore, o comunque in generale degli attori dell’interazione. L’interoperabilità fra amministrazioni, infatti, non può che svilupparsi sulla base di standard omogenei e condivisi in modo tale che siano identificati i servizi ed i dati che ogni amministrazione deciderà di rendere disponibili sulla rete. Poiché lo scambio di dati e servizi delle amministrazioni avviene tra entità di pari livello, lo scopo dell’architettura di cooperazione applicativa è quello di permettere l’integrazione dei processi e dei dati di amministrazioni diverse. Per consentire ciò sono state stabilite sia le modalità attraverso cui i dati di interesse possano essere individuati che le modalità attraverso cui possano essere acceduti come servizi applicativi. E’ stata definita un’infrastruttura tecnologica di “interfaccia” con cui i diversi sistemi/organizzazioni “presentano” e “scambiano” i propri dati e servizi. La definizione di questa infrastruttura (i cui elementi tecnologici principali sono stati individuati nella Porta di Dominio e nella busta di e-Gov) consente di organizzare un vero e proprio backbone di interscambio e di cooperazione per i dati ed i servizi delle diverse amministrazioni. Questo approccio garantisce il minimo impatto economico ed organizzativo sulle scelte tecnologiche già effettuate dai diversi enti coinvolti. La realizzazione ed il funzionamento delle modalità di cooperazione implicano la realizzazione di un sistema di coordinamento e gestione che garantisca l’interfaccia con i diversi sistemi interoperanti. In questo contesto ambientale le risorse infrastrutturali condivise di cooperazione applicativa sono la risorsa strategica abilitante, il coordinamento ed la collaborazione armonica tra soggetti diversi (amministrazioni) che interagiscono in un ambiente complesso e dinamico. Tali aspetti di coordinamento e collaborazione rappresentano a loro volta una condizione abilitante per la piena realizzazione dell’e-Government nel nostro paese, soprattutto se si guarda al concetto di interoperabilità tra enti e/o reti di enti centrali e regionali.

Il modello di cooperazione applicativa del SPCoop si basa sui seguenti principi:

 

Cooperazione tra amministrazioni

Le amministrazioni cooperano attraverso l’erogazione e la fruizione di servizi applicativi; tali servizi vengono offerti dalla singola amministrazione attraverso un unico elemento (logico) del proprio sistema informativo denominato Porta di Dominio. Questo principio garantisce la completa autonomia, da parte dell’amministrazione, nella progettazione, realizzazione e gestione dei servizi applicativi, in quanto essi possono essere basati su qualsiasi piattaforma applicativa, preesistente o di nuova acquisizione, purchè vengano poi erogati attraverso la Porta di Dominio. La fruizione dei servizi applicativi avviene attraverso lo scambio di messaggi applicativi, secondo il formato definito nel documento di specifica della busta di e-Gov.

 

Ambito di responsabilità

Ciascun amministrazione cooperante mantiene la responsabilità dei servizi da essa erogati e dei dati forniti attraverso tali servizi, dando luogo ad un singolo Dominio di servizi applicativi (brevemente Dominio). Ciò consente il disaccoppiamento tra i vari soggetti cooperanti, mantenendo nel loro ambito di responsabilità gli elementi di propria competenza.

 

Accordi

Un servizio applicativo opera sulla base di accordi tra almeno due soggetti (erogatore e fruitore), accordi che hanno un fondamento normativo/istituzionale oltre che tecnico. Tali accordi devono essere formalizzati in maniera tale che su di essi si possa operare in modo (semi-)automatico a supporto del ciclo di sviluppo e di esercizio dei servizi stessi. La formalizzazione dell’accordo viene indicata come Accordo di Servizio, ed è basata su linguaggio XML.

 

Tecnologie di cooperazione

I servizi applicativi vengono erogati/fruiti attraverso tecnologie e standard indicati genericamente come Web Service; queste rappresentano la soluzione effettiva proposta oggi dal mercato per l’interoperabilità di sistemi applicativi eterogenei in grado di soddisfare i requisiti precedentemente indicati. Attraverso queste tecnologie/standard, è possibile, infatti, esportare una qualsiasi funzionalità, operante su una qualsiasi piattaforma, affinché venga invocata remotamente. Il vantaggio di queste tecnologie è nella vasta opera di standardizzazione che vede coinvolti differenti comitati a livello internazionale (W3C ed OASIS1) e trova supporto da parte di tutti i maggiori fornitori di ICT del settore. In particolare risultano ben definiti i seguenti aspetti di base:

• protocolli applicativi per l’invocazione remota dei servizi: SOAP (Simple Object Access Protocol);

• linguaggi per la descrizione dell’interfaccia (intesa come insieme di operazioni) offerta da un servizio: WSDL (Web Service Description Language);

• architettura ed interfaccia di un sistema di registro con accesso prevalentemente basato su identificatori univoci: UDDI (Universal Description, Discovery and Invocation);

mentre risultano non ancora sufficientemente sviluppati i seguenti aspetti avanzati:

• protocolli per l’invocazione remota con caratteristiche di affidabilità, auditing e sicurezza point-to-point;

• descrizione delle conversazioni supportate/ammesse dal servizio;

• descrizione dei livelli di qualità del servizio;

• descrizione dei requisiti e caratteristiche di sicurezza end-to-end del servizio;

• descrizione della semantica del servizio e della semantica dell’informazione veicolata dal servizio;

• definizione dell’architettura e dell’interfaccia di un sistema di registro con caratteristiche di accesso più flessibili, basate sugli aspetti avanzati precedentemente menzionati.

Un’analisi attenta dei vari aspetti  mostra che per la cooperazione applicativa non sono sufficienti gli aspetti di base, ma sono necessari anche gli aspetti avanzati. Ecco allora che il modello ipotizzato deve prevedere:

• la caratterizzazione di alcuni aspetti avanzati attraverso la definizione di standard a livello nazionale, da sviluppare nel tempo e/o far convergere verso standard internazionali equivalenti quando verranno emessi;

• l’inserimento di alcuni aspetti descrittivi della qualità nell’Accordo di Servizio, in maniera da caratterizzare il servizio applicativo in una forma più completa.

Inizialmente, questi elementi saranno non obbligatori, ma opzionali. Quando in futuro saranno disponibili per tali elementi degli appositi standard, o quando sarà raggiunto a livello nazionale un opportuno accordo su tutti gli aspetti, tale da permetterne la loro standardizzazione, anche questi elementi dell’Accordo di Servizio diverranno obbligatori.

 

Cooperazione fra Amministrazioni

Insiemi di amministrazioni che concorrono a fornire servizi applicativi composti formano un Dominio di Cooperazione; il servizio erogato dal tale Dominio è, analogamente agli altri servizi, descritto attraverso un Accordo di Servizio, che però in questo caso è affiancato da una specifica che descrive come le varie amministrazioni componenti concorrono al servizio composto finale. Tale documento viene indicato come Accordo di Cooperazione, ed è trasparente rispetto ai fruitori del servizio composto, mentre ha utilità interna al Dominio di Cooperazione. Viene così definito un modo per distinguere tra servizi la cui responsabilità è di esclusiva pertinenza di un singolo dominio/amministrazione, e servizi che invece sarebbero sotto la responsabilità di più domini/amministrazioni, per i quali un’amministrazione assume (per legge, per delega concordata dagli altri, ecc.) la responsabilità complessiva. Un modello così complesso, richiede la definizione di differenti elementi condivisi, sia in termini di specifiche che di componenti software di supporto . Pertanto, nel modello è presente un ulteriore componente architetturale, denominato SICA (Servizi di Interoperabilità, Cooperazione ed Accesso), che offre una serie di servizi e componenti software infrastrutturali (non riconducibili a nessuna amministrazione specifica), il cui obiettivo è di mediare e supportare la cooperazione tra le amministrazioni. In sintesi, il modello di cooperazione applicativa del SPCoop è basato sul paradigma SOC (Service Oriented Computing) ed organizzato come una SOA (Service Oriented Architecture); mentre, però, gli aspetti base di questa SOA sono già definiti a livello di tecnologie/standard, su altri è necessario operare delle estensioni, al fine di rendere tale architettura adeguata al contesto del e-Government italiano. Va notato, infine, che tutte le architetture a servizi2/SOA richiedono la presenza di un elemento “logicamente” neutro, con il compito di mediare tra i differenti soggetti che cooperano attraverso l’erogazione/fruizione di servizi3. Il SICA costituisce di fatto tale elemento mediatore, dotato di funzionalità evolute in virtù del fatto che il modello di cooperazione proposto prevede la gestione non solo degli aspetti di base, ma anche e soprattutto di alcuni aspetti avanzati dei Web Services.

In tale contesto devono essere definiti degli obiettivi minimi di sicurezza da rispettare, quali:

Autenticazione delle entità.

Deve essere verificata l’identità dichiarata da tutte le entità implicate direttamente o indirettamente nello scambio di messaggi e nella erogazione e/o fruizione dei servizi. Essa riguarda i soggetti (utenti ed amministratori), i sistemi (PD, Registri, etc.) e le applicazioni che richiedono e/o erogano servizi. Le modalità di autenticazione sono dipendenti dalle operazioni effettuate. Devono essere individuate le categorie di operazioni per le quali è richiesto sempre l’uso dei certificati digitali nell’ambito di uno scenario di identità federate secondo standard generali ed a valenza normativa.

Autorizzazione dei soggetti/applicazioni all’effettuazione delle operazioni.

Devono essere gestite le autorizzazioni intese come attribuzione, sospensione e revoca dei profili di accesso ai soggetti. I profili di accesso sono predisposti in relazione alle operazioni consentite, secondo i tempi previsti, relativamente ad insiemi di dati definiti, e secondo le altre modalità ritenute necessarie. Sono individuati i responsabili dell’attribuzione dei privilegi, che curano altresì le modalità di conferimento e revoca. Per il conseguimento di tale obiettivo è richiesto sempre l’uso dei certificati digitali, salvo eccezioni corrispondenti a modalità di gestione ben individuate e circoscritte.

Delega delle Autorizzazioni all’effettuazione delle operazioni.

Deve essere possibile da parte di un soggetto delegante a favore di un soggetto delegato il conferimento delle autorizzazioni all’effettuazione di operazioni, come previsto dalla normativa vigente (delega, procura speciale, procura generale, etc.). Il conferimento delle autorizzazioni richiede l’uso di strumenti a valenza normativa (Firma Digitale, ecc).

Mantenimento dell’Integrità dei dati.

Deve essere assicurata l’integrità dei dati tra l’originatore delle richieste e l’erogatore, nel senso che vi deve essere assoluta confidenza che i dati non vengano modificati in modo accidentale o intenzionale e, sopratutto, all’insaputa di una o entrambe le entità.

Assicurazione della Riservatezza dei dati.

Deve essere assicurata la riservatezza dei dati scambiati sia in conformità alla normativa vigente (Decreto Legislativo n. 196/2003, conosciuto come Codice per la protezione dei dati personali, e successive modificazioni e integrazioni) sia per ogni altra ragione valida (ad esempio per evitare l’intercettazione dei dati classificati dall’amministrazione come “riservati”);

Non ripudiabilità a livello di richiesta e di risposta.

Ogni messaggio contenente una richiesta inoltrata ed ogni messaggio contenete una risposta erogata devono contenere la prova che sono state effettuate da determinate entità, in un determinato contesto spazio/temporale di esecuzione.

Registrazione degli eventi/Ispezione/Tracciabilità.

Deve essere sempre possibile risalire a chi ha effettuato le operazioni, dove, quali operazioni sono state effettuate e quando. L’ispezione è la capacità di acquisire dinamicamente le informazioni di registrazione.

Amministrazione della sicurezza.

Devono essere individuate ed attribuite responsabilità al personale incaricato di gestire, in particolare, le operazioni di definizione dei profili di accesso, configurazione dei sistemi, generazione degli account, ecc.

I principali rischi di attacco a cui sono esposti i sistemi partecipanti a un sistema informatico di cooperazione sono:

Intrusione attraverso impersonificazione: un’entità cerca di raggirare il processo di autenticazione e presentarsi sotto falsa identità. Per raggiungere lo scopo vengono solitamente sfruttate delle anomalie (exploit) presenti nei sistemi operativi/applicazioni a livello di codice o causate da errate configurazioni.

Abuso di privilegi: un’entità sfrutta le vulnerabilità dei sistemi per accedere a funzionalità con privilegi differenti da quelli attribuiti. Per limitare tale rischio occorre definire un meccanismo rigoroso di controllo degli accessi, rilevazione di intrusioni e verifiche sulle assegnazioni dei privilegi.

Intercettazione dei dati: un’entità non autorizzata cerca di acquisire dati durante il transito. Per limitare tale rischio devono essere implementate tecniche di cifratura.

Manomissione dei dati: un’entità cerca di inserire dati non autentici o alterare il contenuto dei messaggi. Per ovviare a questo attacco devono essere implementate tecniche per la “firma” dei dati.

Distruzione delle tracce: un’entità all’origine di un attacco vuole evitare di essere identificata e/o che si ritrovi la traccia di talune operazioni che ha effettuato, quindi cerca di cancellare le tracce di tutte o parte delle operazioni effettuate. Per garantire l’imputabilità delle azioni devono essere attivate le registrazioni degli eventi, meccanismi di allerta e di controllo della disponibilità e corretto funzionamento dei sistemi. Devono essere custoditi secondo procedure di sicurezza gli archivi contenenti le tracce informatiche.

Riutilizzazione/Dirottamento dei messaggi: un’entità intercetta i messaggi trasmessi e li riutilizza effettuando nuovi invii. Per ovviare a questo attacco occorre che i produttori dei dati e i mittenti ed i destinatari dei messaggi vengano autenticati, che i messaggi stessi siano identificati, autenticati e datati.

Distruzione dei messaggi/Negazione di invio/Negazione di ricezione: un’entità vuole evitare che vengano eseguite talune operazioni oppure vuole negare che esse siano state effettivamente richieste, attraverso la distruzione dei messaggi. Per garantire l’imputabilità delle azioni devono essere attivate le registrazioni degli eventi, meccanismi di allerta e di controllo della disponibilità e corretto funzionamento dei sistemi. Devono essere custoditi secondo procedure di sicurezza gli archivi contenenti le tracce informatiche.

Una corretta gestione delle problematiche di sicurezza nell’ambito di un sistema d cooperazione non può prescindere dall’individuazione e dall’adozione di appropriate e specifiche politiche di sicurezza, anche in accordo con la normativa vigente (Direttiva del PCM del 16 gennaio 2002, Decreto Legislativo n. 196/2003, Decreto Legislativo n. 42/2005, ecc.).

 

 

Dottor Guzzo Antonio

Diventa autore di Diritto.it

© RIPRODUZIONE RISERVATA


Per la tua pubblicità sui nostri Media:
maggioliadv@maggioli.it  |  www.maggioliadv.it

Gruppo Maggioli
www.maggioli.it

Ricevi tutte le novità di Diritto.it attraverso le nostre newsletter. 

Non abbandonare Diritto.it
senza iscriverti alle newsletter!