progetto firm@

167
Edizioni Change Progetto Firm@ L’impiego della firma digitale per la gestione dei progetti di Fondo Sociale Europeo in Regione Lombardia. Un caso concreto di eGovernement Carla Almirante Angelo Cardani Ruggero Civitarese Filippo Chesi BUONE PRATICHE

Upload: loris-rizzi

Post on 06-Jun-2015

593 views

Category:

Documents


0 download

DESCRIPTION

Volume 2 della collana Archidata

TRANSCRIPT

Edizioni Change

Progetto Firm@L’impiego della firma digitale per la gestione dei progetti di Fondo Sociale Europeo in Regione Lombardia. Un caso concreto di eGovernement

Carla Almirante Angelo Cardani Ruggero Civitarese Filippo Chesi

B U O N E P R AT I C H E

© 2005 - Edizioni Change

20100 Milano – Via Vittor Pisani 13 – Tel. 02-6700230

Progetto grafico: Francesca Caricato

Indice

Parte I - Aspetti generali dei progetti di e-gov

1. Definizione del problema ed approcci possibili1.1 Aspetti qualificanti e portata innovativa nei progetti di

e-go vernment1.2 Le diverse forme dei progetti di e-government

1.2.1 Il livello di interazione1.2.2 Il livello di servizio effettivo offerto 1.2.3 Le tipologie di servizio di e-government offerto1.2.4 Il posizionamento del Progetto Firm@

1.3 Concezione e attuazione di un progetto di e-gov

2. Le problematiche intrinseche del singolo progetto di e-gov2.1 La razionalizzazione dei processi e il ridisegno organizzativo2.2 La gestione dell’interazione con l’utente

2.2.1 L’identificazione dell’utente2.2.2 Lo scambio di informazioni “firmate”2.2.3 La gestione documentale: scambi e archiviazione

2.3 Il problema della sicurezza delle transazioni2.3.1 La sicurezza degli accessi2.3.2 Gestione delle transazioni economiche2.3.3 Tutela della privacy

3. I presupposti tecnologici ed infrastrutturali 3.1 La tecnologia del certificato digitale

3.1.1 Concetti generali 3.1.2 Il certificato digitale3.1.3 Le infrastrutture a chiave pubblica

3.2 Interoperabilità e standardizzazione3.2.1 Interoperabilità tecnica3.2.2 Interoperabilità e firma digitale3.2.3 Interoperabilità semantica e gestionale

3.3 Strumenti di identificazione3.3.1 La Carta d’Identità Elettronica3.3.2 La Carta Nazionale dei servizi3.3.3 Le Carte Regionali dei Servizi

9

10

10

111113

151718

23232626293133343539

424242434548

49505253535555

3.3.4 La Tessera Sanitaria3.4 Firma digitale e autenticazione dei documenti

3.4.1 Concetto e definizioni3.4.2 La questione del non ripudio della firma digitale3.4.3 Concessione e gestione della firma: la certificazione

della Firma Digitale3.4.4 Processo di funzionamento della Firma Digitale3.4.5 Problemi Aperti

3.5 Trasmissione certa: posta elettronica certificata (PEC)3.5.1 Concetto e definizioni3.5.2 La sperimentazione relativa alla PEC

3.6 Ricezione e gestione: il protocollo informatico3.6.1 Concetto e definizioni3.6.2 Il Protocollo Informatico nella PA: livelli di attivazione3.6.3 Il nucleo minimo di protocollo: soluzioni e approcci3.6.4 Il percorso di attivazione

4. Conclusioni e prospettive4.1 L’attivazione di servizi innovativi4.2 L’evoluzione del contesto normativo: il futuro “Codice della PA

Digitale”

5. Allegato: le fonti normative di riferimento5.1 Fonti normative in materia di firma digitale5.2 Fonti normative in materia di e-mail certificata5.3 Fonti normative in materia di protocollo informatico

Parte II - Il progetto firm@

6. Introduzione6.1 Obiettivi del progetto 6.2 Ambito di riferimento 6.3 Documentazione di riferimento 6.4 Articolazione del Progetto

7. Aspetti di contesto7.1 Strutture regionali di riferimento per la gestione FSE

7.1.1 Autorità di Gestione7.1.2 Autorità di Pagamento7.1.3 Autorità di Controllo di II livello

7.2 Le procedure di gestione dei Progetti FSE7.2.1 Procedure dell’Autorità di Gestione

60616165

6974767878798080818385

8888

90

92929494

97

9898

100102104

106

106106

109110110110

7.2.2 Procedure dell’autorità di pagamento7.2.3 Procedure Generali

7.3 La Gestione Documentale7.4 Il Sistema informativo per la gestione FSE

7.4.1 MonitorWEB - Schema complessivo del sistema7.4.2 Presentazione progetti 7.4.3 Valutazione7.4.4 Gestione progetti7.4.5 Gestione delle visite ispettive7.4.6 Porte applicative7.4.7 Architettura

8 Il Protocollo Informatico della Regione Lombardia8.1 La Posta Elettronica Certificata e il Protocollo Regionale8.2 Gestione della Firma Digitale da parte del Sistema Protocollo

Regionale

9 Introduzione della Firma Digitale nella Gestione FSE9.1 L’approccio metodologico9.2 Documenti trattati nell’ambito del Progetto [email protected] Le procedure interessate dal Progetto [email protected] Attuale supporto informatico alle procedure individuate

9.4.1 Area rivolta agli operatori di formazione9.4.2 Area rivolta ai funzionari regionali

9.5 Modifiche apportate al Sistema Informativo con l’introduzione della Firma Digitale9.5.1 Descrizione delle procedure prima dell’introduzione della

Firma Digitale 9.5.2 Descrizione delle procedure dopo l’introduzione della Firma

Digitale9.6 Sintesi della soluzione informatica adottata

9.6.1 Architettura del Sistema9.6.2 Il flusso procedurale

10 Modalità di attuazione della sperimentazione 10.1 Individuazione della procedura di test: l’Avvio dei Progetti10.2 Supporto informatico alla gestione della Firma Digitale

10.2.1 Area rivolata agli operatori di formazione10.2.2 Area rivolta ai funzionari regionali

Bibliografia

Sitografia

111112112117119120121122124125126

127128129

131131132138141141143

144

144

146147148150

151151151152159

165

166

7 PROGETTO FIRM@ Documento di progettazione

Introduzione

Il Progetto Firm@ si inserisce nel più vasto panorama dei pro-getti di e-government che, attraverso l’utilizzo della rete e delle nuove tecnologie, si propongono di trasformare le relazioni interne ed esterne della Pubblica Amministrazione.

Gli obiettivi di fondo di questi progetti sono: • migliorare la disponibilità del servizio (efficacia del servizio);• ottimizzare le attività di produzione del servizio (efficienza del

servizio);• dare centralità a cittadini e imprese lungo tutto il ciclo di vita

del servizio;• semplificare le procedure amministrative.L’introduzione delle nuove tecnologie comporta la rivisitazione

di interi processi, determinando la necessità di analizzare e gestire i cambiamenti che insorgono nei seguenti ambiti:

• organizzazione;• tecnologia e infrastrutture;• interoperabilità dei processi tra Pubbliche Amministrazioni.Un aspetto in qualche modo trasversale ai tre ambiti individuati

è dato dallo stato ancora incerto, e a tratti contraddittorio, della nor-mativa.

Il documento che segue propone, da un lato, un focus sulle pro-blematiche generali intrinseche ai progetti di e-government (presuppo-sti tecnologici e infrastrutturali, normativa di riferimento e strumenti tecnologici) e, dall’altra, esamina in modo approfondito, a titolo di test case, il Progetto Firm@, un progetto finanziato col Fondo Sociale Eu-ropeo che introduce la firma digitale nel processo di gestione dei corsi di formazione finanziati via FSE dalla Regione Lombardia.Più precisamente, il documento si articola nel modo seguente:

Parte I • si propone una classificazione dei progetti di e-government se

condo le due variabili efficienza ed efficacia e si focalizzano le problematiche di carattere organizzativo e tecnologico;

8 PROGETTO FIRM@ Documento di progettazione

• si esaminano nel dettaglio le principali componenti tecnologi che e infrastrutturali che costituiscono una sorta di kit che permette l’attivazione di questo tipo di progetti;

• si richiama la normativa di riferimento.

Parte II

• si esaminano gli aspetti di contesto del Progetto Firm@, quali: l’organizzazione della Direzione Generale, l’insieme delle procedure all’interno delle quali viene introdotta la firma digitale e il sistema informativo di supporto;

• si fa il punto sulle infrastrutture tecnologiche presenti che con sentono l’introduzione dell’utilizzo della firma digitale all’interno del processo;

• si approfondiscono l’architettura generale della soluzione e le variazioni apportate a livello organizzativo, procedurale e applicativo dall’introduzione della firma digitale.

PARTE IASPETTI GENERALI DEI PROGETTI DI e-GOV

1.1 Aspetti qualificanti e portata innovativa nei progetti di e-government

Da un punto di vista gestionale (connesso quindi con le proble-matiche relative all’attivazione di un servizio e dunque, in ultima ana-lisi, con l’ottica dell’Ente attuatore) si può affermare che la gestione on line di un servizio è caratterizzata almeno da tre componenti tipiche:

• la costruzione e attivazione di un portale di interfaccia e interazione con l’esterno, che può avere diversi gradi di evoluzione nella quantità e qualità dei servizi offerti;

• la riorganizzazione dell’Ente attraverso un intervento sulla struttura organizzativa, che viene rivista in chiave di servizio al cittadino in una logica per processi;

• l’informatizzazione e l’allineamento delle basi dati del back office a supporto dell’erogazione del servizio “a distanza”, in modo esaustivo.

Attivare un servizio con modalità on line significa quindi prende-re in considerazione tutte e tre le componenti sopra descritte.

Con riguardo alle possibili variabili di lettura e interpretazione delle esperienze di gestione on line si ritiene possibile individuarne due:

• la prima variabile fa riferimento al livello di interazione che viene consentito all’utente esterno che si appresta all’utilizzo delle funzionalità offerte. Nei sistemi e-government essa com prende sia le modalità di interfaccia che la quantità e qualità dei servizi offerti;

• la seconda variabile fa riferimento al livello di servizio effetvo per l’utente, tale livello dipende da come funziona il sistema di erogazione del servizio e dall’impatto con il sistema organizzativo dell’Ente. Le principali caratteristiche di questa seconda variabile sono:

1. la possibilità di operare a distanza senza necessità di recarsi presso il luogo fisico di erogazione del servizio;

2. una riduzione certa dei tempi di attesa;

1. Definizione del problema ed approcci possibili

10 L’impatto Economico dei Fondi Strutturali

11 PROGETTO FIRM@ Documento di progettazione

3. la possibilità di avere servizi innovativi, accessori rispetto a quanto erogabile in modo tradizionale.

Le caratteristiche peculiari del servizio erogato sono date da una lettura congiunta di tali variabili.Infatti le stesse ne definiscono le caratteristiche attraverso:

• la definizione delle funzionalità del portale di interfaccia;• la definizione del funzionamento sostanziale della macchina

amministrativa nel suo complesso, che può essere descritto in termini di relazioni tra i meccanismi che governano ciò che accade nel back office:

- software;- basi dati;- modello organizzativo.

Il capitolo successivo ha lo scopo di fornire un quadro delle varia-bili che caratterizzano la reale portata innovativa (in termini di “cambio di paradigma” nell’erogazione dei servizi pubblici) dei diversi progetti di e-gov che sono in gestione in questi anni.

L’idea è che i diversi progetti vanno analizzati non solo per l’am-bito di cui si occupano (p.es. tributi piuttosto che erogazione di finan-ziamenti) ma anche per la loro reale portata innovativa.

1.2 Le diverse forme dei progetti di e-government

1.2.1 Il livello di interazione

L’Unione Europea ha definito un sistema di monitoraggio del-lo sviluppo dell’e-government, in modo da stimolare il confronto e l’attività dei Paesi Membri in materia, individuando quattro livelli di interazione tra il cittadino e la Pubblica Amministrazione:

Livello 1: Informativo (Information). Sono disponibili on line solo le informazioni necessarie per avviare la procedura che porta all’eroga-zione del servizio. In particolare devono essere presenti sul sito infor-mazioni in merito a:

• descrizione dell’organizzazione e delle attività dell’ente che ero ga il servizio;

• contatti per richiedere ulteriori informazioni;• dettagli sulle procedure e sulle modalità di erogazione del servizio.

Livello 2: Download modulistica (One-way Interaction). E’ pos-sibile scaricare on line i moduli necessari ad avviare la procedura che

12 PROGETTO FIRM@ Documento di progettazione

porta all’erogazione del servizio. In particolare deve verificarsi almeno una delle seguenti condizioni:

• esistenza di link on line per eseguire il download del modulo;• possibilità di stampare on line il modulo;• possibilità di ordinare on line il modulo.

Livello 3: Inoltro richiesta (Two-way Interaction). E’ possibile avvia-re on line la procedura che porta all’erogazione del servizio. In partico-lare, devono verificarsi contemporaneamente le seguenti condizioni:

• disponibilità del modulo elettronico che, una volta compi-lato dall’utente, consente all’ente di avviare la procedura che porta all’erogazione del servizio;

• esistenza di strumenti di autenticazione dell’utente tipo:- nome utente;- nome utente e informazioni personali;- numero identificativo utente e password;- identificazione elettronica;- firma digitale.

Livello 4: Esecuzione transazione, compreso pagamento e conse-gna (Full electronic case handling). Possibilità di eseguire on line l’intera procedura che porta all’erogazione del servizio, comprensiva di pagamento, notifica e consegna. In particolare devono verificarsi contemporaneamente le seguenti condizioni:

• assenza totale di moduli cartacei ai fini dell’erogazione del servizio;• possibilità di gestire, da parte dell’utente, tutto il processo dal

terminale di accesso on line;• possibilità di gestire on line la notifica, il pagamento e la con-

segna associati all’erogazione del servizio.Il servizio minimo consiste nel garantire on line ai cittadini una

semplice offerta informativa per arrivare poi alla possibilità di scaricare la modulistica (modalità interattive monodirezionali) ed infine di effettuare dei pagamenti attraverso modalità differenti, che vanno dal pagamento con carta di credito all’addebito diretto su c/corrente bancario o postale.

Il pagamento on line, infatti, rappresenta la modalità interattiva più avanzata, che va a completare l’intera transazione tra il cittadino e l’ente e che, allo stato attuale, è attiva solo in pochi casi concreti, sia per la difficoltà nel mettere a punto l’infrastruttura necessaria ad effettuare tali operazioni sia per la necessità di implementare ambienti sicuri per le transazioni e l’identificazione univoca del cittadino.

13 PROGETTO FIRM@ Documento di progettazione

1.2.2 Il livello di servizio effettivo offerto

Con riferimento al livello di servizio effettivo, si possono indi-viduare almeno 4 livelli caratterizzanti le funzionalità del sistema di erogazione e l’impatto con il sistema organizzativo interno all’Ente:

1. un primo livello che possiamo definire portale isolato, caratterizzato da un livello di integrazione minima con il sistema organizzativo e i sistemi informativi dell’Ente. L’inse-rimento di dati da parte dell’utente non provoca interazioni né con i sistemi informativi né con il processo di gestione dei tributi. Le caratteristiche distintive di questo livello di interazione on line sono: • utente compila i propri dati direttamente su web;• il sistema non è in grado di interpretare e valutare il conte-

nuto della transazione;• nessuna interazione tra sistema web e sistemi informativi di

back office;• impegno operatori nella trascrizione dei dati.

2. un secondo livello definibile come portale non integrato ma che guida il processo caratterizzato da un livello di integrazione medio/bassa con il sistema organizzativo e con i sistemi informativi di back office, ma da una individuazione e definizione dei processi di lavoro caratteristici. Il portale non interviene sugli archivi delle procedure ma guida l’operatore nelle operazioni da svolgere. Le caratteristiche distintive di questo livello di interazione on line sono: • utente compila i propri dati direttamente su web;• non è in grado di interpretare e valutare il contenuto della

transazione;• fornisce un workflow che segue tutto l’iter del processo;• nessuna interazione tra sistema web e sistemi informativi

diback office;• impegno operatori nella trascrizione dei dati;

3. un terzo livello più evoluto definito come portale integrato con i sistemi transazionali, caratterizzato dalla piena integrazione tra sistema web e i sistemi informativi di back office dell’ufficio tributi. Permette la integrazione con i sistemi informativi di back office, l-utente riconosciuto può intervenire di

14 PROGETTO FIRM@ Documento di progettazione

rettamente sui dati/processo, sempre con la supervisione e il controllo degli operatori. Le caratteristiche distintive di questo livello di interazione on line sono:• utente compila i propri dati direttamente su web;• interazione completa tra sistema web e sistemi informativi

di back office;• nessun impegno da parte degli operatori nella trascrizione

dei dati;• l’utente riceve dal sistema informazioni dirette sulla propria

posizione.4. un quarto livello del portale integrato con banche dati del

l’ente integrate, il livello è caratterizzato da una completa integrazione e messa a sistema di tutte le banche dati dell’Ente, per cui l’immissione dei dati dell’utente genera un impatto diretto non solo sui sistemi informativi di back office dell’ufficio con cui il cittadino si sta relazionando, ma anche sui sistemi informativi di altri uffici interessati e rispetto ai quali possono essere effettuati controlli incrociati di correttezza dei dati immessi. Le caratteristiche distintive di questo livello di interazione on line sono:• utente compila i propri dati direttamente su web;• i processi dell’Ente sono tutti integrati tra di loro, permette

di avere in linea più banche dati;• interazione completa tra sistema web e sistemi informativi

di back office di tutte le aree dell’ente;• nessun impegno da parte degli operatori nella trascrizione

dei dati.Dall’analisi congiunta del posizionamento rispetto alle due varia-

bili descritte in questo e nel precedente paragrafo (livello di interazione e livello di servizio), deriva un giudizio complessivo sulla portata del progetto di e-government, con:

• un primo dimensionamento degli sforzi necessari per l’Ente attuatore e dunque delle risorse umane e tecnologiche da uti- lizzare;

• un’idea di massima sulla strada da percorrere una volta definte le priorità relativamente ai servizi da erogare (alcuni richie- dono per definizione livelli di interazione più alti ecc.).

15 PROGETTO FIRM@ Documento di progettazione

Conseguentemente un Ente, una volta deciso quali servizi ero-gare secondo modalità innovative, si deve porre la domanda di quanto è disposto ad innovare la struttura organizzativa e i processi al fine di supportare tale scelta e, soprattutto, di quante risorse ha a disposizione.

Ancora una volta la scelta è collegata al grado di innovatività verso cui ci si spinge, e ancora una volta le alternative possibili sono molte.

Possono ad esempio essere gestiti completamente interi processi attraverso l’impiego di procedure e strumenti innovativi, ma qualo-ra manchi l’integrazione con altri sistemi informativi e banche dati dell’Ente, e dunque con altri processi gestionali (che andrebbero per questo opportunamente rivisti) questi processi rischiano di essere delle “isole”, e dunque di perdere molti dei vantaggi impliciti nell’adozione di forme di gestione differenti (efficienza su tutti).

Al di là comunque delle scelte appena illustrate appare chiaro che l’implementazione di una qualsiasi introduzione di innovazioni di questo tipo ha delle ricadute in termini organizzativi, dove non in ter-mini strettamente “numerici” (adeguamento delle strutture), di sicuro in termini di competenze da sviluppare attraverso, per esempio, inter-venti formativi specifici.

Una scelta trasversale rispetto a quelle poste in precedenza riguar-da la decisione, da prendersi una volta definiti i confini dei servizi da erogare in modalità on line, di quali flussi documentali “spostare” nelle nuove modalità di interazione, e di quali invece mantenere nelle moda-lità tradizionali (trasmissione cartacea, protocollazione e gestione della pratica nel modo consueto).

Un esempio che si può fare a riguardo è quello della presentazio-ne di una domanda (es. di accreditamento o di partecipazione ad una gara di appalto) per via telematica e utilizzando un dispositivo di firma digitale, in modo da avere immediata visione del numero di pratiche e delle caratteristiche della “domanda” del servizio, rimandando la verifica della conformità dei documenti e dei requisiti ad un momento successi-vo consentendone la trasmissione, ad esempio, per posta ordinaria.

L’esempio può essere esteso ai flussi documentali tra enti diversi e a diversi ambiti di applicazione.

1.2.3 Le tipologie di servizio di e-government offerto

Mettendo a sistema le due variabili (livello di interazione e livello di servizio effettivo) è possibile costruire una matrice caratterizzata dal-l’incrocio tra i diversi livelli.

16 PROGETTO FIRM@ Documento di progettazione

Ciascuno dei quadranti della matrice rappresenta uno stato tipi-co del sistema di e-government attuato da un’amministrazione.

Sistema di e-government Caratteristiche

informazioni on linelivello minimo di servizio percepito

solo cambiamento nella modalità di erogazione

alto livello di servizio tradizionale

livello medio di servizio percepito

individuazione e defi nizione dei processi di

lavoro

e-government formalealto livello di servizio percepito

rischio di delusione rispetto alle prestazioni

e-government sostanziale

equilibrio tra servizio percepito e servizio

erogato oneroso da mantenere allineate

le basi dati

PA on linemacchina amministrativa innovativa a regime

ampliamento della gamma dei servizi da off rire

La matrice successiva mostra invece un altro modo di interpre-tare i diversi incroci possibili tra livelli delle variabili e fa riferimento alle conseguenze organizzative che comporta la realizzazione di un servizio di e-government.

17 PROGETTO FIRM@ Documento di progettazione

1.2.4 Il posizionamento del Progetto Firm@

18 PROGETTO FIRM@ Documento di progettazione

Il posizionamento del Progetto Firm@ così come riportato nello schema nasce dalla considerazione che:

• il progetto stesso prevede un elevato livello di interazione, per il quale “a regime” tutto il processo sarà completato on-line, senza necessità di trasmissione di documenti cartacei (livello 4 dell’asse delle ordinate);

• esiste di fatto già un portale (monitorweb) che permette di erogare interamente il servizio a distanza, chiudendo la tran-sazione on-line ed effettuando tutte le operazioni e verifiche successive previo riconoscimento dell’utente (livello 3 dell’as-se delle ascisse).

Da questo punto di vista comunque il Progetto Firm@ rappresen-ta un caso molto interessante per riuscire a contestualizzare, a toccare con mano all’interno di un unico progetto, tutte le principali proble-matiche connesse con la realizzazione di un progetto di e-government “evoluto”, in grado cioè di mettere concretamente in pratica tutta una serie di attività con il supporto concreto di strumenti di interazione ad alto contenuto tecnologico.

Il livello medio, esclusi i casi di “eccellenza” che rimangono co-munque molto pochi, di tali progetti si attesta infatti su un livello di interazione tendenzialmente più basso e su una minore capacità di erogare completamente il servizio a distanza, mancando in molti casi presupposti (organizzativi e gestionali più che tecnologici), in grado di spingere il posizionamento verso l’alto nei termini delle due variabili di riferimento.

1.3 Concezione e attuazione di un progetto di e-gov

La parte I del presente documento non tratta più di tanto dei vantaggi e delle opportunità legati all’introduzione di un progetto di e-gov – che sono ben noti e discussi in letteratura – ma si pone piut-tosto l’obiettivo di fornire un quadro degli aspetti da considerare nella concezione e nell’attivazione di un progetto di e-gov per poterne defi-nire un piano di fattibilità concreto e garantire così l’effettivo livello di innovatività che è possibile raggiungere.

Come abbiamo visto, il concetto di e-government presuppone un completo cambio di paradigma nell’erogazione dei servizi pubblici reso possibile dall’evoluzione tecnologica, dalla sviluppo delle tecnolo-gie ICT e dalla diffusione di internet.

La realizzazione di questo “salto” impone però di presidiare con-

19 PROGETTO FIRM@ Documento di progettazione

giuntamente evoluzioni che interessano diversi ambiti: organizzativo, tecnologico, istituzionale e che si sviluppano inevitabilmente in un orizzonte medio-lungo.

Nella realizzazione di un progetto di e-gov si possono individuare alcuni passaggi “chiave”.

Concezione e progettazione del modello “a tendere”

E’ la fase iniziale in cui il progetto prende forma. Scopo di questa fase è da un lato definire le modalità innovative di erogazione dei servi-zi e il loro contenuto effettivo, e dall’altro di effettuare una macro-valu-tazione di fattibilità (tecnologica, organizzativa, normativa, culturale, infrastrutturale...) e di sostenibilità economica.

Chiude questa fase la progettazione dell’”action plan” per la rea-lizzazione dell’intervento, ossia l’esplicitazione delle tappe fondamen-tali (su un orizzonte inevitabilmente di più anni) di sviluppo in fun-zione tra l’altro dello sviluppo dei necessari presupposti infrastrutturali e/o del comportamento dei soggetti esterni collegati.

Progettazione di dettaglio

Scopo di questa fase è la progettazione effettiva del sistema al-meno nelle sue prime tappe di sviluppo. Si tratta di una progettazione che abbraccia congiuntamente sia gli aspetti organizzativo-gestionali (assetti, processi, procedure, flussi di interscambio, ...) che quelli tec-nologici (hardware e software).

Nella pratica questa fase vede spesso una focalizzazione dell’at-tenzione sugli aspetti tecnologici. Va segnalato tuttavia che, affinché le innovazioni non rimangano in superficie ma incidano profondamen-te nelle modalità della PA di erogare servizi, questo passa attraverso un’inevitabile ridisegno gestionale dei processi rispetto a cui le solu-zioni tecnologiche sono da un lato uno dei presupposti e dall’altro lo strumento che supporta e che quindi viene plasmato su misura rispetto alle esigenze organizzative.

Sviluppo della soluzione tecnologica

Scopo di questa fase è la realizzazione e l’attivazione dei sistemi informativi che consentono l’erogazione dei servizi on-line (primo tra tutti il “portale di interazione” con il cittadino) e il loro collegamento con l’insieme dei sistemi che gestiscono i procedimenti amministrativi.

Punti di attenzione di questa fase sono innanzitutto la capacità di integrare i processi informativi tradizionali presieduti unicamente

20 PROGETTO FIRM@ Documento di progettazione

dal personale dell’ente con l’interazione con il cittadino garantita dal portale, ovvero di acquisire ex-novo soluzioni in grado di supportare i processi laddove non fosse presente una sufficiente automatizzazione.

L’altro aspetto problematico (e che in alcuni casi, come p.es. la gestione dei tributi locali, può avere un impatto molto forte sull’at-tuazione dell’intero progetto) è l’aggiornamento, la pulizia e l’allinea-mento delle banche dati dell’ente coinvolte nell’erogazione del servizio on-line: se qualunque cittadino in ogni momento deve poter conoscere la sua situazione relativamente ad un certo aspetto della sua vita sociale (p.es. la possibilità di iscrivere i figli ad un asilo comunale) il sistema deve basarsi su una banca dati perfettamente aggiornata della situazione.

Attivazione del servizio

E’ questa forse la fase più delicata perché presuppone la gestione contemporanea di diversi aspetti:

• test di funzionamento delle soluzioni tecnologico-gestionali;• formazione degli addetti;• informazione sul territorio;• avvio del servizio in forma “prototipale” e/o circoscritta ad

alcune categorie di utenti;• gestione in parallelo del servizio in modalità tradizionale ed

on-line.La tabella successiva riporta a titolo esemplificativo le attività

principali coinvolte nell’attivazione di un generico progetto di e-gov.

Fasi Sotto-fasi Attività principali

Concezione e progettazione del modello “a tendere”

Analisi-diagnosiAnalisi-diagnosi organizzativa / gestionale e sullo stato delle tecnologia

Definizione modello servizi/modello di organizzazione

Progettazione delle linee guida del modello

Esplicitazione delle macro-alternative tecnico-gestionali

Valutazione di macro-fattibilità

Piano di azione

Valutazione del gap tra situazione attuale e modello a tendere

Valutazione dei presupposti infrastrutturali

Esplicitazione del percorso da compiere

21 PROGETTO FIRM@ Documento di progettazione

Come già detto, lo scopo del presente lavoro non è tanto indivi-duare le soluzioni, quanto piuttosto fornire una mappa il più possibile chiara delle problematiche e degli aspetti che devono essere considerati nella pianificazione e nella gestione di un progetto di e-gov.

La mappatura delle problematiche presentata si articola su due fronti:

• i problemi intrinseci al singolo progetto di e-gov, con questo intendendo gli aspetti, i vincoli e le opportunità la cui defini-zione e soluzione ricade generalmente nell’ambito di influenza dei decisori che governano il singolo progetto

• le problematiche “infrastrutturali” con questo intendendo gli aspetti che devono essere presidiati o le condizioni che de-vono essere assicurate perché il progetto abbia successo, ma che generalmente ricadono al di fuori della sfera di azione dei decisori coinvolti nello sviluppo del singolo progetto.

Progettazionedi dettaglio

Adeguamento organizzativo

Progettare gli aspetti organizzativi e procedurali di massima

Reingegnerizzazione dei processi

Predisporre le linee guida per procedure di funzionamento coerenti con il modello complessivo

Progettazione software (front office e integrazione back office)

Analisi della struttura e tipologia dei dati e degli archivi

Progettazione esecutiva del sw e relativa documentazione

Definizione specifiche di dettaglio delle procedure di estrazione dati

Sviluppo e avvio servizi on line

Sviluppo servizio web e customizzazione

Predisposizione HW e sviluppo SW

Definizione dei test case di componente

Esecuzione dei test di componente

Test e collaudo

Integrazione dei diversi cluster di servizi sulla piattaforma

Test

Collaudo

Impianto e gestione centro di competenza

Acquisizione ed installazione delle attrezzature client per il test ed il supporto allo sviluppo del sw

Fornitura servizi assistenza e supporto ai comuni

22 PROGETTO FIRM@ Documento di progettazione

La distinzione tra aspetti locali ed infrastrutturali è utile nella analisi del contesto in cui si inserisce un progetto di e-gov in vista del-la progettazione di un piano di attuazione coerente con le aspettative p.es. in termini di innovazione dei servizi che il progetto comporta, ma anche con la valutazione concreta della sua fattibilità complessiva.

23 PROGETTO FIRM@ Documento di progettazione

2.1 La razionalizzazione dei processi e il ridisegno organizzativo

L’esplicitazione dei contenuti e delle modalità innovative del ser-vizio da offrire in modalità e-gov sono il primo passo per la definizione dei confini del problema da affrontare.

Le possibilità nei confronti dell’utente sono:• offrire servizi nuovi (aggiuntivi al servizio tradizionale) che pri-

ma non era tecnicamente possibile offrire ovvero non era economicamente possibile offrire;

• cambiare le modalità di erogazione dei servizi tradizionali fa-cilitando l’utente:

• possibilità di gestione del servizio on-line interagendo direttamente con il sistema;

• eliminando gli scambi cartacei e la necessità della presenza fisica allo sportello.

Dal punto di vista dell’Ente la portata dell’innovazione risiede in:• razionalizzazione dei processi: automazione dei flussi e intera-

zione con le basi dati: necessità di integrità, completezza e protezione;

• risparmio di tempo/di risorse.La realizzazione di un progetto di e-gov non può quindi prescin-

dere dal considerare gli impatti che questo ha sul modo di funzionare dell’Ente. E’ abbastanza evidente che perché il progetto possa funzio-nare è necessario introdurre nell’Ente una serie di elementi organiz-zativi “minimali”:

• esplicitazione e razionalizzazione di procedure e processi: l’ero-gazione di un servizio on-line comporta che l’organizzazione dell’Ente sia in grado di funzionare in accordo alle richieste che arrivano al sistema attraverso processi fluidi e integrati. Se questo non avviene l’e-gov rimane un aspetto superficiale:

2. Le problematiche intrinseche del singolo progetto di e-gov

24 L’impatto Economico dei Fondi Strutturali

il sistema accetta richieste via internet che tuttavia vengono erogate in maniera tradizionale. E’ fondamentale quindi procedere ad un ridisegno delle procedure in tal senso. Va notato che in molti casi esistono delle procedure “di fatto”, non formalizzate e poco riproducibili. Il primo passo nell’attivazione del sistema sarà quindi una presa d’atto delle procedure esistenti, prima ancora di una loro ri-progettazione;

• presidio protocollo/sportello telematico e integrazione con i processi tradizionali: l’erogazione di un servizio on-line avviene attraverso l’interazione dell’utente con un portale attraverso cui viene raccolta l’esigenza ed erogato il servizio. Indipendentemente dalle caratteristiche dei processi o dei sistemi informativi di supporto deve essere presidiata l’interazione dell’utente con il portale in modo da garantire la qualità del servizio;

• sviluppo di sistemi informativi dedicati e integrazione banche dati: l’evasione on-line della richiesta dell’utente presuppone infine che il processo possa essere gestito da un sistema informativo (con una supervisione dei punti sensibili) e che siano disponibili basi dati aggiornate ed affidabili. Si pensi ad esempio al problema dei tributi locali: i processi sono complessi ma formalizzabili, sono disponibili molti sistemiinformativi a supporto ma la vera difficoltà degli Enti consiste nell’avere a disposizione basi dati sufficientemente aggiornate e complete da permettere un’interazione diretta dell’utente con i suoi dati tributari senza rischio di danni.

Nella maggior parte dei casi, ad esempio, un sistema di protocol-lo informatico rappresenta il primo passo nell’automazione dei proce-dimenti amministrativi o, più in generale, nel supporto all’informatiz-zazione dei processi o flussi di lavoro (workflow).

Tali flussi possono in alcuni casi essere gestiti attraverso oppor-tuni strumenti informatici (WorkFlow Management Systems) rappre-sentati da prodotti commerciali attualmente diffusi in diversi settori industriali, ed in tutti quei casi (diffusi anche nelle imprese di servizi) dove è possibile individuare le condizioni che permettono a soluzioni di workflow di migliorare la produttività complessiva del sistema. Tali condizioni sono rappresentate dalla stabilità temporale dei processi, dalla complessità dei procedimenti amministrativi e dalla loro numerosità.

Se l’adozione del protocollo informatico spesso rappresenta il pri-mo passo verso l’automazione dell’ufficio, il passo successivo è in gene-

25 PROGETTO FIRM@ Documento di progettazione

re costituito dal supporto concreto alla gestione di flussi documentali generati dal procedimento per il quale il passaggio dal protocollo è solo una delle diverse attività che possono essere svolte.

L’Ente è così chiamato a delineare la relazione tra i sistemi di protocollo e gestione di flussi documentali e il loro possibile sviluppo, identificando una soluzione completa e flessibile in grado di essere ap-plicata nei differenti uffici della Pubblica Amministrazione e di evolve-re a seconda delle necessità.

Appare da subito evidente come queste scelte abbiano delle no-tevoli ricadute organizzative e gestionali, che possono anche essere mi-nime (es. attuazione del solo protocollo informatico e gestione delle pratiche in modo “tradizionale” un volta ricevuti gli input), ma posso-no anche arrivare, con degli interventi di BPR, a ridefinire in tutto o in parte processi, ruoli e procedure.

Oltre a capire le condizioni minime che devono essere garantite il punto importante è la possibilità di incidere significativamente sul modo di funzionare attraverso una rivisitazione “strutturale” dell’orga-nizzazione dell’Ente in funzione dell’erogazione del servizio.

Le alternative di progettazione della macro-struttura inoltre sono legate alla responsabilità e alle modalità di coordinamento per quanto riguarda l’attività interna:

• modello “tradizionale”: lo sportello di interfaccia interagisce con gli altri uffici dell’Ente in modo del tutto analogo a come si comporta con gli altri (p.es. secondo un regolamento che definisce le modalità di interazione); non intervengono variazioni sostanziali rispetto al modello organizzativo preesistente;

• modello “evoluto”: l’organizzazione dell’Ente viene rivista in chiave di servizio al cittadino e organizzata per processi. In questo senso lo sportello coordina direttamente l’attività degli uffici coinvolti nei procedimenti autorizzatori (definendone di volta in volta priorità, tempi e modi a seconda delle esigenze e del livello di servizio).

