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