LA POSTA ELETTRONICA CERTIFICATA

(UN SISTEMA DI TRACCIATURA DELLE E-MAIL)

Contesto nel quale è stata sviluppata

Per la Pubblica Amministrazione l'utilizzo delle e-mail, sia ai fini dell'efficienza interna sia per migliorare e velocizzare il rapporto con l'esterno (cittadini ed imprese), rappresenta una fondamentale evoluzione delle abitudini operative, testimoniata anche dalle numerose iniziative, sotto il profilo normativo e infrastrutturale, che si sono susseguite nell'ultimo decennio.

Nell'ambito delle attività di indirizzo dello sviluppo informatico delle amministrazioni centrali, assegnate all'AIPA (Autorità per l'informatica nella Pubblica Amministrazione) dalla L. 39/93, sono stati avviati progetti intersettoriali tra i quali quello della rete unitaria della Pubblica Amministrazione (RUPA).

Tale progetto aveva come obiettivo quello di ottenere risparmi economici e di efficienza, attraverso l'acquisizione di infrastrutture e servizi di rete da fornitori unici, selezionati mediante gara. In sostanza una intranet delle Pubbliche Amministrazioni.

Presso l'AIPA venne costituito il Centro Tecnico per la Rete Unitaria della PA, con il compito di governare il progetto nelle varie attività di realizzazione, gestione degli SLA, supervisione della sicurezza, supporto alle amministrazioni, gestione dei cambiamenti e delle evoluzioni tecnologiche e contrattuali.

L'AIPA con l'art. 176 della legge 196/2003 è stata trasformata in CNIPA (Centro Nazionale per l'informatica nella P.A.) e nella stessa struttura è stato incorporato il Centro Tecnico, art. 5 L. 343/2003.

Il CNIPA è un organo collegiale che opera presso la Presidenza del Consiglio per l'attuazione delle politiche del Ministro per l'Innovazione e le Tecnologie, con autonomia tecnica, funzionale, amministrativa, contabile, finanziaria e con indipendenza di giudizio.

Attraverso le infrastrutture realizzate nell'ambito della RUPA il Centro Tecnico è riuscito a mantenere l'operatività delle amministrazioni nei casi di attacchi (virus, etc.) e di avviare attività a carattere sperimentale in tema di antispam, e sistemi di posta elettronica con "tracciatura".

Le prime, tra le attività suddette, rientrano tra gli obiettivi della RUPA di erogare i servizi in un contesto di "sicurezza", le seconde sono state avviate per promuovere servizi di qualità in grado di favorire lo sviluppo informatico delle amministrazioni. Il contesto tecnico nel quale tali attività sono state svolte è quello del centro di gestione dei servizi di interoperabilità della RUPA (CG-I) che svolge, tra l'altro, funzioni di snodo per i servizi di posta elettronica tra le amministrazioni connesse ed Internet; tale centro svolge altresì funzioni di sicurezza per i servizi erogati. In questi anni di esercizio della RUPA (2000 - 2004) il numero di mail in circolazione tra le amministrazioni connesse e con il mondo esterno, è cresciuto costantemente, in maniera quasi proporzionale è cresciuto il numero di virus intercettati. Il numero di worm e di messaggi UCE (Unsolicited Commercial E-mail) ha subito una netta crescita a partire dalla fine dello scorso anno.

Le misurazioni hanno confermato che il fenomeno è, sia pur inferiore, nella media dei valori registrati in internet. Come accennato, negli ultimi anni il legislatore ha posto attenzione al tema della trasmissione di documenti informatici con mezzi telematici. In particolare norme primarie stabiliscono che la trasmissione di documenti informatici con mezzi telematici è valida ad ogni effetto di legge (art 15 comma 2 L. 59/97). Nel Testo unico sulla documentazione amministrativa DPR 445/2000 l'art. 14 definisce la validità della trasmissione telematica di documenti informatici (vd. riquadro).

art. 14 (per la pubblica amministrazione e i privati):
  • 1. Il documento informatico trasmesso per via telematica si intende inviato e pervenuto al destinatario, se trasmesso all'indirizzo elettronico da questi dichiarato.
  • 2. La data e l'ora di formazione, di trasmissione o di ricezione di un documento informatico, redatto in conformità alle disposizioni del presente testo unico e alle regole tecniche di cui agli articoli 8, comma 2 e 9 comma 4, sono opponibili ai terzi.
  • 3. La trasmissione del documento informatico per via telematica, con modalità che assicurino l'avvenuta consegna, equivale alla notificazione per mezzo della posta nei casi consentiti dalla legge.

Partendo da tali basi normative il Centro Tecnico ha lavorato sull'ipotesi che il legislatore volesse individuare uno o più "canali" telematici e protocolli affidabili.

Sul piano tecnico, se da un lato la previsione di indirizzo telematico rendesse suggestiva l'ipotesi di utilizzare la posta elettronica e di conseguenza suggerisse come indirizzo telematico quello di una casella di posta elettronica, com'è noto lo standard SMTP non è sufficiente a fornire le garanzie richieste. Invero, l'exetended SMTP è in grado di fornire le ricevute di ricezione, purché tale funzionalità sia prevista su tutta la catena di mail server tra quello del mittente e quello del destinatario (estremi compresi).

Ma in ogni caso, il problema è evidentemente quello di fornire in maniera automatica ricevute opponibili, in grado di attestare rispettivamente l'avvenuto invio e la ricezione. Tali ricevute, inoltre, dovrebbero avere un formato ed un contenuto univocamente definito. Infine, è evidentemente necessario definire un sistema di tracciatura in grado di registrare le attività, con particolare riguardo all'emissione delle ricevute.

La complessità del tema, unitamente all'assenza di standard di riferimento, suggerì al Centro Tecnico di utilizzare da un lato un approccio sperimentale e dall'altro ampliare il dibattito sul tema. A tal fine il CT avviò, anche con la partecipazione di soggetti privati, un gruppo di lavoro con l'obiettivo di approfondire il tema e definire un insieme di requisiti di sistema e le regole tecniche per il funzionamento; quasi contemporaneamente, il CT ha realizzato un sistema aderente a tali regole, tuttora utilizzato dalle PAC.

La pubblicazione delle regole ha creato un significativo interesse e i numerosi contributi pervenuti dalle amministrazioni e dalle società, le realizzazioni effettuate da queste ultime (ad oggi si conoscono circa 20 realizzazioni la cui conformità tecnica alle regole è stata anche provata su testbed), nonché il sistema realizzato nell'ambito della RUPA, hanno portato alla messa a punto delle regole tecniche, con la specificazione di alcuni particolari e l'aggiunta di ulteriori funzionalità.

Tale versione consolidata verrà allegata al DPCM e rappresenterà la prima versione di "produzione". Da sottolineare che, mentre nelle fasi iniziali dello studio e delle sperimentazioni l'orientamento era quello di soddisfare le necessità della Pubblica Amministrazione e dei rapporti tra la PA e i privati, successivamente, l'interessamento al tema di significativi settori privati, nei quali proficuamente può essere introdotto uno strumento in grado di elevare le garanzie di consegna e non ripudio di documenti informatici, ha portato utili contributi di arricchimento. D'altra parte sotto il profilo giuridico le previsioni normative citate si applicano anche nei rapporti tra privati, con il consenso che va stabilito di volta in volta.

L'architettura di sistema prescelta, anche a seguito delle sperimentazioni di diversi modelli, non si discosta dal modello di posta elettronica internet, rispetto al quale, sul piano tecnico, sono state introdotte funzionalità aggiuntive, rafforzando i punti nei quali la posta elettronica internet risultava insufficiente per gli scopi previsti dalle norme di riferimento.

Non meno importanti, come vedremo nel seguito, risultano le norme che regolano il comportamento dei gestori e le garanzie di ordine giuridico, tecnico ed organizzativo che tali soggetti saranno tenuti a fornire.

Prima di descrivere le funzionalità del sistema di posta certificata nel suo complesso, è bene evidenziare alcune considerazioni preliminari. Il sistema di posta elettronica certificata (PEC), per affiancarsi e sostituire progressivamente i sistemi tradizionali di trasmissione documentale che forniscono attestazioni opponibili, deve soddisfare i requisiti di tali sistemi:

  • Gli eventi e la loro validità -l'invio del documento, la consegna nella disponibilità del destinatario, il collegamento dell'indirizzo di posta ad un procedimento (l'utente può averne diversi), l'inalterabilità del documento trasmesso, la tracciatura della trasmissione, l'accettazione di tali eventi come validi e rilevanti nei procedimenti amministrativi (concorsi pubblici, gare, etc)-;
  • L'affidabilità dei gestori -i gestori del servizio, in ragione della delicatezza delle attività da svolgere, devono prestare adeguate garanzie-;
  • La valenza delle norme preesistenti -La normativa in uso, per quanto possibile, non deve essere alterata dall'introduzione di un nuovo sistema-.

Tuttavia, la PEC, utilizzando tecnologie informatiche, si presta a correggere alcune "anomalie" del sistema tradizionale quali:

  • Certezza del contenuto della spedizione (nel mondo tradizionale non esiste legame tra le ricevute, che sono relative ad una busta di trasmissione e il contenuto di quest'ultima);
  • Mancanza dell'identità di chi spedisce (non vengono richieste le generalità di colui che effettua la spedizione);
  • La granularità temporale (nei sistemi tradizionali la precisione è al giorno, si può essere meno sicuri sull'ora attestata).

Descrizione e funzionamento della posta elettronica certificata (PEC)

La posta elettronica certificata viene definita come un sistema di posta elettronica in grado di soddisfare i principi della norma.

Un utente che voglia utilizzare un servizio di posta certificata dovrà rivolgersi ad un gestore autorizzato. Può svolgere l'attività di gestore un qualunque soggetto pubblico o privato dotato di requisiti tecnologici e organizzativi, che dovranno essere valutati da un organismo competente (nello schema di DPR in approvazione il CNIPA).

Un'istruttoria dovrà accertare il possesso dei requisiti richiesti per l'erogazione del servizio. L'esame riguarderà ad esempio l'architettura di sistema prescelta e l'ambiente gestionale ai fini della robustezza, sicurezza e aderenza alle funzionalità richieste. Altri aspetti riguarderanno le procedure di gestione e i servizi accessori resi disponibili.

Per i soggetti privati, alle categorie di valutazioni precedenti si aggiungono quelle relative alla tipologia societaria e all'insussistenza di clausole ostative (ad esempio è il caso di soggetti per i quali risultano procedimenti penali pendenti per delitti in danno di sistemi informatici o telematici).

Su tali gestori viene esercitata attività di vigilanza, sia per verificare il mantenimento dei requisiti richiesti sia per accertare, in base a segnalazioni, la violazione di qualche prescrizione. Alla sottoscrizione di una richiesta di fornitura di un servizio PEC, il gestore fornirà all'utente, previo accertamento dell'identità, le istruzioni e le credenziali per essere riconosciuto e accedere al servizio.

La preparazione di un messaggio di posta certificata non richiede client o software specifici, questi ultimi potrebbero essere forniti dal gestore per casi particolari; pertanto, l'utente può utilizzare gli strumenti ai quali è abituato. Per effettuare la spedizione, l'utente dovrà essere riconosciuto dal sistema ed il gestore avrà il compito di controllare che l'utente corrisponda al mittente. Il canale di comunicazione tra il client dell'utente ed il server dovrà essere sicuro ovvero utilizzare protocolli sicuri.

Successivamente alla fase di autorizzazione all'uso del servizio, il gestore dovrà effettuare controlli relativi all'introduzione di codice malevolo (è definito tale qualunque codice introdotto, senza l'assenso di chi lo riceve, per arrecare danno a qualcuno o utilizzare impropriamente risorse elaborative). Nel caso in cui un utente introduca un codice malevolo, riceverà dal sistema un messaggio di anomalia che impedirà la trasmissione.

Superati gli ulteriori controlli formali viene emessa una ricevuta di accettazione. Tale ricevuta, opponibile a tutti gli effetti, contiene i cosiddetti dati di certificazione (mittente, destinatario, data, ora, minuti e secondi dell'invio, oggetto, codice univoco identificativo del messaggio) e identifica come momento dell'invio l'immissione di un messaggio, formalmente corretto, nel circuito PEC. La ricevuta contiene sia dati immediatamente leggibili all'utente sia dati strutturati (formato XML) utilizzabili per elaborazioni automatiche. Il messaggio formalmente corretto viene inserito dal gestore in una busta di trasporto (tecnicamente una struttura MIME) che contiene il messaggio originario e i dati di certificazione, la busta viene firmata dal gestore con la propria chiave privata e a questo punto spedita al destinatario. In maniera contestuale o comunque con gli stessi dati viene registrata l'operazione in un file di log (per inciso in tale file sono riportate anche le attività non andate a buon fine quali anomalie, errori, etc.).

L'attestazione temporale viene ricavata da un sistema UTC. Il gestore del mittente, qualora il destinatario non appartenga ad un proprio dominio (nel qual caso dovrà comunque svolgere le attività previste da quel lato, comprese l'emissione di ricevute e la scrittura nel log), dovrà stabilire, consultando il previsto indice dei gestori PEC, se il destinatario appartenga ad un dominio PEC tra quelli gestiti dai soggetti autorizzati. In tal caso dovrà indirizzare direttamente il dominio del destinatario, altrimenti dovrà produrre nei confronti del mittente una segnalazione chiara, con la conseguenza che ovviamente non verrà successivamente recapitata al mittente la ricevuta di avvenuta consegna. In ingresso il gestore PEC non è tenuto ad accettare posta internet ed in ogni caso, nei confronti di un proprio destinatario PEC, deve trattarla come anomalia, imbustando il messaggio nel formato previsto dalla busta di anomalia.

Nel caso in cui il messaggio in ingresso provenga da un dominio PEC il gestore dovrà, controllare l'integrità della busta di trasporto (contenente il messaggio originario inviato) e la validità della firma, prima di emettere nei confronti del gestore del mittente una ricevuta di presa in carico, che testimonia il passaggio di responsabilità tra i due gestori. Il sistema del gestore del destinatario a questo punto si trova a dover gestire un messaggio di posta certificata valido che, senza entrare nei particolari tecnici dei casi possibili, può essere tanto un messaggio quanto una ricevuta. Il sistema dovrà quindi distinguere tali casi utilizzando i dati presenti nell'intestazione della busta e, qualora si tratti di un messaggio, effettuare i controlli di sicurezza.

Tali controlli dovranno verificare l'eventuale presenza di codice malevolo nel messaggio e negli eventuali allegati e qualora il sistema riscontri tale presenza, il messaggio verrà imbustato in una busta di sicurezza con un'indicazione di potenziale contenuto pericoloso per il destinatario. In entrambi i casi di eventuale contenuto "potenzialmente dannoso" o di contenuto "corretto", il sistema dovrà collocare il messaggio nella mailbox del destinatario. In caso di esito positivo dell'operazione il messaggio si considera a tutti gli effetti nella disponibilità del destinatario e viene emessa nei confronti del mittente una ricevuta di avvenuta consegna, che testimonia al mittente il recapito del messaggio all'indirizzo telematico del destinatario.

Tuttavia, nel caso in cui il messaggio sia stato inserito in una busta di sicurezza il mittente riceverà nella ricevuta tale indicazione, che testimonia che il messaggio pervenuto all'indirizzo telematico del destinatario potrebbe non essere letto da quest'ultimo per motivi di sicurezza (ricordiamo che il messaggio di posta certificata in questo caso aveva superato in ingresso i controlli di sicurezza del gestore del mittente).

La ricevuta di avvenuta consegna, contiene i dati di certificazione in formato leggibile, gli stessi in formato elaborabile (XML) e, su richiesta del mittente, potrà contenere l'intero messaggio o un suo condensato (hash). Evidentemente nel primo caso la ricevuta è autoconsistente ed è adatta ad un certo tipo di interazione, nell'altro caso, più efficiente, si presta ad essere utilizzato maggiormente in contesti applicativi. Nel caso in cui il sistema non riesca a recapitare il messaggio nella mailbox del destinatario il mittente riceverà una ricevuta di mancata consegna.

Il sistema utilizzerà protocolli che consentano di realizzare connessioni protette. Nei confronti dell'utente, in caso di smarrimento delle ricevute, il sistema continua a mantenere il valore formale, in quanto dalle informazioni contenute nei log, tutte correlabili, è possibile ricostruire la transazione e riemettere le ricevute (al netto del messaggio originario che non viene conservato).

Per quanto concerne la pubblicità degli indirizzi di posta certificata, per le amministrazioni pubbliche è già previsto ed operativo, un registro consultabile sia attraverso protocollo LDAP sia attraverso interfaccia WEB, successivamente verrà realizzato un web service; per i privati, ovviamente solo in caso di consenso di questi ultimi, non è ancora previsto un tale registro. In definitiva il sistema di posta certificata si presenta, sia pure collocato in internet e potenzialmente aperto ai messaggi provenienti da internet, come un sistema "controllato" di scambio mail, con: percorsi definiti, attori noti o conoscibili, sistemi di tracciatura degli eventi, utilizzo di strumenti per l'accertamento delle identità, controlli sulla presenza di codice malevolo, protocolli e canali sicuri, regole governate e vigilate nella loro applicazione.

Un sistema indubbiamente più resistente agli spammer, tuttavia, non è immaginabile sostituire la posta certificata a tutto il traffico e-mail internet, così come nel mondo tradizionale cartoline, lettere e pacchi viaggiano con sistemi differenti dotati di diverso grado di affidabilità.

FRANCESCO TORTORELLI

  • Francesco Tortorelli
  • Attualmente responsabile dell'Ufficio Servizi di interoperabilità evoluti e di cooperazione applicativa del Centro Nazionale per l'Informatica nella Pubblica Amministrazione (CNIPA).
  • Si è laureato in Matematica (indirizzo applicativo numerico) nel 1983 all'Università di Napoli.
  • Dal 1999 al 2003 ha lavorato al Centro Tecnico per la rete unitaria della P.A. in qualità di responsabile dell'Area interoperabilità, dove si è occupato, tra l'altro, del coordinamento delle attività di realizzazione dei servizi di interoperabilità RUPA, delle attività sperimentali e del loro consolidamento, tra le quali la posta elettronica e l'accesso ad internet.
  • Dal 1988 al 1999 ha lavorato alla CONSOB, in carriera direttiva, dove ha ricoperto diversi ruoli di responsabilità negli ambiti di realizzazione di progetti applicativi telematici e conduzione del sistema informativo.
  • Dal 1983 al 1988 ha lavorato alla Datamat S.p.A. , dove con i ruoli di analista programmatore e capo progetto ha lavorato in molteplici contesti applicativi.
  • la rete contro lo spam indice
    tortorelli