Il modello “evoluto” comporta:• una riorganizzazione per processi (in una logica cliente-forni-

tore) di tutta la parte dell’Ente interessata all’erogazione di servizi di e-gov (alle imprese ma anche ai cittadini);

• lo sviluppo di un sistema informativo “on-line” a supporto dell’erogazione dei servizi che faciliti:- l’interazione con l’utente;

26 PROGETTO FIRM@ Documento di progettazione

- il fluire del processo autorizzatorio;- l’interazione con gli altri attori coinvolti;

• un cambiamento culturale forte e pervasivo (diffuso).

Tipologia Caratteristiche principaliRuolo dello sportello e-gov nei confronti della struttura

tradizionale

• struttura funzionale

• meccanismi di coordinamento

tra uffici

• sportello e-gov “coordina chi

eroga”

• sportello e-gov inserito in una

Funzione

• interagisce con gli utenti

• coordina lo scambio di infor

mazioni e documenti tra uffici

ed enti

• ha funzioni di expediting

orientata al cliente

• struttura per processi secondo

un modello “cliente-fornitore”

• sportello e-gov “è chi eroga”

• sportello e-gov inserito in

una struttura complessiva di

front-office

• si supera la competenza “set

toriale” dell’Ente, a favore di una

competenza “tematica” ritaglia

ta sui bisogni dell’utente

• interagisce con gli utenti

• governa i processi programman-

do l’attività delle risorse

• ha funzioni di expediting

Queste scelte in molti casi riescono a fare la differenza tra progetti di e-government “ambiziosi”, che si pongono l’obiettivo di (e a volte rappresentano l’occasione per) rivedere regole strutturate di funzio-namento, e progetti di e-government che semplicemente permettono l’utilizzo di strumenti di interazione evoluta, ma “realizzano” poi i ser-vizi secondo procedure consolidate.

2.2 La gestione dell’interazione con l’utente

2.2.1 L’identificazione dell’utente

L’erogazione on-line di un qualunque servizio pubblico ha come presupposto la possibilità per l’Ente di riconoscere inequivocabilmente l’identità dei soggetti che fruiscono dei servizi attraverso i portali te-lematici. L’identificazione dell’utente rappresenta quindi un elemento estremamente delicato e critico nel processo di erogazione di un servi-zio on line.

In particolare l’interazione da parte dell’Ente con un soggetto che accede ad un servizio on line comporta:

27 PROGETTO FIRM@ Documento di progettazione

• l’accesso al sistema tramite un portale web attraverso cui l‘utente possa fornire la sua identità (p.es. mediante l’inseri-mento di username e password, ovvero mediante l’inserimen-to di una tessera magnetica) al sistema;

• l’attivazione di un sistema di riconoscimento e decodifica di codici di accesso inseriti dall’utente e in grado di collegarli al dossier che raccoglie le informazioni legate all’utente;

• la costruzione e l’aggiornamento del dossier del soggetto che accede ai servizi, completo dei dati già in possesso dell’ammi-nistrazione, più alcuni dati aggiuntivi inseriti direttamente dall’utente;

• il fatto che ci sia stato un riconoscimento certo da parte di un’autorità preposta dell’utente al momento in cui richiede per la prima volta l’accesso ai servizi on line;

• la garanzia della sicurezza dei dati immessi e del rispetto della privacy.

L’identificazione dell’utente di un servizio on-line può avvenire attraverso soluzioni differenti che hanno ricadute diverse in termini di impatto sull’attivazione del servizio (tecnologico ed economico), po-tenzialità di servizi principali ed accessori erogabili, tipologia di intera-zione possibile da parte dell’utente.

L’impatto sull’attivazione del servizio on-line può essere ricondot-to ai seguenti aspetti che devono in qualche modo essere presidiati:

• creazione iniziale del profilo utente per quel particolare servizio, a fronte di un riconoscimento certo dell’utente (primo ac-cesso e apertura profilo);

• gestione in sicurezza di tutte le transazioni successive riconoscendo univocamente gli utenti registrati (accessi successivi);

• verifica periodica, attraverso un’attività di auditing, della va-lidità dei presupposti di accesso, ossia che non ci siano disallineamenti tra lo strumento di identificazione e il soggetto che lo utilizza (es. furti di password, smarrimento di tessere, ecc.).

Tra i molteplici strumenti di identificazione in questa sede è op-portuno distinguere tra le seguenti alternative:

• sistemi basati sulla coppia username e password: l’attiva-zione al servizio avviene solitamente attraverso registrazione spontanea dell’utente e rilascio delle chiavi di accesso da parte del sistema. Richiede il minor investimento a livello infrastrut-

28 PROGETTO FIRM@ Documento di progettazione

turale ma ha anche una portata limitata genericamente al sin-golo sistema/servizio;

• sistemi basati sul rilascio di tessere di riconoscimento (ma-gnetiche, con codice a barre o con microchip) dedicate a quella famiglia di servizi: la concessione della tessera è solitamente l’occasione dell’identificazione certa dell’utente da parte del gestore del servizio, sono necessari lettori dedicati ma i problemi infrastrutturali da affrontare sono più limitati del caso suc-cessivo. Questa soluzione consente generalmente di utilizzare la tessera oltre che come mero strumento di riconoscimento anche come supporto per la memorizzazione di informazioni utili all’erogazione di servizi specifici (p.es. la storia clinica del paziente sulla tessera sanitaria);

• sistemi basati sull’utilizzo di tessere di riconoscimento (ma-gnetiche, con codice a barre o con microchip) a rilevanza generale (p.es. regionale o nazionale): il vantaggio indubbio di questa soluzione è da un lato che il gestore del servizio non deve preoccuparsi né dell’identificazione certa dell’utente né della validità del supporto perché questi aspetti sono garantiti da un certificatore a monte e dall’altro che il sistema consente l’identificazione del soggetto in quanto “cittadino” (codice fi-scale) e quindi ha potenzialmente una valenza universale per tutti i servizi legati alla persona. Gli svantaggi sono legati es-senzialmente a difficoltà e vincoli infrastrutturali.

Per quanto riguarda il tipo di interazione consentita è evidente che i sistemi basati su username e password sono molto indicati per quei servizi che vengono erogati essenzialmente attraverso un’intera-zione diretta del cittadino con un portale telematico: non richiedendo lettori dedicati, possono essere utilizzati comodamente ovunque e sono attivabili con costi contenuti. Gli svantaggi sono ovviamente una mi-nore sicurezza, un campo di utilizzo limitato a quel servizio e un costo maggiore per l’eventuale identificazione certa in sede di rilascio iniziale e per la verifica della validità.Per contro i sistemi basati su tessera di riconoscimento sono adatti a servizi che richiedono un’interazione del soggetto con operatori di-versi e diffusi sul territorio (p.es. nel caso dei servizi sanitari la tessera di riconoscimento con memorizzazione dei dati del paziente consente l’interazione con farmacisti, medici di base, ...).

29 PROGETTO FIRM@ Documento di progettazione

2.2.2 Lo scambio di informazioni “firmate”

La gestione di un servizio on-line generalmente richiede che pos-sa avvenire tra utente ed Ente lo scambio di informazioni “firmate”, os-sia di informazioni o dichiarazione di cui si possa attestare l’autenticità e la provenienza ai fini della validità legale del servizio erogato.

Gli aspetti che vanno presidiati sono:• la produzione dell’informazione e la sua firma;• la sua eventuale cifratura;• la trasmissione e la ricezione.Per quanto riguarda il primo aspetto è opportuno distinguere

due situazioni paradigmatiche a seconda che l’interazione tra utente ed ente consista:

a) essenzialmente nello scambio on-line di un documento prodotto dall’utentequesta procedura, che va ripetuta tante volte quanti sono i documenti da firmare, prevede la digitazione del PIN una vol-ta individuato il documento da firmare, e previo inserimento della smart card nell’apposito lettore. In nessun modo avviene una trasmissione automatica di questo documento, che andrà trasmesso al destinatario utilizzando l’e-mail (per l’im-piego di posta certificata si veda il relativo paragrafo).Ciò che viene garantito in questo caso dall’impiego di un cer-tificato di firma digitale è la certezza del contenuto, non l’av-venuta trasmissione e/o ricezione;

b) nella gestione di un processo articolato, supportato da un oppor-tuno sistema informativo di workflow che preveda la generazione e la firma di più documenti impiegando procedure automaticheQuando la mole di documenti da firmare lo richiede è consentito l’utilizzo di procedure automatiche, nel corso delle quali sostanzialmente avviene una sola volta l’operazione fisica di sottoscrizione a fronte di più documenti.In particolare, è necessario che quando il titolare appone la sua firma mediante una procedura automatica utilizzi una coppia di chiavi diversa da tutte le altre in suo possesso.

Nel secondo caso si propone la seguente problematica: da un lato il sistema informativo che gestisce il processo e che genera i documenti da scambiare con l’utente ha la necessità di gestire un proprio criterio di codifica dei documenti scambiati e delle informazioni in questi con-tenute, in modo da saperli riconoscere e poterli gestire correttamente

30 PROGETTO FIRM@ Documento di progettazione

lungo tutto il procedimento. Dall’altro, per poter certificare l’auten-ticità e la correttezza dei singoli scambi il sistema informativo deve interagire – e quindi creare e scambiare documenti compatibili – con le autorità di certificazione che attestano la validità e la provenienza dei documenti e con il protocollo informatico che attesta la ricezione degli stessi e questo comporta inevitabilmente delle limitazioni nelle possibilità di codifica dei documenti in funzione del riconoscimento automatico ai fini della gestione del procedimento.

Per quanto riguarda il tipo di firma da adottare si pongono le se-guenti alternative: firma “debole” quando il supporto non ha validità generale e l’autenticità della firma è garantita esclusivamente dall’ente che emette il certificato per fini propri; firma “forte” quando si utilizza la firma digitale la cui autenticità e rilascio sono garantite dagli enti certificatori indipendenti.

I documenti firmati possono essere suddivisi in tre sottocategorie:• Documento in chiaro con firma digitale;• Documento cifrato con firma digitale;• Documento cifrato con firma digitale e validazione temporale.Le caratteristiche delle tre tipologie di documenti sopra citate

sono riportate nella tabella seguente.

Tipi di documenti firmati digitalmente:

in chiaro cifrato cifrato con validazione

temporale

Azioni del mittente

Appone la propria firma digitale a un documento in chiaro, ovvero lo cifra con la propria chiave priva-ta, e lo spedisce

Cifra il testo del documento con la chiave pubblica del destinatario prelevata dall’archivio della CA e vi appone la propria firma digitale (ovvero cripta ancora il testo con la propria chiave privata)

Cifra il testo del docu-mento con la chiave pubblica del desti-natario, vi appone la firma digitale e lo spedisce all’autorità per la validazione temporale

Azioni dei soggetti certificatori

Certifica l’identità del possessore di una coppia di chiavi; registra e pubblica la chiave pubblica

Certifica, conserva e pubblica le chiavi identificando il pos-sessore

La TSA appone il timestamping, cioè stabilisce la data di ri-lascio del documen-to e, dunque, la sua validità temporale

31 PROGETTO FIRM@ Documento di progettazione

2.2.3 La gestione documentale: scambi e archiviazione

L’erogazione di servizi da parte della PA, è basata necessariamente sulla forte interazione con l’utenza e con altri Enti.

Si pensi ad esempio al rilascio di una autorizzazione: il processo “standard” prevede almeno il deposito di una domanda da parte del cittadino interessato e in molti casi una serie di interazioni dell’ente che rilascia l’autorizzazione con altri attori pubblici e/o privati (es. tri-bunale, ASL, Questura, ecc.).

Tutti questi passaggi intermedi comportano la produzione e la gestione di documenti che hanno generalmente rilevanza giuridica, e lo scambio degli stessi a diversi livelli istituzionali. Ciò comporta la ne-cessità di una continua e celere identificazione univoca della “pratica”, sia da parte del cittadino che dell’Amministrazione, al fine di valutarne e presidiarne lo stato di avanzamento.

La gestione di un servizio on-line presuppone che questo flusso sia automatizzato e gestito attraverso un sistema di workflow ad hoc e che i documenti oggetto dello scambio siano possibilmente digitali.

L’eliminazione della carta nella gestione delle procedure ammini-strative è un passaggio che offre molte opportunità (facilità di indivi-duazione e tracciabilità dei documenti, possibilità di automatizzazione del flusso, risparmio di spazio fisico nell’archiviazione, ...) ma pone anche una serie di problemi: disponibilità di tecnologie e di competen-ze specifiche, affidabilità dei sistemi informatici di gestione, soluzione di problematiche infrastrutturali, presidio dell’evoluzione tecnologica

Azioni del destinatario

Riceve il docu-mento, preleva la chiave pubblica del mittente dalla CA e decifra il messaggio rilevando l’identità del mittente

Decifra il testo rice-vuto con la propria chiave privata e verifica l’identità del mittente prelevan-do la sua chiave pubblica (associata al certificato di identità digitale) dalla CA

Decifra il testo con la propria chiave priva-ta, verifica l’identità del mittente, prende atto della validità temporale del docu-mento

Condizioni

Mittente e destinata-rio sono collegati via Internet o Intranet; le procedure di registrazione e certi-ficazione sono rigo-rose; la segretezza della chiave privata è garantita

Mittente e destinata-rio sono collegati via Internet o Intranet; le procedure di registra-zione e certificazione sono rigorose; la se-gretezza della chiave privata è garantita

Mittente e destinata-rio sono collegati via Internet o Intranet; le procedure di registra-zione e certificazione sono rigorose; la se-gretezza della chiave privata è garantita

32 PROGETTO FIRM@ Documento di progettazione

e conseguente aggiornamento dei supporti.Il documento informatico deve preservare tutte le caratteristi-

che funzionali attribuite al documento cartaceo, proprio per questo motivo è necessario predisporre un sistema di produzione, distribuzio-ne e conservazione del documento informatico.Relativamente al documento informatico vi sono alcuni concetti-chia-ve di cui è indispensabile tenere conto:

• l’immodificabilità: che può essere garantita via software attraverso il salvataggio del documento in modalità non più modificabile ovvero protetto da password, oppure tramite l’ap-posizione della firma digitale;

• la conservabilità: questa viene assicurata attraverso la periodi-ca duplicazione dei documenti su supporti nuovi al fine di prevenire il deperimento degli stessi e il periodico aggiorna-mento del formato di codifica e/o del supporto in funzione dell’evoluzione tecnologica degli strumenti hardware e softwa-re di riproduzione;

• l’autenticità: tale proprietà viene assicurata al documento in-formatico attraverso la firma digitale che consente di stabilire se un documento è stato emesso da un determinato soggetto;

• il non ripudio: anche tale proprietà viene garantita dalla fir-ma digitale e consiste nel fatto che il documento non può essere disconosciuto da chi lo ha emesso (salvo querela di falso).

Anche relativamente al flusso documentale vi sono alcuni con-cetti-chiave che è necessario prendere in considerazione:

Gestione automatizzata del flusso dei documenti e protocollo informatico: per realizzarla è necessaria un’infrastruttura applicativa su cui incentrare i sistemi di gestione documentale integrati con il pro-tocollo, i sistemi di pianificazione e controllo, i sistemi di workflow per la gestione dell’iter procedurale. Le funzionalità prevedono l’acqui-sizione dei documenti da supporti informatici e l’integrazione con le e-mail (utilizzando lo standard XML, la classificazione e fascicolazione in base al titolario di archivio, la certificazione dei documenti). La nor-mativa stabilisce che ogni amministrazione deve individuare al proprio interno un insieme di “Aree organizzative omogenee” (AOO) e per ciascuna di esse deve dotarsi di un sistema di protocollo informatico che realizzi alcune funzionalità di base (nucleo minimo). Le funzio-nalità che realizzano il nucleo minimo del sistema di protocollo sono quelle che permettono di fornire il servizio di certificazione. Il nucleo

33 PROGETTO FIRM@ Documento di progettazione

minimo prevede anche l’adozione di un titolario di classificazione per permettere all’amministrazione di archiviare i documenti protocollati a seconda dell’argomento di riferimento. In tal modo, oltre a favorire la ricerca dei documenti protocollati grazie all’uso di parole chiave, si pongono le basi per una eventuale gestione dell’intero patrimonio documentale dell’amministrazione.

Registrazione di protocollo: è l’operazione con la quale si me-morizzano le informazioni principali relative al documento nel registro di protocollo, corrisponde alla assunzione di responsabilità da parte dell’amministrazione e in particolar modo serve a certificare l’esistenza del documento a partire da una certa data. Questo significa:

• nel caso di documenti ricevuti, l’amministrazione non può ne-gare, a fronte della richiesta di esibizione del contenuto di una registrazione, che un documento sia esistito. Inoltre essa certi-fica il fatto che il documento è entrato nell’ambito dell’ammi-nistrazione e dei processi amministrativi di quest’ultima che lo riguardano;

• nel caso di documenti prodotti dall’amministrazione, la stessa può avvalersi dello strumento protocollo informatico per fini probatori (ad esempio per dimostrare a terzi che un proprio documento è stato prodotto o che ha ottenuto un valore uffi-ciale prima di una certa data).

2.3 Il problema della sicurezza delle transazioni

Il tema della sicurezza ha sempre rivestito un importante ruolo nella gestione di qualunque sistema informatico.

Nel nostro caso, senza trascurare i temi della sicurezza intrinseca dei dati gestiti (protezione dal rischio di perdita delle informazioni a causa di rotture o malfunzionamenti dei sistemi informatici), il tema della sicurezza si focalizza inevitabilmente sulla protezione delle tran-sazioni gestite.

Gli aspetti più rilevanti da presidiare in un progetto di e-gov sono quindi la gestione sicura di:

• accessi da parte degli utenti: il sistema deve permettere l’acces-so ai soli utenti riconosciuti come validi e deve essere in grado di non far commettere danni e di tenere traccia di quello che succede;

• transazioni di informazioni riservate e più specificamente di pagamento;

• tutela della privacy.

34 PROGETTO FIRM@ Documento di progettazione

2.3.1 La sicurezza degli accessi

Con la diffusione dei computer e delle reti locali vissuta negli anni ‘ ed ‘ diventa rilevante la gestione di accessi sicuri ai sistemi connessi in rete.

E’ proprio in questi anni che vengono alla ribalta i problemi cor-relati all’accesso non autorizzato, se non addirittura fraudolento, ad importanti basi dati anche di organizzazioni governative e militari.

Dunque al problema della salvaguardia dell’informazione contro eventi imprevisti si affianca la necessità di vigilare sull’identità del per-sonale che accede ai sistemi e sulla costruzione di infrastrutture logiche di sicurezza che consentano la strutturazione di veri e propri livelli di accesso collegati alla precedente operazione di riconoscimento. Tutto ciò viene spesso sintetizzato con l’acronimo A.A.A. (Access Authoriza-tion Accounting), ovvero Accesso Autorizzazione e Registrazione. Con ciò si intende che l’utilizzo di un sistema informatico può avvenire solo se vengono soddisfatti questi 3 prerequisiti:

1. Access: un processo che consenta di vigilare sulla provenienza della richiesta di utilizzo del sistema informatico;

2. Authorization: una procedura che consenta di gestire il sopra- citato “livello di accesso” ovvero il problema di “cosa” deve essere disponibile all’utente;

3. Accounting: una serie di log e procedure che consentano di“tracciare” l’operato dell’utente una volta che esso abbia passa-to le prime due fasi di verifica.

I problemi più immediati che si devono fronteggiare sono colle-gati alla possibilità che un operatore non autorizzato acceda al sistema informativo attraverso l’utilizzo di credenziali altrui o addirittura senza nemmeno possedere alcuna credenziale al sistema.

In fondo non si tratta che di riproporre in ambito allargato le soluzioni escogitate per il medesimo problema nel caso di computer singoli.Altro problema poi è l’esistenza delle remote vulnerabilities: vulnerabi-lità remote, che permettono cioè ad un operatore via rete di accedere in modo non autorizzato alle risorse del sistema informatico.

Le soluzioni per questo tipo di problemi si diluiscono su più at-tività di cui citiamo:

1. installazione di firewall per limitare le metodologie di accesso;2. installazione di sistemi IDS (Intrusion Detection System) per

l’immediato rilevamento di tentativi di intrusione;

35 PROGETTO FIRM@ Documento di progettazione

3. manutenzione evolutiva dei sistemi.Come ultima tematica rilevante citiamo la necessità di proteggere

i dati che transitano su una rete da tentativi di intercettazione o copia dei medesimi da parte di soggetti terzi.

La risposta tecnologica più frequente risiede nell’adozione di metodi di cifratura più o meno complessi dei dati in transito; il re-cente interesse globale per le reti VPN (Virtual Private Network) e le tecnologie collegate alla cifratura secondo lo standard SSL/TLS sono l’evidente sintomo di quanto questo problema non possa più essere considerato secondario.

Un elemento importante per una strategia di protezione globale è la corretta identificazione della persona che effettua una qualunque transazione.

I sistemi d’accesso basati su autenticazione si fondano attualmen-te su tre classi di verifica:

1. Secret based: basata sulla conoscenza di un segreto (una pas-sword, una chiave privata, ecc...);

2. Token based: basata sul possesso di un oggetto unico, non riproducibile e che non può essere manomesso (smartcard crittografiche, token usb, ecc...);

3. Biometrico: basata su una caratteristica individuale specifica e unica (firma autografa, impronte digitali, pattern dell’iride e della retina, impronta vocale, forma del palmo della mano, caratteristiche del viso, dinamica di digitazione su tastiera, ecc...).

In particolare le tecniche biometriche, nate inizialmente in am-bienti dove il problema dell’identificazione certa della persona assume carattere critico, quali quelli militari o comunque legati alla Difesa, si stanno progressivamente espandendo anche all’ambito dell’industria privata e della PA; ciò al fine di controllare gli accessi ad applicazioni informatiche critiche ed a dati sensibili da parte del personale dipen-dente o dei fruitori dei servizi erogati on-line.

2.3.2 Gestione delle transazioni economiche

Il pagamento on line di un tributo può avvenire attraverso mo-dalità diverse:

• attraverso l’utilizzo di carta di credito direttamente dal porta-le dell’Ente;

36 PROGETTO FIRM@ Documento di progettazione

• attraverso i servizi di home banking messi a disposizione dalle banche;

• attraverso il servizio messo a disposizione dalle Poste italiane;• ecc.La modalità di pagamento con carte di credito è quella più fre-

quentemente utilizzata su Internet. L’utente esegue il pagamento di un servizio (in questo caso di un servizio di Fiscalità Locale) inserendo in un apposito spazio i dati della propria carta di credito.

Questo tipo di pagamento è basato sul concetto di credito e que-sto perché una banca “acquirer” garantisce il credito per una persona, o per una azienda, nei confronti del circuito emittente la carta, fino ad una certa cifra giornaliera o mensile. In questo modo, nel momento in cui il portatore della carta effettua un pagamento non viene controllata la sua reale disponibilità, il suo conto in banca. Il creditore (nel nostro caso tipicamente la Tesoreria dell’Ente) può quindi immediatamente essere accreditato del valore dell’operazione, anche se in quel momento l’utente non ne ha sufficiente disponibilità.

Dal punto di vista tecnico esistono due modalità mediante le quali è possibile fornire il servizio di pagamento con carta di credito nei confronti di un Ente:

• Pagamento diretto sul sito dell’Ente (payment gateway inter-no all’Ente);

• Ridirezione dell’utente dal Portale al sito di una banca che, ad esempio, potrebbe essere proprio la banca che gestisce la Tesore-ria dell’Ente (payment gateway esterno all’Ente).La differenza sostanziale tra la prima e la seconda ipotesi si ri-

scontra non tanto rispetto al servizio percepito dall’utente, che sostan-zialmente resta lo stesso, quanto dal punto di vista dell’Ente che, nella seconda ipotesi viene sollevato dall’onere di dover acquisire e gestire il payment gateway ed anche dalla responsabilità della gestione sicura dei dati delle carte di credito, che è a totale carico della banca reindirizzata per il pagamento.

Il pagamento attraverso l’utilizzo dei servizi di home banking messi a disposizione dalle banche è un processo che si realizza esterna-mente al portale dell’Ente e coinvolge l’utente, la banca a cui si appog-gia e la Tesoreria quale destinatario del pagamento. Lo stesso vale per il pagamento attraverso il servizio di Poste Italiane.

La sicurezza della transazione di pagamento rappresenta di fatto l’elemento più delicato dell’intero processo e può essere considerata

37 PROGETTO FIRM@ Documento di progettazione

sia dal punto di vista di chi offre il proprio servizio a pagamento, sia dal punto di vista di chi utilizza la propria carta di credito on line per l’esecuzione del pagamento.

Dal momento in cui si decide di effettuare un acquisto utiliz-zando una carta di credito, la transazione è gestita da una complessa sequenza di procedure e strutture. In breve, le figure chiave sono:

• le associazioni o circuiti a cui fanno capo le carte di credito; • le società emittenti, ovvero le banche; • i venditori e gli acquirenti. Gli acquirenti sono rappresentati

dalle società di servizi finanziari che trattano la transazione nell’interesse dei venditori. Alcuni grandi venditori gestiscono il passaggio internamente, ma la maggior parte delega a terzi, che possono anche fornire servizi di hosting.

La domanda di quale sia la parte che si accolla il costo in caso di fro-de on line è complessa. Nella maggior parte dei casi il titolare della carta di credito è responsabile per l’uso di una carta rubata, ma la sua responsabilità si ferma a un limite piuttosto basso. In tal modo le socie-tà emittenti coprono gran parte dei costi, compresa l’istruttoria della transazione contestata. I costi possono diventare molto più alti se la controversia non si risolve rapidamente.

Se fosse possibile autenticare i titolari di carta di credito prima di un acquisto con un ragionevole livello di certezza, si potrebbe ridurre la probabilità di utilizzo di una carta rubata. Ne gioverebbero diretta-mente venditori e banche, ma allo stesso modo, seppur indirettamente, anche i titolari delle carte. Una procedura che dimostri la propria iden-tità darebbe un maggior senso di sicurezza, così da incoraggiare i pos-sessori di carta di credito ad effettuare tranquillamente acquisti on line.

Per garantire la sicurezza dei dati immessi, soprattutto del nu-mero di carta di credito, possono essere utilizzati sistemi senza o con crittografia:

• Sistemi senza crittografia: non usare crittografia significa af-fidarsi alla sicurezza “fuori banda”: per esempio i beni ordinati elettronicamente non saranno consegnati prima che il compratore spedisca un fax (o una lettera, o una chiamata telefonica) a conferma dell’ordine. Esempi di questo tipo di sistemi sono Compuserve, First Virtual e Internet Shopping Network. In Compuserve ogni cliente, per comunicare, usa una linea che ritiene sicura e si identifica col sistema. Sia in First Virtual che in Internet Shopping Network il compratore ha un

38 PROGETTO FIRM@ Documento di progettazione

conto con il sistema e riceve una password in cambio del nu-mero di carta di credito. La password non è protetta mentre viaggia su Internet e dunque è vulnerabile agli attacchi di chi “origlia” (eavesdropper). First Virtual fornisce una certa forma di protezione chiedendo conferma al compratore di ogni pa-gamento tramite e-mail, ma l’attuale forma di sicurezza si basa sul fatto che il compratore può revocare l’acquisto entro un certo periodo di tempo e fino ad allora il venditore si assume la totalità del rischio.

• Crittografia a chiave condivisa: per tale tipo di crittografia, il compratore e il venditore da un lato e le parti che forniscono autenticazione e autorizzazione dall’altro hanno bisogno di un segreto condiviso (per esempio una chiave DES o almeno una password o un PIN). È quindi chiaro che tale tipo di codifica non consente di risolvere casi di pagamenti contestati. Per questo motivo la crittografia a chiave condivisa non è con-sigliata per pagamenti oltre un certo valore.

• Crittografia a chiave pubblica: il compratore ha una chiave segreta per la firma, e un certificato per la corrispondente chiave pubblica per la verifica della firma (certificato rilasciato, per esempio, da una specifica autorità). Tale tipo di crittografia consente di risolvere qualsiasi contesa tra mittente e destinatario. In questo caso l’autenticazione off-line non comporta alcun problema, dal momento che il venditore può facilmen-te verificare la firma del compratore (e può confrontare il cer-tificato del compratore con una propria “lista nera” di certifi-cati, se necessario). L’autorizzazione richiede comunque o una connessione in linea o la presenza di hardware affidabile pres-so il compratore.

Con riguardo alle transazioni economiche tra Pubbliche Ammi-nistrazioni ed utenti merita di essere segnalato il progetto volto a far sì che la Carta Nazionale dei Servizi-CNS non sia soltanto una chiave personale di accesso on-line alla P.A. ma anche strumento sicuro per i pagamenti telematici di tasse, prestazioni e servizi erogati dagli uffici pubblici, rendendo così più agevoli e comodi i rapporti che imprese e cittadini intrattengono con la Pubblica ammini-strazione. Grazie all’accordo siglato il giugno tra il CNIPA e l’e-Commit-tee (Comitato di coordinamento delle infrastrutture per l’e-banking) dell’ABI (Associazione Bancaria Italiana), si sono poste le basi per l’in-serimento della Pubblica Amministrazione nel sistema “Bankpass Web”

39 PROGETTO FIRM@ Documento di progettazione

consentendo così ai cittadini-utenti di farsi riconoscere e di richiedere servizi on line alla Pubblica Amministrazione e, al tempo stesso, auto-rizzare eventuali pagamenti.Tale sistema è stato sperimentato a Bologna e a Verona e si intende estenderlo progressivamente a tutto il territorio nazionale. BANKPASS Web è un servizio che offre ai consumatori una soluzio-ne per effettuare transazioni sicure su Internet tramite l’integrazione di diversi strumenti di pagamento in un unico “portafoglio virtuale” (wallet).

Tale wallet virtuale può contenere carte di credito bancarie, carte di debito PagoBancomat, carte ricaricabili, ecc..

Il servizio consente agli utilizzatori di effettuare pagamenti su Internet senza mai inserire i dati sensibili delle proprie carte di pa-gamento. Il pagamento viene infatti avviato tramite l’utilizzo di una coppia di chiavi di sicurezza (User ID e Password) che vengono asse-gnate al momento della sottoscrizione del contratto presso una banca distributrice.

Il cittadino, nel caso in cui debba acquistare servizi erogati da una Pubblica Amministrazione, accede al sito Internet della stessa e richiede di usufruire di un servizio a pagamento inserendo la propria CNS in un apposito lettore per identificarsi.

Al momento del pagamento il sistema riconoscerà il cittadino/titolare del wallet Bankpass Web e aprirà automaticamente il portafo-glio virtuale consentendo al consumatore di scegliere lo strumento di pagamento con cui desidera concludere la transazione senza chiedergli di autenticarsi con user id e password.

Questa modalità di riconoscimento per il momento è valida so-lamente per i servizi offerti dalla Pubblica Amministrazione per cui è richiesta l’identificazione del cittadino tramite CNS e solo se al wallet Bankpass è stata precedentemente associata la CNS del titolare del wallet.

E’ da rilevare il fatto che la piattaforma tecnologica realizzata da e-Committee è condivisa ed utilizzata dalla maggior parte delle ban-che presenti nelle aree interessate dai progetti di e-Government e può essere gestito da più società, nel rispetto del Regolamento di Bankpass Web, definito dalla stesso e-Committee.

2.3.3 Tutela della privacy

Un ambito sempre più rilevante del tema della sicurezza dei dati e della loro protezione dalle eventuali intrusioni di agenti esterni, è rappresentato ultimamente dalla questione legata alla privacy.

40 PROGETTO FIRM@ Documento di progettazione

Sotto questa etichetta stanno una serie di regole, norme, azioni e stru-menti, ai quali ogni organizzazione (e per certi versi ogni singolo cit-tadino) deve far ricorso al fine di assicurare l’effettiva protezione, se-condo degli standard condivisi, di tutta una serie di dati personali e aziendali.

In estrema sintesi ogni organizzazione e ogni individuo che nel-l’esercizio delle proprie funzioni si trovi a gestire, memorizzare e/o scambiare dati personali riguardanti membri della propria organiz-zazione e terzi, deve garantire che gli stessi vengano detenuti presso sistemi di archiviazione protetti da intrusioni esterne, ma soprattutto deve dichiarare ex-ante l’approccio seguito nell’archiviazione e gestione degli stessi dati.

Le Pubbliche Amministrazioni che agiscono perseguendo finalità istituzionali (come è l’erogazione di pubblici servizi anche attraverso modalità e strumenti innovativi) non sono tenute a chiedere esplicita autorizzazione ai proprietari degli stessi dati.

La normativa di riferimento, recentemente innovata, fa esplicito riferimento ai dati conservati su supporto informatizzato e/o gestiti avvalendosi dell’uso di calcolatori.

In tal senso ogni individuo che interagisca con il flusso di dati di questa natura, provvedendo all’archiviazione, alla conservazione o all’aggiornamento, deve essere esplicitamente incaricato dall’azienda, che parimenti è obbligata a nominare un responsabile del trattamento dei dati, il quale risponde in solido con gli amministratori/rappresen-tanti legali nei confronti dei terzi per eventuali casi di danno causato a terzi dalla gestione non idonea dei dati.

Tutto questo insieme di regole e procedure è ulteriormente aggra-vato nel caso ci si trovi di fronte alla gestione di dati così detti sensibili (riguardanti nello specifico dati di natura legale, medica ecc.). In tutti questi casi occorre una ulteriore esplicita dichiarazione delle modalità secondo le quali avviene il trattamento dei dati e un incarico specifico agli addetti al trattamento.In sintesi riguardo a questo aspetto appare necessario esplicitare quanto segue: “I dati sensibili e giudiziari contenuti in elenchi, registri o ban-che di dati, tenuti con l’ausilio di strumenti elettronici, sono trattati con tecniche di cifratura o mediante l’utilizzo di codici identificativi o di altre soluzioni che, considerato il numero e la natura dei dati trattati, li rendono temporaneamente inintelligibili anche a chi è autorizzato ad accedervi e permettono di identificare gli interessati solo in caso di necessità” (fonte: dlgs /).

41 PROGETTO FIRM@ Documento di progettazione

Quanto finora esposto comporta una serie di azioni specifiche da porre in essere a cura dell’Amministrazione nel caso la stessa si trovi a gestire, nell’ambito di un progetto di e-government, dei dati di natura personale. Ciò comporta ovviamente la necessità di tenere conto di queste problematiche in sede di progettazione preventiva, e ha delle ricadute sulle successive fasi di attuazione del progetto e di erogazione dei servizi.

Queste ricadute sono così sintetizzabili:• nella necessità di proteggere adeguatamente i dati personali ed

eventualmente sensibili da intrusioni esterne (la protezione da deterioramento dei supporti informatici e/o da agenti che possano causare la perdita parziale o totale di dati non è stret-tamente rilevante in questo caso), che possano comportare la sottrazione e/o la cessione a terzi dei dati gestiti (eventi che l’amministrazione si impegna a scongiurare, e rispetto ai quali si assume preventivamente la responsabilità);

• di predisporre meccanismi di archiviazione e codifica dei dati sensibili idonei a non renderli immediatamente leggibili an-che agli operatori autorizzati, se non in caso di necessità;

• di regolare lo scambio di dati con altre Pubbliche Amministrazioni, verificando che lo stesso avvenga solo se esplicitamente richiesto dalla normativa vigente;

• nella necessità di essere in grado in ogni momento di dimostrare:- che il trattamento dei dati avviene a cura di personale incari

cato e nelle modalità consone;- le singole responsabilità, anche individuali, in caso di eventi

come quelli appena descritti.Tutto ciò comporta la necessità pratica di dotarsi di strumenti in grado di tracciare gli eventi eseguiti sulla base di dati, e di attribuire ad ogni azione una responsabilità.

Tale risultato è ottenibile pensando e realizzando:• strumenti che consentano accessi controllati (attraverso log in)

al sistema di gestione dei dati e che siano in grado di monito-rare e registrare le sessioni di lavoro;

• sistemi evoluti e regole precise di archiviazione e lettura dei dati stessi.

42 PROGETTO FIRM@ Documento di progettazione

3.1 La tecnologia del certificato digitale

3.1.1 Concetti generali

