e.toscana Compliance visione d insieme

Transcript

1 Direzione Generale Organizzazione e Sistema Informativo Area di Coordinamento Ingegneria dei Sistemi Informativi e della Comunicazione I.T.S.A.E. e.toscana Compliance visione d insieme Gennaio 2007 Versione 1.7

2 DOCUMENTO: e.toscana Compliance visione d insieme EMISSIONE VERIFICA APPROVAZIONE Funzione Nome firma Emissione Specialista Tecnico Walter Volpi Centro Tecnico MICC Fabrizio Baldini Approvazione Responsabile LISTA DI DISTRIBUZIONE AGGIORNAMENTI Versione Data Paragrafi Modificati Motivo Modifica Prima stesura Aggiunte e modifiche a tutto documento , 2.3, 3 Rivisti i soggetti e i ruoli Rivisti soggetti e ruoli del processo di certificazione, dettagliato il processo. Introdotte le sottosezioni 3.1 e Aggiornato il paragrafo , 4 Introdotti riferimenti ad RFC infrastrutturali Rivista la descrizione del processo di accreditamento. Eliminazione stato Ammesso. Modifiche varie al paragrafo Tutto il documento Correzioni, proposte e chiarimenti su tutto il documento (autore Riccardo Del Dotto) Pag. 2 di 11

3 1. Obiettivi Request For Comments (RFC) e.toscana Tipologie di RFC Soggetti e ruoli Descrizione del processo Il processo di accreditamento e.toscana Compliance Soggetti e ruoli Descrizione del processo Riferimenti Pag. 3 di 11

4 1.Obiettivi In attuazione della Legge Regionale n.1 del 2004 [1], Regione Toscana, di concerto e secondo gli indirizzi della Rete Telematica Regionale Toscana e del progetto e.toscana, ha realizzato una infrastruttura di tecnologie e servizi per la cooperazione applicativa denominata CART. Tale infrastruttura rende possibile e perseguibile lo sviluppo coordinato dei sistemi informativi pubblici valorizzandone e condividendone il patrimonio informativo in una logica di servizio per i cittadini, le imprese e la stessa pubblica amministrazione. CART definisce un architettura di cooperazione e la realizza in un infrastruttura che abilita l integrazione di componenti e servizi. CART promuove inoltre lo sviluppo e l evoluzione della infrastruttura individuando e sostenendo i requisiti che garantiscono l interoperabilità dei sistemi, la sicurezza dell informazione, la continuità nell erogazione dei servizi e l automazione di processi che coinvolgono più soggetti organizzativi. CART è quindi una infrastruttura tecnologica e di servizi a disposizione di tutti i soggetti pubblici e privati e rappresenta l opportunità per la pubblica amministrazione di mettere a fattor comune i patrimoni informativi secondo una logica di reciproco interscambio, di semplicità di soluzioni, di rispetto degli ambiti e delle prerogative di competenza, di sicurezza e titolarità nel trattamento delle informazioni. CART rappresenta un opportunità per il mondo delle imprese di investire in settori nuovi, di migliorare i propri prodotti, di ottenere valore aggiunto dalla creazione di un sistema che promuove l integrazione e il riuso di prodotti e soluzioni. Al fine di rendere disponibile l infrastruttura CART a tutti, è stato definito un regolamento [3] che ha l obiettivo di creare un contesto di concreto e utile confronto con il mondo delle imprese ICT e attivare un processo di accreditamento di prodotti e soluzioni aderenti agli standard infrastrutturali di e.toscana che prende il nome di e.toscana Compliance. L obiettivo di e.toscana Compliance è valutare la capacità di uno specifico sistema o software applicativo di cooperare in modo corretto attraverso CART con altri sistemi anch essi accreditati e integrati con l infrastruttura. Questa capacità è sostenuta da attività quali la definizione di standard per infrastruttura e per domini applicativi specifici, la definizione di requisiti che garantiscono la corretta integrazione e la capacità di riuso e di evoluzione, un processo di accreditamento di prodotti e soluzioni. Questo documento illustra i componenti del processo e.toscana Compliance e in particolare i concetti di RFC e.toscana e il processo di accreditamento e.toscana Compliance. Pag. 4 di 11

