| Uso della firma digitale in ambito SIPA |
| |
| Al fine di dematerializzare impegni ed ordini, occorre soddisfare i seguenti requisiti di base: |
|
a) sostituzione delle attuali firme autografe dei dirigenti/funzionari abilitati con le rispettive firme digitali;
b) sostituzione della conservazione degli attuali documenti cartacei con l’archiviazione dei documenti elettronici firmati digitalmente, secondo le regole per l’archiviazione dei documenti generati elettronicamente: questo aspetto viene trattato nel presente documento solamente in termini generali e per quanto concerne il successivo punto d).
Per il buon funzionamento del sistema complessivo (SIPA) sono altresì da garantire alcuni aspetti tecnico-organizzativi relativi alla sicurezza:
c) presenza di regole certe in merito alla responsabilità dei soggetti (Amministrazione mittente, RGS, Banca d’Italia), nel seguito organizzazioni;
d) possibilità di individuazione certa dell'organizzazione nel cui ambito sia stato alterato un dato (accidentalmente o meno), ovvero la possibilità di verificare (nell’accezione di opporre a terzi), in qualsiasi momento, che cosa è stato trasmesso e cosa è stato ricevuto ;
e) garanzia della riservatezza dei dati "riservati" (segnatamente che riguardano i beneficiari), ovvero impossibilità anche solo di lettura degli stessi da parte di persone non autorizzate.
|
|
|
| Firma digitale |
|
| Occorre ricordare due requisiti normativi relativi alla firma digitale: |
- le procedure utilizzate per la generazione, l'apposizione e la verifica delle firme digitali debbono presentare al sottoscrittore, chiaramente e senza ambiguità, i dati a cui la firma si riferisce e richiedere conferma della volontà di generare la firma (DPR 445/2000 art.29 sexies);
- l’operazione di firma deve generare un unico file (o stringa di dati) detto busta o file firmato aderente allo standard PKCS#7 (RFC 2315) relativo al contenuto "dati firmati" e contenente:
- i dati originari, in chiaro;
- la firma;
- il certificato di sottoscrizione del firmatario, che contiene la sua chiave pubblica ed opzionalmente il ruolo in base al quale ha potere di firma (DPR 445/2000 art.27).
|
|
| Per quanto concerne il ruolo, poichè il citato DPR lo pone come facoltativo, per il SIPA si ritiene che allo stato attuale sia opportuno non farne uso e gestire invece il problema a livello applicativo. |
|
|
| Responsabilità |
|
| Già nell’impostazione generale del SIPA si era deciso che ogni organizzazione è responsabile: |
- della qualità dei dati che trasmette;
- del corretto aggiornamento della propria contabilità (informatizzata o meno),
- della gestione della sicurezza all’interno del proprio dominio.
|
| Nel prosieguo dei lavori era poi stato precisato che spetta all'organizzazione mittente garantire che vengano trasmessi unicamente dati per i quali siano state verificate: |
- l’integrità dei dati firmati (i dati non sono stati alterati dopo l’apposizione della firma);
- la validità della firma apposta (chi ha firmato era – alla data – abilitato ad apporre la propria firma sui dati, ad es. relativamente all’importo).
|
|
| È altresì evidente che l'organizzazione che riceve i dati per poi inoltrarli ad altre organizzazioni (la RGS alla Banca d’Italia, quest’ultima al circuito bancario e postale) deve garantire che non avvengano alterazioni improprie di quanto ricevuto rispetto a quanto trasmesso. In altre parole, poiché l'organizzazione che riceve i dati ha necessità di controllarli, memorizzarli, elaborarli, selezionare quelli da inoltrare ed eventualmente modificarne il formato, detta organizzazione deve garantire che non venga alterato il contenuto informativo dei dati stessi. |
|
| Chi riceve i dati non è tenuto, quindi, ad effettuare verifiche di integrità dei dati o di attendibilità della firma, in quanto entrambe già garantite dal mittente (v. seguito): ha però l’esigenza di estrarre i dati dalle buste PKCS#7 ai fini del controllo e dell’elaborazione, eseguendo una semplice operazione di sbustamento (tramite apposito software di mercato, disponibile anche in ambiente mainframe). |
|
|
| Confrontabilità tra quanto spedito e quanto ricevuto |
|
| Per poter verificare (nell’accezione di opporre a terzi), in qualsiasi momento, che cosa è stato trasmesso (Amministrazione, RGS) e cosa è stato ricevuto (Amministrazione, RGS, Banca d’Italia), è necessario che chi trasmette i dati li memorizzi opportunamente così come spediti e, analogamente, chi li riceve li memorizzi così come ricevuti: in questo modo sarà sempre possibile confrontare quanto spedito con quanto ricevuto ed individuare le eventuali responsabilità di una manomissione. Occorre perciò individuare i “morsetti” ove poter effettuare gli eventuali confronti tra i dati trasmessi dal mittente e quelli ricevuti dal destinatario, nonché le “tratte” tra i morsetti (sia di rete che interne all'organizzazione di appartenenza) lungo le quali va garantita la sicurezza dei dati. |
|
| Nell'architettura prevista per il SIPA (cfr. "Specifica del servizio" ed il suo Allegato B "Specifiche EAS) la "catena" di sistemi ed apparati utilizzati tra il sistema informativo dell'organizzazione e la rete è costituita dall’EAS che unitamente al Front End Multi-Servizio (FEMS), fornisce il servizio di trasporto responsabile della comunicazione tra le Applicazioni. In particolare: |
- EAS: Entità di Accesso al Sistema, è il punto di accesso alla rete di trasporto e si può considerare come un confine applicativo del sistema informativo dell'organizzazione, in quanto vi risiedono le code di input e di output;
- FEMS: (Front End Multiservizio): ) è il punto di accesso alla rete e costituisce il confine fisico tra il mondo della RUPA e il sistema informativo degli utenti connessi.
Dialoga con EAS, gestendo i servizi specializzati di Message Switching, File Transfer e Transazionale. FEMS sono le macchine che interfacciano fisicamente i sistemi informativi delle Amministrazioni alla rete e che provvedono al trasporto dei dati attraverso la rete.
|
|
|
| Da quanto detto segue che i morsetti sono: |
- le code EAS dal punto di vista applicativo (trasporto logico), più precisamente le code di output per chi trasmette e quelle di input per chi riceve,
- FEMS dal punto di vista della rete (trasporto fisico);
|
| mentre le tratte sono di due tipi: |
- interne, di esclusiva responsabilità dell'organizzazione (Amministrazione, RGS, Banca d’Italia), cioè quelle tra il sistema informativo dell'organizzazione stessa ed EAS, tra EAS e FEMS ( FEMS comunica mediante collegamenti Token-ring o Ethernet in protocollo SNA logical unit 6.2 con il prodotto software EAS installato sul sistema informativo dell'Utente o su Server UNIX fornito da SIA)
- di rete (RUPA/RNI) cioè FEMS-to.FEMS (di organizzazioni diverse).
|
|
| Le code EAS sono però "temporanee", quindi la memorizzazione dei dati trasmessi e ricevuti consiste rispettivamente nella memorizzazione dei dati: |
- prima di accodarli alle code di output,
- come presenti sulle code di input, prima di elaborarli;
|
| come delineato negli schemi riportati alla fine del presente documento. |
|
|
| Riservatezza dei dati |
|
| Occorre ricordare che: |
- l'identificazione dell'organizzazione mittente è garantita dall'utilizzo di EAS (autenticazione)
La funzione di autenticazione prevede un riconoscimento reciproco fra EAS e FEMS, attraverso la condivisione una chiave comune. Questa è calcolata da SIA mediante un processo che in modo random, attraverso l'utilizzo di un algoritmo, genera un valore personalizzato per ogni utente.
La "quantità di sicurezza" è considerata come password per tutte le applicazioni che vogliono utilizzare i servizi di rete mediante quel punto di accesso.
- La funzione di crittografia di rete che garantisce la sicurezza tra FEMS-to-FEMS è realizzata attraverso l’utilizzo del protocollo IPSEC direttamente implementato da Windows 2000. Tale funzionalità viene realizzata mediante la soluzione Micorsoft Kerberos e consente di realizzare la funzione di autenticazione e crittografia delle diverse frame IP inoltrate verso le controparti di rete.
- sulle code EAS, sia di input che di output, i dati sarebbero crittografati solamente in seguito all'adozione della crittografia applicativa, che garantisce la riservatezza EAS-toEAS, ma vanno considerati due diversi scenari:
|
|
|
| Conclusioni |
|
- non utilizzo del ruolo nei certificati di sottoscrizione;
- invio dei dati come firmati, ovvero si trasmettono le buste PKCS#7;
- memorizzazione dei dati come trasmessi, ovvero si memorizzano le buste spedite;
- memorizzazione dei dati come ricevuti, ovvero si memorizzano le buste ricevute;
- crittografia applicativa:
a) non utilizzo nel periodo transitorio,
b) da studiare l'opportunità dell'utilizzo a regime.
|
| Gli schemi seguenti delineano i processi a regime: |
- del mittente, senza distinguere tra Amministrazione ed RGS: è la fase finale del processo, dall'apposizione della firma digitale all'accodamento su EAS;
- del ricevente, distintamente per RGS (con rinvio allo schema di cui sopra) e Banca d’Italia.
|
|
|
 |
|
|
 |
|
|
 |
|
|
|