Come anticipato, la tecnologia legata ai certificati digitali rende, di fatto, possibile, sia la sicurezza delle comunicazioni via Internet che l’autenticazione di documenti elettronici tramite firma digitale. Si in-tende, qui, approfondire le modalità del loro utilizzo e i meccanismi alla base del loro funzionamento.

Un certificato digitale è un file che può essere paragonato ad un passaporto, o ad una carta di identità, cioè ad un documento di rico-noscimento rilasciato da un’Autorità di Certificazione (CA nel seguito) universalmente nota, accettata e riconosciuta come affidabile, e utiliz-zata per autenticare l’identità di un soggetto. Le CA svolgono, cioè, il ruolo di garanti dell’identità di chi usa il certificato da loro rilasciato. Hanno anche il compito di mantenere un pubblico registro dei certi-ficati emessi e una Lista dei Certificati Revocati (Certification Revoca-tion List) disponibile per la verifica per via telematica da parte di tutti gli utenti della validità del certificato.

I certificati digitali vengono utilizzati non solo per garantire l’iden-tità di un soggetto fisico che ne fa uso ma anche di un sito Internet o di un software. Per comunicare ed effettuare con fiducia transazioni via Internet, aziende e persone devono essere in grado di identificare gli individui con cui hanno a che fare e di assicurarsi che le informazioni scambiate on-line siano al sicuro da intercettazioni e alterazioni.

Il meccanismo su cui si basa il loro utilizzo è la crittografia, che consiste nell’applicazione di un algoritmo ad un messaggio che lo ren-de illeggibile a meno di non possedere la chiave di decifratura.

In generale un sistema crittografico può trasformare un file di dati in un insieme di simboli incomprensibili a chiunque non possieda lo strumento per decifrarli. Un qualunque messaggio viene nascosto (crittografato) in modo che esista un altro procedimento simile che consenta di risalire al messaggio originale, è cioè un sistema reversibile.

Le principali tecniche crittografiche sono:1. La tecnica di crittografia a chiave privata o simmetrica, pre-

vede l’esistenza di una sola chiave da utilizzare per cifrare e

3. I presupposti tecnologici ed infrastrutturali

43 PROGETTO FIRM@ Documento di progettazione

decifrare il messaggio che si intende inviare. Ciò comporta la necessità, una volta crittografato il messaggio, di trasmettere al destinatario la chiave segreta per decifrarlo, con il rischio che questa venga intercettata da un terzo. Se non si hanno sistemi sicuri la chiave può essere facilmente scoperta e usata da chiun-que abbia interesse;

2. Nel caso di crittografia a chiave pubblica o asimmetriche, si ottiene invece una coppia di chiavi asimmetriche, una privata, che conosce solo il sottoscrittore, il quale ha anche l’obbligo di custodirla, e l’altra pubblica, custodita da un terzo garante – il certificatore – che ha l’obbligo di renderla pubblica a chiunque abbia necessità di decodificare un messaggio criptato con la chiave privata del sottoscrittore.

Il messaggio può essere cifrato in due modi: il mittente può co-dificare il messaggio con la chiave pubblica del destinatario - nota e resa disponibile dalle CA - il quale, per decodificare il messaggio, usa la propria chiave privata, nota solo a questi.

Oppure si può operare al contrario: il mittente cifra il messaggio da inviare con la propria chiave privata e il destinatario lo decifrerà con la chiave pubblica del mittente. Se il destinatario riuscirà a leggere in chiaro il messaggio decifrato con la chiave pubblica del mittente avrà la certezza che il messaggio in questione viene proprio da quel soggetto. Anche in questo caso la sicurezza della chiave privata spetta al sotto-scrittore, mentre la sicurezza di quella pubblica è garantita dalla CA, che la renderà disponibile a chi ne farà richiesta.

È opportuno rilevare che la conoscenza della chiave resa pubblica non fornisce alcuna informazione sulla correlata chiave privata, né può essere strumento per riuscire a ricavarla. La chiave pubblica è solo il mezzo per codificare o decodificare un testo su un supporto elettronico.

3.1.2 Il certificato digitale

Tornando al certificato digitale, siamo ora in grado di dettagliar-ne meglio il contenuto. Il file, oltre ai dati anagrafici del sottoscrittore, contiene la sua chiave pubblica (sia esso una persona fisica o un di-spositivo hardware) firmata digitalmente dalla chiave privata di una Autorità di Certificazione. Esistono più tipologie di certificati digitali che, pur sfruttando le potenzialità della crittografia, hanno obiettivi diversi:

• Accesso sicuro ad un portale: il certificato digitale funziona

44 PROGETTO FIRM@ Documento di progettazione

come chiave d’accesso a determinate pagine Internet o a particolari servizi. Anziché fornire all’utente username e pas-sword (o un codice pin) si provvede a dotarlo di un certificato digitale, che dovrà essere caricato sul proprio pc. In tal modo si ottiene il vantaggio di evitare che altre persone possano ac-cedere in luogo di quel determinato utente in quanto il certi-ficato digitale è strettamente personale.

• Firma di un documento: il certificato digitale permette di ap-porre una firma digitale ad un documento informatico. Questo significa che, quando il messaggio giunge al destinatario, la firma digitale apposta alla e-mail fornisce la garanzia che il messaggio è stato scritto e spedito effettivamente dal mittente.

• Crittografatura di un documento: viene utilizzata la chiave pubblica contenuta nel certificato per crittografare e spedire un messaggio al titolare del certificato stesso, con la sicurezza che nessun altro potrà leggere il contenuto del messaggio (infatti solo il titolare è in possesso della corrispondente chiave privata per decifrare il messaggio).

• Firma e crittografatura di un documento: le due opzioni pos-sono essere sommate per dare la garanzia al destinatario che il messaggio può essere letto solo da lui ed è stato inviato da una persona ben precisa.

Il formato standard più diffuso di certificato digitale è l’X.., contenente, in uno standard riconosciuto, una serie di dati obbligatori ai quali possono essere aggiunte ulteriori estensioni per riportare infor-mazioni aggiuntive.

Un certificato digitale contiene sempre i seguenti elementi:• numero di serie del certificato;• ragione e denominazione sociale del certificatore;• dati identificativi del titolare della chiave pubblica;• valore della chiave pubblica;• periodo di validità delle chiavi.

Il certificato contiene anche le informazioni sulla validità tem-porale dello stesso. Ciò è dovuto al fatto che la sicurezza di qualsiasi sistema di “cifratura” non è assoluta, ma relativa al tempo necessario a terzi per risalire alla chiave segreta con la tecnologia attualmente dispo-nibile: tempo molto maggiore di quello che si attribuisce come periodo di validità del certificato e delle chiavi.

Generalmente il certificato digitale ha validità biennale.

45 PROGETTO FIRM@ Documento di progettazione

3.1.3 Le infrastrutture a chiave pubblica

Attraverso i certifi cati digitali è possibile realizzare una struttura gerarchica di autenticazione, nella quale una Autorità di Certifi cazione Primaria (Primary Certifi cation Authority - PCA) autentica l’identità di Autorità di Certifi cazione sottostanti, autorizzandole ad autenticare, a loro volta, l’identità di altre Autorità di Certifi cazione o di utenti fi nali. Tale tipo di struttura gerarchica viene defi nito PKI - Public Key Infrastructure (Infrastruttura a Chiave Pubblica).

L’implementazione di una PKI deve tenere conto di una serie di requisiti progettuali che si possono sintetizzare nei seguenti:

• supporto per applicazioni multiple: una stessa infrastruttura deve garantire il supporto per molteplici applicazioni (posta elettronica sicura, applicazioni Web, trasferimento di fi le sicu-ro); il modello di gestione della sicurezza deve essere consisten-te e uniforme per tutte le applicazioni;

• interoperabilità tra infrastrutture diff erenti: in presenza di domini di sicurezza distinti, ognuno amministrato da un’in-frastruttura specifi ca, è richiesta l’interoperabilità delle varie infrastrutture al fi ne di garantire il raggiungimento di un buon livello di scalabilità;

• supporto per una molteplicità di politiche: cammini di cer-tifi cazione considerati appropriati per un’applicazione, posso-no non essere considerati altrettanto validi per un’altra applicazione; ci si potrebbe ad esempio fi dare di un’autorità di certifi cazione che certifi ca web server relativamente a transazioni comerciali di bassa entità, ma non relativamente a transazioni di

46 PROGETTO FIRM@ Documento di progettazione

elevato valore; per rispondere, quindi, ad entrambi i requisiti di scalabilità e supporto per applicazioni multiple, è necessario implementare meccanismi che permettano da un lato di attribuire politiche differenti ai vari cammini di certificazione dall’altro di associare ad ogni applicazione una politica di sicurezza specifica;

• aderenza agli standard: una vera interoperabilità tra PKI distinte è ottenibile soltanto con l’adozione di standard che de-finiscono i protocolli funzionali e di comunicazione relativi ai componenti costitutivi di una infrastruttura a chiave pubblica.

Le infrastrutture a chiave pubblica forniscono il supporto neces-sario alla tecnologia di crittografia a chiave pubblica, offrendo servizi relativi alla gestione delle chiavi, dei certificati e delle politiche di si-curezza.

Le componenti di una infrastruttura a chiave pubblica sono:• Autorità di registrazione (che nel caso italiano coincide con

l’Autorità di certificazione): si occupa di accertare l’identità dell’utente che richiede il certificato elettronico prima della effettiva emissione dello stesso; è indispensabile procedere a tale verifica dato che con l’emissione di un certificato elettronico si rende pubblicamente valida l’associazione tra una certa chia-ve pubblica e una certa entità. Una volta attestata la validità dell’identità dell’utente attraverso una serie di procedure definite nell’ambito di una precisa politica di sicurezza, l’autorità di registrazione ha il compito di abilitare l’utente come appartenente ad uno specifico dominio di fiducia.

• Autorità di certificazione (che nel caso italiano funge anche da Autorità di registrazione): costituisce la componente chiave di una PKI; la funzionalità principale di un’autorità di certifi-cazione consiste nel creare certificati elettronici; un’autorità di certificazione tuttavia non si deve limitare esclusivamente alla generazione dei certificati, ma deve poterne gestire l’intero ci-clo di vita. Il ciclo di vita comprende le fasi di generazione, aggiornamento (nel caso in cui il certificato stia per perdere validità temporale), sostituzione (nel caso di scadenza della validità temporale) e revoca nel caso in cui le condizioni di emis-sione del certificato non siano più valide; compito ulteriore dell’autorità di certificazione è stabilire relazioni di fiducia con altri domini di fiducia gestiti da altre Autorità di certificazione.

47 PROGETTO FIRM@ Documento di progettazione

• Sistema distribuito di directory: tale sistema costituisce un elemento fondamentale per la distribuzione su larga scala delle chiavi pubbliche utilizzate nella cifratura e nella firma dei dati; il sistema di directory contiene i certificati a chiave pubblica, reperibili dagli utenti quando necessario, e le liste contenenti certificati a chiave pubblica sottoposti a revoca; l’obiettivo che si intende raggiungere disponendo di directory pubbliche è facilitare la gestione e la distribuzione di certificati elettronici su larga scala.

• Autorità di timestamping: un problema fondamentale, nella gestione del ciclo di vita di un documento elettronico firmato, riguarda la collocazione temporale del documento stesso e della firma digitale su di esso apposta: può accadere infatti che un documento elettronico venga firmato con una chiave privata relativa ad un certificato che ha esaurito il proprio periodo di validità, oppure che è stato revocato dalla CA. Chi deve verificare la firma, controllando la lista di revoca (CRL) emessa dalla CA, può appurare se esse vada ritenuta valida o meno; per poter fare questo, occorre però conoscere le posizioni temporali relative fra data di revoca del certificato e data di firma del documento: se il documento è stato firmato prima che il certificato venisse revocato, allora la firma è da ritenersi valida; viceversa, nel caso in cui il documento sia stato firmato dopo la revoca del certificato, la firma non è valida. Risulta quindi necessario, per far fronte al problema sopra delineato, poter disporre di un servizio che fornisca un riferimento tem-porale assoluto all’interno della CA: a questa esigenza viene incontro il servizio di timestamping. Questo servizio fornisce una marca temporale a chi ne fa richiesta: se un documento, dopo essere stato firmato, viene inviato al server di timestam-ping (TSS), esso pone una marca temporale sul documento, e poi lo firma, collocando così la firma in un determinato istante temporale. Anche ogni revoca di un certificato sarà marcata temporalmente: avremo così gli elementi per poter effettuare il confronto fra gli istanti di revoca del certificato e di firma del documento. Quando il documento verrà restitui-to marcato temporalmente, ad esso sarà allegato il certificato contenente la chiave pubblica necessaria a verificare la firma del TSS.

• Utenti finali: devono essere dotati di un software in grado di interagire con tutte le componenti della PKI.

48 PROGETTO FIRM@ Documento di progettazione

E’ essenziale che ogni PKI stabilisca relazioni di fiducia con PKI esterne (si parla di cross certification), solo in questo modo si è in gra-do di stabilire dei corretti cammini di certificazione.

3.2 Interoperabilità e standardizzazione

Il concetto di interoperabilità indica la possibilità per un sistema ricevente di una certa amministrazione di trattare automaticamente le informazioni trasmesse dal sistema di mittente di un’altra amministra-zione o di un cittadino al fine di automatizzare le attività e i processi sottostanti.

Con riguardo alla Pubblica Amministrazione il nuovo paradig-ma di riferimento risulta dunque di difficile compatibilità con il tradi-zionale modello di azione diffuso nella stessa.

Questo infatti tendeva storicamente ad adottare sistemi di infor-mazione a compartimenti stagni.

Essere interoperabili al proprio interno significa consentire alle informazioni di circolare in sicurezza e tuttavia semplicemente, al fine di accrescere l’efficienza complessiva del processo.

E’ questo il presupposto per estendere lo stesso modello all’ester-no, in modo da poter cooperare efficacemente con tutte le altre orga-nizzazioni coinvolte e con il destinatario finale del procedimento.

Nel dibattito dottrinale si è andata consolidando una classifica-zione della interoperabilità che verte su tre aspetti distinti:

• l’interoperabilità tecnica, che concerne questioni tecniche di collegamento tra sistemi, la definizione delle interfacce, il formato dei dati e i protocolli, comprese le telecomunicazioni;

• l’interoperabilità semantica, che si occupa di assicurare che il significato esatto delle informazioni scambiate sia compren-sibile da qualsiasi altra applicazione, anche non pensata inizialmente per quel determinato scopo;

• l’interoperabilità gestionale, che si occupa di modellare i pro-cessi di lavoro, allineando le architetture dell’informazione con gli obiettivi dell’organizzazione, e di aiutare i processi di busi-ness nella cooperazione.

In concreto riteniamo possibile distinguere da un lato quelle che sono le problematiche connesse alla interoperabilità tecnica inerenti gli aspetti hardware e software; dall’altro quelle concernenti l’interope-rabilità semantica e gestionale che tratteremo congiuntamente presen-tando numerosi punti di connessione e costituendo l’aspetto al tempo

49 L’impatto Economico dei Fondi Strutturali

stesso più critico e strategico di questa tematica.Riteniamo inoltre possibile collocare a un livello intermedio, ri-

spetto ai due sopra definiti, la problematica dell’interoperabilità con-nessa alla firma digitale in quanto essa presenta sia aspetti di tipo tec-nico che di tipo semantico.

3.2.1 Interoperabilità tecnica

In questo ambito si inseriscono tutte le problematiche connes-se all’utilizzo di tecnologie e strumenti altamente innovativi, che non sempre sono attuabili utilizzando infrastrutture tecnologiche (personal computer, reti e connessioni) obsolete, o semplicemente non aggiorna-te rispetto agli ultimi standard.

Ciò che occorre dunque fare in via preventiva rispetto all’avvio/sperimentazione del progetto di e-government è una puntuale verifica di quali siano gli standard tecnologici minimi che debbano caratteriz-zare gli strumenti attraverso cui è gestito il processo che si decide di innovare.

La risposta che può essere data a tale problema non può che es-sere comunque quella di scegliere di adeguare le infrastrutture che non dovessero soddisfare tale vincolo tecnologico, pena l’inattuabilità del progetto.

In seguito all’analisi del gap esistente tra le proprie dotazioni tec-nologiche e quelle necessarie, va stabilito un percorso di adeguamento, che può essere volto alla semplice risposta puntuale alle nuove esigenze oppure può inserirsi in una politica di innovazione complessiva delle dotazioni tecnologiche.

Ciò di cui si dovrà tenere conto è che l’adeguamento delle do-tazioni tecnologiche non riguarda solo l’Ente attuatore del progetto, ma insiste anche su tutti gli attori coinvolti nello stesso, siano essi altre Pubbliche Amministrazioni o utenti finali/destinatari. La criticità di tale variabile è sempre da tenere presente in quanto non sempre si han-no a disposizione le leve gestionali per poterla correttamente gestire.

In molti casi la soluzione attuata è una “convivenza” tra vecchie e nuove procedure e modalità di interazione, tali da favorire l’interazione evoluta da parte di coloro che riescono a rispondere al vincolo tecnolo-gico, mantenendo comunque inalterata la possibilità di operare di chi non risponde a tali standard, almeno nella fase iniziale.

Una ulteriore problematica è rappresentata dalla “disponibilità delle librerie necessarie”; è infatti necessario che i software impiegati nella gestione del processo che si vuole innovare abbiano determinate caratteristiche.

50 PROGETTO FIRM@ Documento di progettazione

Tale problematica, al contrario di quella vista sopra, ha una con-figurazione “asimmetrica”, nel senso che investe maggiormente l’Ente attuatore rispetto agli altri attori.

Se ad esempio si pensa all’applicazione della firma digitale, si può subito notare come, indipendentemente da quale sia il software di sottoscrizione o l’Ente che ha fornito il certificato di firma, e dun-que indipendentemente dagli strumenti impiegati dal singolo utente, l’Ente che si trova nel ruolo del destinatario delle richieste/domande, deve essere in grado di “leggere” tutti i documenti inviati (ovviamente inviati impiegando tecnologie standard e compatibili).

Ciò pone un problema di disponibilità e aggiornamento di tutti i software potenzialmente utilizzabili dall’utenza per la sottoscrizione e la trasmissione, al fine di garantire a tutti pari opportunità.

Si deve inoltre prendere in considerazione il fatto che un utente dotato di firma digitale potrebbe relazionarsi con una pluralità di sog-getti; tale soggetto in assenza di una piena interoperabilità tecnica po-trebbe scontrarsi con la circostanza che per compiere due diverse ope-razioni dovrebbe essere dotato di due card e di altrettanti supporti.

Esemplificativo può essere il caso di una Società che per ricevere determinati finanziamenti si relazionerà con il sistema implementato dalla Regione ed utilizzerà la card da questa rilasciata mentre per l’invio dei bilanci utilizzerà il sistema della Camera di Commercio e la card rilasciatagli dalla CCIA.

In presenza di una piena interoperabilità tecnica al soggetto dovreb-be essere consentito compiere queste operazioni grazie ad una sola card.

3.2.2 Interoperabilità e firma digitale

Per interoperabilità delle firme digitali si intende la possibilità che un qualsiasi documento elettronico firmato da un soggetto mittente, che utilizza i servizi di un determinato certificatore, possa essere corret-tamente trattato da un soggetto destinatario che utilizza i servizi offerti da un diverso certificatore.

Ove non fosse assicurata l’interoperabilità come sopra definita, lo scambio di documenti elettronici potrebbe avvenire solo nella cerchia ristretta dei soggetti che utilizzano un medesimo certificatore.

In termini generali il processo di firma di un documento elettro-nico, dopo che il firmatario abbia verificato il contenuto del documen-to da sottoscrivere, comporta i seguenti passi:

1. generazione dell’impronta del documento elettronico; 2. firma, tramite la chiave privata accessibile solo previo inseri-

51 PROGETTO FIRM@ Documento di progettazione

mento del PIN, dell’impronta del documento elettronico (tut-to ciò corrisponde alla firma del documento);

3. creazione di una “busta elettronica” che contiene il documen-to, la firma definita come al punto precedente e il certificato che collega la chiave privata al suo possessore cioè, in questo caso, al firmatario.

A sua volta il destinatario dovrà essere in grado di eseguire il pro-cesso di verifica e in particolare di:

1. aprire la “busta elettronica”;2. verificare se il certificato del firmatario è “fidato”, ossia se rila-

sciato da un certificatore inserito nell’elenco pubblico dei cer-tificatori accreditati;

3. verificare l’impronta del documento elettronico con la chiave pubblica del firmatario estratta dal certificato (tutto ciò corri-sponde alla verifica della firma e della integrità del documento);

4. calcolare l’impronta del documento elettronico e confrontare il valore ottenuto con quello firmato ai fini dell’integrità del messaggio;

5. aprire il certificato e leggere l’identità del soggetto per verifica-re l’identità del mittente e la validità temporale della sua firma; per effettuare tale verifica dovrà accedere ad una speciale lista (Certification Revocation List) generata da ogni certificatore e ricercare se il certificato ricevuto appartenga alla lista oppure no; in caso negativo, il certificato deve essere considerato anco-ra valido e pertanto il documento elettronico può considerarsi valido.

Per assicurare l’interoperabilità dei processi di firma e di verifica allorquando mittente e destinatario utilizzino i servizi offerti da due diversi certificatori, occorre che il sistema di verifica fornito da ciascun certificatore sia sempre in grado di:

1. riconoscere il formato della busta elettronica;2. aprire la busta stessa ed estrarre le informazioni in essa contenute;3. leggere il contenuto del certificato ed estrarre correttamente

l’identità della persona che ha firmato e la relativa chiave pubblica;

4. capire quale algoritmo sia stato utilizzato per ottenere l’im-pronta del documento elettronico e applicare lo stesso algorit-mo al documento estratto dalla busta elettronica;

52 PROGETTO FIRM@ Documento di progettazione

5. verificare la validità del certificato sulle liste di revoca o sospen-sione del certificatore che lo ha rilasciato.

Quanto sopra, e cioè l’interoperabilità, non è garantito dal sem-plice rispetto delle vigenti regole tecniche in materia di firma digita-le, che non possono individuare soluzioni tecniche univoche, essendo vietato ogni riferimento diretto a tecniche specifiche, per evitare l’in-sorgere di squilibri del mercato o di escludere a priori di una serie di fornitori di tecnologie.

Al fine di assicurare l’interoperabilità almeno con riferimen-to all’ambito della Pubblica Amministrazione, l’AIPA (ora CNIPA) nel corso dell’anno ha emanato la circolare AIPA/CR/24 del //, recante “Le linee guida per l’interoperabilità dei certificato-ri”, consistenti in un insieme di specifiche tecniche univoche definite con il contributo dei primi certificatori iscritti nell’elenco pubblico e con l’apporto della Banca d’Italia.

Dette linee guide considerano, ai fini dell’interoperabilità:• i contenuti del certificato e la loro rappresentazione e formato;• le estensioni del certificato e i relativi contatti;• le liste di revoca e sospensione e i relativi contenuti;• la rappresentazione delle informazioni nelle buste PKCS#7.

3.2.3 Interoperabilità semantica e gestionale

Tale tematica ricomprende da un lato problematiche relative alla co-municazione tra sistemi e allo scambio di informazioni, dall’altro proble-matiche organizzative legate alla reingegnerizzazione dei processi di lavoro.

Tali aspetti non sono stati al momento ancora affrontati in un’ot-tica generale ma ci si è limitati ad occuparsene relativamente a singoli sistemi. Si è di conseguenza cercato di creare sistemi all’interno dei quali le informazioni scambiate fossero comprensibili da qualsiasi ap-plicazione e che avessero come utilizzatori organizzazioni con strutture e processi di lavoro funzionali e conseguenti alle nuove architetture dell’informazione.

L’aspetto della interoperabilità gestionale è probabilmente quello più problematico poiché incide direttamente e profondamente sulle modalità operative degli Enti, riguardando i dirigenti di ogni settore, e modificando le abitudini di qualsiasi dipendente pubblico.

Il punto chiave è bene noto a tutte le (poche) organizzazioni, pubbliche e private, che hanno provato a ridisegnare i propri processi di lavoro a seguito dell’introduzione delle nuove tecnologie. I processi

53 PROGETTO FIRM@ Documento di progettazione

vanno estesi fino ad includere partner, fornitori e utenti. Si pensi, ad esempio, al fatto che il cittadino che compila modulistica on line è come se entrasse nella sede dell’ente e si aggirasse tra gli uffici, aprendo da solo cassetti per prendere moduli e timbri.

Essere interoperabili al proprio interno significa consentire alle informazioni di circolare senza steccati, perseguendo la cooperazione al posto della rigida suddivisione di mansioni e compiti, semplicemente col fine di essere più efficienti. E’ questo il presupposto per estendere lo stesso modello all’esterno, in modo da poter cooperare efficacemente con tutte le altre organizzazioni.

3.3 Strumenti di identificazione

Gli strumenti di identificazione on line, quali la Carta di Identità Elettronica e la Carta Nazionale dei Servizi, vengono individuati nelle politiche di e-government come i mezzi attraverso i quali gli utenti vengono riconosciuti in rete in modo certo al fine di usufruire dei ser-vizi erogati per via telematica dalle amministrazioni pubbliche.

Tali strumenti risultano dunque funzionali ai progetti mirati al-l’ammodernamento della pubblica amministrazione e al miglioramen-to del dialogo tra uffici pubblici e cittadini.

In particolare sono da considerarsi indispensabili per lo sviluppo dei servizi di e-government a maggior valore aggiunto, che necessitano di condizioni di certezza e sicurezza (si pensi ad esempio agli accorgi-menti da adottare in materia di accesso ad archivi personalizzati, tran-sazioni ecc.).

3.3.1 La Carta d’Identità Elettronica

Per Carta d’Identità elettronica si intende il documento di rico-noscimento personale rilasciato dal Comune su supporto informatico. La CIE ha validità di cinque anni.

Il legislatore nel prevedere lo strumento della Carta d’Identità Elettronica ha posto come elementi cardine del progetto:

• la sicurezza dello strumento: risponde all’esigenza di produrre uno strumento sicuro sotto i diversi aspetti della produzione, rilascio nonché utilizzo da parte del titolare. La sicurezza non solo deve accompagnare tutti i flussi informatici necessari al circuito di emissione, ma deve anche essere presente sul sup-porto fisico al fine di scoraggiare tentativi di contraffazione, nonché di consentire un’identificazione certa da parte delle istituzioni competenti;

54 PROGETTO FIRM@ Documento di progettazione

• l’interoperabilità a livello nazionale: consiste nella possibilità di utilizzare il documento di identità come strumento per ac-cedere ai servizi informatici, attraverso l’utilizzo di tecniche di autenticazione opportunamente combinate alla specificazione di un codice personale di identificazione (PIN);

• l’utilizzo della carta d’identità elettronica come carta servizi: relativo alla necessità di disporre di un supporto in grado di funzionare allo stesso modo e su tutto il territorio naziona-le nei confronti delle pubbliche amministrazioni centrali. La richiesta di un servizio ad una pubblica amministrazione cen-trale deve essere uguale in tutti i Comuni e le diverse modalità di richiesta, a parte i contenuti specifici del servizio coinvolto, devono conservare, ai fini dell’usabilità da parte dell’utente, le stesse caratteristiche di rappresentazione.

Il legislatore ha anche previsto che la CIE possa essere utilizza-ta per il trasferimento elettronico dei pagamenti tra soggetti privati e pubbliche amministrazioni, previa definizione, d’intesa tra il Comune interessato e l’intermediario incaricato di effettuare il pagamento, delle modalità di inserimento e validazione dei dati necessari.

Con riguardo alla CIE si è avuta una prima sperimentazione che ha portato al rilascio effettivo di circa mila card in Comuni ita-liani. Successivamente il Ministero dell’interno, d’intesa con il Mini-stro per l’Innovazione e le Tecnologie, ha varato la II fase del progetto in cui, recependo le indicazioni emerse dalla fase pilota, sono state va-rate le nuove caratteristiche organizzative e tecniche delle infrastrutture necessarie per la diffusione più capillare del nuovo strumento.

E’ in atto la diffusione vera e propria nei comuni che hanno aderito alla II fase. Saranno distribuiti altri mila esemplari a coloro che, avendo superato i anni di età, ne faranno richiesta.

Nella fase di sperimentazione è stata realizzata l’infrastruttura di accesso (sicura e certificata) ai servizi anagrafici, demografici e di con-valida dei dati anagrafici in oltre . comuni (su ) con più di milioni di posizioni controllate e allineate. Nei comuni sperimentatori sono stati complessivamente implementati servizi tra i quali l’ac-cesso ai servizi demografici (in comuni) e tributari (), il pagamen-to elettronico di imposte, contravvenzioni e tributi (), lo sportello telematico municipale (), l’autocertificazione assistita (), i sondaggi on-line (), l’anagrafe on-line (13), lo stato di avanzamento delle pra-tiche () e i servizi di autorizzazione e concessione ().

55 PROGETTO FIRM@ Documento di progettazione

A supporto delle attività è stato istituito un gruppo di lavoro in-terministeriale a sua volta articolato in un sottogruppo organizzativo-giuridico-amministrativo e in uno tecnico-scientifico.

3.3.2 La Carta Nazionale dei servizi

La Carta nazionale dei servizi è stata oggetto del recente DPR / nel quale si prevede che in attesa della carta d’identità elet-tronica essa sia emessa dalle pubbliche amministrazioni interessate al fine di anticiparne le funzioni di accesso ai servizi in rete delle stesse.

La CNS, diversamente dalla CIE non è un documento per l’iden-tificazione “a vista” ma costituisce solamente uno strumento di identi-ficazione in rete.

All’emissione provvedono, su richiesta del soggetto interessato, le P.A. che intendono rilasciarla, previa identificazione del titolare.

La CNS contiene:• un certificato di autenticazione, consistente nell’attestato elet-

tronico che assicura l’autenticità delle informazioni necessarie per l’identificazione in rete del titolare della carta, rilasciato da un certificatore accreditato;

• i dati identificativi del titolare;• il codice numerico di identificazione della carta, nonché le

date del suo rilascio e della sua scadenza.La CNS può contenere le informazioni necessarie per apporre

firme digitali. La CNS ha la validità temporale determinata dall’amministrazio-

ne emittente, comunque non superiore a sei anni.Tutte le pubbliche amministrazioni che erogano servizi in rete

devono consentire l’accesso ai servizi medesimi da parte dei titolari del-la carta nazionale dei servizi indipendentemente dall’ente di emissione, che e’ responsabile del suo rilascio.

3.3.3 Le Carte Regionali dei Servizi

3.3.3.1 Regione Lombardia

Il progetto CRS-SISS prevede l’utilizzo delle infrastrutture di rete e della Carta a microprocessore per il miglioramento dei Servizi al Cit-tadino in Lombardia.

La Regione Lombardia ha incaricato Lombardia Informatica di realizzare il progetto avvalendosi della società LISIT, appositamente costituita, e di un gruppo di Partner (Telecom Itala, Finisiel, Lutech)

56 PROGETTO FIRM@ Documento di progettazione

costituitisi in RTI e partecipanti al capitale azionario LISIT in grado di assicurare la realizzazione di tutte le componenti del progetto. Lombar-dia Informatica S.p.A.: braccio operativo della Regione per l’ICT, ha in carico il coordinamento e la supervisione tecnica del progetto (Project Management).

Con l’acronimo SISS si indica il Sistema Informativo Socio Sa-nitario ovvero la extranet che connette tutti gli operatori e le strutture sanitarie della Lombardia.

All’interno del progetto si vengono a prevedere due carte: la CRS destinata ai cittadini e la Carta Siss destinata agli operatori.

Carta Regionale dei ServiziLa Carta CRS permetterà di accedere ai servizi che la Regione

Lombardia e, in un secondo momento, altre Pubbliche Amministra-zioni renderanno progressivamente disponibili.

Si prevede che la Carta Regionale dei Servizi possa essere utiliz-zata dal medico curante, in farmacia, in una struttura ospedaliera o negli uffici della ASL e permetta di accedere ai dati sanitari aggiornati e ad informazioni cliniche relative all’assistito. Tali informazioni sa-ranno leggibili soltanto attraverso appositi terminali e potranno essere utilizzate dal medico di fiducia e dagli operatori socio-sanitari abilitati. La Carta CRS darà inoltre accesso ad un sistema che permette di fare prenotazioni a distanza.

La Carta Regionale dei Servizi sostituisce da subito la Tessera Sa-nitaria Cartacea.

Infine, la nuova Carta CRS fungerà anche da Tessera Europea di Assicurazione Malattia, consentendo di beneficiare dell’assistenza sani-taria nei paesi europei, in sostituzione del modello E-111.Funzioni della Carta Regionale dei Servizi:

• Identifica e autentica il titolare• Registra informazioni sanitarie utili per emergenze • Sostituisce l’attuale tesserino sanitario cartaceo e il CF• Sostituisce l’attuale tesserino esenzioni cartaceo• Funge da Carta Europea mod. E111• Consente agli operatori sanitari di accedere a tutti i dati del

titolareContenuto della Carta Regionale dei Servizi:

• Dati amministrativi

57 PROGETTO FIRM@ Documento di progettazione

• Dati sanitari di emergenza• Dati anagrafici• Possibilità di inserire la firma digitale• 6 Kb per servizi privatiNel caso delle smart card del cittadino, Regione Lombardia ha

in corso di definizione un accordo con la Pubblica Amministrazione Centrale per far sì che la carta CRS sia la Carta Nazionale dei Servizi (CNS) per la Lombardia. A questo fine LISIT e i Partner dovranno assicurare la conformità della carta CRS con la carta CNS.

Carta SISS Funzioni della Carta Siss:• Identifica ed autentica l’operatore • Consente all’operatore sanitario di utilizzare il SISS• Permette l’accesso ai dati clinici dei cittadini (conformemente

al ruolo dell’operatore)• Permette di aggiornare la storia clinica dei cittadiniContenuto della Carta Siss:• Dati anagrafici • Firma digitale • Cifratura

Cittadini MMG/PLS Farmacie

320.339 Carte Cittadino Circolanti;

250 MMG/PLS Aderenti su 275;

89 Farmacie Attivate su 89

52% Consensi Informati registrati

90 Sale di Ambulatori Comunali attivate;

14 Cartelle Cliniche Inte-grate

Fonte: Relazione al

Forum P.A. 2004

Risultati della sperimentazione nella Asl di LeccoSituazione utenti attivati

58 PROGETTO FIRM@ Documento di progettazione

Azienda Sanitaria Locale

Azienda Ospedaliera

Enti Erogatori Privati

Enti gestori delle Assi

15 Presidi di Scelta e Revoca;

3 Presidi Avviati; Mangioni 6 Residenze Sani-tarie ed Assistenziali per Anziani (RSA)

23 Postazioni di Lavoro Attivate

230 Postazioni di Lavoro Attivate

8 Sportelli con Identifi cazione Cittadino tramite Carta;

10 Consultori Familiari Pubblici

20 Branche Specia-listiche Prenotabili;

100 Prestazioni Prenotabili

250 Prestazioni Disponibili

Casa di cura di Lecco

12 Sportelli con Identifi cazione Cittadino tramite Carta

Fonte: Relazione

al Forum P.A. 2004

Situazione strutture attivate

Fonte: Relazione

al Forum P.A. 2004

I risultati della sperimentazione su Lecco

59 PROGETTO FIRM@ Documento di progettazione

3.3.3.2 Regione Lazio

Il progetto Cartalazio è stato realizzato da Laziomatica S.p.A., nell’ambito del piano di E-Government della Regione Lazio.

Il progetto, presentato a Forum P.A. , consta di due fasi:• Prima fase: individuazione di . utenti pilota tra: farma-

cisti, medici di base, operatori ASL, sindaci, categorie profes-sionali (architetti, ingegneri), dirigenti regionali; ad essi verrà consegnata una smart card con firma digitale e autenticazione.

• Seconda fase: distribuzione massiva di smart card a tutti i cit-tadini della Regione Lazio, ad essi verrà consegnata una smart card con sola autenticazione.

Tale progetto ha come obiettivi:• l’autenticazione univoca per tutti i Servizi che prevedono la