5 2.Request For Comments (RFC) e.toscana Il processo e.toscana Compliance coinvolge una molteplicità di soggetti all interno di una comunità (comunità CART) che realizza un contesto di concreto e utile confronto fra gli Enti RTRT e il mondo delle imprese ICT. La comunità ha tra i suoi obiettivi principali quello di combinare interessi e motivazioni diverse, individuare gli obiettivi della cooperazione, definire i requisiti e gli standard che sostengono la cooperazione, lo sviluppo e l integrazione di servizi. La comunità è il luogo da cui prende avvio la collaborazione tra i diversi soggetti che è presupposto fondamentale alla realizzazione della cooperazione applicativa tra i sistemi informativi degli enti. Questa collaborazione è particolarmente necessaria nella determinazione dei requisiti e degli standard che guidano l evoluzione del sistema. Per questi motivi, nell'attuazione del CART, è stato avviato un processo di definizione collaborativa di specifiche che riguarda sia l infrastruttura di cooperazione, sia i singoli domini applicativi e che richiede contributo a tutti i soggetti della comunità. Il processo è attuato attraverso l uso di documenti Request For Comments (RFC) e con l'attivazione di gruppi di discussione on-line su temi che riguardano la cooperazione applicativa. Un RFC e.toscana è un documento che tratta argomenti inerenti le interazioni e il formato delle informazioni scambiate tra soggetti che cooperano attraverso l infrastruttura CART. L obiettivo del documento è la realizzazione di uno standard aperto che include la definizione di tecniche, modalità, standard tecnologici e informativi, atti a garantire la circolarità delle informazioni nel rispetto dei livelli di sicurezza e riservatezza, e con una latenza nell aggiornamento dei patrimoni informativi dei diversi enti prossima allo zero. Un RFC e.toscana nasce per definire il protocollo che due o più organizzazioni devono utilizzare per scambiarsi informazioni riguardanti un tema di interesse comune (ad es. il Protocollo Informatico, la rete dei SUAP, la rete degli URP, ). 2.1.Tipologie di RFC La definizione e l adozione di standard aperti è un elemento chiave per definire un modello architetturale e realizzarlo in un infrastruttura che abilita l integrazione e la cooperazione di applicazioni esistenti. La creazione e la diffusione di standard aperti è quindi elemento fondamentale per attuare un concetto di apertura che riguarda non solo i singoli domini applicativi, ma anche e soprattutto lo sviluppo di soluzioni di integrazione e cooperazione. In e.toscana si individuano quindi due tipi di RFC: RFC Applicativi che descrivono gli standard relativi alla cooperazione in un particolare dominio applicativo in termini di soggetti coinvolti, modalità di cooperazione, specifiche tecniche di interfacce di cooperazione; RFC Infrastrutturali che affrontano tematiche quali il corretto utilizzo delle infrastrutture ed hanno la finalità di condividere gli strumenti e le procedure da utilizzare per fruire in modo corretto dell infrastruttura di cooperazione applicativa CART. Pag. 5 di 11

