posta elettronica nella pa: standard di internet e mobilità

Transcript

posta elettronica nella pa: standard di internet e mobilità
Posta Elettronica: standard di Internet e mobilità
1
POSTA ELETTRONICA NELLA P. A.:
STANDARD DI INTERNET E MOBILITÀ
F. Gennai1
Il servizio di Posta Elettronica riveste un aspetto di fondamentale importanza sia
nelle comunicazioni interne ad organizzazioni pubbliche e private (Intranet), che
tra soggetti diversi connessi alla rete Internet.
Una semplice analisi del servizio di Posta Elettronica per una organizzazione con
caratteristiche analoghe a quelle della Pubblica Amministrazione sarà la base per
la nostra discussione e l’occasione per presentare i protocolli, di recente
introdotti in Internet, per la mobilità e per le problematiche di sicurezza che essa
induce nei servizi che la supportano.
1. INTRODUZIONE
I diversi campi applicativi del servizio di Posta Elettronica (attività commerciali,
istituzioni pubbliche e private, singolo cittadino, etc.), uniti alle molteplici
implicazioni tecnologiche che il servizio comprende, creano un quadro generale di
non sempre facile lettura.
Quando ci troviamo di fronte a scelte di prodotti per l’attivazione di un servizio di
rete, è importante considerare le attività svolte nei gruppi di lavoro da cui vengono,
sin dalle origini di Internet, emanati gli “standard” (o “raccomandazioni”) in base
ai quali la rete funziona: l’Internet Engineering Task Force (IETF) sovraintende a
tali gruppi di lavoro. Potremo quindi individuare in ACAP (Application
Configuration Access Protocol - RFC 2244) [1] il nuovo protocollo per il supporto
alla mobilità degli utenti in Internet, in SASL (Simple Authentication and Security
Layer – RFC 2222) [2] la possibilità di selezionare i meccanismi per
l’autenticazione delle sessioni di rete (anche SMTP ! – Simple Mail Transfer
Protocol - RFC 821 [3]), in CRAM-MD5 (Challenge Response Authentication
Mechanism – RFC 2195) [4], un nuovo meccanismo di autenticazione client/server
e scoprire che le attività per la definizione di uno standard per l’attivazione di un
Directory Service (qualcosa di simile ad un elenco telefonico) hanno portato di
recente all’emanazione di nuove specifiche per il protocollo LDAP v3
(Lightweight Directory Access Protocol (v3) RFC 2251) [5].
Il servizio di Posta Elettronica viene troppo spesso sottovalutato. Web e Firewall
sembrano catalizzare interessi ed attenzioni di molti amministratori e fornitori di
servizi di rete, ma è altrettanto importante approfondire la conoscenza tecnica del
servizio di Posta Elettronica per magari scoprire che molto spesso un Firewall è
causa di forti degradazioni del servizio verso Internet.
1
Istituto Applicazioni Telematiche (CNR) - E-mail: [email protected]
Posta Elettronica: standard di Internet e mobilità
2
È importante comprendere le differenze tra un servizio per le comunicazioni
interne ad una organizzazione, dove è possibile avere un maggior controllo sulle
scelte tecniche, e quello per le comunicazioni verso l’eterogeneo mondo esterno.
Con queste conoscenze saranno maggiori le possibilità di individuare tra le diverse
soluzioni che il mercato ci offre, quella che meglio risponde alle nostre esigenze.
2. AMBIENTE APPLICATIVO
L'introduzione del servizio di Posta Elettronica nella Pubblica Amministrazione
richiede di affrontare sia problemi organizzativi derivanti dalla sua applicazione
all'interno di una consolidata infrastruttura, che problemi tecnici con l'adozione di
soluzioni che consentano di mantenere la massima compatibilità con i più recenti
Standard Internet presenti nel servizio di Posta Elettronica.
Il servizio deve rispondere alle esigenze interne dell'organizzazione presso la quale
sarà attivato identificando alcune componenti primarie quali la tipologia del flusso
dei messaggi (interno, esterno, riservato, distribuito, etc.) ed il livello di sicurezza
richiesto per ciascun flusso. Queste esigenze sono presenti anche nella Pubblica
Amministrazione dove il necessario interfacciamento verso il cittadino porta
all'individuazione di diversi flussi di traffico (cittadino - P.A., P.A.-P.A., P.A. Internet, cittadino - cittadino).
Talvolta uno degli obiettivi che ci si prefigge è la realizzazione di un servizio di
Posta Elettronica a supporto ed integrazione della organizzazione interna dell'Ente
(posta elettronica per l'Intranet) che al tempo stesso offra l'accesso al servizio di
Posta Elettronica Internet.
Nel caso di alcuni Enti Locali si può prevedere anche l’offerta di una casella
postale elettronica (c.p.e.) a particolari classi di cittadini (liberi professionisti,
assistenti sociali, associazioni culturali, etc.) per la sola comunicazione con gli
amministratori.
Si comprende come in un servizio ben strutturato ed integrato sia importante
riconoscere e controllare tali flussi di traffico in modo semplice ed efficace
attraverso filtri e controlli di accesso per limitare le c.p.e. del cittadino alla sola
comunicazione verso i propri amministratori, (impedendo quindi la comunicazione
verso Internet) e consentire a quelle degli amministratori (ovvero alcuni dipendenti
della P.A.) un libero accesso alle comunicazioni via posta elettronica verso
Internet.
In base a quanto detto possiamo individuare alcune caratteristiche peculiari del
servizio di Posta Elettronica interno ad un Pubblica Amministrazione:
- larga diffusione all'interno dell'istituzione (auspicabile una c.p.e. per ogni
dipendente)
- integrazione con strumenti di lavoro mirati a migliorare il "workflow"
(integrazione tra posta elettronica ed altri strumenti produttivi, firma digitale)
- adozione di uno schema di indirizzamento significativo (nome di c.p.e., domini)
Posta Elettronica: standard di Internet e mobilità
3
- predisposizione di strumenti a supporto del flusso di informazioni nell'Intranet
(esempio: liste di distribuzione).
Per l'accesso al servizio esterno (Internet) sono rilevanti le problematiche relative
alla sicurezza, alla compatibilità con gli standard Internet, al controllo del flusso
dei messaggi. Deve essere definita una politica amministrativa e di sicurezza da
rispettare in fase progettuale e di successiva amministrazione del servizio che
determini le condizioni sotto le quali rilasciare accessi liberi, che stabilisca le
classi di sensibilità dei dati che circolano via posta elettronica, che individui il tipo
di controlli da effettuare sul flusso dei messaggi: analisi/filtro dei contenuti,
registrazione di eventi (apertura/chiusura connessioni, trasmissione/ricezione
messaggi, etc.)
Questa "dualità" tra servizio per l'Intranet e servizio per l'Internet, si accentua nei
casi in cui per varie ragioni (amministrative, sicurezza, economiche, etc.) vengono
individuate due classi di utenti:
- una classe aperta, a cui apparterranno tutti gli utenti con possibilità di
comunicare via posta elettronica con altri utenti di Internet
- una classe chiusa, a cui apparterranno gli utenti che possono comunicare solo
all'interno della classe stessa, (nessuna comunicazione con utenti esterni).
Talvolta è richiesto che la classe aperta sia in realtà un sottoinsieme privilegiato
della classe chiusa e le scelte tecnico/organizzative del servizio di Posta
Elettronica, in grado di mantenere questo prerequisito sono argomento di sicuro
interesse.
2.1 UNA SCELTA IMPORTANTE
Si possono individuare due importanti categorie di sistemi per la messaggistica: la
prima basata sugli standard Internet e la seconda basata su sistemi proprietari.
Il servizio per l'Intranet potrebbe trovare maggiori vantaggi nelle soluzioni
proprietarie dove sono presenti buoni sistemi di Directory Service e dove
l'integrazione tra i vari applicativi d'ufficio è elevata (GROUPWARE). D’altra
parte la comparsa di nuovi protocolli come IMAP (Internet Message Access
Protocol) [6], LDAP, ACAP e SASL nel panorama di Internet e la loro adozione
anche da parte dei maggiori produttori di software per la messaggistica, lascia
intendere la disponibilità futura di soluzioni integrate basate solo su protocolli
“standard” Internet.
È consigliabile mantenere il massimo livello di interoperabilità con Internet
scegliendo soluzioni “aperte”, anche se questo può comportare la rinuncia a
funzioni di elevata integrazione tra applicativi tipiche delle soluzioni proprietarie
(GROUPWARE).
2.2 CLASSI DI UTENZA
Come già discusso in precedenza, un Ente Locale potrebbe offrire ai cittadini un
servizio di Posta Elettronica che consenta soltanto comunicazioni con gli
Posta Elettronica: standard di Internet e mobilità
4
amministratori. I cittadini apparterranno alla classe di utenti chiusa, e gli
amministratori a quella aperta. I principali flussi di messaggi individuabili in un
tale servizio sono quelli interni all’ente stesso, tra ente ed Internet e tra ente e
cittadini.
Molte soluzioni per questo tipo di organizzazione del servizio, prevedono l'utilizzo
di più server di posta elettronica, alcuni dedicati alle c.p.e. appartenenti alla classe
"chiusa" (per esempio quelle dei cittadini), altri a quelle con libero accesso ad
Internet, appartenenti cioè alla classe "aperta" (per esempio quelle degli
amministratori). Per ottenere tale risultato è possibile ricorrere ad un firewall che
isoli totalmente dal resto della rete Internet i server delle c.p.e. "chiuse" e lasci
passare le connessioni relative ai server delle c.p.e. “aperte”. Inoltre i server delle
c.p.e. “aperte” dovranno rifiutare l’inoltro verso Internet di messaggi provenienti
da c.p.e. “chiuse”.
Una simile configurazione, non sempre giustificata, comporta alcuni aspetti
negativi, quali:
- gestione di più server e-mail (almeno 2)
- scarsa flessibilità. Nelle peggiori delle ipotesi è possibile che:
- c.p.e. "aperte" e c.p.e. "chiuse" debbano appartenere a domini diversi
- per passare un utente dalla classe "chiusa" a quella "aperta" o viceversa occorre
cambiare server (e quindi l'indirizzo di posta elettronica dell'utente).
L'analisi degli standard Internet per la posta elettronica, la conoscenza delle
discussioni aperte all' interno dell' Internet Engineering Task Force (IETF) devono
essere elementi guida nella stesura delle specifiche, che porteranno alla scelta dei
prodotti, alla configurazione del server e alla sua messa in servizio.
3. SERVIZIO DI POSTA ELETTRONICA INTERNO ED ESTERNO
Consideriamo un ipotetico caso in cui la classe di utenti aperta altro non è che un
sottoinsieme della classe di utenti chiusa, cioè solo alcuni tra gli utenti della rete
interna (Intranet) potranno comunicare verso Internet.
Una opportuna collocazione del server di posta elettronica ne consentirà l’accesso
sicuro sia dalla rete interna (Intranet) che esterna (Internet).
È bene individuare una convenzione nella definizione degli indirizzi di posta
elettronica in base alla quale potremmo avere due tipi di mailbox:
- personali ([email protected])
- di ruolo ([email protected], [email protected])
Notare che tipicamente gli indirizzi di ruolo saranno degli alias della mailbox
personale di colui che al momento riveste tale ruolo, qualora il ruolo sia rivestito
da più persone (esempio: una mailbox per l’assistenza al cittadino
[email protected]) è consigliabile utilizzare come protocollo client/server
IMAP (anziché POP – Post Office Protocol – RFC 1939 [7]) che consente una
efficiente condivisione di una stessa mailbox tra più client.
Posta Elettronica: standard di Internet e mobilità
5
In alcun modo l'appartenenza all'una o all'altra classe potrà influire sul nome della
c.p.e. e sul nome del dominio cui essa appartiene.
L'adozione di questa regola consente agli utenti di identificarsi con indirizzi
uniformi.
I controlli del server di posta elettronica si possono attuare a vari livelli:
- semplice controllo del campo from del messaggio.
- controllo del campo from e dell’indirizzo IP di provenienza del messaggio.
- autenticazione delle sessioni SMTP (oltre che POP e IMAP) (SASL).
Il server di posta elettronica effettua tali controlli mediante apposite regole che
filtrano i messaggi sulla base dei campi from e to, dell’indirizzo IP del client, del
meccanismo di autenticazione richiesto.
In taluni casi si può rendere necessario un controllo più restrittivo, anche per
educare gli utenti all'uso di un indirizzo corretto, si possono definire regole di
controllo degli accessi che associano un indirizzo di posta elettronica all'indirizzo
IP del PC.
4. POSTA ELETTRONICA E MOBILITÀ
I nuovi protocolli ACAP, SASL e CRAM-MD5 sono fondamentali per una
migliore organizzazione e sicurezza del servizio di Posta Elettronica.
Negli ultimi anni le necessità e le possibilità di accedere uno stesso servizio da più
punti della rete sono aumentate, così pure i metodi di accesso si sono diversificati
sempre di più (dalla linea commutata al wireless, al 100 Mbit direttamente sulla
stazione di lavoro). Le interfacce grafiche per l’accesso ai servizi di rete hanno
sempre più comuni funzionalità di base che l’utente deve ridefinire ogni qualvolta
cambia postazione di lavoro.
Questi sono alcuni degli aspetti che introducono ad un nuovo modello di accesso ai
servizi Internet caratterizzato dalla mobilità dell’utente, delle applicazioni, dei
server su cui è attivo un determinato servizio.
I protocolli di base di Internet fanno veramente poco per aiutare gli amministratori
dei servizi nella gestione di questa crescente classe di utenza e servizi. Proprio per
questo recentemente è stato definito un modello client/server per la
memorizzazione/accesso su un server remoto di classi di dati caratteristici dello
scenario sopra descritto.
Alcuni esempi: l’utente può accedere un determinato servizio (mailbox, web) da
client diversi (diverse postazioni lavoro) avendo sempre a disposizione le proprie
“Preferences”, il proprio “Address Book”, “Bookmarks”, etc. che saranno
mantenuti ed automaticamente acceduti su un server ACAP.
ACAP consente la definizione di attributi standard da parte dell'amministratore del
sistema che potranno opzionalmente essere sostituiti dai corrispondenti scelti
dall'utente.
In uno scenario caratterizzato dalla mobilità dell’utente sia a livello locale che
geografico diventa importante la sicurezza e riservatezza negli accessi ai servizi di
Posta Elettronica: standard di Internet e mobilità
6
rete. Anche in questo caso Internet propone già delle soluzioni definendo nuovi
standard per consentire la migrazione di tutti gli applicativi "connection-based"
(SMTP, POP, IMAP, etc.) da meccanismi di autenticazione client/server con
password in chiaro verso nuovi (già definiti) standard come CRAM-MD5 (uno dei
metodi di autenticazione previsti da SASL).
Nel nostro semplice progetto di un servizio di Posta Elettronica, certi meccanismi
sono fondamentali quando si voglia evitare la trasmissione in rete di password in
chiaro durante sessioni di lavoro provenienti da utenti esterni. Posso cioè
consentire l’accesso da una qualsiasi postazione di Internet al server di posta della
mia organizzazione a patto però che vengano rispettate alcune condizioni di
sicurezza (esempio CRAM-MD5 o Transport Layer Security) che il server stesso
imporrà al client. Perciò l’amministratore del server potrà imporre diversi
meccanismi di autenticazione e/o trasporto per l’accesso ad una stessa mailbox.
Il server è in grado di determinare tramite l'indirizzo IP del client quale tipo di
meccanismo (più o meno sicuro) proporre al client per la sua autenticazione. Se il
client non supporta uno dei meccanismi proposti la connessione sarà rifiutata.
Un altro aspetto a cui dobbiamo porre attenzione è la pressante richiesta di un
servizio di Directory Service per Internet (qualcosa di simile all'elenco telefonico).
LDAP v3 sembra ormai individuato come lo standard che finalmente consentirà di
avere in Internet un Directory Service distribuito. Con tale servizio attivo
potremmo inviare un messaggio di posta elettronica utilizzando nell’indirizzo uno
degli attributi che caratterizzano l’utente nel directory server (esempio: [email protected] o [email protected], etc. ).
LDAP è in grado di supportare diverse informazioni, tra cui i certificati pubblici
necessari nella crittografia a chiave pubblica.
5. BIBLIOGRAFIA
1.
2.
3.
4.
5.
6.
7.
C. Newman and J.G. Myers: Application Configuration Access Protocol. RFC 2244,
november 1997
J.G. Myers: Simple Authentication and Security Layer (SASL). RFC 2222, october
1997
J.B. Postel: Simple Mail Transfer Protocol. RFC 821, august 1982
J. Klensin, R. Catoe and P. Krumviede: IMAP/POP AUTHorize Extension for Simple
Challenge/Response. RFC 2195, September 1997
M. Wahl, T. Howes and S. Kille: Lightweight Directory Access Protocol. RFC 2251,
December 1997
M. Crispin: Internet Message Access Protocol - Version 4rev1. RFC 2060, december
1996
J.G. Myers, M. Rose: Post Office Protocol - Version 3. RFC 1939, may 1996