smart card;• la diffusione degli strumenti di Firma Digitale;• l’avviamento della Carta del Professionista;• l’avviamento della Carta Nazionale dei Servizi per i cittadini.CartaLazio non surroga il documento d’identità, non contiene

la foto del titolare e non è dunque sottoposta agli stessi requisiti di sicurezza interna ed esterna previsti per Carta d’Identità Elettronica (CIE).

Essa contiene invece un Certificato di Autenticazione Digitale e di Firma Digitale che viene rilasciata dall’Amministrazione che la emette, la quale è responsabile della verifica dell’identità del richieden-te, della consegna fisica del supporto, della sua eventuale revoca, della conservazione e della tutela dei dati personali.

L’accesso ai servizi può essere variabile, in funzione delle caratte-ristiche di quello richiesto. Si hanno servizi ad accesso:

• libero;• basato su codice identificativo e password;• mediante carta a microchip con codice di autenticazione se-

condo lo standard previsto dalla Carta Nazionale dei Servizi (come descritto nell’allegato 4 all’Avviso di selezione dei pro-getti di e-government emessi dal Dipartimento per l’innova-zione e le tecnologie);

• mediante carta a microchip con certificato di firma digitale a norma;

60 PROGETTO FIRM@ Documento di progettazione

• mediante carta a microchip o dispositivo equivalente, con cer-tificato di autenticazione e/o di firma leggera.

L’obiettivo primario di CartaLazio è la possibilità di gestire le diverse modalità di autenticazione univoca per tutte le Amministrazio-ni interessate, semplificando l’accesso alle applicazioni informatiche e fornendo un sistema ben strutturato per la gestione di certificazioni ed autorizzazioni.

A questo scopo il progetto prevede la realizzazione e la messa in opera della struttura tecnica ed organizzativa che, fruendo di servizi erogati dalla Certification Authority, consenta l’avviamento della Car-ta dei Servizi per i Cittadini e la diffusione degli strumenti di firma digitale.

3.3.4 La Tessera Sanitaria

La tessera sanitaria è prevista dall’art. 50 della Legge 326/2003 al fine di effettuare il monitoraggio della spesa farmaceutica e delle presta-zioni specialistiche erogate dal Servizio Sanitario Nazionale. L’obiettivo prioritario di tale monitoraggio è di pervenire alla auspicata apprio-priatezza delle prescrizioni e, conseguentemente, al miglior governo e razionalizzazione della spesa in campo sanitario.

Lo scopo del monitoraggio suddetto è, quindi, la conoscenza del-la tipologia di spesa sanitaria al fine di pervenire al miglior grado di appropriatezza delle prescrizioni sanitarie. Ciò costituisce un elemento di notevole importanza per le decisioni di carattere economico-pro-grammatico che la Regione dovrà assumere nella fase di adozione del prossimo Bilancio e del Piano Sanitario Regionale.

La normativa sopra riportata prevede la consegna a tutti i citta-dini della tessera sanitaria sulla quale è riportato il codice fiscale del titolare in codice a barre e in banda magnetica. La tessera consente ai cittadini sia l’accesso alle prestazioni specialistiche (visite, esami dia-gnostici, di laboratorio, prestazioni specialistiche varie) sia l’erogazione dei farmaci. Pertanto, senza la tessera sanitaria non sarà più possibile ottenere tali prestazioni, se non dietro pagamento del corrispettivo da parte del cittadino.

I dati relativi ai farmaci nonché alle prestazioni specialistiche ero-gate su presentazione della tessera sanitaria verranno trasmessi, dalle farmacie e dalle strutture erogatrici, per via telematica, al Ministero delle Finanze per il monitoraggio della relativa spesa.

La Tessera sanitaria contiene: • i dati anagrafici dell’assistito ed il codice fiscale;

61 PROGETTO FIRM@ Documento di progettazione

• la data di scadenza valida ai soli fini dell’assistenza sanitaria (ad esempio per gli stranieri con permesso di soggiorno);

• un’area libera per eventuali dati sanitari regionali;• tre caratteri braille per i non vedenti;• il codice fiscale in formato bar code e banda magnetica dell’as-

sistito e la Tessera europea di assicurazione di malattia (E111). Quest’ultima potrà essere utilizzata, a partire dal mese di novem-

bre , per l’assistenza sanitaria nei Paesi dell’Unione europea e nei Paesi aventi accordi bilaterali con l’Italia

Con riguardo alla modalità di funzionamento è da sottolineare, come sopra precisato, che la tessera sanitaria reca il codice fiscale del titolare in formato a codice a barre nonché in banda magnetica, quale unico requisito necessario per l’accesso alle prestazioni a carico del Ser-vizio sanitario nazionale (SSN).

All’atto dell’utilizzo di una ricetta medica recante la prescrizione di farmaci, sono dunque rilevati otticamente i codici a barre relativi al numero progressivo regionale della ricetta, ai dati delle singole con-fezioni dei farmaci acquistati nonché il codice a barre della Tessera sanitaria.

Riguardo allo stato attuale del progetto è da segnalare che a no-vembre , con decreto, firmato dal Ministro dell’Economia e delle Finanze e dal Ministro della Salute, è stata estesa a Umbria, Emilia Romagna, Veneto e Lazio l’attivazione del sistema Tessera Sanitaria già sperimentato in Abruzzo da luglio .

L’inizio della sperimentazione è previsto a novembre in Umbria, a gennaio in Emilia Romagna, a febbraio in Vene-to e a marzo in Lazio.

3.4 Firma digitale e autenticazione dei documenti

Come già anticipato, la tecnologia dei certificati digitali e, quin-di, la crittografia a chiave pubblica, sta anche alla base del sistema di autenticazione di documenti attraverso la firma digitale.

La tecnica crittografica, in questo caso, non viene utilizzata per rendere il documento riservato ma solo, come meglio specificato in seguito, per garantirne l’integrità e la provenienza.

3.4.1 Concetto e definizioni

I termini firma elettronica e firma digitale vengono erroneamente utilizzati come sinonimi, sebbene tecnicamente ci si riferisca a due ri-sultati diversi.

62 PROGETTO FIRM@ Documento di progettazione

Per firma elettronica, esplicitamente considerata nella direttiva comunitaria //CE, si intende qualunque mezzo informatico di identificazione di un documento elettronico, cioè l’insieme di dati in forma elettronica, allegati oppure connessi tramite un’associazione lo-gica ad altri dati elettronici, utilizzati come metodo di autenticazione informatica.

Questo tipo di firma assicura solo la provenienza del documento, ma non offre alcuna garanzia circa l’integrità del contenuto.

La firma elettronica avanzata rappresenta un’evoluzione della firma elettronica; come questa è ottenuta attraverso una qualunque procedura informatica che garantisca la connessione univoca al fir-matario e la sua univoca identificazione, creata con mezzi sui quali il firmatario può operare un controllo esclusivo. Tale firma deve anche essere collegata ai dati ai quali si riferisce in modo da consentire di rilevare se i dati stessi siano stati successivamente modificati.

La firma digitale (tipico esempio di firma elettronica forte), se-condo quanto scritto nel D.P.R. n. 513/199 e ripreso dal D.P.R. n. 445/200 è il

“risultato della procedura informatica (validazione) basata su un sistema di chiavi asimmetriche a coppia, una pubblica e una pri-vata, che consente al sottoscrittore, tramite la chiave privata, e al destinatario, tramite la chiave pubblica, rispettivamente di rendere manifesta e di verificare la provenienza e l’integrità di un documen-to informatico o di un insieme di documenti informatici”.La firma digitale è quindi un’informazione aggiunta ad un docu-

mento informatico al fine di garantirne l’esatta provenienza e l’assoluta integrità rispetto al testo originale. Obiettivo naturale della firma di-gitale è quello di permettere la sottoscrizione di documenti realizzati su supporti informatici, snellendo le procedure di trasmissione di tali documenti, mantenendone intatta l’integrità e garantendone la prove-nienza.

Il legislatore europeo, dovendo fornire un quadro coerente a li-vello comunitario per la regolamentazione delle firme elettroniche, si è ispirato al principio di neutralità nei confronti della tecnologia, citan-do espressamente la fattispecie della firma elettronica.

Il legislatore italiano invece, citando specificatamente la firma di-gitale, ha stabilito requisiti più rigidi, al fine di equiparare questa ulti-ma alla firma autografa per riconoscerle validità e rilevanza giuridica.

Affinché una tipologia di sottoscrizione, differente dalla firma tradizionale su carta, possa rappresentarne giuridicamente una valida

63 PROGETTO FIRM@ Documento di progettazione

sostituzione, è necessario che soddisfi tutti i requisiti tipici propri di questa ultima.

La firma autografa attraverso la calligrafia, elemento identifica-tivo della persona, è rivelatrice immediata dell’autore del documento, quindi permette l’esatta identificazione del soggetto mittente di deter-minati documenti; è inoltre esclusiva, e quindi indica solo un soggetto firmatario. Apposta, inoltre, su ogni singola parte del documento ne garantisce l’integrità del contenuto.

La firma digitale opera come la firma autografa grazie al requisito di esclusività di cui gode la coppia di chiavi, assegnata ad un determi-nato soggetto. È evidente che una coppia di chiavi indica uno e un solo sottoscrittore. Inoltre, la pubblicazione della chiave pubblica nell’ap-posito registro e la garanzia circa l’identità del sottoscrittore concessa dal certificatore, permettono di individuare, senza alcun dubbio il mit-tente/firmatario.

Infine la firma autografa non è riutilizzabile, è indissolubile ri-spetto al supporto sul quale è impressa, non può essere trasportata su un altro documento, è intrinsecamente legata al testo cui è apposta tanto che i due oggetti, documento e firma, possono essere separati fisicamente senza che il legame tra loro venga meno.

Ne segue che la firma digitale è sempre unica, a testi diversi corri-sponderanno firme diverse. Ciò garantisce l’integrità del contenuto del documento firmato digitalmente rispetto all’originale.

Infine la firma digitale può essere generata solo dal legittimo pro-prietario. Il regolamento tecnico impone, infatti, che una coppia di chiavi sia attribuibile ad un’unica persona fisica e rivolge particolare at-tenzione ai requisiti di sicurezza dei dispositivi di custodia delle chiavi.

Nella tabella di seguito proponiamo un quadro completo e sinte-tico delle diverse tipologie di firma elettronica citate dalla normativa.Uso della firma digitale nella PA

64 PROGETTO FIRM@ Documento di progettazione

Tabella 2.1.1: le tipologie di firma elettronica

Tipo di firma DescrizioneRequisiti del certificatore

Funzione dei certificati

Effetti

Firma

elettronica

Dati elettronici

allegati ad altri

dati elettronici,

utilizzati come

metodo di

autenticazione

informatica

Sono gli stessi

requisiti richie-

sti per l’attività

bancaria e cre-

ditizia. L’attività

è libera e non

necessita di

autorizzazione

preventiva

Collegano la firma

elettronica al titolare

e ne confermano

l’identità

Sul piano

probatorio sono

liberamente

valutabili in base

alle caratteristiche

di qualità e sicu-

rezza del sistema

di firma utilizzatoFirma

elettronica

avanzata

Firma

elettronica

creata con

mezzi sui quali

il firmatario ha

un controllo

esclusivo

Firma

elettronica

qualificata

Firma

elettronica

avanzata,

creata con un

dispositivo

sicuro, accom-

pagnata da

un certificato

rilasciato da

un Certificato-

re qualificato

Sono gli stessi

richiesti per

l’attività banca-

ria e creditizia,

più alcuni di

affidabilità. È

richiesta una

comunicazione

di inizio attività

al M.I.T.

Contengono i dati

previsti dalla

normativa e sono

firmati digitalmente

dal Certificatore che

li ha rilasciati.

Tutte le operazioni

relative a tali

certificati

(revoca,sospensione,

ecc.) sono oggetto

Hanno piena

validità giudica

e quindi

i documenti

firmati in questo

modo hanno

pieno valore

legale. Sul piano

probatorio fanno

piena prova di

autenticità.

Firma digitale

Firma

elettronica

qualificata,

è un’

informazione

aggiunta ad

un documento

informatico al

fine di garan-

tirne l’esatta

provenienza

e l’assoluta

integrità

rispetto al

testo originale

Gli stessi

requisiti

dell’attività

bancaria e

creditizia.

In più è

richiesto

l’accreditamen-

to presso

il M.I.T.

65 PROGETTO FIRM@ Documento di progettazione

La firma digitale è sicuramente utile e utilizzabile sia in ambito pubblico – in relazione all’agire della P.A. – che in ambito privato, come nel caso dei contratti stipulati a distanza.

La pubblica amministrazione italiana sta vivendo una sicura ri-voluzione per quanto riguarda l’applicazione delle nuove tecnologie in genere, e di strumenti di informatizzazione di documenti e proces-si in particolare. Si attende ancora, tuttavia, la creazione di una Rete Unitaria della P.A. che manterrà il dialogo con i cittadini attraverso Internet.

Entro il //, anche se il termine non è perentorio, le P A. do-vranno, anche se è meglio dire avrebbero dovuto, adottare il Protocollo informatico.

In una accezione minimale avrebbero dunque dovuto quanto meno trasformare gli archivi cartacei in archivi informatizzati.

Questo dovrebbe consentire un’accelerazione non solo nello scambio di informazioni tra uffici ma anche nell’accesso alle stesse da parte dei privati interessati e, in ultima analisi una riduzione dei tempi di erogazione di una serie di servizi al cittadino.

Occorre precisare che esistono due tipi di documenti amministra-tivi: quelli a rilevanza interna, per i quali non è indispensabile l’utilizzo della firma digitale, e quelli a rilevanza esterna, che, invece, richiedono la firma digitale, idonea a identificare il sottoscrittore.

Trattando di firma digitale ci si riferisce dunque alla seconda ti-pologia di documenti.

3.4.2 La questione del non ripudio della firma digitale

3.4.2.1 Situazione attuale

Al secondo comma dell’art. 10 del DPR 445/00 (Testo unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa) il legislatore prende in considerazione il documento informatico sottoscritto con firma elettronica. La firma elettronica leg-gera non è altro che un sistema di identificazione alla base del quale vi è sempre la crittografia asimmetrica, ma manca una terza parte fidata che garantisca sia sulla vigenza della validità della coppia di chiavi, sia l’identità del titolare della stessa. Si accede, quindi, ad un programma di firma, si genera la coppia di chiavi e da questo momento sarà possi-bile firmare elettronicamente qualsiasi documento informatico.

Tale tipo di firma non fornisce tutte le garanzie necessarie a dare certezza ai documenti informatici. Nonostante le scarse garanzie for-nite da questo tipo di firma il legislatore ne ha affermato la capacità di

66 PROGETTO FIRM@ Documento di progettazione

soddisfare il requisito della forma scritta. Una affermazione del genere si discosta totalmente da ciò che il legislatore aveva previsto per questa materia nel DPR 513/97. La prima organica regolamentazione della materia, infatti, permetteva solamente ai documenti informatici sotto-scritti con firma digitale, di soddisfare il requisito della forma scritta.

Il legislatore del ’97 prevedendo che il documento informatico firmato con firma digitale fosse equiparato alla scrittura privata (con l’esplicito richiamo alla disciplina contenuta nell’art. 2702 c.c. ad ope-ra dell’art. 5 DPR 513/97) e che i contratti stipulati con strumenti informatici o per via telematica mediante l’uso della firma digitale, fossero validi e rilevanti a tutti gli effetti di legge (art. 11 DPR 513/97), aveva di conseguenza stabilito che la forma informatica che rispettasse determinati requisiti fosse idonea a soddisfare la forma scritta ad sub-stantiam.

La mutazione legislativa operata dal legislatore del DLgs 10/02 è di enorme rilevanza all’interno del quadro normativo di riferimento del documento informatico. Si è infatti modificato l’art. 10 del DPR 445/00 stabilendo che un documento informatico sottoscritto con fir-ma elettronica leggera assolva al requisito della forma scritta; ciò impli-ca che per tutti gli atti per i quali era richiesta la forma scritta ad sub-stantiam sia sufficiente l’apposizione di una firma elettronica debole.

Gli “atti che devono farsi per iscritto” a norma dell’art. 1350 c.c. potrebbero secondo il nuovo assetto normativo, essere fatti attraverso documenti informatici per loro natura insicuri.

A questo punto ci si deve chiedere quale sia il valore probatorio del documento informatico previsto dal secondo comma dell’art. 10 del DPR 445/00 a seguito della modifica operata dal DLgs 10/02. Visti i presupposti sarebbe naturale pensare che il documento infor-matico sottoscritto con una firma debole abbia l’efficacia probatoria della scrittura privata. Invece, da una parte si dice che il documento informatico soddisfa il requisito della forma scritta e dall’altra che non sarebbe considerato sotto il profilo probatorio come una scrittura pri-vata ma semplicemente rimessa al libero apprezzamento del giudice.

Il documento informatico sottoscritto, sia pure con una firma elettronica debole, è comunque un documento informatico al quale dovrebbe applicarsi il primo comma dell’articolo 10 che espressamente richiama l’art. 2712 del codice civile. A norma di questo articolo il giudice è tenuto a considerare veri i fatti e le cose rappresentate in un documento informatico, salvo che colui contro il quale il documento è prodotto non ne disconosca la conformità ai fatti e alle cose medesi-

67 PROGETTO FIRM@ Documento di progettazione

me. Se ciò è valido per un documento informatico non sottoscritto a maggior ragione lo sarà per un documento sottoscritto. Il documento non sottoscritto, infatti, dovrebbe avere un valore minore rispetto ad uno sottoscritto.

Il terzo comma regola il documento informatico quando questo è sottoscritto con una firma digitale “o con un altro tipo di firma elet-tronica avanzata”. Questo fa piena prova fino a querela di falso, della provenienza delle dichiarazioni di chi l’ha sottoscritto. Il vecchio testo richiamava esplicitamente l’art. 2702 c.c. e, quindi la intera normati-va relativa alla scrittura privata. La modifica apportata dal legislatore ha una portata non indifferente, poiché il richiamo operato sembra ricondurre alla fattispecie probatoria dell’atto pubblico o almeno alla scrittura privata autenticata. Le garanzie che circondano la procedura di certificazione della firma digitale hanno presumibilmente condotto il legislatore a considerare che il documento informatico firmato di-gitalmente abbia la stessa efficacia probatoria di una scrittura privata autenticata.

Questa impostazione sembra però essere smentita dal successivo articolo 24, che prevede la possibilità dell’autenticazione della firma digitale per opera di un notaio o di altro pubblico ufficiale autorizzato.

La scrittura privata informatica era sottoposta alle medesime regole descritte dall’articolo 2702 cod. civ. (art. 5 DPR 513/1997). Quindi, sotto il profilo del valore da attribuire al documento all’in-terno del processo, anche il documento informatico sottoscritto con firma digitale era sottoponibile agli istituti del riconoscimento, della verificazione e, infine, della querela di falso.

Il legislatore nella ultima stesura del terzo comma dell’articolo 10 del testo unico, non richiama più per intero l’articolo 2702 del codice civile al fine di regolare la nuova fattispecie informatica; il legislatore si limita a dire che tale nuovo tipo di documento fa piena prova fino a querela di falso.

A tal proposito c’è chi considera la firma digitale come un ra-dicale cambiamento rispetto al vecchio sistema di imputazione degli atti giuridici. Difatti, per tale filone interpretativo, il documento infor-matico firmato digitalmente impedirebbe, per sua stessa natura disco-noscimento della sottoscrizione digitale, quindi non potrebbe essere messa in discussione, attraverso l’atteggiamento della parte contro cui il documento è proposto, l’autenticità del documento. Secondo questo orientamento, è sufficiente l’uso della chiave segreta, necessario per ap-porre la firma giudizio di verificazione, a vincolare il titolare della cop-

68 PROGETTO FIRM@ Documento di progettazione

pia di chiavi, il quale per evitare gli effetti giuridici derivanti dall’uso della firma dovrà dimostrare di non essere il soggetto che fisicamente ha firmato il documento; questo sarà possibile solo attraverso una que-rela di falso.

3.4.2.2 Lo scenario prospettato dal Codice delle Pubbliche

Amministrazioni

E’ da segnalare che il Consiglio dei Ministri, l’ novembre , ha approvato in via preliminare lo schema del “Codice delle pub-bliche amministrazioni digitali”. Nelle sue linee generali il codice di-sciplinerà praticamente tutti gli aspetti dell’impiego delle tecnologie nelle pubbliche amministrazioni, con particolare attenzione non solo alla gestione dei documenti, ma anche ai rapporti con i cittadini per via telematica e allo sviluppo, all’acquisizione e al “riuso” dei sistemi informatici.

Le precedenti disposizioni sono abrogate, compresi tutti gli ar-ticoli del testo unico sulla documentazione amministrativa (DPR 445/00) che riguardano la materia.

Viene inoltre abrogato il decreto legislativo 10/02, che tanta confusione ha creato nel campo delle firme elettroniche.

Le “nuove” disposizioni, che nella sostanza riprendono i principi del DPR 513/97, con l’aggiornamento necessario per il rispetto della direttiva //CE prevedono tre tipologie:

1. Firma “forte” (ovvero firma digitale o firma elettronica qualificata, cioè basata su un certificato qualificato e creata median-te un dispositivo sicuro): il documento soddisfa il requisito della forma scritta ed è equiparato alla scrittura privata per gli aspetti processuali.

2. Firma “debole” (che non comprende le “autorizzazioni infor-matiche”, in sostanza le combinazioni username-password): il documento “è liberamente valutabile in giudizio, tenendo conto delle sue caratteristiche oggettive di qualità e sicurezza”; così è soddisfatta la previsione della direttiva europea.

3. Documento non firmato: vale come una riproduzione mecca-nica (è prevista una piccola modifica all’art. 2712 del codice civile).

69 PROGETTO FIRM@ Documento di progettazione

3.4.3 Concessione e gestione della firma: la certificazione della Firma Digitale

Il principio fondamentale della firma digitale è quello di garan-tire, attraverso una precisa serie di elaborazioni, che un documento redatto in forma elettronica abbia la stessa valenza giuridica di un do-cumento cartaceo firmato con firma olografa.

La firma digitale in quanto tale tuttavia non garantirebbe la vera identità del titolare della chiave privata. Chiunque potrebbe infatti ge-nerare (o farsi assegnare) una coppia di chiavi a nome di un terzo e come tale agire nel mondo virtuale.

Per risolvere questo problema, è necessaria una operazione di certificazione, è necessaria, cioè, la presenza di un organismo terzo ga-rante. La garanzia che questo ente fornisce è relativa all’identità del titolare, o meglio alla relazione univoca tra la chiave utilizzata nella transazione/trasmissione e la persona cui la chiave appartiene.

Nel proseguo della trattazione ci occuperemo preliminarmente di quella che è l’architettura complessiva del sistema e dunque del ruolo

Tabella riepilogativa evoluzione normativa

DPR 513/97 D.Lgs 10/02Codice delle PA

digitali 2005

Documento infor-

matico firmato con

firma debole

Non soddisfa

il requisito della

forma scritta

Si dice che assolva

il requisito

della forma scritta;

normativa

contradditoria:

il documento è in-

fatti rimesso al libero

apprezzamento del

giudice

Si prevede che

il documento sia

rimessa alla libera

valutazione

del giudice, tenuto

conto delle sue

caratteristiche

oggettive di qualità

e sicurezza

Documento

informatico firmato

con firma digitale

Equiparato

alla scrittura privata;

richiamo

all’art. 2702 c.c

Piena prova fino

a querela di falso,

sembrerebbe

riconducibile

alla fattispecie

della scrittura privata

autenticata ma

normativa contrad

dittoria.

Ritorno ai principi

del 1997.

Il documento

soddisfa il requisito

della forma scritta;

equiparato alla forma

scritta per gli aspetti

processuali. L’utilizzo

del dispositivo di

firma si presume

riconducibile al

titolare, salvo sia data

prova contraria

70 PROGETTO FIRM@ Documento di progettazione

dei certificatori che assolvono alle funzioni di concessione delle firme digitali, verifica e (qualora sia necessario) revoca delle stesse.

Successivamente esamineremo il ciclo di funzionamento della fir-ma digitale e quindi prenderemo in considerazione sia i vari passaggi necessari alla creazione di un documento firmato digitalmente sia i possibili supporti necessari alla memorizzazione.

3.4.3.1 Definizione del problema L’utilizzo della firma digitale prevede un quadro nel quale gli at-

tori coinvolti sono oltre naturalmente al firmatario del documento e al destinatario dello stesso, l’Ente Certificatore e, più in generale, l’in-frastruttura in grado di presidiare dal punto di vista tecnologico e della sicurezza l’utilizzo della crittografia.

Il quadro può essere dunque rappresentato come l’insieme di una serie di soggetti che si riconoscono mutuamente ed interagiscono in una occasione particolare (vedi rilascio) o ripetutamente (in ogni caso di utilizzo della firma).

Il mutuo riconoscimento è attualmente l’unica cosa in grado di assicurare il funzionamento del sistema, in quanto non esistono degli standard (o meglio non sono applicati) né riguardo alla struttura dei certificati, né riguardo alla rappresentazione dei dati, ecc. ma più che altro delle regole pratiche di funzionamento.

In base a queste regole pratiche vigenti nel sistema italiano, si è giunti alla situazione in cui ogni Autorità di certificazione iscritta al-l’elenco pubblico del CNIPA è in grado di leggere e gestire i certificati emessi da altre Autorità di certificazione.

L’insieme degli attori, ma anche delle infrastrutture tecnologiche, delle “regole del gioco” e delle persone, che rendono possibile l’utilizzo di dispositivi di firma digitale, vanno sotto il nome di PKI (Public Key Infastructure).

3.4.3.2 Il certificatore

Appare dunque evidente il ruolo primario ricoperto dalle autori-tà di certificazione, che rappresentano l’unico attore in grado di garan-tire “erga omnes” l’identità del soggetto dotato di dispositivo di firma digitale e di chiave di firma.

Il Certificatore ha il compito di accertare l’identità personale del richiedente e di aggiornare apposite liste dei certificati emessi e di quelli sospesi o revocati, cosicché:

71 PROGETTO FIRM@ Documento di progettazione

• chi abbia firmato un messaggio con una chiave non sospesa né revocata non possa in alcun modo disconoscerne il contenuto e la paternità;

• chiunque riceva un documento con firma digitale possa verifi-care l’identità del firmatario e la validità del relativo certificato.

La certificazione della chiave pubblica è il punto critico del siste-ma della firma digitale, tanto che, anche in questo caso, il nostro legi-slatore ha dettato regole piuttosto restrittive per coloro i quali vogliano candidarsi come enti certificatori.

L’ente certificatore, terza parte fidata nella trasmissione di docu-menti con firma digitale, è chiamato a svolgere una serie di compiti, principalmente deve:

• stabilire l’algoritmo di codifica e decodifica e predisporre il pacchetto software in grado di gestirlo;

• ricevere le domande di assegnazione di una coppia di chiavi;• valutare e registrare le caratteristiche di ogni richiedente (azien-

da o persona) per assegnare la relativa chiave pubblica (e quin-di la chiave privata corrispondente), emettendo un apposito certificato digitale;

• registrare in un’apposita banca dati la coppia di chiavi assegna-ta perché non possa essere più assegnata;

• stabilire il termine di scadenza del certificato, quindi il periodo di validità delle chiavi (in funzione di determinate caratteristiche individuate dal regolamento tecnico all’articolo 4, comma 7);

• pubblicare on line il certificato e la chiave pubblica in modo che chiunque abbia interesse possa avere la sicurezza dell’avve-nuta certificazione;

• ricevere le segnalazioni di eventuali smarrimenti, furti, divul-gazioni improprie di chiavi, ecc. ecc., e ne pubblica la sospen-sione o la revoca in tempi molto stretti.

L’utente che desidera utilizzare il meccanismo della firma digitale, si registra presso un’autorità di certificazione, grazie a tale registrazione, gli viene attribuito un identificatore.

Mediante un software adatto al sistema crittografico adottato, l’utente genera la coppia di chiavi da utilizzare.

La richiesta di certificazione all’Autorità di Certificazione da par-te dell’utente avviene attraverso l’invio della chiave pubblica, generata

72 PROGETTO FIRM@ Documento di progettazione

autenticandola mediante l’identificatore ricevuto nel momento della registrazione, dall’Autorità stessa.

A questo punto l’Autorità crea il certificato che garantisce l’ap-partenenza della chiave pubblica all’utente; la veridicità del certificato è assicurata dalla firma digitale che l’autorità appone sul certificato. In questo modo viene risolto il problema della distribuzione delle chiavi pubbliche, in quanto tale distribuzione avviene tramite l’invio dei cer-tificati, che in quanto sottoscritti dall’Autorità, garantiscono l’autenti-cità e la veridicità delle chiavi pubbliche.

E’ bene sottolineare che questo ruolo fondamentale non è rico-perto però da un solo ente riconosciuto da tutti, ma in linea teorica può essere ricoperto da chiunque rispetti determinati requisiti e si sot-toponga al processo di riconoscimento come ente di certificazione. Ciò vale a livello nazionale, e ancora di più a livello globale.

L’esistenza di più Autorità comporta che i certificati necessari per la conoscenza della chiave pubblica appartenente ad un soggetto, sono firmati da diverse autorità, ed è impensabile che ogni utente abbia di-retta conoscenza delle chiavi pubbliche di ogni interlocutore, sotto for-ma di certificato elettronico, o delle chiavi pubbliche delle corrispon-denti autorità di certificazioni competenti (che gli permette di venire a conoscenza della chiave pubblica del suo interlocutore).

E’ indispensabile, quindi, avere a disposizione un meccanismo che permetta il ritrovamento dei certificati elettronici degli interlocu-tori appartenenti a domini di sicurezza esterni, curati da Autorità di certificazioni diverse dalla propria. Questo meccanismo utilizza le cate-ne di certificazione, note anche come cammini di certificazione.

Il cammino di certificazione permette, grazie alla conoscenza di un insieme di chiavi pubbliche appartenenti al proprio dominio, di risalire attraverso varie ricerche, alle chiavi pubbliche registrate in un dominio differente, grazie alle comunicazioni che si vengono ad in-staurare tra Autorità differenti.

Il problema di avere più autorità di certificazione, e quindi diver-se liste da consultare per rintracciare le chiavi pubbliche, è stato risolto prevedendo l’elenco pubblico dei certificatori, previsto dall’articolo comma 6 del DPR dicembre n. 445 e specificato nel DPCM gennaio , viene mantenuto dal Centro nazionale per l’infor-matica nella pubblica amministrazione e viene reso disponibile per via telematica attraverso la rete Internet. Con il Decreto della Presidenza del Consiglio dei Ministri del luglio viene definitivamente sancita l’assegnazione al CNIPA della competenza per la tenuta del-l’elenco pubblico dei certificatori.

73 PROGETTO FIRM@ Documento di progettazione

L’elenco pubblico viene reso disponibile in due distinte unità in-formative:

• La prima contiene la lista dei certificati delle chiavi di certifica-zione (art. 41 comma 1 lettera f ) e le rimanenti informazioni previste nel medesimo articolo 41 fatta eccezione per i manua-li operativi;

• La seconda contiene i manuali operativi aggiornati forniti al CNIPA dai certificatori (art. 41 comma 1 lettera g).

La lista dei certificati ed i singoli manuali operativi sono sotto-scritti dal CNIPA, nella persona del Presidente. I codici identificativi del certificato di sottoscrizione utilizzato dal Presidente del Cnipa, Li-vio Zoffoli, sono stati pubblicati con la Circolare settembre , n. CNIPA/CR/42 (G.U. n. 222 del settembre ).

La lista dei certificati è strutturata, in un archivio WINZIP non compresso, come insieme di directory, ciascuna dedicata ad un certifi-catore iscritto, ognuna contenente i certificati forniti dalle aziende, ed un file in formato che presenta le informazioni previste dall’articolo 41.

La verifica della firma del CNIPA e la successiva estrazione degli oggetti firmati può essere effettuata con qualsiasi software in grado di elaborare file firmati in modo conforme alla circolare AIPA/CR/24, giugno .

La P.A. come possibile certificatore

Merita di essere segnalato il fatto che, ai fini della sottoscrizione di documenti informatici di rilevanza esterna, le pubbliche ammini-strazioni, ai sensi dell’art.29 quinquies del DPR 137/2003, possono optare per due diverse soluzioni:

• svolgere direttamente l’attività di rilascio dei certificati qualifi-cati avendo a tal fine l’obbligo di accreditarsi; tale attività può essere svolta esclusivamente nei confronti dei propri organi ed uffici, nonché di categorie di terzi, pubblici o privati. I certifi-cati qualificati rilasciati in favore di categorie di terzi possono essere utilizzati soltanto nei rapporti con l’Amministrazione certificante, al di fuori dei quali sono privi di ogni effetto. Con decreto del Presidente del Consiglio dei ministri, su proposta dei Ministri della funzione pubblica e per l’innovazione e le tecnologie e dei Ministri interessati, di concerto con il Mini-stro dell’economia e delle finanze, sono definite le categorie di terzi e le caratteristiche dei certificati qualificati;

74 PROGETTO FIRM@ Documento di progettazione

• rivolgersi a certificatori accreditati, secondo la vigente normativa in materia di contratti pubblici.

3.4.3.3 Le revoche dei certificati

Critica nel processo di gestione dei certificati elettronici è l’ope-razione di revoca.

La difficoltà legata a tale operazione è il garantire una corretta no-tifica su larga scala dell’avvenuta revoca di un particolare certificato.

Il meccanismo comunemente utilizzato per notificare su larga scala le revoche, utilizza le “liste di revoca dei certificati” (certificate revocation list o CRL).

Ogni autorità di certificazione pubblica periodicamente una struttura dati contenente l’elenco dei certificati revocati (firmata digi-talmente dall’autorità stessa, a garanzia della sicurezza dei dati conte-nuti nella lista).

Ogni CRL deve poter essere consultabile da ogni utente, in fase di verifica di una firma, per essere certi che il certificato utilizzato sia valido e non revocato.

La pubblicazione delle liste avviene con una certa periodicità, quin-di il problema che si pone è che non avviene una revoca in tempo reale.

Alternativamente alla pubblicazione delle liste, alcune autorità usano un metodo di comunicazione delle liste in modalità broadcast, ossia appena sopravviene una revoca l’autorità comunica agli utenti interessati la CRL, questo sistema presenta degli svantaggi in quanto non è sicuro che le CRL effettivamente raggiungano gli utenti finali in modo sicuro.

3.4.4 Processo di funzionamento della Firma Digitale

La firma digitale è la sequenza, o “stringa di dati”, che risulta dal procedimento di codifica di un file (messaggio di posta elettronica, documento di testo, immagine, ecc.), ottenuta utilizzando il metodo della crittografia a doppia chiave.

Poiché l’interesse, in questo caso, è garantire non la riservatezza, bensì l’autenticità e integrità del contenuto, il meccanismo di cifratura non si applica all’intero documento, bensì alla cosiddetta impronta, una stringa di dati riassuntiva ottenuta applicando al documento un algoritmo di hash, ciò rende le operazioni di firma estremamente più veloci. Una volta ottenuta l’impronta, questa viene crittografata con la chiave privata del mittente e costituisce la firma del documento.

Al momento della ricezione, il destinatario, attraverso apposito

75 PROGETTO FIRM@ Documento di progettazione

software, effettua nuovamente la funzione di hash sul documento per-venuto in chiaro e decodifica con la chiave pubblica la firma del docu-mento, ottenendo così l’originale impronta.

A questo punto, la verifica dell’uguaglianza delle due impronte garantisce l’integrità e l’autenticità del documento.

Per firmare un documento digitalmente occorre seguire un de-terminato iter:

1. si deve produrre l’impronta dal file originario, ossia la stringa di dati riassuntiva che ne sintetizza univocamente il contenuto;

2. si prosegue con la cifratura dell’impronta con la chiave privata del mittente/firmatario. Il risultato di questa operazione è la firma digitale vera e propria;

3. generata così la firma digitale, il mittente può inviare in chiaro il documento firmato, corredato della firma e del certificato digitale contenente la chiave pubblica;