6 A titolo di esempio, negli RFC infrastrutturali possiamo indicare: la definizione di accordi di servizio, le definizione delle interfacce dell infrastruttura di cooperazione applicativa, la definizione dei parametri di monitoraggio di qualità del servizio. Tra gli RFC infrastrutturali di fondamentale importanza è l RFC che stabilisce quali caratteristiche deve avere il software che utilizza l infrastruttura di cooperazione. Attraverso tale RFC la comunità si dà un insieme di regole che definiscono il comportamento corretto da rispettare nell utilizzo dell infrastruttura. Di seguito è illustrata la struttura e il processo organizzativo della produzione di RFC Applicativi e Infrastrutturali e.toscana. 2.2.Soggetti e ruoli I diversi soggetti che costituiscono la Comunità CART collaborano tra loro proponendo, aggiornando e rendendo obsoleti gli RFC e.toscana, fornendo spunti riflessivi, approfondimenti di tematiche, ecc. E corretto quindi parlare di una comunità che sviluppa RFC e.toscana. Il termine sviluppa (e quindi di comunità di sviluppatori di RFC) è da intendersi in un contesto in cui gli RFC vengono proposti, discussi e resi standard attraverso un processo evolutivo del documento basato sulla collaborazione. All interno della comunità si individuano in particolare le seguenti categorie di soggetti: Enti (Comuni, Province, ASL, ): include i soggetti che utilizzano a scopi diversi i servizi dell infrastruttura. Attraverso gli RFC, un ente mantiene una vista sull insieme dei servizi proposti, sviluppati ed erogati attraverso l infrastruttura di cooperazione. Imprese: partecipano attivamente al processo di produzione di RFC tramite l ideazione, la discussione e l implementazione di RFC, esercitando un importante influenza sui percorsi di sviluppo. Un impresa può anche utilizzare i servizi di cooperazione per interagire con la Pubblica Amministrazione. Comitato e.toscana Compliance fornisce lo stimolo per la ricerca, l innovazione, la competizione per la produzione di nuovi RFC. Attua una forma di controllo sul grado di maturità di un RFC decretandone la transizione a standard e.toscana. Centro Tecnico e.toscana Compliance: costituito da esperti nel tema della cooperazione applicativa, partecipa al processo valutando la conformità delle proposte agli standard architetturali e tecnologici di e.toscana. Il Portale e.toscana Compliance ( costituisce il punto di incontro della comunità dei soggetti. Il portale permette la costituzione di un Team Virtuale di soggetti che collaborano alla produzione di RFC e.toscana, e condividono idee e competenze attraverso gli strumenti offerti dal portale (archivio RFC, forum di discussione, mailing list, ). I soggetti assumono ruoli diversi nelle fasi del processo di sviluppo degli RFC. In particolare si individuano i seguenti ruoli: Proponente: è il ruolo ricoperto dagli Enti e dalle Imprese che propongono un tema di interesse per la Comunità CART. Un soggetto Proponente esercita inoltre un ruolo di influenza sulle direzioni di sviluppo degli RFC. Pag. 6 di 11

7 Sviluppatore: è il ruolo ricoperto dai soggetti (Enti, Imprese, Centro Tecnico) che partecipano attivamente al processo evolutivo del documento tramite la produzione di nuove versioni degli RFC e.toscana o tramite contributi attraverso gruppi di discussione. Gestore: è il ruolo assunto dal Comitato per la e.toscana Compliance che, in collaborazione col Centro Tecnico fornisce stimoli agli sviluppatori e svolge un ruolo di coordinamento e decisionale nello sviluppo degli RFC e successivamente in quello della diffusione e distribuzione dei servizi. Supporta inoltre la comunità attraverso finanziamenti specifici finalizzati alla realizzazione di servizi tramite lo strumento delle Call For Proposal. 2.3.Descrizione del processo Lo sviluppo degli RFC avviene attraverso un processo di collaborazione tra i diversi soggetti che prende avvio da un RFC Presentato e termina con l approvazione di un RFC Standard. Il grado di maturazione del processo di sviluppo è indicato dallo stato assunto dall RFC e.toscana: Presentato : in questo stato un RFC è sottoposto dal Proponente all approvazione del Gestore che ne valuta l effettivo interesse per la Comunità CART; Discussione : in questo stato un RFC e.toscana è soggetto alla discussione della Comunità; Candidato : in questo stato RFC e.toscana ha subito il processo di maturazione e il Proponente lo giudica prossimo a diventare Standard; Standard : in questo stato RFC e.toscana è divenuto lo standard di riferimento nel contesto applicativo per cui è stato sviluppato. Un RFC standard è uno standard aperto, in quanto è un insieme di specifiche pubblicamente disponibili e mantenute tali nel tempo. Il processo di sviluppo dell RFC guida il documento attraverso i vari stati con l obiettivo di produrre un RFC Standard di qualità in tempi certi. Il processo prende avvio dalla presentazione di un tema da parte di un Proponente al Gestore attraverso il Portale e.toscana Compliance. Il Gestore valuta se il tema è interessante per la comunità, ed eventualmente promuove l RFC dallo stato di Presentato a quello di Discussione rendendolo visibile e sottoponendolo al giudizio della Comunità CART. Attorno all RFC in Discussione si costituisce in forma spontanea un team di Sviluppatori che lavora alla produzione di nuove proposte di revisione attraverso il Portale e.toscana Compliance. Gli Sviluppatori producono proposte di revisione all RFC aggiungendo ogni volta le modifiche ritenute necessarie al miglioramento della specifica. Il soggetto Proponente stabilisce quali tra le differenti proposte di revisione debba divenire oggetto di discussione, guidando il processo verso la produzione di una forma stabile dell'rfc. Il Proponente ha la responsabilità di stabilire il raggiungimento di tale forma stabile cambiando lo stato dell RFC in RFC Candidato attraverso il Portale e segnalando al Gestore l avanzamento del processo. Il Proponente deve quindi governare il processo di produzione di RFC cercando il compromesso tra la ricerca di nuove soluzioni e la Pag. 7 di 11

8 necessità di convergere verso standard aperti orientati alla realizzazione di servizi condivisi. Tutti i membri della Comunità CART sono chiamati ad esprimere un'opinione sull'rfc Candidato. Se la Comunità CART non produce osservazioni significative entro 20 giorni dall entrata nello stato di Candidato, il Gestore promuove il documento a Standard. In caso contrario, il Proponente o il Gestore possono rimettere il documento in Discussione. La possibilità di un RFC di diventare standard è subordinata quindi ad un ampia e aperta discussione da parte della comunità. E quindi necessario fornire un continuo stimolo agli sviluppatori degli RFC: di questo si occupa il Gestore che favorisce i rilasci in modo da stimolare il contributo attivo. Per lo stesso motivo, è anche necessario favorire la comunicazione e l organizzazione tra i soggetti della comunità: l uso intensivo della rete Internet e il Portale e.toscana Compliance sono fondamentali in questo senso in quanto offrono il canale e gli strumenti che permettono di abbattere i costi della partecipazione. Pag. 8 di 11

9 3.Il processo di accreditamento e.toscana Compliance La realizzazione di ogni servizio di cooperazione infrastrutturale o applicativo avviene nel rispetto dei documenti RFC Standard [5] e [6] che ne definiscono le caratteristiche e le modalità con cui esso deve integrarsi con l infrastruttura esistente. Per sostenere l attuazione dei requisiti posti dagli RFC è necessario un processo di accreditamento che, per ogni prodotto software sviluppato con funzioni di cooperazione applicativa interne alle RTRT, verifichi e certifichi il rispetto dello standard. 3.1.Soggetti e ruoli Come per la produzione di RFC, anche il processo di accreditamento coinvolge una molteplicità di soggetti: Enti (Comuni, Province, ASL, ): sono i soggetti che hanno acquisito o devono acquisire un prodotto software da un fornitore o che devono adattare un prodotto esistente per poter utilizzare i servizi resi disponibili dall infrastruttura. Imprese: sono i soggetti che partecipano attivamente allo sviluppo del prodotto software. Centro Tecnico e.toscana Compliance: è un insieme di soggetti esperti a cui è assegnata la responsabilità di verificare se il software prodotto è conforme agli RFC Standard e.toscana. Comitato e.toscana Compliance: è un insieme di soggetti che delega al Centro Tecnico la responsabilità di verificare la conformità software ed ha l autorità di certificare un prodotto e.toscana Compliant. I soggetti assumono ruoli diversi nelle fasi del processo di accreditamento. In particolare si individuano i seguenti ruoli: Proprietario: è il ruolo ricoperto dagli Enti e dalle Imprese proprietari dei prodotti software sottoposti al processo di accreditamento. Referente Tecnico: è il ruolo ricoperto dai soggetti (Imprese o strutture tecniche degli Enti) che hanno competenza tecnica sul prodotto software. Certificatore Tecnico: è il ruolo assunto dal Centro Tecnico per la e.toscana Compliance che verifica la conformità del prodotto software agli RFC e.toscana. Il Certificatore interagisce col Referente Tecnico per produrre le evidenze necessarie alla certificazione tecnica. Gestore: è il ruolo assunto dal Comitato per la e.toscana Compliance che decreta la conformità e.toscana dei prodotti che hanno ottenuto la certificazione tecnica. Anche in questo caso i soggetti coinvolti nel processo di verifica e accreditamento collaborano e interagiscono utilizzando il Portale e.toscana Compliance. In questo caso il portale è lo strumento che permette ad un Proprietario di richiedere la certificazione di un prodotto e di seguirne il processo fino all eventuale certificazione. Se il prodotto software è ritenuto conforme agli RFC, esso viene certificato e.toscana Compliant ed inserito nel catalogo di prodotti certificati pubblicato sul portale stesso. Pag. 9 di 11

10 3.2.Descrizione del processo La certificazione di un prodotto si svolge secondo un processo che prende avvio dalla sottomissione di un prodotto e termina con la decretazione di conformità e.toscana. L avanzamento del processo di certificazione del prodotto è indicato del suo stato: proposto : il prodotto è proposto al processo di accreditamento da parte del Proprietario attraverso il portale e.toscana Compliance. Candidato : in questo stato il prodotto attende il decreto di certificazione da parte del Gestore. Certificato : il prodotto ha completato il processo di accreditamento ed è pubblicato nell albo dei prodotto accreditati sul Portale e.toscana Compliance. Il processo inizia con la sottomissione di un prodotto da parte del Proprietario, attraverso il Portale e.toscana Compliance. La proposta di accreditamento deve contenere: (i) la descrizione del prodotto; (ii) il riferimento agli RFC applicativi che descrivono il dominio applicativo nel quale il prodotto si colloca; (iii) l indicazione di un responsabile; (iv) l indicazione del Referente Tecnico; (v) la documentazione tecnica del prodotto conforme alle specifiche [5] e [6]; (vi) se richiesto, il codice sorgente del prodotto (nel formato descritto da [5] e [6]) Il prodotto proposto è quindi sottoposto alla verifica tecnica operata dal Certificatore Tecnico che valuta la conformità agli standard e.toscana definiti dagli RFC infrastrutturali e applicativi. Durante la verifica il Centro Tecnico può richiedere al Referente Tecnico chiarimenti sulle caratteristiche del prodotto, sulla documentazione, sulle procedure di installazione, utilizzo e gestione, ed eventuali integrazioni alla documentazione fornita. Al termine della verifica il Centro Tecnico emette la documentazione tecnica che ha portato alle conclusioni espresse in un documento di certificazione. Il superamento della verifica comporta il passaggio del prodotto allo stato Candidato e la gestione del processo passa al Gestore che ne decreta formalmente la conformità dichiarando il prodotto Certificato. I prodotti Certificati sono inseriti nell albo dei prodotti accreditati pubblicato sul Portale e.toscana Compliance. Se, al contrario, il prodotto non supera la verifica tecnica, esso è dichiarato non conforme e il Gestore è informato della conclusione del processo di accreditamento. A fronte del rilascio di una nuova versione di un prodotto, il Proprietario deve inserire sul portale i dati della versione, la documentazione ed eventualmente il codice sorgente aggiornato 1. La documentazione dovrà essere sostitutiva delle precedenti versioni e dovrà riportare la descrizione completa del prodotto, evidenziare gli aggiornamenti rispetto all ultima versione e includere un breve storico dei nuovi elementi o modifiche introdotte. A seguito della sottomissione della nuova versione, il prodotto è nuovamente sottoposto alla verifica tecnica. La durata dell intero processo di accreditamento, dalla proposta alla decretazione di conformità (o di non conformità) non dovrà superare i tre mesi. Il Gestore ha comunque la facoltà di prorogare, su motivata richiesta del Proprietario o del Certificatore Tecnico, il termine del completamento della certificazione. 1 La sottomissione di una nuova versione non potrà tuttavia avvenire nel caso in cui sia in corso il processo di accreditamento di una versione precedente sottomessa dallo stesso Proprietario. Pag. 10 di 11

11 4.Riferimenti [1] LEGGE REGIONALE 26 gennaio 2004, n. 1 Promozione dell amministrazione elettronica e della società dell informazione e della conoscenza nel sistema regionale. Disciplina della "Rete telematica regionale toscana" Bollettino Ufficiale della Regione Toscana - n. 3 [2] CART, Processo di accreditamento e.toscana Compliance, 5 Aprile 2005 [3] CART, Processo di accreditamento e.toscana Compliance Regolamento, Regione Toscana, 5 Aprile 2005 [4] Portale e.toscana Compliance, [5] CART, Processo di accreditamento, RFC - Certificazione e.toscana Compliance di Proxy Applicativi, Regione Toscana, 2 Gennaio 2007 [6] CART, Processo di accreditamento, RFC - Certificazione e.toscana Compliance di applicativi SIL, Regione Toscana, 2 Gennaio 2007 Pag. 11 di 11