4. il destinatario, attraverso un opportuno software, decifra la firma digitale con la chiave pubblica del mittente (legge l’im-pronta). Se questa operazione riesce, il destinatario ha la cer-tezza che il Message Digest è stato generato dalla unica chiave privata - quindi da quel determinato sottoscrittore;

5. successivamente il destinatario calcola nuovamente la funzio-ne di HASH sul documento ricevuto in chiaro e confronta il risultato con l’impronta del mittente. Se le due impronte coincidono il destinatario ha la conferma che il contenuto del documento ricevuto in chiaro non ha subito alcuna alterazio-ne o danneggiamento durante la trasmissione (anche un solo bit modificato avrebbe generato un’impronta diversa da quella “firmata”).

La trasmissione del documento firmato ad un destinatario preve-de, quindi, il contemporaneo invio di:

• testo originale in chiaro;• impronta cifrata;• certificato digitale del mittente contenente la chiave pubblica.Il tutto viene accorpato in un file, secondo lo standard PKCS#7

che definisce i formati standard per file cifrati e/o firmati digitalmen-te. Secondo la normativa italiana, i file firmati digitalmente devono necessariamente assumere l’estensione .p7m, in aggiunta all’estensione originaria.

E’ importante sottolineare che la stringa di dati che chiamiamo

76 PROGETTO FIRM@ Documento di progettazione

“firma digitale”, essendo il risultato di un’operazione effettuata su uno specifico file di dati, è in realtà diversa per ogni singolo file trattato. E’ infatti la chiave privata, quella che genera il risultato, ad essere unica.

La firma digitale non è riproducibile, non è possibile associare una certa firma digitale ad un testo diverso dall’originale. La sicurezza dell’intero meccanismo è garantita dalla impossibilità di ricostruire la chiave privata (segreta) a partire da quella pubblica, anche se le due chiavi sono univocamente collegate.

Supporti per la memorizzazione

L’algoritmo che produce la firma digitale, quindi la chiave pri-vata, deve risiedere su un supporto di memorizzazione, e così anche il certificato elettronico che serve per la trasmissione della chiave pubbli-ca, legata alla chiave privata.

Un importante, e sicuro supporto di memorizzazione è la smart card, che consente di archiviare certificati, chiavi private, e di eseguire operazioni di crittografia con chiave pubblica, come la firma digitale.

Esistono due tipi di smart card, una dotata di capacità di elabora-zione, che quindi può eseguire dei veri e propri programmi come critto-grafare un documento, ed una che ha solo funzioni di memory card.

Altri dispositivi di memorizzazione come la flash memory (è un chip di memoria), o il cd-rom non si prestano ad essere utilizzati per la memorizzazione di chiavi private e certificati in quanto non possiedo-no una capacità elaborativi propria.

Altro dispositivo di memorizzazione è il Token USB, che è un dispositivo hardware da collegare alla porta USB del pc, che come la smart card incorpora un chip dotato di capacità elaborative autonome con memoria non volatile.

3.4.5 Problemi aperti

Una realtà che può comportare alcuni problemi è quella del-l’omocodia; con tale termine si intende quella particolare situazione che si verifica quando due (o più) soggetti abbiano dati anagrafici tali da generare lo stesso codice fiscale (Omocodici). Fino ad oggi sono stati riscontrati oltre 25.000 casi.

In caso di omocodia l’Agenzia delle Entrate provvede ad attri-buire a ciascun soggetto un nuovo codice fiscale, calcolato a partire dal codice fiscale “base” comune a più soggetti. La distinzione avviene effettuando, nell’ambito dei sette caratteri numerici, sistematiche so-stituzioni di una o più cifre, a partire da quella più a destra, con corri-

77 PROGETTO FIRM@ Documento di progettazione

spondenti caratteri alfabetici. Sul sito Internet dell’Agenzia delle Entrate è disponibile il pro-

gramma di controllo della correttezza formale del codice fiscale; questo può essere utilizzato e integrato da Enti e Amministrazioni nei propri sistemi informativi, per la verifica di codici fiscali, anche se generati da una risoluzione di omocodia.

Il fatto che vengano risolti eventuali casi di omocodia risulta si-gnificativo in relazione alla tematica della firma digitale. Il soggetto che richiede una smart card ad un Ente Certificatore infatti deve presenta-re, tra la documentazione necessaria, proprio il codice fiscale. Inoltre tra i dati inseriti nel certificato digitale vi è anche il codice fiscale.

Si deve poi tenere conto del fatto che il codice fiscale è lo stru-mento attraverso il quale gli utenti compiono tutta una serie di attività relative ai loro rapporti con la P.A. (si pensi alla richiesta di determinati certificati o alla tessera sanitaria che si basa proprio sul codice fiscale); di conseguenza nel caso in cui il cittadino dovesse svolgere operazioni che comportano l’utilizzo sia della smart card (per la firma digitale) che del codice fiscale un caso di omocodia potrebbe determinare notevoli complicazioni.

Una ulteriore problematica di particolare rilevanza è quella legata alla presenza di una pluralità di certificatori e alla scelta del legislatore di non individuare regole tecniche univoche al fine di non ingene-rare squilibri nel mercato. Infatti nel caso in cui venissero dettate delle regole tecniche particolarmente precise e dettagliate si finirebbe per forza di cosa a rifarsi a uno dei modelli esistenti. Ciò verrebbe a deter-minare, per il Certificatore individuato come modello, una posizione di forza inaccettabile da parte degli altri Certificatori.

Questa scelta se da un lato tutela il mercato dall’altro pone ap-punto dei problemi legati alla ancora scarsa standardizzazione presente nella realtà italiana delle firme digitali.

Sia il Cnipa sia l’Assocertificatori sono attivi per cercare di creare una sempre maggiore omogeneità.

Assocertificatori, dopo avere contribuito alla definizione della circolare AIPA sulla interoperabilità, ha provveduto a costituire al pro-prio interno il “Comitato Tecnico per la firma digitale”, cui sono stati attribuiti dal Consiglio Direttivo dell’Associazione i seguenti compiti:

• analisi delle problematiche relative all’interoperabilità e predi-sposizione di proposte operative per la piena attuazione del-l’interoperabilità tra i soci;

78 PROGETTO FIRM@ Documento di progettazione

• esecuzione di un piano di verifiche periodiche di interoperabi-lità tra i soci;

• studio ed approfondimento delle questioni tecniche relative a nuove norme tecniche, all’adozione di nuovi standard, alle modifiche di norme tecniche o standard esistenti, all’adozione ed alla compatibilità di standard internazionali ed elaborazio-ne di proposte operative per i soci;

• elaborazione di documenti, studi, indicazioni o raccomanda• studio ed approfondimento delle necessità di intervento o mo-

difica delle procedure operative e di sicurezza dei soci a seguito dell’eventuale verificarsi di problemi applicativi ed elaborazio-ne di proposte di intervento per i soci;

• elaborazione di proposte di miglioramento degli aspetti tecnici in generale relativi all’attività di certificazione.

3.5 Trasmissione certa: posta elettronica certificata (PEC)

3.5.1 Concetto e definizioni

La Posta Elettronica Certificata (PEC) è un sistema di posta elet-tronica nel quale è fornita al mittente documentazione elettronica, con valenza legale, attestante l’invio e la consegna di documenti informatici.

“Certificare” queste due fasi significa che il mittente riceve dal proprio gestore di posta (il cui elenco ufficiale è istituito presso il CNI-PA, al quale sono assegnati compiti di vigilanza e controllo sull’attività degli iscritti) una ricevuta che costituisce prova legale dell’avvenuta spe-dizione del messaggio e dell’eventuale allegata documentazione. Allo stesso modo, quando il messaggio perviene al destinatario, il gestore invia al mittente la ricevuta di avvenuta (o mancata) consegna con precisa indicazione temporale. Nel caso in cui il mittente smarrisca le ricevute, la traccia informatica delle operazioni svolte viene conservata per 24 mesi in un apposito registro informatico custodito dai gestori, con lo stesso valore giuridico delle ricevute.

L’oggetto dell’invio fra mittente e destinatario è un messaggio di posta certificata composto dal messaggio originale, che coincide con quanto predisposto dal mittente, da una parte di testo descrittivo e dai dati di certificazione. La trasmissione, tra mittente e destinatario, avviene mediante l’invio del messaggio di posta certificata sottoscritto dal gestore di riferimento del mittente con firma elettronica.

Tale procedura in effetti non fissa però in modo univoco il conte-nuto della mail e dei relativi allegati, ponendo la questione dell’opportu-

79 PROGETTO FIRM@ Documento di progettazione

nità o della necessità di una firma disgiunta da parte del mittente (utiliz-zando ognuno propri supporti e certificati) e del certificatore di posta.

Nel primo caso si ha la “validazione” dei contenuti, nel secondo la certezza dell’avvenuta trasmissione e dell’avvenuta o mancata ricezione.

Il DPR approvato il gennaio prevede che il documento informatico trasmesso per via telematica si intende inviato dal mitten-te se trasmesso, e si intende consegnato al destinatario se disponibile all’indirizzo elettronico da questi dichiarato.

La validità della trasmissione e ricezione del messaggio di posta elettronica certificata è attestata rispettivamente dalla ricevuta di accet-tazione (fornita al mittente dal suo gestore di posta elettronica) e dalla ricevuta di avvenuta consegna (fornita al mittente dal gestore di posta elettronica utilizzato dal destinatario).

La ricevuta di avvenuta consegna è rilasciata contestualmente alla consegna del messaggio di posta elettronica certificata nella casella di posta elettronica del destinatario, indipendentemente dall’avvenuta lettura da parte del soggetto destinatario.

Nel caso la trasmissione del messaggio avvenga tra diversi gestori deve essere assicurata l’interoperabilità dei medesimi (ovviamente ciò non si pone come problema se i due utenti utilizzano lo stesso gestore (sulla cui scelta la legge però non pone vincoli, né consente alla PA di imporre il suo gestore agli utenti). Il gestore del destinatario provvede-rà a rilasciare al gestore del mittente una “ricevuta di presa in carico” con la quale attesta l’avvenuta presa in carico del messaggio.

Attraverso l’impiego di posta certificata, le problematiche relati-ve all’interoperabilità risultano, per quanto possibile, amplificate, così come si complica il quadro della verifica della validità dei certificati, che diventa doppia (verifica del certificato dell’utente e verifica del cer-tificato del gestore di posta).

3.5.2 La sperimentazione relativa alla PEC

La sperimentazione ha avuto inizio nel per iniziativa del Centro tecnico per la Rupa attraverso l’attività del Gruppo di Lavo-ro; inizialmente sono stati presi in considerazione principalmente gli aspetti legati all’interoperabilità e sono stati prodotti una serie di docu-menti tecnici di supporto per i fornitori del servizio.

Successivamente, in seguito alla istituzione del CNIPA, sono pro-seguite le verifiche di interoperabilità delle piattaforme sw e le relative richieste d’iscrizione all’”Indice dei Gestori” del servizio.

Il CNIPA considera ormai conclusa la fase di sperimentazione e

80 PROGETTO FIRM@ Documento di progettazione

di conseguenza dal novembre non vengono più accettate nuove richieste d’iscrizione per i Gestori e non si procede a verificare l’intero-perabilità di nuove piattaforme.

La partecipazione alla fase di sperimentazione non costituisce nessun tipo di titolo rispetto alla successiva fase ufficiale della PEC, che sarà regolata da legge dello Stato.

3.6 Ricezione e gestione: il protocollo informatico

3.6.1 Concetto e definizioni

Ogni Pubblica Amministrazione, perseguendo gli obiettivi pre-visti dal proprio mandato istituzionale, riceve e produce una enorme quantità di documenti. Tale attività si estrinseca in processi governati da procedure e regole variabilmente complesse ed articolate.

È evidente come sia necessario quindi, che tutte le informazioni, che transitano da e per la Pubblica Amministrazione, siano all’occorren-za rintracciate. A questa necessità rispondono gli uffici del protocollo.

Ma che cos’è esattamente l’attività di protocollazione? Si tratta di quella fase del processo che certifica provenienza e data di acquisizio-ne del documento identificandolo, in maniera univoca, nell’ambito di una sequenza numerica collegata con l’indicazione cronologica. Costi-tuisce chiaramente il punto nevralgico di tutti i flussi di lavoro tra le amministrazioni e all’interno di ciascuna di esse.

Proprio in materia di semplificazione amministrativa, infatti, si inserisce il Protocollo Informatico.

Il Protocollo Informatico e, più in generale, la gestione elettro-nica dei flussi documentali, hanno la finalità di migliorare l’efficienza interna degli uffici attraverso la riduzione dei volumi cartacei, la razio-nalizzazione dei flussi documentali fino ad arrivare, dove è possibile all’eliminazione dei registri cartacei.

Il legislatore italiano, scegliendo il gennaio come termine, non perentorio, per realizzare la struttura minima necessaria per attiva-re il Protocollo Informatico lo definisce come

“l’insieme delle risorse di calcolo, degli apparati, delle reti di comuni-cazione e delle procedure informatiche utilizzati dalle amministra-zioni per la gestione dei documenti”.Si tratta di tutte le risorse tecnologiche necessarie alla realizzazio-

ne di un sistema automatico per la gestione e l’archiviazione elettronica dei flussi documentali.

Ottimizzare la gestione delle informazioni in modo da rendere di facile reperibilità i documenti e i dati in transito è indispensabile non

81 PROGETTO FIRM@ Documento di progettazione

solo per semplificare le azioni di chi lavora all’interno della macchina amministrativa ma anche per fornire ai cittadini e alle imprese servizi più efficienti e con un grado di trasparenza sempre maggiore.

Infatti con l’introduzione del protocollo informatico si facilite-rebbe l’accesso allo stato dei procedimenti e ai relativi documenti da parte di cittadini, imprese e altre amministrazioni.

Il Protocollo Informatico si pone come il punto di avvio di un sistema informatico nel quale l’informazione che vi transita è solo di tipo digitale, e l’informazione su supporti documentali cartacei viene trasformata in digitale.

Ciò significa, quindi, accelerare e promuovere presso gli Enti Lo-cali la gestione del flusso documentale informatico nel rispetto della sicurezza operativa e delle condizioni di interoperabilità tra sistemi di protocollo informatico al fine di semplificare e rendere più efficiente ed efficace l’azione amministrativa.

Infatti dietro al concetto di Protocollo Informatico si configura una nuova strategia per la gestione di documenti e informazioni che impegnerà ogni Amministrazione a:

• riorganizzare e concentrare gli Uffici di protocollo, dando vita a nuove aree organizzative (AAOO);

• adottare precisi standard di protocollo identici per tutte le am-ministrazioni;

• rivedere tutte le attuali procedure informatiche per renderle compatibili con il Protocollo Informatico e garantire l’inte-roperabilità tra amministrazioni e facilitare l’accesso ai docu-menti da parte dei soggetti interessati.

3.6.2 Il Protocollo Informatico nella PA: livelli di attivazione

Il legislatore definisce protocollo informatico come “l’insieme delle risorse di calcolo, degli apparati, delle reti di comunicazione e delle procedure informatiche utilizzati dalle amministrazioni per la ge-stione dei documenti”, ovvero, tutte le risorse tecnologiche necessarie alla realizzazione di un sistema automatico per la gestione elettronica dei flussi documentali.

Ogni sistema di protocollo informatico, che si intende adottare o realizzare, deve ottemperare a specifiche indicazioni, riportate nel Testo Unico (DPR 445/2000).

Il Centro Nazionale per l’Informatica nella Pubblica Ammini-strazione (CNIPA) e il legislatore italiano hanno individuato 4 livelli

82 PROGETTO FIRM@ Documento di progettazione

di realizzazione della piattaforma del Protocollo informatico:1. Nucleo minimo di protocollo2. Gestione documentale3. Workflow documentali4. BPR.La data del gennaio è un termine non perentorio che in-

dica il termine entro il quale le amministrazioni dovrebbero garantire almeno le funzionalità minime del protocollo.

Il nucleo minimo di Protocollo non è altro che la gestione infor-matica dei documenti in modalità base, caratterizzata da una serie ele-mentare di attività.

In particolare rientrano nel nucleo minimo le attività di:• registrazione in un archivio informatico delle informazioni ri-

guardanti un documento (numero di protocollo, data, mitten-te/destinatario, oggetto, ecc.,);

• segnatura sul documento delle informazioni riguardanti il do-cumento stesso (numero, data, AOO);

• classificazione d’archivio al fine di permettere una corretta or-ganizzazione di tutto il materiale documentale.

La scelta del nucleo minimo evidenzia l’intenzione, almeno in una prima fase, di circoscrivere gli obietti degli interventi della P.A. alla sola registrazione dei documenti (protocollazione), e alla loro orga-nizzazione nel sistema documentario, ciò al fine di considerare solo la documentazione protocollata e quindi coinvolgere nel processo di informatizzazione il solo Ufficio di Protocollo.

La realizzazione del nucleo minimo di protocollo permette co-munque di fornire un servizio di certificazione, attraverso l’assunzione di responsabilità che deriva dalla registrazione di protocollo (operazio-ne che permette di memorizzare le informazioni principali del docu-mento nel registro di protocollo).

Per gestione documentale – secondo livello di realizzazione del Pro-tocollo Informatico – si intende la gestione informatica dei documenti in modalità avanzata la quale comprende:

• registrazione del documento con trattamento delle immagini (scansione di documenti cartacei);

• assegnazione per via telematica al destinatario;

83 PROGETTO FIRM@ Documento di progettazione

• gestione avanzata della classificazione dei documenti (utilizzo di thesauri e vocabolari avanzati ecc..);

• collegamento dei documenti alla gestione dei procedimenti.Realizzare le attività del secondo livello significa, in linea di mas-

sima, concentrarsi sull’obiettivo di creazione di un patrimonio infor-matico, nonché considerare la maggior parte delle informazioni che partono e arrivano alla P.A. coinvolgendo più uffici.

Ciò dovrebbe permettere di:• archiviare, trasmettere e gestire flussi documentali in forma

elettronica, lungo canali telematici sicuri e certificati.• ricercare il contenuto dei documenti in base a criteri logico-

funzionaliPer Workflow Documentali - terzo livello di realizzazione – si in-

tende tutta l’attività di razionalizzazione e conseguente informatizza-zione dei soli processi documentali di un’amministrazione escludendo i processi primari.

Si tratta in pratica di rendere il protocollo un ambiente condivi-so, in cui visualizzare e gestire i documenti elaborati nei vari momenti del workflow, ma con in più un forte impatto dei flussi documentali sui processi di lavoro, che non vengono di fatto reingegnerizzati, ma “adeguati” al flusso documentale.

Il BPR prevede, invece, la reingegnerizzazione di tutti i processi dell’amministrazione al fine di una loro conseguente informatizzazio-ne. Nello specifico ci riferiamo a quei processi, gestiti mediante work-flow, che possiedono dei particolari requisiti quali la complessità, la ripetitività e la stabilità dell’iter.

3.6.3 Il nucleo minimo di protocollo: soluzioni e approcci

Sebbene il DPR 445/2000 fissasse la data del gennaio come termine minimo entro il quale le amministrazioni avrebbero dovuto garantire almeno le funzionalità minime del protocollo, non molti Enti hanno provveduto ad attivarsi in tale direzione.

Tra i pochi progetti relativi al protocollo informatico meritano di essere menzionati:

• il progetto di Protocollo informatico della Regione Campa-nia (segnalato dal “Secondo rapporto sulla innovazione nel-le Regioni italiane ”) : esso é conforme alla normativa vigente e integrato con la gestione dei flussi documentali; si

84 PROGETTO FIRM@ Documento di progettazione

pone l’obiettivo di creare un vero e proprio archivio informa-tico. E’ in uso un’applicazione per la gestione dei documenti che è in grado di decentrare le attività di protocollazione con numerazione unica; collegare i documenti (flusso documenta-le); registrare e segnare il protocollo; classificare i dati a livello archivistico; ricercare e individuare le informazioni e i relativi spostamenti;

• il progetto PROTOINT della Regione Friuli Venezia Giulia (segnalato dal “Secondo rapporto sulla innovazione nelle Re-gioni italiane ”) cofinanziato col 1° Avviso di e-govern-ment e in fase di realizzazione: il progetto prevede, attraverso l’integrazione dei diversi sistemi di protocollo delle PA pre-senti sul territorio regionale, la realizzazione di una rete per lo scambio dei documenti in modo certificato e sicuro, pur in presenza di sistemi informativi e di strumenti applicativi gestionali eterogenei.

Si prevede anche la realizzazione di un indice locale delle infor-mazioni ed una gestione a carico del singolo ente per l’aggiornamento costante dell’indice nazionale. Obiettivo finale del progetto è dunque la semplificazione delle operazioni d’interscambio documentale tra le Pubbliche Amministrazioni, anche grazie all’utilizzo di un sistema di posta certificata;

• il progetto di Protocollo informatico del Comune di Porde-none: per realizzarlo il Comune si è dotato di firma digita-le e di una casella di posta istituzionale certificata ([email protected]), che garanti-sce l’identificazione e l’originalità del documento e consente l’emissione di una apposita ricevuta di recapito. Di conseguen-za tutti i documenti soggetti a registrazione debbono essere inviati a tale indirizzo. La corrispondenza così pervenuta viene immediatamente protocollata e trasferita via e-mail all’Ufficio competente, evitando così l’utilizzo di materiale cartaceo. Per garantire l’originalità della corrispondenza gli utenti debbono fornirsi di firma digitale da richiedere agli Enti Certificatori.

Con riguardo alla Regione Lombardia è da segnalare: il Progetto relativo al Sistema Documentale Regionale.

Obiettivo di tale progetto è la sostituzione dei flussi documentali cartacei con il loro equivalente digitale, in armonia con la normativa vigente, in una logica di ottimizzazione dei costi ed incremento di ef-ficienza.

85 PROGETTO FIRM@ Documento di progettazione

Il sistema documentale regionale agisce secondo tre direttrici:1. Gestire l’ingresso e l’uscita dei documenti elettronici ed even-

tualmente produrre copie digitali anche dei documenti ancora generati in forma cartacea;

2. Seguire il percorso dei documenti all’interno dell’organizza-zione regionale ed assistere gli operatori nell’espletamento dei processi amministrativi ad essi collegati, indipendentemente dalle caratteristiche e dalla natura specifica del procedimento;

3. Mettere a disposizione degli operatori un sistema universale per l’archiviazione digitale di tutti i documenti (elettronici e non) di facile consultazione e conforme alle norme di legge.

Con riguardo alle modalità di funzionamento del sistema si pre-vede che il documento digitale acquisito attraverso una Casella di posta Certificata venga messo a disposizione delle altre componenti del Siste-ma Documentale Regionale.

Inoltre un sistema di Protocollo Informatico assiste l’operatore nella protocollazione automatica o semi automatica del documento digitale, e provvede alla sua archiviazione (Gestione Documentale) ed al suo smistamento, secondo le norme CNIPA.

Si prevede di mettere a disposizione degli operatori un sistema di Gestione Procedimenti (Workflow Management System) per l’even-tuale gestione informatizzata dell’intero iter. I processi amministrativi possono generare nuovi documenti digitali che, se destinati all’esterno, possono essere affidati al sistema di Protocollo informatico e spediti automaticamente mediante il sistema di posta certificata.

Si stabilisce inoltre che un sistema universale ed integrato di Ge-stione Documentale custodisca ogni tipo di documento digitale (anche multimediale) trattato dal sistema informativo regionale e lo archivi, mantenendolo a disposizione per consultazione on line, secondo l’or-ganizzazione richiesta dagli utenti (cartelle, pratiche ecc.).

L’estensione delle caselle di posta certificata a tutte le strutture regionali e la progressiva generalizzazione dell’uso di un unico sistema per la gestione e l’archiviazione dei documenti rappresenta la fase con-clusiva dell’attivazione del Sistema Documentale Regionale.

3.6.4 Il percorso di attivazione

Le regole tecniche per il funzionamento del protocollo infor-matico nella pubblica amministrazione sono rintracciabili nel DPR 445/2000 e nel DPCM 31/10/2000.

86 PROGETTO FIRM@ Documento di progettazione

In particolare il DPCM 31/10/200 introduce una nuova disci-plina per le modalità di registrazione e di trasmissione dei documenti informatici per via telematica.

Tuttavia per poter implementare un’efficiente piattaforma per il Protocollo Informatico le Amministrazioni devono affrontare diverse problematiche.

È la normativa a definire le caratteristiche tecniche ed i requisiti operativi del Protocollo Informatico e ad offrire i contributi di maggio-re rilevanza in materia.

Vengono, infatti, proposti alle PA quali interventi predisporre per rendere operativo il sistema di workflow-management digitale. In particolare viene suggerito di:

• individuare le aree organizzative omogenee (AAOO); • individuare i settori dell’amministrazione che presentano esi

genze omogenee di gestione della documentazione; • nominare i responsabili del servizio di gestione del protocollo

informatico, della gestione dei flussi documentali, degli archivi;• adottare il manuale di gestione del Protocollo da condividersi

all’interno dell’organizzazione; • definire i tempi,le modalità e le misure organizzative/tecniche

finalizzate ad eliminare i protocolli di settore e quelli diversi dal Protocollo informatico.

Ogni amministrazione dovrebbe quindi, fare una precisa analisi che riguardi:

• gli obiettivi di adeguamento organizzativo: individuazione delle AAOO (Aree organizzative Omogenee);

• le modalità tecniche di registrazione dei documenti informatici ed i requisiti di sicurezza dei sistemi di protocollo informatico;

• il formato e le modalità tecniche di trasmissione dei documenti informatici tra le pubbliche amministrazioni.

L’attuazione del progetto protocollo informatico è il primo passo per il raggiungimento degli obiettivi di trasparenza previsti in uno dei 10 obiettivi di legislatura.

A tale scopo sono stati avviati dei gruppi di lavoro con alcune amministrazioni per la realizzazioni di sistemi integrati di protocollo informatico e di processi amministrativi automatizzati. In tale attività il Project Office offre alle amministrazioni una collaborazione tecnica e acquisisce le informazioni relative all’architettura dei vari modelli in

87 PROGETTO FIRM@ Documento di progettazione

riferimento ai vari progetti, al loro contesto applicativo, alle problema-tiche sorte in termini di identificazione degli interlocutori, sicurezza, privacy e quanto altro.

Tutto ciò allo scopo di individuare una casistica da mettere a disposizione delle amministrazioni che intendano in futuro realizzare progetti analoghi e che pertanto si trovano di fronte, a prescindere al tipo di processo amministrativo da mettere in trasparenza, a problema-tiche simili.

88 PROGETTO FIRM@ Documento di progettazione

4.1 L’attivazione di servizi innovativi

Come abbiamo visto l’attuazione concreta di un sistema di e-go-vernment comporta il presidio di un insieme molto variegato di proble-matiche che spesso non sono direttamente sotto la sfera di influenza dei decisori coinvolti nello sviluppo del singolo progetto, ovvero non han-no trovato ancora completa definizione dal punto di vista normativo.

Il grande movimento che si sta facendo attorno ai progetti di e-gov testimonia indubbiamente la grande attenzione e aspettativa che si ha nei confronti di queste innovazioni.

Va tuttavia detto che i servizi e-gov attualmente attivati sfruttano ancora poche delle potenzialità offerte dalla tecnologia e si concentra-no prevalentemente sull’attuazione di portali e canali informativi o di transazioni che tuttavia non incidono significativamente nelle modalità di approccio al problema e quindi dell’aumento dell’efficacia percepita dai cittadini stessi:

• spesso i progetti sono solo di facciata e non si colgono le reali potenzialità innovative dell’e-gov;

• spesso si dà risalto solo all’aspetto informatico-tecnologico.In questo senso il nostro punto di vista è che l’e-Government

richieda di spostare il focus dell’attenzione dalla tecnologia e dall’infor-matica alla complessità dei problemi di natura organizzativo-gestionale che devono essere presidiati sia nella concezione (maggiore “coraggio” nella ricerca di innovazioni radicali nel modo di concepire i servizi tradizionali, ma anche pragmatismo e capacità di implementarli) ma anche nella pianificazione del cambiamento e del business planning per finire con lo start-up e il supporto al cambiamento.

A completamento del lavoro, nella pagina successiva si riporta un breve estratto di una indagine che inquadra il fenomeno dell’impiego di strumenti informatici evoluti a supporto dei processi caratteristici e di quelli di erogazione dei Servizi, nell’ambito degli Enti locali.

In estrema sintesi quello che si riscontra è:a) un basso utilizzo di strumenti di riconoscimento certo del-

l’utente come la CIE, i quali hanno carattere tendenzialmente

4 Conclusioni e prospettive

89 PROGETTO FIRM@ Documento di progettazione

sperimentale soprattutto nelle realtà di medio-grandi dimen-sioni, molti quale risultato “collaterale” nell’ambito dei proget-ti di e-government finanziati nell’ambito del I Avviso del DIT.Ciò che non è chiarito dall’inchiesta di cui si riporta l’estratto è cosa si intenda per impiego di CIE, se il semplice rilascio anche a titolo sperimentale o la concreta possibilità di interazione a distanza da parte del cittadini con l’impiego della CIE;

b) un buon grado di diffusione del protocollo informatico (dovu-to alle ultime innovazioni normative che ne rendono di fatto obbligatoria l’adozione), per il quale da altre fonti sembra però possibile poter affermare che ci si attesta su livelli minimali di attuazione (cd nucleo minimo di protocollo informatico);

c) un livello di diffusione della firma digitale abbastanza basso, con ogni probabilità statisticamente correlato con l’introduzio-ne di strumenti come la CIE e con la partecipazione a progetti di e-governemt, con una diffusione quindi ancora a carattere sperimentale.

Area

geograficaRisposte

Carta identità

elettronica

Protocollo

informaticoFirma digitale

n° % n° % n° %

Province

Nord 37 0 0 26 70 14 38

Centro 18 1 6 8 44 4 22

Sud 19 0 0 11 58 5 26

Isole 9 0 0 5 56 0 0

Italia 83 1 1 50 60 23 28

Comuni medio–grandi (*)

Nord 33 11 33 22 67 9 27

Centro 14 6 43 10 71 4 29

Sud 21 0 0 11 52 2 10

Isole 8 1 13 5 63 0 0

90 PROGETTO FIRM@ Documento di progettazione

Italia 76 18 24 48 63 15 20

Comuni medio-piccoli (**)

Nord 463 17 4 287 62 19 4

Centro 148 4 3 87 59 4 3

Sud 189 4 2 70 37 3 2

Isole 88 1 1 26 30 3 3

Italia 888 26 3 470 53 29 3

Fonte:

Deliberazione

4/2003 della Corte

dei Conti Sezione

Autonomie

(*): più di 60.000

abitanti

(**): da 8.000 a

59.999 abitanti

4.2 L’evoluzione del contesto normativo: il futuro “Codice della PA Digitale”

E’ da segnalare che il Consiglio dei Ministri, l’ novembre , ha approvato in via preliminare lo schema del “Codice delle pub-bliche amministrazioni digitali”. Nelle sue linee generali il codice di-sciplinerà praticamente tutti gli aspetti dell’impiego delle tecnologie nelle pubbliche amministrazioni, con particolare attenzione non solo alla gestione dei documenti, ma anche ai rapporti con i cittadini per via telematica e allo sviluppo, all’acquisizione e al “riuso” dei sistemi informatici.

Le precedenti disposizioni sono abrogate, compresi tutti gli ar-ticoli del testo unico sulla documentazione amministrativa (DPR 445/00). Viene inoltre abrogato il decreto legislativo 10/02.

Vediamo ora le più importanti statuizioni del Codice dell’Ammi-nistrazione Digitale:

Obbligo per le Pubbliche amministrazioni di scambiarsi on-line i dati relativi alle pratiche di cittadini ed imprese.

Obbligo per le Pubbliche Amministrazioni di riorganizzare i pro-pri siti Internet in modo da individuare una serie di contenuti minimi e necessari, compresa la disponibilità di moduli e formulari per via te-lematica. Devono essere disponibili: organigramma con articolazione degli uffici e relative attribuzioni; nomi dei responsabili dei vari pro-cedimenti e relativa durata; scadenze e modalità di adempimento dei procedimenti; elenco completo delle caselle di posta elettronica istitu-zionali; elenco di tutti i bandi di gara; elenco dei servizi forniti in rete.

Obbligo per le Pubbliche amministrazioni di utilizzare la posta

91 PROGETTO FIRM@ Documento di progettazione

elettronica per lo scambio di documenti ed informazioni, verificando-ne la provenienza.

Obbligo per le Pubbliche Amministrazioni di adottare, a partire dal � gennaio , quale unico standard di accesso ai servizi erogati on-line esclusivamente la Carta d’Identità Elettronica e la Carta Na-zionale dei Servizi.

Obbligo di trasferire fondi per via telematica tra Pubbliche am-ministrazioni e tra esse ed i cittadini e le imprese.

Sistematico allargamento dello Sportello Unico Telematico delle Imprese verso l’utenza, snellendo e facilitando il disbrigo on-line delle pratiche e, soprattutto, avviando una omogeneizzazione delle relative procedure a livello nazionale.

Diritto per i cittadini e le imprese a richiedere ed ottenere l’uso delle tecnologie dell’informazione e della comunicazione nei rapporti con le Pubbliche amministrazioni centrali e con i gestori di pubblici servizi statali.

Obbligo per le Amministrazioni pubbliche di accettare da cittadini e imprese i pagamenti effettuati on-line a partire dal � gennaio .

Possibilità per cittadini e imprese di accedere ai documenti e par-tecipare al procedimento amministrativo grazie all’uso dei nuovi stru-menti informatici.

Diritto di trasmettere documenti alla Pubblica Amministrazione con qualsiasi mezzo telematico o informatico, purché sia accertata la fonte di provenienza.

Possibilità, grazie alle nuove tecnologie, di una maggiore parte-cipazione dei cittadini, anche residenti all’estero, alla formazione dei processi decisionali attinenti alla collettività (e-Democracy).

Riconosciuto il valore probatorio al documento informatico.

92 PROGETTO FIRM@ Documento di progettazione

5.1 Fonti normative in materia di firma digitale

In materia di firma digitale bisogna innanzitutto fare riferimento all’art. 15.2 della legge n. 59/97 (Bassanini 1) il quale prevede che “gli atti, dati e documenti formati dalla pubblica amministrazione e dai privati con strumenti informatici o telematici, i contratti stipulati nelle medesime forme, nonché la loro archiviazione e trasmissione con strumenti informatici sono validi e rilevanti a tutti gli effetti di legge”. Merita di essere rilevato il fatto che si viene a stabilire il medesimo tipo di criterio per il settore pubblico e per quello privato.

Per dare attuazione a tale previsione è stato successivamente ema-nato il DPR 513/97 che è stato poi ricompreso nel DPR 445/2000.

Anche l’Unione Europea è intervenuta sulla tematica delle firme con la direttiva CE 93/99 recepita dal legislatore italiano con il D.lgs n. 10/02.

Tale recepimento ha presentato degli aspetti di problematicità non soltanto perché la direttiva prevede più tipologie di firme elettro-niche e diversi livelli di servizi di certificazione, ma soprattutto perché, non occupandosi della validità giuridica del documento informatico, lasciava al legislatore nazionale il compito di coordinare la disciplina di tali firme, con le norme interne relative alla validità e all’efficacia probatoria del documento con esse sottoscritto.

Il legislatore italiano ha stabilito che sia sufficiente la firma elet-tronica affinché Il documento informatico soddisfi il requisito legale della forma scritta.

Invece, affinché il documento informatico faccia piena prova, fino a querela di falso, della provenienza delle dichiarazioni da chi l’ha sottoscritto ha stabilito che debba essere sottoscritto con firma digi-tale o con un altro tipo di firma elettronica avanzata, e la firma debba basarsi su di un certificato qualificato ed essere generata mediante un dispositivo per la creazione di una firma sicura.

Inoltre per la generazione della firma digitale deve utilizzarsi una chiave privata la cui corrispondente chiave pubblica sia stata oggetto dell’emissione di un certificato qualificato che, al momento della sot-toscrizione, non risulti scaduto di validità ovvero non risulti revocato o sospeso.

5 Allegato: le fonti normative di riferimento

93 PROGETTO FIRM@ Documento di progettazione

Attraverso il certificato elettronico si devono rilevare la validità del certificato elettronico stesso, nonché gli elementi identificativi del titolare e del certificatore.

Il legislatore ha poi previsto che in tutti i documenti informatici delle pubbliche amministrazioni la firma autografa o la firma, comun-que prevista, possa essere sostituita dalla firma digitale.

Per quanto riguarda le istanze e le dichiarazioni inviate per via telematica alla P.A. esse sono valide:

a) se sottoscritte mediante la firma digitale, basata su di un cer-tificato qualificato, rilasciato da un certificatore accreditato, e generata mediante un dispositivo per la creazione di una firma sicura;

b) ovvero quando l’autore è identificato dal sistema informatico con l’uso della carta d’identità elettronica o della carta nazio-nale dei servizi.

Fonti normative in materia di firma digitale e di strumenti di identificazione

L. 59/97

Delega al Governo per il conferimento di funzioni e compiti

alle regioni ed enti locali, per la riforma della Pubblica

Amministrazione e per la semplificazione amministrativa

DPR 513/97

Regolamento recante criteri e modalità per la formazione,

l’archiviazione e la trasmissione di documento con strumenti

informatici e telematici a norma dell’art. 15 della legge n.59/97

Direttiva CE 93/99 Quadro comunitario per le firme elettroniche

DPCM 22/10/99Regolamento recante caratteristiche e modalità per il rilascio

della Carta d’Identità Elettronica

DPR 445/00Testo Unico delle disposizioni legislative e regolamentari in materia

di documentazione amministrativa

D.Lgs. 10/02Attuazione della direttiva 1999/93/CE relativa ad un quadro

comunitario per le firme elettroniche

DPR 137/03

Regolamento recante disposizioni di coordinamento in materia

di firme elettroniche a norma dell’articolo 13 del decreto legislativo

n. 10, 23 gennaio 2002

DPCM 13/01/2004

Regole tecniche per la formazione, la trasmissione, la conservazione,

la duplicazione, la riproduzione e la validazione, anche temporale,

dei documenti informatici

DPR 117/2004 Regolamento concernente la diffusione della Carta Nazionale

dei -servizi

DPCM 2/07/04 Competenze in materia di certificatori di firma elettronica

94 PROGETTO FIRM@ Documento di progettazione

5.2 Fonti normative in materia di e-mail certificata

Il marzo il Consiglio dei Ministri su proposta del Mi-nistro per l’Innovazione e le Tecnologie e del Ministro per la Funzione Pubblica ha approvato uno schema i DPR volto a disciplinare le mo-dalità di utilizzo della Posta Elettronica Certificata sia nei rapporti con la PA che tra privati cittadini.

Nella seconda metà di ottobre le Commissioni parlamenta-ri competenti hanno completato i lavori, valutando positivamente lo schema di DPR relativo alla PEC.

Il gennaio il decreto è stato definitivamente approvato dal Consiglio dei Ministri.

5.3 Fonti normative in materia di protocollo informatico

In base alla attuale normativa relativa al protocollo informatico le pubbliche amministrazioni devono provvedere ad introdurre nei piani di sviluppo dei sistemi informativi automatizzati progetti per la realiz-zazione di sistemi di protocollo informatico.

Le pubbliche amministrazioni debbono dunque predisporre ap-positi progetti esecutivi per la sostituzione dei registri di protocollo cartacei con sistemi informatici.

Le pubbliche amministrazioni avrebbero dovuto provvedere entro il � gennaio a realizzare o revisionare sistemi informativi automatizzati finalizzati alla gestione del protocollo informatico e dei procedimenti amministrativi.

Ciascuna amministrazione deve individuare, nell’ambito del pro-prio ordinamento, gli uffici da considerare ai fini della gestione unica o coordinata dei documenti per grandi aree organizzative omogenee, assicurando criteri uniformi di classificazione e archiviazione, nonché di comunicazione interna tra le aree stesse.

I Concetti chiave riscontrabili nella normativa sono:A) Sistema di gestione informatica dei documenti (in forma

abbreviata “sistema”) è l’insieme delle risorse di calcolo, degli apparati, delle reti di comunicazione e delle procedure infor-matiche utilizzati dalle amministrazioni per la gestione dei do-cumenti; esso deve:

• garantire la sicurezza e l’integrità del sistema;• garantire la corretta e puntuale registrazione di protocollo dei

documenti in entrata e in uscita;

95 PROGETTO FIRM@ Documento di progettazione

• fornire informazioni sul collegamento esistente tra ciascun documento ricevuto dall’amministrazione e i documenti dalla stessa formati nell’adozione dei provvedimenti finali;

• consentire il reperimento delle informazioni riguardanti i do-cumenti registrati;

• consentire, in condizioni di sicurezza, l’accesso alle informa-zioni del sistema da parte dei soggetti interessati, nel rispetto delle disposizioni in materia di tutela delle persone e di altri soggetti rispetto al trattamento dei dati personali;

• garantire la corretta organizzazione dei documenti nell’ambito del sistema di classificazione d’archivio adottato.

B) Registrazione di protocollo: per ogni documento ricevuto o spedito dalle pubbliche amministrazioni è effettuata mediante la memorizzazione delle seguenti informazioni:

• numero di protocollo del documento generato automaticamente dal sistema e registrato in forma non modificabile;

• data di registrazione di protocollo assegnata automaticamente dal sistema e registrata in forma non modificabile;

• mittente per i documenti ricevuti o, in alternativa, il destina-tario o i destinatari per i documenti spediti, registrati in forma non modificabile;

• oggetto del documento, registrato in forma non modificabile;• data e protocollo del documento ricevuto, se disponibili;• l’impronta del documento informatico, se trasmesso per via

telematica, costituita dalla sequenza di simboli binari in grado di identificarne univocamente il contenuto, registrata in forma non modificabile.

C) Segnatura di protocollo: operazione che va effettuata con-temporaneamente alla segnatura di protocollo, è l’apposizio-ne o l’associazione all’originale del documento, in forma per-manente non modificabile, delle informazioni riguardanti il documento stesso. Essa consente di individuare ciascun do-cumento in modo inequivocabile. Le informazioni minime previste sono:

• il progressivo di protocollo;• la data di protocollo;• l’identificazione in forma sintetica dell’amministrazione o dell’area.

96 PROGETTO FIRM@ Documento di progettazione

Merita di essere segnalato il fatto che il legislatore si è occupa-to di normare in maniera approfondita lo scambio documentale tra Pubbliche Amministrazioni mentre si è occupato solo marginalmente di disciplinare lo scambio documentale tra P.A. ed altri soggetti quali privati cittadini, aziende, ecc.

Riguardo quest’ultimo punto l’Allegato n°3 al Primo Avviso per la selezione di progetti di e-government “Interoperabilità dei sistemi di protocollo e la Posta certificata” si è occupato dello scambio docu-mentale tra cittadini e imprese dotati di una casella di posta certificata e Pubblica Amministrazione (eventualità che, attualmente, risulta an-cora poco frequente).

Fonti normative in materia di protocollo informatico e posta elettronica certificata

DPR 428/98

(Abrogato e sostituito

dal DPR 445/2000)

Regolamento recante norme per la gestione del protocollo

informatico da parte delle amministrazioni pubbliche

DPR 445/2000Testo Unico delle disposizioni legislative e regolamentari in materia

di documentazione amministrativa

Direttiva M.I.T 9/12/02Direttiva sulla trasparenza della azione amministrativa e gestione

elettronica dei flussi documentali

Allegato n°3 al Primo

avviso per la selezione

di progetti

di e-government

Interoperabilità dei sistemi di protocollo e la posta certificata

D.M. 14/10/03

Approvazione delle linee guida per l’adozione del protocollo

informatico e per il trattamento informatico dei procedimenti

amministrativi

Direttiva

M.I.T.27/11/2003Impiego della posta elettronica nelle pubbliche amministrazioni

PARTE II IL PROGETTO FIRM@

98 PROGETTO FIRM@ Documento di progettazione

6.1 Obiettivi del progetto

Il Progetto Firm@ si configura come un progetto di e-Govern-ment attuato dalla Regione Lombardia, volto ad accelerare l’informa-tizzazione dei processi di gestione del Programma Operativo Regionale (POR), Obiettivo 3 del Fondo Sociale Europeo (FSE), attraverso l’in-troduzione della Firma Digitale.

In particolare, il progetto si occupa di studiare e attuare soluzioni che consentano alla Direzione Generale Formazione Istruzione e Lavo-ro, che ha in carico l’Obiettivo 3 del FSE, di recepire documentazione firmata con Firma Digitale eliminando, o comunque riducendo, scam-bio di documentazione cartacea con gli operatori di formazione, ossia i soggetti beneficiari del Fondo.

Da un punto di vista operativo, il progetto prevede la realizza-zione delle procedure per la gestione di documentazione firmata con firma digitale all’interno di MonitorWEB, l’applicativo già in uso per la gestione on-line delle pratiche di richiesta di finanziamento.

Attraverso MonitorWEB, infatti, la Direzione Generale ha già introdotto un ottimo livello di informatizzazione del processo: la tec-nologia Internet/intranet permette agli operatori di intergire via WEB con la Regione presentando i progetti e effettuandone la gestione in itinere, e permette ai funzionari regionali di svolgere il loro lavoro di ricezione, valutazione, gestione e controllo.

Gli operatori, accedendo a MonitorWEB attraverso una coppia username –password riservate, hanno la possibilità di inserire e trasmet-tere alla Regione le informazioni rilevanti nei diversi momenti dell’iter della pratica. Non essendo gestita la Firma Digitale, tuttavia, l’utilizzo dell’applicativo WEB non ha implicato, per quanto riguarda i docu-menti più critici, l’abolizione della carta, ma il suo affiancamento alle altre informazioni trasmesse dagli operatori alla Regione per via elet-tronica. In altre parole, la documentazione cartacea, firmata in origi-nale con firma autografa, viaggia per così dire in parallelo alla pratica elettronica, lungo l’intero iter di lavoro.

L’introduzione della Firma Digitale rappresenta, quindi, un ul-teriore passaggio per raggiungere un maggiore livello di informatizza-

6 Introduzione

99 PROGETTO FIRM@ Documento di progettazione

zione che vede crearsi, accanto ad un archivio cartaceo costituito da tutti i documenti inerenti una pratica e prodotti sia internamente che esternamente alla Regione, un archivio elettronico parallelo.

Il progetto si propone di affrontare e avviare un processo di riso-luzione delle diverse problematiche di carattere procedurale, organizza-tivo e tecnologico derivanti dall’introduzione della Firma Digitale nella gestione FSE. Le tematiche principali su cui è rivolta l’attenzione sono le seguenti:

• i momenti e le modalità di comunicazione operatore-Regione che prevedono la ricezione di documentazione da firmata da parte degli operatori di formazione

• le tipologie di documento oggetto di scambio e le eventuali criticità derivanti dall’introduzione della firma digitale

• le strutture regionali di riferimento che recepiscono, verifica-no e validano la documentazione pervenuta da parte degli operatori

• gli aspetti di contesto tecnologico ed informatico ai fini di una proposta operativa per l’integrazione delle procedure di firma all’interno del flusso informativo attuale

Per quanto riguarda gli aspetti di carattere procedurale, un pre-supposto fondamentale per l’analisi condotta nel Progetto Firm@ è il Manuale delle Procedure FSE, il documento ufficiale che descrive le attività svolte all’interno della Direzione.

Per quanto riguarda gli aspetti organizzativi, si è individuato un elemento di problematicità nel fatto che la firma digitale è, a tutt’oggi, utilizzata solo in alcuni ambiti e sono poco conosciute le implicazioni di carattere legale e operativo legate al suo utilizzo. Questo comporta la necessità di prevedere un’adeguata istruzione sia del personale addet-to al protocollo che dei funzionari regionali di riferimento, che devono familiarizzarsi con la ricezione di documenti elettronici e con le pro-cedure di gestione di situazioni anomale, muovendosi su un terreno legislativo e tecnologico ancora poco conosciuto,

A proposito del contesto tecnologico, invece, facciamo presente che l’attivazione del Progetto Firm@, va a coincidere con la fase di sperimentazione, a cura di Lombardia Informatica, delle procedure per la ricezione e la protocollazione di documenti firmati con firma digi-tale pervenuti per via elettronica al Protocollo Elettronico Regionale. Oltre alle problematiche di carattere prettamente applicativo, quin-di, si tratta,almeno in una prima fase, di affrontare le problematiche

100 PROGETTO FIRM@ Documento di progettazione

derivanti dalle modifiche apportate all’architettura del sistema Moni-torWEB per permettere il dialogo col protocollo.

Queste osservazioni suggeriscono di collocare il Progetto Firm@ in un contesto strettamente sperimentale e di ipotizzare un passaggio in produzione solo dopo la verifica e il consolidamento delle procedure applicate ad un ristretto numero di pratiche e limitatamente ad alcuni particolari momenti dell’iter burocratico dei progetti FSE.

E’, quindi, senz’altro da prevedere, per un periodo di tempo signi-ficativo, un parallelismo tra le vecchie e le nuove modalità di trasmis-sione di documenti, garantendo che il risultato finale sia esattamente il medesimo, indipendentemente dal flusso procedurale seguito.

6.2 Ambito di riferimento

La Pubblica Amministrazione sta utilizzando le nuove tecnologie basate su Internet per rinnovare e snellire l’iter burocratico di diver-se procedure e per proporre alle aziende e ai cittadini, destinatari dei servizi, una nuova immagine di sé stessa in termini di efficienza e di efficacia.

L’utilizzo della rete permette lo sviluppo di progetti di e-govern-ment, che si propongono la trasformazione delle relazioni interne ed esterne della P.A. mediante l’uso di tecnologie informatiche e di comu-nicazione :

Gli obiettivi di fondo di questi progetti sono:• migliorare la disponibilità del servizio (efficacia del servizio)• dare centralità a cittadini e imprese lungo tutto il ciclo di vita

del servizio• semplificare le procedure amministrative• ottimizzare le attività di produzione del servizio (efficienza del

servizio). Un settore in cui la tecnologia Internet sta offrendo notevoli

vantaggi è quello della gestione delle richieste di finanziamento di at-tività da parte di aziende, enti o privati cittadini su fondi erogati dalla P.A.. Questo tipo di pratiche prevede, solitamente, iter piuttosto lun-ghi e complessi, a partire dalla distribuzione dei formulari cartacei, con tutti i problemi di aggiornamento e di adeguamento a nuovi criteri che vengono via via deliberati, alla loro consegna agli sportelli abilitati, fino all’erogazione del finanziamento e alla certificazione delle spese da parte del destinatario, attraverso tutti i passaggi intermedi quali l’istruttoria e le fasi di gestione in itinere.

101 PROGETTO FIRM@ Documento di progettazione

Il beneficiario spesso non ha visibilità di quanto succede alla pra-tica nei diversi passaggi e stenta ad avere precisi riferimenti interni alla P.A. a cui rivolgere i propri dubbi e le proprie richieste.

A questo proposito, la tecnologia internet sta certamente rappre-sentando la chiave di volta per la rivisitazione di questo tipo di proces-si: gli utenti (enti di formazione, aziende, enti pubblici, ecc.) possono accedere al sito web e consultare le informazioni relative alla legge e ai fondi di loro interesse (destinatari, spese ammissibili, tempi per la presentazione etc.) e, una volta compilata e presentata la pratica on-line, seguirne in tempo reale lo stato di avanzamento, inviare quando richiesto i moduli di certificazione della spesa, e effettuare attraverso il sito tutte le altre operazioni di carattere gestionale e amministrativo previste.

I vantaggi così ottenuti per i beneficiari finali si possono riassu-mere nel modo seguente:

• l’utente non ha più bisogno di recarsi agli sportelli per richiedere informazioni e la modulistica per presentare i progetti

• l’utente compila il progetto dall’ufficio o da casa, tramite Internet, e poi lo invia alla Struttura di competenza sempre via Internet

• il servizio è fruibile ore al giorno, sette giorni su sette• la possibilità di errori è fortemente ridotta• per consultare e compilare la modulistica non c’è bisogno di

installare software particolari, ma è sufficiente un normale browser

• si può seguire in tempo reale lo stato di avanzamento dei pro-pri progetti

• i ritardi nel flusso di lavoro diminuiscono con un vantaggio per tutti.

I vantaggi offerti alla P.A. sono altrettanto evidenti:• l’immagine della Struttura di competenza offerta al pubblico è

quella di un centro vitale ed efficiente, capace di dare e ricevere informazioni e servizi in modo puntuale e rapido

• la banca dati relativa ai progetti è automaticamente alimentata a partire dal data-entry effettuato dagli tenti, senza ulteriori oneri di inserimento

In particolare, Firm@ riguarda il finanziamento di progetti di

102 PROGETTO FIRM@ Documento di progettazione

formazione attraverso i fondi stanziati per l’Obiettivo 3 del Fondo so-ciale Europeo, gestiti dalla Regione Lombardia - Direzione Generale, Istruzione, Formazione e Lavoro. I beneficiari sono gli operatori di formazione (operatori nel seguito) che svolgono attività di formazione nell’ambito della Lombardia.

L’iter per ottenere il finanziamento è piuttosto articolato, ma, dal punto di vista del beneficiario, può essere riassunto nelle seguenti fasi fondamentali:

• la pubblicazione di un bando di gara che stabilisce il settore della formazione, le risorse disponibili e le caratteristiche dei destinatari

• la presentazione dei progetti da parte degli operatori interessati• la valutazione dei progetti• la comunicazione, da parte degli operatori alla Regione, di infor-

mazioni rilevanti in alcuni momenti critici di avanzamento dei progetti, quali l’avvio e la conclusione delle attività formative

• il rilascio degli attestati regionali ai partecipanti ai progetti• la certificazione delle spese• l’erogazione di acconti e del saldo finale• eventuali controlli ispettivi effettuati presso l’operatore per ve-

rificare il corretto svolgersi delle attività

6.3 Documentazione di riferimento

L’argomento trattato dal Progetto Firm@ è vasto e complesso e necessita, per una piena comprensione, della conoscenza di diversi presupposti di base concernenti sia gli aspetti di carattere legale e le-gislativo legati alla Firma Digitale che di quelli legati alle procedure, alle modalità di attuazione e agli strumenti informatici di supporto all’attività della D.G.

Riteniamo indispensabile, quindi, citare le fonti documentali di riferimento relativi ad aspetti di carattere generale, procedurale e tec-nologico già consolidati, ritenuti presupposti di partenza indispensabi-li per la comprensione dell’analisi che segue. Esse sono esplicitate nei seguenti punti:

- Il documento “Progetto Firm@ - Parte I”, in cui si sono esami-nate le problematiche di carattere generale, legale e legislativo legate all’introduzione della firma digitale nella Pubblica Am-ministrazione

103 PROGETTO FIRM@ Documento di progettazione

- il “Manuale delle Procedure FSE”, il documento ufficiale della D.G. decretato con Atto Formale n. data, in cui vengono de-scritti in modo analitico i processi principali attraverso cui la Direzione Generale Formazione, Istruzione e Lavoro svolge la propria attività di programmazione, gestione e controllo del Programma Operativo Obiettivo 3 del Fondo Sociale Europeo (-)

- le “Specifiche Tecniche di MonitorWEB” stilate e distribuite a cura di Archidata. MonitorWEB è il Sistema Informativo Regionale, realizzato in architettura Internet, utilizzato per la presentazione dei progetti di Fondo Sociale Europeo a cura degli operatori di formazione e per la gestione degli stessi da parte delle Strutture competenti della alla D.G. Formazione Istruzione e Lavoro della Regione Lombardia

Ulteriori presupposti di partenza utili alla comprensione di quanto segue, sono le modalità di implementazione del protocollo in-formatico a cura di Lombardia Informatica. Tali modalità non sono a tutt’oggi consolidate in quanto è prevista la loro sperimentazione pro-prio contestualmente a quella del Progetto Firm@. A tale proposito è opportuno senz’altro citare i seguenti documenti, stilati e distribuiti a cura di Lombardia Informatica s.r.l.:

“Linee guida per l’interoperabilità tra Portali Verticali e Protocollo”...“Documento tecnico per l’integrazione tra Portali Verticali e Protocollo”...Rimandando, quindi, ai documenti di cui sopra per la definizio-

ne del contesto legislativo, procedurale ed informatico in cui si opera, ci si propone qui di definire nello specifico le procedure in cui attivare la sperimentazione della Firma Digitale, descrivendone le nuove mo-dalità di attuazione confrontandole con le precedenti.

Nel seguito del capitolo viene approfondito maggiormente il contesto, esaminando alcuni aspetti di dettaglio relativi:

• alla struttura della Direzione Generale Formazione, Istruzione e Lavoro, committente del progetto

• alle procedure di gestione del Programma Operativo Regionale • al Sistema Informativo che attualmente supporta l’attività de-

gli operatori di formazione e dei funzionari regionaliQuesti argomenti sono ampiamente sviluppati nel Manuale delle

Procedure FSE citato in premessa e vengono qui richiamati in modo

104 PROGETTO FIRM@ Documento di progettazione

sintetico solo gli aspetti interessanti ai fini del “Progetto Firma”. Delle procedure di gestione e del Sistema Informativo, quindi, si prende-ranno in considerazione solo i momenti che prevedono scambio di corrispondenza tra operatori e Regione Lombardia. Si rimanda, quin-di, alla lettura del “Manuale delle Procedure” per ogni altro ulteriore approfondimento.

6.4 Articolazione del Progetto

Segue una tabella riassuntiva con le principali fasi in cui si ar-ticola il Progetto Firma@, con il dettaglio delle attività previste, dei risultati attesi e del ruolo giocato dai diversi membri della compagine proponente del progetto.

Tabella riepilogativa evoluzione normativa

Fase Attività principali Risultati attesi Ruolo

1 Analisi e modello di soluzione

- analisi di esperienze di firma digitale nella P.A.

- analisi delle problematiche legate alla attivazione della firma digitale sotto i diversi aspetti: procedurale, tecnologico, organizzativo/culturale all’interno della gestione FSE

- sviluppo relativo a MonitorWEB

- descrizione del modello di funzionamento esplicitando vincoli e alternative di soluzioni informative (macro flussi) e gestionali

- messa a punto di un action plan di riferimento

Documento di sintesi contenente:

- aspetti di carattere generale sulla firma digitale e sua introduzione nella P.A.

- esperienze di firma digitale nella P.A.

- aspetti di carattere procedurale e organizzativo nell’introduzione della firma nella gestione FSE

- modello di soluzione adottato

- specifiche tecniche della soluzione

Action Plan del Pro-getto Firm@

Lattanzio & Associati

Think Lab

2 Sviluppo dei moduli sw

sviluppo e attivazione dei moduli software necessari

attivazione della fase di sperimentazione

Think Lab

105 PROGETTO FIRM@ Documento di progettazione

3 Progettazione funzionamento di dettaglio

- manuale operativo per il funzionamento (proce-durale) del processo gestito da Monitorweb- rappresentazione dei flussi informativi e dei processi- esplicitazione dei ruoli- definizione delle procedure di riferimento

Manuale operativo del funzionamento

Lattanzio & Associati

106 PROGETTO FIRM@ Documento di progettazione

In questo capitolo viene fornito il contesto organizzativo in cui si colloca il Progetto Firm@, attraverso la descrizione sintetica dei se-guenti aspetti:

• le strutture interne alla Direzione Generale Formazione, Istru-zione e Lavoro che hanno in gestione l’attività FSE

• le procedure di gestione suddivise per area d’intervento• il Sistema Informativo attuale, che deve ospitare le procedure

di gestione della firma digitaleQuanto riportato è un estratto di argomenti ampiamente trattati

nel Manuale delle Procedure FSE, citato tra i documenti essenziali di riferimento.

7.1 Strutture regionali di riferimento per la gestione FSE

Il Manuale delle procedure FSE classifica i principali attori regio-nali coinvolti nella gestione del Fondo in:

• Autorità di Gestione• Autorità di Pagamento• Autorità di Controllo di II Livello.

7.1.1 Autorità di Gestione

L’organizzazione della DG Formazione Istruzione e Lavoro at-tualmente si articola in Unità Organizzative all’interno delle quali sono presenti diverse strutture. Ciascuna U.O. e quindi ciascuna struttura opera, per le attività di sua competenza come autorità di Gestione.

La Giunta Regionale, attribuisce la responsabilità dell’attuazione del POR FSE 2000-2006 alla DG Formazione Istruzione e Lavoro. Le varie competenze dell’Autorità di Gestione vengono poi suddivise, nell’ambito della stessa DG, attraverso atti formali interni.

Conformemente al regolamento CE 1260/1999 l’Autorità di Gestione è responsabile dell’efficacia e della regolarità ella gestione e dell’attuazione degli interventi finanziati dal FSE o da altre fonti co-munitarie.

7 Aspetti di contesto

107 PROGETTO FIRM@ Documento di progettazione

I principali compiti dell’Autorità di gestione sono i seguenti:• predisposizione delle modifi che del complemento di program

mazione• elaborazione e presentazione del rapporto annuale di esecuzione• organizzazione della valutazione intermedia, in collaborazione

con lo Stato Membro e la Commissione• predisposizione e defi nizione dei dispositivi e degli atti conse

quenziali• selezione dei progetti• adempimenti delle procedure connesse alla gestione (avvio,

modifi che, revoche, ecc.)• gestione degli importi da recuperare relativi a pagamenti già

eff ettuati• vigilanza sul rispetto degli obblighi in materia di informazione

e pubblicità• compatibilità politiche comunitarie (appalti, pari opportunità,

ambiente)• aiuti di stato• attuazione di misure di controllo interne volte a verifi care la

regolarità delle operazioni fi nanziate• controllo sull’avanzamento della realizzazione dei progetti• ricezione controllo dei dati di spesa nonché garanzia della loro

reperibilità• adozione di disposizioni per la disciplina delle attività di ge-

stione e di controllo

Organigramma della dg formazione, istruzione e lavoro

108 PROGETTO FIRM@ Documento di progettazione

Unita’ organizzative, strutture e loro ruolo

U.O. Struttura Ruolo

Qualificazionedei sistemi riforme e programmazione

Piani e programmi

• Predispone gli atti tipici della programmazione pluriennale in materia di formazione istruzione e politiche del lavoro, in armonia con la programmazione regionale. Stabilisce le modalità di attuazione dell’erogazione dei finanziamenti.

• Predispone i dispositivi (BANDI) di finanziamento;

• Si occupa dell’Accreditamento delle sedi

Qualificazione dei sistemi

• Opera una valutazione di legittimità e di merito sia sulle Azioni di sistema che sulle Azioni rivolte alle persone;

• Svolge controlli a campione sugli operatori che hanno ottenuto i finanziamenti FSE

Innovazione del sistema educativo, dell’istruzionee della formazione professionale

• Assiste la Direzione generale per la realizzazione di un sistema organico di Obbligo Formativo

• Supporto la Direzione generale nella definizione dei criteri di articolazione territoriale dell’offerta formativa

Formazione emercato del lavoro

Politiche attive e preventive del lavoro • Ciascuna struttura coadiuva

la struttura Piani e Programmi nella predisposizione dei dispositivi di finanziamento che riguardano ciascuna tipologia specifica di intervento formativo;

• Ciascuna struttura si occupa della gestione operativa del progetto relativo alla sua area di intervento

Formazione continua e sviluppo dell’imprenditorialita’

Formazione professionale

Centro permanente per l’innovazione dei sistemi informativi

Supporto del sistema formazione

109 PROGETTO FIRM@ Documento di progettazione

Sistema educativo e universita’

Istruzione e diritto allo studio • Ciascuna struttura coadiuva la struttura Piani e Programmi nella predisposizione dei dispositivi di finanziamento che riguardano ciascuna tipologia specifica di intervento formativo;

• Ciascuna struttura si occupa della gestione operativa del progetto relativo alla sua area di intervento

Formazione superiore e universita’

Monitoraggio flussi finanziari e relazioni istituzionali f.S.E.

Autorita’ di pagamento F.S.E.

• Autorità di pagamento FSE.verifica degli indicatori fisici e finanziari FSE raccordandosi con il Sistema Informativo Ragioneria Generale dello Stato

• Supporta l’attività del valutatore indipendente. Monitora e semplifica i flussi finanziari FSE .Certificazione la spesa FSE

7.1.2 Autorità di Pagamento

L’Autorità di Pagamento, secondo quanto stabilito dai regola-menti CE / e 438/, ha la responsabilità della gestione complessiva dei flussi di risorse finanziarie del Programma/i finan-ziato/i.

È infatti l’organismo preposto alla ricezione dei pagamenti dalla Commissione Europea e dal Ministero dell’economia e delle Finanze nonché all’elaborazione e alla presentazione delle richieste di pagamento.

L’Autorità di Pagamento e l’Autorità di Gestione sono collocate in strutture distinte per assicurare la necessaria segregazione funzionale tra la gestione delle attività di controllo e di certificazione delle spese da quelle di gestione vera e propria degli interventi.

Tale separazione nel caso specifico della Regione Lombardia è assicurata dall’attribuzione della qualità di Autorità di Pagamento, e quindi dei compiti ad essa affidati, ad un ufficio specifico - Struttura Monitoraggio FSE – gerarchicamente sottoposto all’U.O. Attuazione Misure FSE.

Quest’U.O. non svolge funzione di line rispetto al POR, per cui non ha né la necessità né tanto meno la responsabilità di svolgere fun-zioni sovrapponibili all’Autorità di Gestione.

L’Autorità di pagamento inoltre accede direttamente a tutti i dati del sistema informativo

110 PROGETTO FIRM@ Documento di progettazione

7.1.3 Autorità di Controllo di II livello

Un accenno all’’Autorità di Controllo di II livello.In posizione di indipendenza rispetto ai responsabili degli altri

processi quest’autorità ha la responsabilità del monitoraggio sistema-tico dell’andamento delle operazioni e dei loro risultati, sia in termini qualitativi che quantitativi. Ha inoltre il compito di accertare l’adegua-tezza del sistema del controllo dei primo livello.

Le diverse tipologie di controllo svolte sono classifi cate in base al soggetto destinatario della verifi ca.

7.2 Le procedure di gestione dei Progetti FSE

Una volta individuati i principali attori regionali coinvolti nel processo di gestione del POR, il Manuale delle procedure FSE va ad individuare e descrivere nel dettaglio le attività svolte dalle Autorità di Gestione e di Pagamento, classifi candole per aree di intervento. Essen-do le procedure svolte dalla Autorità di Controllo di II livello, di com-petenza della Direzione Generale Bilancio, non rappresentano oggetto di indagine. Vengono, invece, individuate alcune procedure trasversali rispetto alle Autorità di Gestione e di Pagamento.

7.2.1 Procedure dell’Autorità di Gestione

Area programmazione che comprende:• Programmazione del POR e del CdP• Programmazione ed emissione dei Dispositivi Procedure di accesso che comprendono• Accreditamento delle sedi operative

111 PROGETTO FIRM@ Documento di progettazione

• Presentazione dei progetti• Valutazione e selezione dei progettiArea gestione che comprende: • Gestione delle attività • Gestione della Garanzia Fidejussoria• Gestione della certificazione antimafia • Gestione delle Commissioni d’esame e rilascio attestati• Gestione delle revoche• Gestione esiti dei controlliArea finanziaria che comprende:• Gestione delle spese (impegni e liquidazioni) • Certificazioni intermedie della spesa e rendicontazione finale

del Beneficiario Finale • Concessione di Aiuti di StatoArea controllo che comprende:• Controllo ordinario di primo livello (In ufficio ed in loco) • Procedure di controllo automatico - Controllo ordinario di

primo livello (in ufficio) • Controllo ordinario di primo livello (in loco) – Controllo

ispettivo • Piste di controllo dell’Autorità di Gestione Area valutazione, monitoraggio, informazione e sorveglianza

che comprende:• Valutazione del programma• Monitoraggio delle attività• Piano di informazione e comunicazione • Sorveglianza del programma• Preparazione delle riunioni del Comitato di Sorveglianza • Rapporto annuale di esecuzione

7.2.2 Procedure dell’autorità di pagamento

• Certificazione della spesa• Gestione delle entrate

112 PROGETTO FIRM@ Documento di progettazione

• Piste di controllo dell’Autorità di Pagamento • Rettifiche finanziarie

7.2.3 Procedure Generali

• Protocollo • Gestione e archiviazione dei documenti• Sistema informativo

7.3 La Gestione Documentale

Particolare attenzione per il Progetto Firm@ merita la procedura Gestione e archiviazione dei documenti citata tra le Procedure Generali. In essa, infatti, tra l’altro, viene descritta l’attuale articolazione e orga-nizzazione dell’archivio delle pratiche FSE -.

Tale archivio risulta suddiviso nelle seguenti principali sezioni:a) l’archivio progetti non finanziati, che contiene la documenta-

zione delle domande di finanziamento dei progetti non am-messi (NA) e non finanziati (NF);

b) l’archivio progetti in corso, distribuito presso i diversi uffici e le strutture di competenza;

c) l’archivio progetti conclusi, che archivia i progetti conclusi, rendicontati e saldati. E’ concentrato in appositi locali;

d) l’archivio pagamenti, suddiviso in archivio Progetti e archivio Operatori e finalizzato a supportare le attività di pagamento relative ai progetti finanziati e ancora in corso;

e) l’archivio accreditamento, che raccoglie la documentazione relativa all’accreditamento delle sedi operative ed è collocato presso la struttura che si occupa della procedura di accredita-mento;

f) l’archivio valutazione, che raccoglie la documentazione (decreti di costituzione dei nuclei di valutazione, verbali, graduatorie, richie-ste di riesame, ecc.) relativa alla valutazione dei progetti FSE;

g) l’archivio dell’Ufficio ispettivo, che raccoglie le pratiche relative alle visite ispettive.

Oltre a questi archivi, vanno ricordati anche gli archivi informa-tici che integrano e completano le informazioni presenti negli archivi cartacei.

113 PROGETTO FIRM@ Documento di progettazione

La struttura complessiva degli archivi cartacei e informatici può essere sinteticamente così rappresentata:

Ai fi ni del Progetto Firm@, come meglio esplicitato nel Capitolo 4., ci concentriamo sui documenti inerenti i progetti FSE, riassumibili nello schema seguente in cui sono organizzati a seconda della fase pro-cedurale.

114 PROGETTO FIRM@ Documento di progettazione

Cartaceo Informatico Documenti e informazoni generali

✓ Domanda di contributo sottoscritta dal:

legale rappresentante

procuratore

persona delegata con atto del...

altro

✓ Progetto originale (fase di presentazione)

✓ Progetto aggiornato o variato (in corso o concluso)

✓ Dati anagrafici dell’Operatore

✓ Dati relativi alle sedi operative

✓Copia della carta d’identità del soggetto che sottoscrive la domanda di contributo

✓Atto costitutivo o statuto oppureriferimento alla pratica dove è archiviato...

✓ Certificato di iscrizione alla C.C.I.A. o depositato c/o...

✓ Modifiche statutarie

✓ Scheda di valutazione del progetto

✓ Domanda riesame valutazione

✓ Motivazione acoglimento/rigetto della domanda

✓ Lettera di intenti ATS/accordo di partership

✓ Costituzione ATS

✓ Certificazione antimafia (se richiesta)

✓ Enta delegato

✓ Lettera di sostegno delle parti sociali

✓ Dichiarazione di conformità provinciali

✓ Dichiarazione di intenti di aziende interessate agli stage

✓ Business Plan

✓ Atri documenti

115 PROGETTO FIRM@ Documento di progettazione

Cartaceo Informatico Atti formali e comunicazioni agli Operatori

✓ Decreto di approvazione delle agraduatorie

✓Lettera di esito istruttoria (procedura adottata per i primi dispositivi)

✓ Pubblicazione dell’esito istitutoria sul BURL con relativi dati

✓ Corrispondenza

✓ ✓ E-mail

✓ Variazione del Legale Rappresentante

Allegato verbale di assemblea straordinaria o altro documento attestante la variazione

✓Richiesta di modifica motivata del nominativo del revisore contabile

✓ Autorizzazione

✓ Richiesta di variazione della sede di svolgimento del corso

✓ allegata autocertificazione idoneità strutture

✓Decreti (revoca, rinuncia, riparametrazione, fermo amministrativo, ecc.

✓ Richiesta di deroghe

✓ Autorizzazioni alle deroghe

Cartaceo Informatico Documenti avvio

✓ Dati generali relativi all’avvio

✓ Atto di adesione firmato

✓Comunicazione avvio sottoscritta dal legale rappresentante contenente:

Dichiarazione del legale rappresentante che comprovi il possesso da parte degli allievi dei requisiti richiesti dal dispositivo

Autocertificazione relativa all’adempimento degli abblighi collegati alle modalità di selezione, definiti nel progetto

Comunicazione nominativo revisione contabile incaricato

Autocertificazione per le strutture non accreditate

✓ Data e n. pagine registro vidimato

✓ Schede stage vidimate registrate

✓ Anagrafica allievi

✓ Elenco allievi con firme autografate

✓ Variazione elenco allievi

✓ Calendario di massima

✓Piano di attività (per azioni di sistema e sovvenzioni globali)

✓Stato avanzamento lavori (per azioni di sistema e sovvenzioni globali)

116 PROGETTO FIRM@ Documento di progettazione

Cartaceo Informatico Liquidazioni e saldi

✓ Dati generali sui movimenti contabili relativi al progetto

Archivio pagamenti

✓ Dati sull’Operatore (Banca, conto corrente, ecc.)

Archivio pagamenti

✓ Decreti di impegno

Archivio pagamenti

✓ Decreti di liquidazione

Archivio pagamenti

✓ Decreto di saldo

Cartaceo Informatico Certificazioni contabile della spesa

✓ Piano dei conti Fondo Sociale Europeo

✓ Dati relativi alle certificazioni della spesa

✓ Elenco giustificativi di spesa

✓Autocertificazione - intermedia (firmata dal legale rappresentante)

✓Autocertificazione - finale(firmata dal legale rappresentante)

✓Relazione di certificazione intermedia della spesa (firmata del revisore)

✓Relazione di certificazione finale della spesa (firmata del revisore)

Richieste di ulteriori acconti

✓ Garanzia fidejussoria (se richiesta)

✓ Svincolo fidejussoria

Cartaceo Informatico Verifiche ispettive

✓ Variabili di ispezione

✓ Provvedimenti:

Archiviazione senza rilievi

Diffida

Revoca

Variabili di ispezione

provvedimenti conseguenti

✓ Variabili G.D.F.

provvedimenti conseguenti

✓ Altro

117 PROGETTO FIRM@ Documento di progettazione

Cartaceo Informatico Fine Attività

✓ Comunicazione fine attività progetto

✓ Relazione finale

✓ Richiesta di commissione d’esami

✓ Richiesta rilascio attestati

✓ Verbale e prove di accertamento finale

Cartaceo Informatico Segnalazioni/esposti

✓ Eventuali segnalazioni/esposti

✓ Altra documentazione su segnalazioni/esposti

7.4 Il Sistema informativo per la gestione FSE

Il Sistema informativo per la gestione FSE da parte della Direzio-ne generale Formazione, Istruzione e Lavoro è costituito dall’insieme delle informazioni, dei flussi e dei processi organizzativi e informati-vi che trattano sia manualmente, sia elettronicamente le informazioni connesse alla gestione, al finanziamento e al controllo del Programma.

Esso può essere descritto anche come un insieme di processi, ciascuno dei quali svolge un insieme di attività, tratta una certa classe di eventi e di informazioni ed è eseguito da una o più unità organizzative.

In estrema sintesi, il Sistema informativo prevede le funzionalità utili:1. alla compilazione, da parte degli operatori di formazione, delle

pratiche di richiesta di finanziamento e di richiesta di accredi-tamento

2. alla valutazione, gestione e controllo della pratiche pervenute da parte dei funzionari preposti

3. alla consultazione ed estrapolazione delle informazioni attra-verso interrogazioni complesse della banca dati

4. alla reportistica per la gestione e il monitoraggio del Programma5. alla gestione finanziaria del Programma6. alla trasmissione delle informazioni relative al monitoraggio al

Ministero del Tesoro e del Bilancio tramite il Sistema Informa-tivo della Ragioneria Generale dello Stato (SIRGS)

7. alla comunicazione dei dati al data warehouse direzionaleLe funzionalità di cui ai punti . e . sono messe a disposizione

dall’applicativo MonitorWEB, prevalentemente rivolto alle attività di carattere gestionale. Sono, di fatto, le funzionalità utili al supporto

118 PROGETTO FIRM@ Documento di progettazione

informatico alle procedure dell’Autorità di Gestione relative alle Aree: Procedure di accesso, Area Gestione, Area Controllo e, parzialmente, Area Finanziaria. Attraverso MonitorWEB, infatti, viene effettuata la certi-ficazione intermedia e finale delle spese da parte dei beneficiari finali.

Le funzionalità di cui ai punti . e . sono messe a disposizione da Nautilus, un sistema di monitoraggio e analisi dati disegnato secondo i criteri progettuali dell’architettura client-server e orientato alla business intelligence. Per motivi di efficienza, dovendo accedere alle informazio-ni in sola consultazione, lavora su una copia aggiornata giornalmente della banca dati di MonitorWEB. Sono funzionalità utili a supportare in modo trasversale l’attività di tutte le Aree, in particolare dell’ Area valutazione, monitoraggio, informazione e sorveglianza.

Per quanto riguarda il punto . l’articolazione degli strumenti è più complessa: per la produzione e gestione degli atti legati all’iter burocratico e finanziario delle pratiche (es. atti di approvazione, di im-pegno e pagamento) è in uso, all’interno di delle Direzioni Generali re-gionali, la procedura informatica di Atti Formali curata da Lombardia Informatica s.p.a. Atti Formali si interfaccia a sua volta alla procedura del Bilancio in uso presso la Ragioneria di Stato, per quanto riguarda la gestione delle risorse finanziarie. Tra Atti Formali e MonitorWEB-Nau-tilus c’è uno scambio reciproco di informazioni: MonitorWEB-Nautilus mettono a disposizione delle strutture regionali competenti le infor-mazioni e la reportistica utile ad attivare la stesura di atti di impegno e pagamento. Tale reportistica comprende, ad esempio, le graduatorie stilate dopo la fase di valutazione e le informazioni relative alla certifi-cazione della spesa in base alle quali vengono liquidati ai beneficiari gli acconti e il saldo relativi ad un progetto. Viceversa, le informazioni di carattere finanziario relative agli atti vengono recepite all’interno della banca dati di MonitorWeb ai fini del mantenimento di tutte le informa-zioni utili a produrre il monitoraggio fisico, procedurale e finanziario. Sono comprese nel punto le funzionalità utili al supporto informati-co delle procedure dell’Area Finanziaria.

Per quanto riguarda il punto ., apposite procedure si preoccupa-no di trasmettere al sistema SIRGS i dati di monitoraggio, attraverso l’interfaccia di comunicazione MonitWEB. L’area di riferimento è an-cora l’Area Finanziaria.

Per quanto riguarda il punto . la banca dati di viene messa a disposizione per alimentare, con apposite procedure a cura della Re-gione, il data warehouse rivolto al sistema direzionale.

Dato che il Progetto Firm@ riguarda in modo specifico l’intro-duzione della firma digitale all’interno delle procedure relative all’Area

119 PROGETTO FIRM@ Documento di progettazione

di Accesso e all’Area di Gestione, viene approfondita solo la compo-nente MonitorWEB dell’intero Sistema Informativo.

7.4.1 MonitorWEB - Schema complessivo del sistema

Lo schema complessivo di MonitorWEB è il seguente:

Attraverso MonitorWEB gli enti di formazione eff ettuano la pre-sentazione on-line dei progetti e delle domande di accreditamento e, per i progetti che vengono fi nanziati, comunicano alla Regione ulterio-ri informazioni utili nelle fasi più signifi cative dell’iter: l’avvio e la con-clusione delle attività formative, la certifi cazione delle spese sostenute e il rilascio dei certifi cati/attestati.

Da parte degli organi di gestione, invece, attraverso MonitorWEB viene svolta la procedura di valutazione dei progetti e vengono inserite o modifi cate le informazioni utili alla gestione dei progetti quali: i dati di protocollo, lo stato di avanzamento e i principali parametri fi sici, fi nanziari e procedurali che possono variare in corso d’opera. Sempre a cura degli organi di gestione viene gestito, attraverso il sistema infor-

120 PROGETTO FIRM@ Documento di progettazione

mativo, il processo di autorizzazione e rilascio dei certificati/attestati regionali e, viene, inoltre, autorizzata l’emissione dei pagamenti da parte dell’Ufficio competente.

Un apposito modulo permette la gestione dell’attività di control-lo di primo livello, ossia delle visite ispettive effettuate presso gli enti di formazione per verificare il corretto svolgersi delle attività formative oltre che la corretta gestione contabile e amministrativa.

Sui dati di MonitorWEB relativi a enti di formazione, progetti, partecipanti viene infine effettuato il monitoraggio finanziario e proce-durale di tutta l’attività di formazione legata al Fondo Sociale Europeo.

Nel seguito vengono esaminati più nel dettaglio i diversi moduli.

7.4.2 Presentazione progetti

Il modulo permette agli enti di formazione di effettuare la pre-sentazione on-line di richieste di finanziamento di progetti di Fondo Sociale Europeo. Le operazioni gestite attraverso il Sistema Informati-vo sono le seguenti:

7.4.2.1 Pubblicazione di un bando di gara

Dopo essere stato pubblicato sul BURL, viene resa disponibile su MonitorWEB la modulistica elettronica relativa ad un nuovo bando. La modulistica è costituita da più sezioni, ossia più pagine WEB in cui vengono logicamente raggruppate le informazioni del progetto richie-ste per quel bando: informazioni di carattere testuale sui contenuti, informazioni di carattere finanziario, numero di partecipanti etc. La modulistica resta disponibile durante tutto il periodo di apertura del bando mentre ne viene inibito l’utilizzo alla data di chiusura.

7.4.2.2 Registrazione di un ente di formazione

La registrazione permette all’ente di formazione di fornire al Si-stema Informativo le proprie credenziali e di ottenere i dati di accesso ai servizi utili alla presentazione dei progetti.

Il valore di username viene proposto dall’ente mentre la password viene assegnata in automatico dal Sistema e inviate via e-mail.

E’ prevista una fase di validazione del profilo dell’ente da parte di un apposito Ufficio al fine di far sì che non siano presenti in banca dati più registrazioni corrispondenti ad un singolo ente.

121 PROGETTO FIRM@ Documento di progettazione

7.4.2.3 Compilazione e trasmissione della modulistica

Gli enti che hanno effettuato con successo la registrazione al Si-stema Informativo possono procedere con la compilazione dei progetti sui bandi pubblicati e aperti. Fino a quando l’ente non effettua l’invio telematico della domanda attraverso un’apposita funzione, la domanda resta in stato di bozza e l’ente può tornare a più riprese sul progetto per apportarne le modifiche opportune. In questa fase il progetto non è visibile ai funzionari regionali preposti alla gestione.

Al momento dell’invio telematico, invece, il Sistema Informativo verifica la congruità di quanto inserito con le specifiche del bando a cui si riferisce il progetto e, se non vengono riscontrate anomalie, con-ferma l’avvenuta operazione, inibendo ulteriori modifiche al progetto e rendendolo disponibile ai funzionari regionali all’interno dell’area loro riservata. Dal momento che, come anticipato in premessa, non essendo a tutt’oggi operativa la firma digitale occorre un documento cartaceo firmato dal legale rappresentante per completare la pratica, il Sistema Informativo permette all’ente di stampare in automatico una Dichiarazione Riassuntiva contenente le principali informazioni del progetto e l’esplicito riferimento agli allegati inviati per via elettronica.

7.4.3 Valutazione

Il Sistema Informativo propone un’area riservata ai membri del Nucleo di Valutazione che ha in carico la protocollazione dei progetti presentati e della successiva fase istruttoria, in cui i progetti vengono esaminati per essere ammessi o meno al finanziamento. Prima di en-trare nel merito di un progetto, i valutatori ne giudicano l’ammissibi-lità formale (valutazione ex-ante). Se la domanda risulta correttamente presentata viene giudicata secondo i diversi criteri di valutazione, già precedentemente stabiliti al momento della pubblicazione del bando. Per ogni criterio è previsto un set di risposte disponibili a ognuna delle quali è associato un diverso punteggio. Al termine della valutazione si assegna ad ogni progetto un punteggio complessivo derivante dalla somma dei punteggi ottenuti sui diversi criteri. I criteri sono relativi sia al soggetto/compagine proponente che al progetto.

Il Sistema Informativo permette al Nucleo di Valutazione di pre-disporre on-line la modulistica per la valutazione dei progetti e degli enti proponenti. In altre parole, i membri del Nucleo possono inserire nel sistema nuovi criteri, assegnarne il set di valori ammessi associan-dovi i punteggio e creare, quindi, le schede di valutazione. Per ogni progetto e ente del bando, procedono poi con la compilazione delle

122 PROGETTO FIRM@ Documento di progettazione

relative schede e, al termine, il Sistema Informativo effettua in automa-tico il calcolo del punteggio complessivo di ogni progetto, dato dalla somma dei punteggi ottenuti sul progetto stesso e sull’ente proponente.

Una volta terminata la valutazione di tutti i progetti di un bando, il Sistema Informativo è in grado di ordinare i progetti ammissibili per punteggio in modo decrescente, stilandone, quindi, in automatico la graduatoria. Una volta note le risorse finanziarie disponibili, è poi in grado di stabilire quali sono i progetti finanziabili e quali sono i proget-ti che, pur rientrando nell’elenco dei progetti ammessi, non risultano finanziabili. Lo stato delle pratiche viene, di conseguenza, modificato in automatico dal Sistema Informativo in base all’elaborazione svolta.

7.4.4 Gestione progetti

Questo modulo contiene tutte le funzioni che permettono agli enti proponenti e ai funzionari di gestione di effettuare via web tutte le operazioni previste per l’avanzamento delle pratiche relative ai progetti presentati.

I principali momenti dell’iter sono: la fase di avvio delle attività, la certificazione intermedia delle spese, il rilascio dei certificati/attesta-ti regionali, la conclusione delle attività e la certificazione finale delle spese.

7.4.4.1 Avvio dei progetti

L’Ente Gestore compila , attraverso MonitorWEB, la scheda di Avvio del progetto e le schede allievi comunicando i dati aggiorna-ti relativamente alla tempistica dell’attività ed ai suoi partecipanti. In questa fase, l’Ente Gestore indica anche i dati del Revisore Contabile del progetto (vedi paragrafo dedicato alla certificazione della spesa). Il Revisore ha il ruolo di controllore delle certificazioni intermedie e finali relative al progetto.

Al termine della compilazione dei dati di avvio, l’Ente Gestore produce la documentazione cartacea utile per completare l’operazione.

Alla ricezione dell’a comunicazione cartacea di avvio, il funziona-rio incaricato ha la possibilità di visualizzare/modificare i dati relativi al numero di allievi, alla durata del progetto e alle date aggiornate di avvio e conclusione nelle sezioni relative ai dati fisici e procedurali. Ha, inoltre, la possibilità di accedere ai dati delle anagrafiche allievi, verificandone la congruenza con le caratteristiche dei destinatari previste dal progetto. Ha, infine, accesso alla funzione utile a segnalare la pagabilità del pri-mo acconto all’Ufficio preposto ai pagamenti.

123 PROGETTO FIRM@ Documento di progettazione

7.4.4.2 Chiusura dei progetti

Una volta terminate le attività previste dal progetto, l’ente ge-store procede con le pratiche utili alla comunicazione di fine attività, comunicando le informazioni definitive relative alla tempistica (date di avvio e conclusione) e al numero di partecipanti che hanno raggiunto i requisiti formativi e sono, quindi, rendicontabili. Una volta effettuata l’operazione di chiusura formale del progetto sul Sistema Informativo, l’ente può procedere con la certificazione finale delle spese.

7.4.4.3 Certificazione periodica delle spese

La certificazione delle spese del progetto è demandata all’ente gestore che, al momento dell’avvio del progetto, sceglie e comunica alla Regione un revisore contabile che ha il ruolo di controllore sulle operazioni contabili svolte dall’ente. I giustificativi cartacei di spesa non vengono, quindi, consegnati e controllati da un apposito ufficio Regionale, ma i dati ad essi relativi vengono inseriti nel Sistema Infor-mativo e tenuti agli atti dagli enti gestori. Dopo l’avvio del progetto, quindi, l’Ente Gestore ha accesso all’inserimento dei giustificativi di spesa nel Sistema Informativo e, a scadenze stabilite, alla stampa del-la documentazione cartacea riassuntiva da consegnare in Regione per completare l’operazione di certificazione periodica della spesa. Conte-stualmente alla documentazione cartacea perviene alla Regione anche una relazione cartacea a cura del Revisore Contabile.

Una volta pervenuta la documentazione relativa alla certificazio-ne intermedia, il funzionario incaricato può accedere alla sezione del progetto dedicata alle certificazioni e verificare la congruenza dei dati con la relazione presentata dal Revisore Contabile. Una volta effettuate le verifiche può, attraverso la maschera confermare o meno l’importo trasmesso e, sempre attraverso il Sistema Informativo, indicare la pa-gabilità del progetto agli Uffici preposti.

7.4.4.4 Rilascio dei certificati/attestati regionali

Lo scopo generale della procedura è quello di snellire il proces-so di rilascio dei certificati/attestati, demandando all’Ente Gestore di progetti di formazione la stampa dei certificati stessi e della documen-tazione utile al rilascio e gestendo, attraverso il Sistema Informativo MonitorWEB, le fasi di richiesta da parte dell’Ente Gestore e di au-torizzazione alla stampa da parte delle strutture regionali competenti. Tali strutture sono:

124 PROGETTO FIRM@ Documento di progettazione

Le tipologie di certificato/attestato regionale attualmente rilascia-te sono le seguenti:

1) Certificato di frequenza2) Certificato di frequenza e profitto3) Attestato di qualifica professionale4) Attestato di qualifica post-diploma5) Attestato di specializzazione professionale6) Attestato di specializzazione post-diplomaIl certificato di cui al punto ) non prevede prova finale ma viene

rilasciato solo in base al raggiungimento di una percentuale minima di frequenza da parte del partecipante che, solitamente, è pari al %. I certificati/attesti di cui al punto ), ), ) e ) prevedono una prova d’esame con una commissione che, nel caso dei certificati di cui al pun-to ) è composta da un funzionario regionale come presidente e da do-centi interni all’ente come membri, mentre, nel caso degli attestati di cui ai punti ), ) ) e ) è a composizione completamente regionale.

Il Sistema Informativo permette di gestire in modalità on-line le comunicazioni tra gli enti gestori e i funzionari di riferimento fina-lizzate alla convocazione della commissione d’esame e alla successiva autorizzazione della stampa dei certificati/attestati da parte degli enti.

Una volta stampati, i certificati/attestati vengono trasmessi alla Regione per la vidimazione finale. Al termine del processo i funzionari incaricati indicano nel Sistema Informativo l’avvenuto rilascio.

7.4.5 Gestione delle visite ispettive

Un ulteriore modulo previsto all’interno del Sistema Informativo MonitorWEB è quello atto a supportare l’attività ispettiva di primo livello, intesa come l’insieme delle attività effettuate dall’amministra-zione nei confronti dei beneficiari e finalizzate alla verifica del rispetto da parte di questi ultimi della normativa e dei fini connessi ai finanzia-menti ottenuti. I controlli di primo livello si differenziano da quelli di secondo livello che rappresentano, invece, una sorta di audit interno all’amministrazione teso alla verifica dell’adeguatezza del sistema atti-vato, in modo da evidenziarne eventuali rischi di inadeguatezza, rischi che potrebbero condurre al mancato raggiungimento degli obiettivi collegati ai fondi comunitari.

I controlli di primo livello trovano la propria fondamentale espli-cazione attraverso una serie di meccanismi di sorveglianza della spesa

125 PROGETTO FIRM@ Documento di progettazione

connessi al monitoraggio di indicatori fisici e finanziari e vedono un contatto diretto con i beneficiari dei cofinanziamenti attraverso il siste-ma dei controlli effettuati ex ante, in itinere ed ex post.

Essi si attuano prevalentemente attraverso delle visite ispettive richieste da apposita Struttura Regionale incaricata e espletate a cura dei membri di un Nucleo Ispettivo, che possono essere funzionari re-gionali o membri interinali di supporto all’attività. I controlli possono essere svolti a campione oppure in seguito a segnalazioni puntuali su determinati progetti e enti gestori.

Il Sistema Informativo propone un potente motore di ricerca che permette di selezionare un set di progetti a campione imponendo dei criteri di selezione su informazioni significative del progetto quali i dati finanziari, l’ambito territoriale e i destinatari. Su uno o più proget-ti selezionati è, quindi. Possibile, aprire una pratica on-line e inserire nella cartella virtuale i vari eventi significativi avvenuti nel corso del-l’indagine (visite, richieste all’ente di documentazione supplementa-re/chiarimenti, segnalazione di anomali verso altri uffici regionali etc.), indicandone l’esito e le eventuali irregolarità riscontrate.

Una articolata reportistica permette, quindi, di monitorare at-traverso il Sistema Informativo l’intera attività ispettiva, effettuando anche indagini statistiche sulla tipologia di irregolarità più o meno fre-quenti.

7.4.6 Porte applicative

Particolare attenzione è da dedicare al modulo che permette di alimentare la banca dati di Monitorweb da parte di sistemi informativi esterni, sfruttando il protocollo SOAP. SOAP è un protocollo applica-tivo e consiste in una serie di regole che permettono ad applicazioni distribuite di scambiarsi informazioni; fornisce un modo consistente e strutturato di trasporto dei dati e di chiamata dei metodi fra le poten-ziali applicazioni distribuite.

Il pacchetto di informazioni scambiate prende il nome di payload ed è una struttura dati, anche complessa, descritta utilizzando XML. Il protocollo di trasporto non è predefinito ma si privilegia http per la sua ampia distribuzione e perché permette di utilizzare le caratteristiche di richiesta/risposta che sono tipiche di SOAP.

In particolare è possibile mettere in comunicazione con Moni-torweb sistemi informativi che producono un flusso di informazioni e di dati relativi a:

126 PROGETTO FIRM@ Documento di progettazione

• anagrafi che degli allievi• giustifi cativi di spesaVisto l’ingente volume di dati, infatti, l’inserimento on-line di

queste informazioni è molto oneroso. Inoltre occorre considerare che esse sono già, di fatto, presenti nei sistemi informativi utilizzati inter-namente dagli enti gestori.

Il modulo permette, quindi, una volta sviluppate le procedure client da parte degli enti gestori, un travaso diretto dei dati dai loro sistemi informativi al Sistema Informativo Regionale MonitorWEB

7.4.7 Architettura

Lo schema fi sico dell’architettura hardware utilizzata può essere rappresentato come in fi gura:

127 PROGETTO FIRM@ Documento di progettazione

Un prerequisito fondamentale per introdurre l’utilizzo della fir-ma digitale nelle attività di gestione del FSE è rappresentato dalla pre-senza di un Sistema di Protocollo Informatico, in grado di recepire in modo automatico documentazione pervenuta in modalità elettronica oltre che cartacea e di effettuare verifiche di congruità e di validità sui documenti firmati in ingresso.

Esigenze simili a quelle di MonitorWEB sono emerse, negli ulti-mi tempi, da parte di diversi Sistemi Informativi interni alla Regione il ché ha portato Lombardia Informatica, responsabile del Sistema Pro-tocollo, alla progettazione di un servizio di comunicazione “privilegiato” fra tali Sistemi (detti anche Portali Verticali) e il Sistema Protocollo Regionale. Le caratteristiche del servizio prevedono l’automazione del-l’attività di protocollazione, garantendo, al Sistema che effettua la ri-chiesta, un feed-back relativo all’esito dell’operazione, comprensivo dei dati di protocollo assegnati, nel caso di esito positivo.

La soluzione tecnologica proposta da Lombardia Informatica, nel rispetto della attuale architettura del Protocollo informatico della Regione Lombardia e dei conseguenti vincoli tecnologici che essa im-pone, prevede una soluzione di interoperabilità basata:

• sulla Posta Elettronica Certificata, per la trasmissione dei docu-menti al Protocollo Regionale

• sull’impiego della Firma digitale, per la validazione dei docu-menti scambiati

Su questi presupposti, Lombardia Informatica ha realizzato un’interfaccia tra il Sistema di Posta Certificata e il Sistema di Proto-collo che permetta ai Portali Verticali la trasmissione delle richieste e la verifica dell’esito dell’operazione con il recupero delle informazioni di protocollo.

Lo schema dell’architettura è il seguente:

8 Il Protocollo Informatico della Regione Lombardia

128 PROGETTO FIRM@ Documento di progettazione

Nel seguito, viene esplicitata con maggiore dettaglio la soluzione adottata. Una trattazione ancora più completa sui requirements fun-zionali relativi all’interoperabilità fra Sistema di Protocollo e Portali verticali e sulla defi nizione delle interfacce dei servizi da realizzare a cura dei Portali stessi, è contenuta nei documenti relativi al Protocollo citati nel Capitolo: Documenti di riferimento.

E’ da considerare che l’attivazione della casella di Posta Elettroni-ca Certifi cata e il suo collegamento con il Protocollo sono attualmente in fase di sperimentazione così come l’introduzione della gestione della Firma Digitale in MonitorWEB.

Questo argomento porta e considerare di limitare, almeno in una prima fase, la mole di documenti elettronici da gestire.

8.1 La Posta Elettronica Certifi cata e il Protocollo Regionale

Per la ricezione di documenti in formato elettronico, è stata at-tivata dalla Regione Lombardia una casella di Posta Elettronica Certi-fi cata (PEC). Le caratteristiche di questo strumento di comunicazione sicura e degli aspetti legislativi che ne supportano l’adozione per la P.A. sono stati ampiamente trattati nella Parte I del documento.

Per automatizzare il processo di protocollazione, Lombardia In-formatica ha realizzato l’interfaccia PEC/PLF tra il Sistema di Posta Elettronica Certifi cata e il Sistema di Protocollo Federato e ha defi nito le specifi che per la trasmissione di documenti.

129 PROGETTO FIRM@ Documento di progettazione

Al fine di stabilire un canale “sicuro” di comunicazione telemati-ca tra il portale e l’interfaccia PEC-PLF viene richiesto che il portale

• sia un Portale Accreditato, ossia un Sistema con un suo codice identificativo noto all’interfaccia PEC/PLF

• utilizzi una casella di posta elettronica ubicata sul mail server della Regione Lombardia.

Per la trasmissione di documentazione elettronica al protocollo, il Portale Verticale Accreditato, deve effettuare le seguenti operazioni:

• predisporre la richiesta secondo le specifiche fornite da Lom-bardia Informatica. In breve la richiesta consiste in un mes-saggio e-mail con uno o più documenti allegati (di cui uno principale, firmato) e con un ulteriore allegato in formato XML contenente, opportunamente formattate, le specifiche della trasmissione (Mittente, Destinatario, Oggetto, Nome dei Documenti ivi contenuti etc.)

• trasmettere il messaggio così composto alla casella di Posta Certificata

• verificare l’esito dell’operazioneA tal fine, l’interfaccia PEC-PLF mette a disposizione i seguenti

servizi:• gestione dei Portali accreditati• richiesta di Protocollazione• riscontro della Richiestae definisce le regole di protocollazione adottate nel sistema infor-

matico.

8.2 Gestione della Firma Digitale da parte del Sistema Protocollo Regionale

Le specifiche del Protocollo Informatico della Regione Lombar-dia stabiliscono che, il messaggio e-mail di richiesta debba contenere:

• un documento primario in formato PDF firmato (con firma forte o debole se accreditata dalla Regione (es. CRS))

• N documenti allegati, in uno dei formati stabiliti dalla Regio-ne, firmati o no

Sui documenti firmati viene effettuata la verifica che la firma sia integra ed il certificato non sia scaduto. In caso contrario, il messaggio viene scartato, con notifica al mittente.

130 PROGETTO FIRM@ Documento di progettazione

Tra i casi di normale protocollazione meritano una particolare attenzione i casi di protocollazione di e-mail, provenienti da sistemi di posta non certificata, contenenti solo testo e/o in allegato documenti informatici non firmati o firmati con un certificato di firma rilascia-to da una “CA non accreditatata”. In tali casi il Protocollista effettua una normale protocollazione evidenziando in un apposito campo del Protocollo le caratteristiche formali dell’e-mail (solo testo, allegati non firmati, CA non accreditata, etc).

131 PROGETTO FIRM@ Documento di progettazione

9.1 L’approccio metodologico

L’analisi del contesto sviluppata nei precedenti capitoli, mette in evidenza che si sono venuti a creare, negli ultimi anni, i requisi-ti per l’introduzione della firma digitale all’interno delle procedure di gestione del POR FSE - Obiettivo 3; ciò, in particolare, per quanto riguarda l’autenticazione della documentazione trasmessa dagli operatori di formazione alla Regione durante l’iter procedurale delle pratiche relative a domande di finanziamento di progetti FSE o di ac-creditamento di sedi operative.

In particolare, le condizioni che evidenziano che i tempi siano maturi per compiere questo passo sono i seguenti:

• l’introduzione di MonitorWEB ha permesso di consolidare un canale di comunicazione on-line “Operatori di Formazione Re-gione Lombardia” mettendo a disposizione funzionalità per un accesso sicuro e per l’inserimento delle informazioni inerenti l’operatore e i progetti di formazione. Attualmente la trasmis-sione delle informazioni viene completata dalla trasmissione di documentazione cartacea, firmata con firma autografa, conte-nente una sintesi dei dati maggiormente sensibili (dati econo-mici, dati identificativi dell’ente).

• l’esigenza di informatizzare la trasmissione di documentazione, da parte dei Sistemi Informativi interni alla Regione Lombar-dia, ha accelerato la messa a punto delle procedure di ricezione di documentazione firmata con firma digitale da parte del Pro-tocollo.

Il prossimo passo consiste, quindi, nello studio delle modalità di introduzione della firma digitale nelle procedure di gestione FSE, tenendo conto delle caratteristiche dei documenti oggetto di scambio e dell’attuale supporto informatico alle procedure stesse.

L’approccio metodologico del Progetto Firm@ prevede i seguenti passaggi:

1. analisi della documentazione cartacea attualmente oggetto di scambio

9 Introduzione della Firma Digitale nella Gestione FSE

132 PROGETTO FIRM@ Documento di progettazione

analisi delle diverse tipologie di documento al fine di ricondurla ad alcune categorie standard. I criteri di aggregazione sono, ad esempio:- la fase procedurale della domanda in cui è richiesta all’opera

tore la presentazione del documento- il soggetto che appone la firma (rappresentante legale, altro

soggetto)- se il documento è o meno generato a partire dalle informazio-

ni inserite nel sistema informativo MonitorWEB2. estrapolazione di ogni singola procedura interessata dall’introdu-

zione della firma digitale:individuazione dei momenti del flusso procedurale in cui av-viene la trasmissione della documentazione di cui sopra e che vengono, quindi, modificati con l’introduzione della firma digitale

3. considerazioni sull’attuale supporto informatico alla procedu-ra da parte di MonitorWEB verifica dell’esistenza o meno di un flusso procedurale già in-formatizzato su cui implementare le procedure di gestione del-la firma digitale

4. studio e realizzazione di soluzioni standardizzare dal punto di vista tecnologico, procedurale e organizzativo per l’introduzione delle firma digitale, al fine di soddisfare le esigenze attuali e quelle che si potranno presentare in futuro.

9.2 Documenti trattati nell’ambito del Progetto Firm@

L’espressione Documenti trasmessi dall’operatore alla Regione, comprende, di fatto, l’insieme delle informazioni utili ai fini dell’otte-nimento del finanziamento/accreditamento. In particolare si tratta di documenti:

• utili a garantire la Regione dal punto di vista legale e finanzia-rio (quali, ad esempio, la garanzia fidejussoria rilasciata dal-l’Istituto di Credito dell’operatore a copertura del progetto in caso di revoca oppure gli obblighi del gestore con cui l’opera-tore si impegna al corretto svolgimento delle attività relative al progetto presentato)

• utili a comunicare alla Regione le informazioni di dettaglio re-lative all’ente, ai progetti di formazione e alle sedi utilizzate

133 PROGETTO FIRM@ Documento di progettazione

Abbiamo già sottolineato in precedenza che tali documenti si di-stinguono attualmente in:

1. documenti elettronici comprendenti dati inseriti nel Sistema Informativo dopo procedura di accesso

2. documenti, firmati o meno con firma autografa, trasmessi in modalità cartacea alla Regione

Alla prima categoria, appartengono, ad esempio le schede conte-nenti i dati dei progetti, compilate via WEB attraverso il Sistema Infor-mativo nella fase di presentazione, dopo aver effettuato l’accesso con i propri dati riservati. Per quanto riguarda queste informazioni, il Pro-getto Firm@ non introduce alcun cambiamento rispetto alla situazione attuale.

Per quanto riguarda la seconda categoria, Il Progetto Firm@ si focalizza sulla documentazione cartacea trasmessa dagli Operatori di formazione alla Regione durante l’iter delle domande di finanziamento di progetti FSE. Verranno, quindi, nel seguito esaminati solo i docu-menti di questa sotto-categoria ed esaminate le fasi procedurali del progetto in cui tali documenti vengono trasmessi. Viene rimandata ad un momento successivo l’analisi di altri documenti; per esempio, quelli relativi alle domande di accreditamento di sedi operative.

Punto di partenza è, quindi, l’elenco riportato al capitolo 2.3 del presente documento, in cui vengono riassunti i documenti che costi-tuiscono un fascicolo di progetto.

Essi sono classificabili, in base all’origine, nel modo seguente (è riportata tra parentesi l’abbreviazione con cui vengono indicati nel se-guito):

• documenti prodotti in automatico dal Sistema Informativo MonitorWEB (prodotto MonitorWEB)

• documenti di cui il prototipo, da compilare e trasmettere a cura dell’Operatore, è presente su MonitorWEB (prototipo MonitorWEB)

• documenti di cui il fac-simile, da utilizzare e trasmettere a cura dell’Operatore, è presente su MonitorWEB (fac-simile MonitorWEB)

• documenti provenienti da altra fonte diversa da MonitorWEB (altra origine)

134 PROGETTO FIRM@ Documento di progettazione

in base alla firma apposta nel modo seguente (è riportata tra pa-rentesi l’abbreviazione con cui vengono indicati nel seguito):

• documenti firmati dal rappresentante legale, o dal soggetto col potere di firma (rappresentante legale)

• documenti firmati da soggetto diverso dal rappresentante lega-le e dal soggetto col potere di firma (altro soggetto)

e in base alla fase di avanzamento del progetto:• documenti trasmessi alla presentazione• documenti trasmessi all’avvio• documenti di notifica variazione trasmessi in itinere• documenti trasmessi alla certificazione intermedia e finale• documenti trasmessi a fine attività• documenti trasmessi in fase di ispezioneLa tabella seguente riassume le considerazione precedenti. I do-

cumenti cartacei che costituiscono un fascicolo progetto sono raggrup-pati per fase di avanzamento e, per ognuno di essi, viene indicato il soggetto firmatario e l’origine del documento.

Presentazione Firma Origine

Domanda di contributo sottoscritta dal: legale rappresentante (o soggetto analogo)

rappr. legaleprodotto Moni-torWEB

Copia della carta d’identità del soggetto che sottoscrive la domanda di contributo

rappr. legale altra origine

Atto costitutivo o statuto oppure riferimento alla pratica dove è archiviato

rappr. legale altra origine

Certificato di iscrizione alla C.C.I.A. o depositato c/o rappr. legale altra origine

Modifiche statutarie rappr. legale altra origine

Domanda riesame valutazione rappr. legale altra origine

Lettera di intenti ATS / accordo di partnership rappr. legale altra origine

Dichiarazione di conformità alle priorità provinciali rappr. legale altra origine

Dichiarazione di intenti di aziende interessate agli stage rappr. legale altra origine

Business Plan rappr. legale altra origine

Notifica delle variazioni

Variazione del Legale Rappresentante rappr. legale altra origine

Allegato verbale di assemblea straordinaria o altro documento attestante la variazione

rappr. legale altra origine

Richiesta di modifica motivata del nominativo del revisore contabile

rappr. legale altra origine

Richiesta di variazione della sede di svolgimento del corso

rappr. legale altra origine

135 PROGETTO FIRM@ Documento di progettazione

Allegata autocertificazione idoneità strutture rappr. legale altra origine

Variazione elenco allievi rappr. legale altra origine

Richiesta di deroghe rappr. legale altra origine

Avvio

Atto di adesione firmato rappr. legale prototipo

MWEB

Comunicazione avvio sottoscritta dal legale rappresentante contenente:

rappr. legaleprototipo MWEB

Obblighi del gestorerappr. legale prototipo

MWEB

Elenco allievi con firme autografe

altro sogget-to (allievi, rappresentante legale)

prototipo MWEB

Costituzione ATSaltro soggetto prototipo

MWEB

Calendario di massimaaltro soggetto (direttore del corso)

Fac-simile MWEB

Garanzia fidejussoria (se richiesta)

altro soggetto (funzionario Istituto di Credito)

prototipo MWEB

Registro didatticoaltro soggetto (direttore del corso)

Fac-simile MWEB

Registro stage

altro soggetto (direttore del corso e respon-sabile azienda)

Fac-simile MWEB

Piano di attività (per azioni di sistema e sovvenzioni globali)

rappr. legale altra origine

Certificazione antimafia (se richiesta)rappr. legale prototipo

MWEB

Stato avanzamento lavori (per azioni di sistema e sovvenzioni globali)

rappr. legale altra origine

Certificazioni contabile della spesa

Piano dei conti Fondo Sociale Europeo rappr. legale prodotto Moni-

torWEB

Autocertificazione - intermedia (firmata dal legale rappresentante)

rappr. legaleprodotto Moni-torWEB

Autocertificazione - finale (firmata dal legale rappresentante)

rappr. legaleprodotto Moni-torWEB

Relazione di certificazione intermedia della spesa (firmata dal revisore)

altro soggetto (revisore)

altra origine

Relazione di certificazione finale della spesa (firmata dal revisore)

altro soggetto (revisore)

altra origine

136 PROGETTO FIRM@ Documento di progettazione

Richieste di ulteriori acconti rappr. legale

Chiusura edizioni

Modello F1altro soggetto (direttore del corso)

prodotto Moni-torWEB

Richiesta di commissione d’esamirappr. legale prodotto Moni-

torWEB

Verbale e prove di accertamento finale.

altro soggetto (direttore del corso, presi-dente)

prodotto Moni-torWEB

Fine Attività

Comunicazione fine attività progetto rappr. legale prodotto Moni-

torWEB

Relazione finale rappr. legale altra origine

Verifiche ispettive

Documentazione richiesta all’ente rappr. legale altra origine

Nel seguito vengono riportati i documenti appartenenti ai diversi incroci Origine/Firma.

137 PROGETTO FIRM@ Documento di progettazione

Origine/firma Rappresentante legale Altro soggetto

Prodotto MonitorWEB

Domanda di contributoComunicazione avvio Piano dei conti Fondo Sociale EuropeoAutocertificazione - intermediaAutocertificazione - finaleRichieste di ulteriori accontiComunicazione fine attività progetto

Elenco allieviModello F1Verbale e prove di accertamento finale

Prototipo MonitorWEB

Atto di adesione firmatoObblighi del gestoreCertificazione antimafiaRichiesta di commissione d’esamiGaranzia fidejussoria

Costituzione ATS

Fac-simile MonitorWEB

Calendario di massimaRegistro didatticoRegistro stage

Altra Origine

Copia della carta d’identità Atto costitutivo o statuto Certificato di iscrizione alla C.C.I.A Modifiche statutarieDomanda riesame valutazioneLettera di intenti ATS Lettera di sostegno delle parti socialiDichiarazione conformità priorità provincialiDichiarazione di intenti per stageBusiness PlanVariazione del Legale RappresentanteRichiesta di modifica revisore contabileRichiesta di variazione della sede Richiesta di derogheVariazione elenco allieviPiano di attivitàVariazioni Elenco allieviStato avanzamento lavoriDocumentazione richiesta in visite ispettive

Relazione di certificazione intermedia della spesaRelazione di certificazione finale della spesa

138 PROGETTO FIRM@ Documento di progettazione

9.3 Le procedure interessate dal Progetto Firm@

Nel Manuale delle Procedure FSE è riportato il seguente schema che traduce il fl usso informativo del ciclo di vita di un progetto FSE:

139 PROGETTO FIRM@ Documento di progettazione

Concentrando l’attenzione sulla documentazione scambiata tra operatori e Regione, è possibile semplificare ulteriormente il flusso e schematizzarlo nel modo seguente:

➞➞

➞➞

➞2) Avvio

1) Presentazione Progetto

3) Certificazione intermedia delle spese

Chiusura delle edizioni formative e rilascio dei certificati/attestati regionali

4) Chiusura del progetto

5) Certificazione finale

In tutte le procedure citate è prevista, da parte dell’ente Gestore, la trasmissione di documentazione firmata da parte del rappresentante legale dell’Ente, da un soggetto con delega di firma o da altri soggetti esterni all’Ente. Le procedure , , , e , relativamente rispettive alla Presentazione, all’Avvio, alla Certificazione intermedia, alla Conclusione e alla Certifica-zione finale si presentano estremamente omogenee per quanto riguarda le funzioni da espletare a cura dell’Ente e del Funzionario per portare a completamento il particolare passo dell’iter. Un elemento importante di diversificazione tra le diverse fasi, invece, è la composizione degli al-legati previsti. Oltre ad essere documenti fisicamente differenti, hanno anche una diversa competenza per quello che riguarda la firma.

In fase di certificazione, per esempio, perviene al funzionario di

140 PROGETTO FIRM@ Documento di progettazione

gestione la relazione trimestrale inviata dal revisore contabile e non dal rappresentante legale o dal soggetto con potere di firma del progetto. In altri casi possono entrare in gioco altri soggetti esterni all’ente, quali, ad esempio, il funzionario dell’istituto di credito che rilascia la garanzia fidejussoria.

Un discorso a parte merita il passo relativo alla Chiusura delle edizioni al fine del rilascio dei certificati. Questo è un processo più articolato, differente a seconda della certificazione rilasciata prevista (certificato di frequenza, frequenza e profitto, attestato di qualifica o specializzazione) e che coinvolge, oltre ai funzionari di gestione, l’Uf-ficio preposto alla nomina delle commissioni d’esame e al rilascio degli attestati. La procedura prevede anche uno scambio di documentazione interna alla Regione che richiede un supplemento di analisi. Al mo-mento, il processo di gestione delle commissioni d’esame non è gestito attraverso MonitorWEB ma ne è prevista a breve l’integrazione e si ri-tiene opportuno rimandare a quel momento l’analisi complessiva della procedura con l’introduzione della Firma Digitale.

Tornando alle procedure , , , e sottolineiamo nuovamente che esse possono essere ricondotte ad una procedura tipo, che prevede sostanzialmente i seguenti passaggi, suddivisi tra quelli effettuati dal-l’operatore e quelli effettuati a cura della Regione, in particolare dal-l’Ufficio Protocollo e dai funzionari regionali di riferimento:

Passaggi effettuati a cura dell’operatore:1. compilazione delle informazioni relative ai progetti, attraverso

le funzionalità offerte dal sistema informativo2. operazione di conferma e conseguente congelamento delle in

formazioni3. preparazione della documentazione cartacea generata in modo

automatico dal Sistema a partire dai dati inseriti 4. completamento del fascicolo con documentazione compilata

dall’operatore in modalità off line rispetto al Sistema Informativo5. trasmissione del fascicolo al Protocollo Regionale

Passaggi effettuati a cura della Regione1. protocollazione dei documenti pervenuti2. trasmissione ai funzionari regionali incaricati3. verifica della documentazione pervenuta a cura dei funzionari

141 PROGETTO FIRM@ Documento di progettazione

9.4 Attuale supporto informatico alle procedure individuate

MonitorWEB off re attualmente ampie funzionalità per la ge-stione del fl usso informativo relativo alle procedure sopra individuate, in particolare per quanto riguarda l’introduzione delle informazioni all’interno del Sistema Informativo. Con l’introduzione della Firma Digitale si aggiungono a tali funzionalità quelle rivolte alla predisposi-zione della documentazione elettronica.

Nel seguito vengono descritte le attuali aree dedicate agli opera-tori di formazione e ai funzionari regionali preposti alla gestione e le modifi che apportate con l’introduzione della Firma Digitale.

9.4.1 Area rivolta agli operatori di formazione

L’area riservata agli operatori permette la navigazione sui progetti suddivisi per fase di avanzamento, come illustrato nelle fi gure seguenti che riportano le pagine di ingresso ai progetti in fase di presentazione e, una volta fi nanziati, di gestione.

Area Operatori: Fase di Presentazione

142 PROGETTO FIRM@ Documento di progettazione

Area Operatori: Fase di gestione

I link in corrispondenza delle diverse fasi (Avvio, Certifi cazione, Rendicontazione e Conclusione) permettono di eff ettuare, per ogni singolo progetto, le seguenti operazioni:

• l’inserimento sul database delle informazioni da comunicare da parte dell’operatore nelle diverse fasi

• la conferma dei dati, operazione che rende defi nitive e im-modifi cabili le informazioni immesse

• la produzione di report sulla base delle informazioni inserite, da fi rmare e consegnare cartacei al protocollo

• l’accesso ai prototipi/fac-simili della documentazione aggiun-tiva, prevista nelle diverse fasi

Per quanto riguarda gli ulteriori allegati che compongono il fascicolo di documenti da produrre, ricordiamo, a titolo esemplifi ca-tivo, che, nella fase di avvio, viene reso disponibile in MonitorWEB il cosiddetto kit di avvio ossia l’insieme dei documenti utili, da scari-care, compilare e trasmettere. Il kit di avvio cambia a seconda del bando.

Come meglio esemplifi cato in seguito, col Progetto Firm@, la gestione del fascicolo si integra maggiormente con le funzionalità di

143 PROGETTO FIRM@ Documento di progettazione

inserimento e conferma dei dati. Una volta terminato l’inserimento dei dati nel database, l’operatore procede con l’upload sul sistema informativo dei documenti da trasmettere e attiva le funzionalità di trasmissione al protocollo informatico.

E’ qui riportato un esempio di kit di avvio attualmente disponi-bile su MonitorWEB.

Area Operatori: Kit di avvio

9.4.2 Area rivolta ai funzionari regionali

L’area rivolta ai funzionari regionali prevede attualmente la possibilità, per ogni singolo funzionario, di accedere alla gestione dei progetti, appartenenti ai bandi di propria competenza, attraverso una maschera di ricerca che permette di impostare criteri di selezione quali:

- IdProgetto- IdBando- IdOperatore- Stato- IdAzione

144 PROGETTO FIRM@ Documento di progettazione

Area Regione: Fase di gestione da parte dei funzionari

Una volta ricercato il/i progetti, è possibile accedere:• alle informazioni inserite nel database • ai report prodotti automaticamente dal SistemaIl collegamento con la documentazione pervenuta cartacea si può

eff ettuare solo accedendo all’archivio cartaceo per il codice identifi cati-vo (IdProgetto) del progetto in esame. Con l’introduzione della fi rma digitale il funzionario ha accesso ai documenti pervenuti in modalità elettronica direttamente da MonitorWEB.

9.5 Modifi che apportate al Sistema Informativo con l’introduzione della Firma Digitale

9.5.1 Descrizione delle procedure prima dell’introduzione della Firma Digitale

Le funzionalità off erte dal sistema informativo MonitorWEB a supporto dell’attività degli operatori e dei funzionari nelle procedurece ,,, e descritte nel paragrafo ., si possono riassumere nel modo seguente:

145 PROGETTO FIRM@ Documento di progettazione

9.5.1.1 Area rivolta agli operatori di formazione

1. compilazione delle informazioni relative ai progettil’operatore accede al sistema MonitorWEB e, quindi, all’am-biente funzionale dedicato alla specifica fase di avanzamento del progetto. Attraverso apposite form elettroniche compila le informazioni significative per quella fase

2. operazione di conferma e conseguente congelamento delle infor-mazionil’operatore conferma i dati inseriti determinando l’avanzamen-to di stato del progetto e il congelamento delle informazioni inserite. Questa operazione abilita la possibilità di stampa dei report da trasmettere cartacei alla Regione.

3. preparazione della documentazione cartacea generata in modo automatico dal Sistema a partire dai dati inseritil’operatore stampa su carta i report prodotti dal Sistema e il soggetto incaricato vi appone la firma.

4. completamento del fascicolo con documentazione compilata dall’operatore in modalità off line rispetto al Sistema Informativol’operatore allega alla documentazione prodotta gli altri allegati previsti, il cui prototipo/fac-simile può essere o meno disponibile sul sito.

5. trasmissione del fascicolo al Protocollo Regionalel’operatore porta/spedisce la documentazione al protocollo regionale.

9.5.1.2 Area rivolta ai funzionari regionali

1. ricezione della documentazione da parte del protocolloil protocollo effettua la ricezione. Rilascia all’operatore la

data di arrivo al protocollo, che fa testo per quanto riguarda i termini di scadenza e, in un momento successivo, effettua la protocollazione rilasciando data e numero di protocollo. Viene assegnatlo un unico numero di protocollo al documento prin-cipale e a tutti i suoi allegati

2. smistamento della comunicazione al funzionario incaricato della gestionein base alla competenza (es. tipo di bando) la documentazione viene smistata al funzionario di riferimento

146 PROGETTO FIRM@ Documento di progettazione

3. verifica formale e di contenuto da parte del funzionario di gestioneIl funzionario effettua il controllo formale della documenta-zione richiedendo eventualmente all’operatore documentazio-ne integrativa

9.5.2 Descrizione delle procedure dopo l’introduzione della Firma Digitale

Con l’introduzione della Firma Digitale, il processo si articola nel modo seguente:

9.5.2.1 Area rivolta agli operatori di formazione

1. compilazione delle informazioni relative ai progettiresta inalterato2. operazione di conferma e conseguente congelamento delle informa

zioni resta inalterato3. preparazione della documentazione cartacea generata in modo

automatico dal Sistema a partire dai dati inseritiuna volta terminato l’inserimento a Sistema dei dati relativi ad una singola procedura (Presentazione, Avvio etc.), l’ope-ratore che desidera servirsi della firma digitale accede ad una nuova sezione, dedicata alla trasmissione dei documenti, in cui ha a disposizione le funzioni per la produzione, il recupero (download) e il successivo caricamento (upload) dei documenti sulla macchina server del Sistema Informativo MonitorWEB.

L’operatore effettua il download sul proprio Computer dei documenti prodotti automaticamente dal Sistema, li fir-ma col. proprio client di firma e ne rieffettua il caricamento (upload) sul Sistema. Al momento del caricamento, Moni-torWEB effettua i necessari controlli di coerenza

4. completamento del fascicolo con documentazione compilata dall’operatore in modalità off line rispetto al Sistema Informativoall’interno della sezione sono disponibili le funzioni di download dei documenti che hanno il prototipo o il fac-si-mile presente sul sistema. L’utente li può scaricare sul proprio client, completare e effettuarne l’upload

5. trasmissione della documentazione al protocollo regionalel’operatore effettua, con apposita funzione messa a disposizio-ne da MonitorWEB, la trasmissione via e-mail dei documenti caricati al Protocollo Elettronico, secondo le specifiche ripor-tate nel capitolo 3.

147 PROGETTO FIRM@ Documento di progettazione

9.5.2.2 Area rivolta ai funzionari regionali

1. ricezione della documentazione da parte del Protocollo Regionale l’e-mail pervenuta viene processata dal Sistema di Protocollo attraverso l’interfaccia realizzata da Lombardia Informatica e, attraverso una tabella di dati condivisa tra i due sistemi, ven-gono restituite a MonitorWEB le informazioni relative a data di arrivo, data e numero di protocollo

2. smistamento della comunicazione al funzionario incaricato della gestioneil funzionario regionale, in base alle informazioni intrinseche nel progetto (numero di bando) accede attraverso il sistema ai documenti di propria competenza caricati tramite upload

3. verifica formale e di contenuto da parte del funzionario di gestionerimandendo all’interno di MonitorWEB, grazie al proprio di-spositivo di firma, il funzionario regionale verifica il documen-to e la firma digitale apposta e valida il documento stesso

9.6 Sintesi della soluzione informatica adottata

Nel seguito viene schematizzata l’architettura hardware della so-luzione informatica adottata e viene esplicitato il flusso procedurale complessivo.

148 PROGETTO FIRM@ Documento di progettazione

9.6.1 Architettura del Sistema

149 PROGETTO FIRM@ Documento di progettazione

Lo schema evidenzia l’insieme dei sistemi che compongono la soluzione architetturale e le loro connessioni:

• il Sistema MonitorWEB, costituito da 4 web server in balancer che accedono ad un ulteriore server di database

• il Server di Posta della Regione Lombardia, utilizzato per spe-dire via e-mail al protocollo, a cura di MonitorWEB, i docu-menti di progetto

• il server di posta con la casella di posta certificata del protocollo elettronico

• il Sistema di Protocollo che si interfaccia al server di posta cer-tificata per recepire e archiviare i documenti e restituire l’esito della protocollazione al Sistema che ha effettuato l’inoltro. Su questo Sistema, infatti, è presente la tabella di database utiliz-zata per la restituzione delle informazioni a MonitorWEB

150 PROGETTO FIRM@ Documento di progettazione

9.6.2 Il fl usso procedurale

Lo schema riassume il fl usso procedurale descritto nel capitolo .. evidenziando sia le operazioni eff ettuate a cura degli operatori che quelle delegate ai funzionari regionale

151 PROGETTO FIRM@ Documento di progettazione

10.1 Individuazione della procedura di test: l’Avvio dei Progetti

In base all’analisi riportata nel presente documento, si sono indi-viduate, all’interno dell’iter burocratico dei progetti FSE, diverse fasi omogenee che comportano scambio di documentazione operatori � Regione e in cui è, quindi, auspicabile prevedere l’introduzione della firma digitale.

L’intento del Progetto Firm@, tuttavia, è soprattutto quello di realizzare una fase di sperimentazione, che permetta di testare le mo-dalità di trasmissione al protocollo informativo e di far emergere even-tuali problemi e criticità legati all’uso di questo nuovo strumento di validazione.

Si è ritenuto preferibile, quindi, concentrare le attenzioni e gli sforzi su una singola fase, tenendo conto che, una volta emersi e risolti gli eventuali problemi insorti, l’estensione della sperimentazione alle altre fasi omogenee non comporta ulteriori incognite.

In particolare, è stato individuato nell’ Avvio dei progetti la fase più adatta per la sperimentazione. La scelta è dovuta a diversi fattori di ordine pratico. Per esempio nel periodo di attivazione della sperimen-tazione sono previsti gli avvii delle attività di progetti attualmente in valutazione, mentre non è prevista la pubblicazione di nuovi bandi. L’avvio, inoltre, è solitamente una fase che si svolge, per un certo ban-do, in un limitato periodo di tempo in cui è previsto che tutti i progetti finanziati inizino l’attività. Tale periodo, per i bandi di prossima pub-blicazione, corrisponde, appunto al periodo previsto per la sperimen-tazione (novembre-dicembre ).

10.2 Supporto informatico alla gestione della Firma Digitale

Segue la descrizione dei moduli software previsti nel Progetto Firm@ per la gestione documentale, suddivisi nelle 2 aree:

• Area Operatori • Area RegioneI moduli dell’Area Operatore si suddividono a loro volta in:

10 Modalità di attuazione della sperimentazione

152 PROGETTO FIRM@ Documento di progettazione

• Moduli per la gestione documentale permettono all’operatore di accedere alle funzioni operative di propria competenza quali la predisposizione e l’inoltro della documentazione

• Moduli per la consultazione permettono all’operatore di accedere ai documenti legati ad un progetto, organizzati per fascicolo, ossia per fase di avan-zamento del progetto stesso. I fascicoli attualmente previsti sono: Presentazione, Avvio, Variazione, Conclusione, Certi-ficazione.

I moduli dell’Area Regione si suddividono a loro volta in:• Moduli di interfaccia col Protocollo Elettronico Regionale:

permettono di recepire l’esito della protocollazione dei docu-menti pervenuti elettronicamente effettuata a cura delle proce-dure di Protocollazione Regionale e di metterlo a disposizione degli utenti del Sistema Informativo MonitorWEB

• Moduli per la protocollazione su MonitorWEB della documentazione pervenuta cartacea: permettono ai funzionari di inserire in MonitorWEB i dati di protocollo dei documenti pervenuti cartacei

• Moduli per la gestione documentale: permettono ai funzionari di accedere alla documentazione tra-smessa dagli operatori, di verificarne la correttezza e di aggior-narne lo stato di avanzamento per il corretto proseguo dell’iter della pratica

• Moduli per la consultazione dei documenti: permettono di accedere ai documenti legati ad un progetto

10.2.1 Area rivolata agli operatori di formazione

10.2.1.1 Moduli per la gestione documentale

L’ambiente di gestione documentale permette all’operatore di predisporre e trasmettere la documentazione firmata, utile per com-pletare la fase di Avvio del progetto. L’interfaccia utente è semplice ed intuitiva, realizzata attraverso la schermata seguente:

153 PROGETTO FIRM@ Documento di progettazione

10.2.1.1.1 Preparazione della documentazione fi rmata

L’attività si articola nel modo seguente:• Dopo aver inserito e confermato nel Sistema Informativo le in-

formazioni richieste per la fase di Avvio, l’operatore ha accesso alla sezione documentale, sopra riportata, per la predisposizio-ne della documentazione elettronica da trasmettere al protocol-lo. Come già anticipato nel capitolo precedente, i documenti vanno scaricati (download) a cura dell’operatore sul proprio computer, fi rmati attraverso il proprio programma client di fi rma digitale e caricati (upload) nuovamente sul Sistema. Le funzioni di download e upload vengono eff ettuate attraverso le funzionalità messe a disposizione del Sistema Informativo.

L’elenco dei documenti da caricare e trasmettere viene predi-sposto in automatico dal Sistema. Alcuni documenti sono obbligatori per tutti gli operatori, altri solo per alcuni di loro (es.il documento di costituzione dell’ATS è obbligatorio solo per gli operatori che non si presentano come attuatori singoli), altri ancora sono facoltativi.

Per ogni documento viene riportato:

Area Operatore: Predisposizione e trasmissione della documentazione elettronica fi rmata

154 PROGETTO FIRM@ Documento di progettazione

o IdDocumento: codice che individua in modo univoco il documento all’inter-no di una tabella anagrafica che li comprende tutti

o Descrizione: descrizione estesa del documento

o Presentazione: indica se il documento deve essere necessariamente presentato solo su supporto cartaceo, oppure se sono possibili entrambe le modalità

o C/E: indica la modalità di presentazione scelta dall’operatore

o Origine: indica una delle seguenti tipologie:documenti prodotti e compilati dal Sistema in modo automa-tico, a partire dalle informazioni analitiche inserite dall’ope-ratore. Tali documenti devono essere firmati e ricaricati sul Sistemadocumenti il cui prototipo è disponibile sul sistema per essere scaricato (download), completato, firmato e caricato firmato (upload)documenti non disponibili sul Sistema, da produrre e caricare (upload) a cura dell’Ente

o Stato indica lo stato del documento del documento tra uno dei seguenti:

155 PROGETTO FIRM@ Documento di progettazione

Idstato Stato

A In attesa di protocollazione

B Da Trasmettere

D Trasmesso cartaceo, da protocollare

G Generato

M Annullato dal funzionario regionale

N Annullato dal protocollo

P Protocollato

S Scartato dal protocollo

T Trasmesso, in attesa di protocollazione

V Valicato

X Non validato

Le funzionalità a disposizione dell’operatore sono le seguenti:permette di eff ettuare il download del documento sulla macchina dell’operatorepermette di eff ettuare l’upload di un documento locale sulla mac-china server del Sistema Informativo

selezione della presentazione cartacea

permette di visualizzare il documento permette di eliminare un documento non ancora trasmesso in Regionepermette la visualizzazione delle informazioni riassuntive del do-cumento, in particolare quelle relative alla sua protocollazioneL’operatore eff ettua, a sua discrezione, il download e l’upload dei

fi les che ritiene necessario trasmettere per completare la fase di avvio. Appone la fi rma, attraverso il proprio software apposito, ai documenti prima di eff ettuarne l’upload.

Nel caso in cui il documento preveda la fi rma, MonitorWEB, al momento dell’upload, eff ettua la verifi ca che l’utente stia caricando eff ettivamente un fi le fi rmato.

Nel caso in cui il documento sia stato prodotto da MonitorWEB, inoltre, al momento dell’upload viene verifi cata la corrispondenza tra il contenuto del fi le che si sta caricando con quello generato dal sistema.

156 PROGETTO FIRM@ Documento di progettazione

10.2.1.1.2 Trasmissione della documentazione firmata

L’attività si articola nel modo seguente:• l’Ente Gestore, attraverso il link Trasmetti documenti, invia al

Protocollo Elettronico Regionale, la domanda e i relativi alle-gati elettronici previsti dal dispositivo, secondo le specifiche fornite da Lombardia Informatica nel documento “Specifiche tecniche per l’interoperabilità fra Portali verticali e Sistema di Protocollo”. Il processo di trasmissione dei documenti si artico-la, di fatto, nelle seguenti microoperazioni:

- Predisposizione dei messaggi e-mailPer ogni documento da trasmettere, viene predisposto un diverso

messaggio e-mail, così costituito:1. un documento primario in formato PDF firmato (con firma

forte o debole se accreditata dalla Regione (es. CRS))2. N documenti allegati (in uno dei formati suggeriti dalla Regione

nel Manuale di Gestione) firmati o no.3. un file XML compilato utilizzando la DTD “Segnatura.dtd”

(la stessa definita dal CNIPA per lo scambio di informazioni fra protocolli della PA). Il file XML, di cui si allega un esem-pio, deve contenere le informazioni utili ad identificare univo-camente il Portale mittente, il richiedente il finanziamento e la singola richiesta, in particolare:

• nella sezione <Identificatore> devono essere presenti le informazioni identificative del Portale e del messaggio:

- <CodiceAmministrazione>, è il codice iden-tificativo assegnato da Regione Lombardia al Portale, è composto da 3 caratteri

- <NumeroRegistrazione>, è l’identificativo della richiesta inviata dal Portale e deve essere composta dai tre caratteri del CodiceAmmi-nistrazione, da un numero a 7 cifre(sequenza nell’anno) e da un numero a 4 cifre(anno), se-parati dal “trattino”

• nella sezione <Mittente> devono essere contenute le informazioni relative all’ente o privato che richiede il finanziamento

• nella sezione <Destinazione> devono essere contenu-

157 PROGETTO FIRM@ Documento di progettazione

te le informazioni della AOO di Regione Lombardia destinataria del messaggio (cosi come riportate nel-l’esempio)

4. l’oggetto composto in accordo alla seguente sintassi:XXX – NNNNNNN – NNNN – stringa liberaDoveXXX : Identificativo del PortaleNNNNNNN: numero di sette cifre (progressivo nell’anno di riferimento)AAAA: Anno di riferimento di 4 cifre.Stringa libera: l’oggetto del messaggio componibile autonomamente dal PortaleLe suddette informazioni devono essere separate da carattere “-“ (trattino)

- Invio di ogni e-mail al Protocollo Elettronico Regionale- Aggiornamento dello stato dei documenti in Trasmesso e in

attesa di protocollazione

10.2.1.2 Moduli per la Consultazione

Questo ambiente, attivabile dal link relativo ai Progetti Finanziati nell’ambiente di Gestione Progetti descritto nel capitolo 4.4.1, per-mette all’operatore di consultare i documenti relativi ad un progetto. I documenti sono organizzati in fascicoli al fine di agevolare la ricerca di uno specifico documento. L’ambiente viene realizzato attraverso le videate seguenti:

158 PROGETTO FIRM@ Documento di progettazione

Area Operatore: Consultazione della documentazione elettronica fi rmata (1)

Area Operatore: Consultazione della documentazione elettronica fi rmata (2)

159 PROGETTO FIRM@ Documento di progettazione

L’operatore ha la possibilità di effettuare download e visualizzazione dei documenti già esaminati dal funzionario regionale

10.2.2 Area rivolta ai funzionari regionali

10.2.2.1 Moduli di interfaccia MonitorWEB - Protocollo Elettronico Regionale:

Questi moduli permettono di acquisire all’interno di Moni-torWEB l’esito della protocollazione elettronica.

Una volta che l’e-mail perviene alla Casella di Posta Certificata, vengono esaminati i file ad essa allegati (ossia il file XML e il documen-to eventualmente firmato) e si presenta la seguente casistica:

- l’e-mail viene ricevuta correttamente e in attesa di essere pro-tocollata

- l’e-mail viene protocollata e vengono assegnati al/ai documen-to/i in essa contenuti numero e data di protocollo

- il documento viene protocollato con eccezioneQuesto caso si verifica quando Il certificato è valido ma non è di una C.A. oppure il certificato è scaduto. Il personale ad-detto alla ricezione alimenta, attraverso una maschera prevista all’interno del Sistema del Protocollo le informazioni relative all’eccezione che si è verificata. Tale informazione, come me-glio esplicitato in seguito, viene restituita a MonitorWEB e resa disponibile ai funzionari. Nel casi in cui il certificato sia revocato o sospeso viene protocollato regolarmente.

- il documento non viene protocollato. Non vengono protocolla-te e-mail con documenti firmati ma pervenuti con contenuto non integro oppure firmati ma con un certificato non valido. In questo caso (cosiddetto di ripudio) il Sistema del Protocollo invia all’indirizzo e-mail del mittente un messaggio del tipo: ri-fiutata email con oggetto: <OGGETTO> dove <OGGETTO> è l’oggetto dell’e-mail contenente il documento rifiutato.

In modalità batch notturna, apposite procedure a cura di Lom-bardia Informatica, provvedono ad aggiornare una tabella di Database, disponibile in sola lettura alle amministrazioni che utilizzano il proto-collo Elettronico, con lo stato e i dati di protocollazione dei documenti pervenuti durante il giorno alla casella di posta certificata.

La tabella preposta alla restituzione delle informazioni ha la se-guente struttura:

- Codice del portale che ha effettuato la richiesta

160 PROGETTO FIRM@ Documento di progettazione

- Codice della richiesta- Oggetto della e-mail con cui è pervenuto il documento- Data e ora di ricezione- Indirizzo e-mail del mittente- Indirizzo e-mail del destinatario- Codice dell’Area Organizzativa Omogenea protocollante- Numero di Protocollo- Anno di protocollo- Data e ora di Protocollo- Struttura assegnataria- Assegnatario- Motivo dell’eventuale scarto- Stato di riscontro- Data di creazione- Data di ultima modificaI valori possibili contenuti nel campo sono i seguenti:- e-mail pervenuta, in attesa di protocollazione- e.mail scartata dal protocollista- e-mail protocollata- e-mail annullata

10.2.2.2 Moduli per la gestione documentale

I moduli per la gestione documentale da parte dei funzionari regionali permettono di effettuare operazioni sia sui documenti perve-nuti per via elettronica attraverso il Protocollo Elettronico Regionale, sia sui documenti pervenuti cartacei. Su questi ultimi il funzionario ha la possibilita di inserire i dati di protocollazione.

Le funzionalità a disposizione dei funzionari sono le seguenti:• Ricerca dei progetti con documenti da elaborare attraverso

l’impostazione dei seguenti criteri: - stato del documento- tipo di fascicolo (Avvio, Conclusione, Certificazione,etc)

161 PROGETTO FIRM@ Documento di progettazione

- operatore- progetto- identificativo documento

• Accesso ai fascicoli documentali dei progetti selezionati attraverso la ricerca

• Accesso ai documenti contenuti nei singoli fascicoli, suddivisi per:- Documenti pervenuti- Documenti non presentati- Documenti già validati a cura del funzionario- Documenti non validati dal funzionario- Documenti presenti come FAC-SIMILE su

MonitorWEB• Possibilità di inserimento dei dati di protocollazione nel caso

di documenti pervenuti cartaceamente.• Possibilità di modiificare lo stato del documento, segnalando la re-

lativa validazione o non validazione indicando contemporanea-mente eventuali note. Le informazioni così inserite possono essere recepite in tempo reale dagli operatori di formazione

L’ambiente di gestione documentale da parte dei funzionari viene realizzato attraverso le videate seguenti:

10.2.2.3 Moduli per la consultazione dei documenti

Questi moduli funzionali permettono al funzionario l’accesso in sola consultazione ai documenti legati ad un progetto, all’interno dell’area Gestione Progetti. Tale area propone al funzionario il quadro sinottico dei progetti di competenza, suddivisi per bando e per stato di avanzamento.

A partire dall’elenco dei progetti Finanziati, è possibile acce-dere ai fascicoli di ciascun progetto e, quindi, visualizzare/scaricare (download) i singoli documenti di un fascicolo.

L’interfaccia grafica è la seguente:

162 PROGETTO FIRM@ Documento di progettazione

Area di gestione regionale: Funzione di Ricerca dei documenti

Area di gestione regionale: Accesso ai fascicoli di un progetto

163 PROGETTO FIRM@ Documento di progettazione

Area di gestione regionale: Accesso ai documenti di un fascicolo di progetto

Area di counsultazione regionale: Gestione Progetti Finanziati

164 PROGETTO FIRM@ Documento di progettazione

Area di counsultazione regionale: Accesso in lettura ai singoli documenti

Area di counsultazione regionale: Accesso ai fascicoli di un progetto

165 PROGETTO FIRM@ Documento di progettazione

AA.VV. “Il Protocollo nella Pubblica Amministrazione” Università della Calabria

AA.VV. “La documentazione amministrativa”, Maggioli,

AA.VV. “Speciale E-government” in Guida agli Enti Locali de Il Sole 24 Ore n°34/

CAMMARATA e MACCARONE, “La firma digitale sicura” Giuffrè

CHIRENTI “Innovazione nella pubblica Amministrazione: Dal sistema di protocollo informatico alla automazione dei flussi di lavoro”, Agorà Edizioni

GUERCIO, “Archivistica Informatica”, Carocci Editore

MERLONI, “L’informazione delle pubbliche amministrazioni”, Mag-gioli,

PIAZZA e BUTTI, “Il protocollo informatico per la pubblica ammini-strazione”, Maggioli

RIDOLFI, “Firma elettronica, tecniche, norme, applicazioni”, Angeli

TOMMASI, “La firma digitale guida pratica all’uso” Maggioli

Bibliografia

166 PROGETTO FIRM@ Documento di progettazione

www.anci.it/cie/

www.buoniesempi.it

www.cantieripa.it

www.card.infocamere.it

www.cartaidentita.it

www.cnipa.gov.it

www.comune.bologna.it/firma_digitale/

www.comune.modena.it/firma/

www.comune.pordenone.it/servizi/protocollo.htm

http://comunicare.provincia.parma.it

www.corteconti.it

www.crcitalia.it

www.crs.lombardia.it

www.ct.rupa.it

www.forumpa.it

www.governo.it/GovernoInforma/Dossier/carta_nazionale_servizi/

www.governo.it/GovernoInforma/Dossier/firma_digitale/

www.governo.it/GovernoInforma/Dossier/protocollo_informatico/

www.indicepa.gov.it/

www.innovazione.gov.it

www.interlex.it

www.lispa.it

http://mizar.comune.livorno.it/firmadigitale/

www.monitorweb.it

Sitografia

167 PROGETTO FIRM@ Documento di progettazione

www.protocollo.gov.it

http://protocollo.rupar.puglia.it/

www.provincia.fi.it/firmadig/prog.htm

www.provincia.torino.it/e_gov/firma.htm

www.regionedigitale.net

www.regione.emilia-romagna.it/firma.digitale/

www.regione.lombardia.it

www.studiocelentano.it

www.ulss.tv.it/firmaelettronica/

www.unict.it/direzione/consip/Firma_digitale.pdf

http://utenti.lycos.it/FirmaDigitale