Amministrazione di un sistema Lotus Notes

Amministrazione di un sistema Lotus Notes / Domino

1 Concetti fondamentali

Cosa è Lotus Notes

Notes è un'applicazione di rete che consente agli utenti di scambiarsi informazioni. I componenti

principali di Notes sono: il Server Domino e le stazioni di lavoro (client) Notes. Il server mette a

disposizione delle stazioni una serie di servizi come la gestione dei database Notes e dei siti Web, la

replica di database condivisi ed i servizi di posta elettronica.

Un sistema Notes può spaziare dal minimo di un server ed alcune stazioni su una piccola rete locale

fino ad un assieme di server e stazioni disseminate in tutto il mondo e servite da svariate reti locali e

linee di trasmissione dati. Vi sono alcuni servizi di Notes che hanno senso solo per reti vaste e

complesse, altri che invece sono di uso generalizzato.

I ruoli degli utenti Notes

Gli utenti di una rete Notes possono idealmente essere classificati in base alle mansioni che svolgono:

- amministratori di sistema;

- sviluppatori di applicazioni;

- utenti operativi.

In piccole reti una stessa persona può ricoprire svariati ruoli, mentre solitamente, in grosse reti, si ha

una specializzazione maggiore.

Il ruolo dell'amministratore di sistema.

Le attività dell'amministratore sono finalizzate principalmente al supporto degli utenti ed al

mantenimento dei server, mentre gli sviluppatori si occupano dell'impostazione dei database Notes.

Notes e la rete locale.

I server e le stazioni di lavoro Notes possono essere situati tutti sulla stessa rete locale (local area

network, nel seguito LAN), oppure su più reti locali o ancora in una rete geografica (wide area network,

nel seguito WAN), come ad esempio Internet. Server Domino e stazioni Notes situati su diverse LAN

possono comunicare fra di loro utilizzando svariati servizi di trasporto, come Internet, la rete telefonica,

bridges e routers o al limite anche un cavo null modem.

Amministrazione di un sistema Lotus Notes - Pag. 1

Il server Domino

Occorre evitare di confondere il file server di rete col server Domino. Il file server consente l'accesso a

risorse condivise come applicazioni, dischi e stampanti, mentre il server Domino è un'applicazione che

gira in un computer connesso alla rete. Il modello client / server di Notes, basato esclusivamente sulla

messaggistica, si inserisce sulla rete direttamente a livello di protocollo, per cui può essere installato su

un qualsiasi computer connesso alla rete, non necessitando di un file server. Ad esempio, installando il

server Domino su una macchina Windows, è possibile utilizzare le versioni workstation (2000

professional, ad esempio), non necessariamente le versioni server.

Il server Notes Domino provvede alla memorizzazione dei dati nei database Notes, allo smistamento

dei messaggi di posta ed alla gestione dei processi di replica dei database sfruttando esclusivamente le

proprie risorse.

Tecnicamente il server Domino può girare sulla stessa macchina che funge anche da file server di rete,

ma è senza dubbio raccomandabile che giri su una macchina a ciò dedicata, diversa quindi dal file

server. Questa scelta presenta molti vantaggi, sia per quanto riguarda la sicurezza dei dati ed il controllo

degli accessi, che per le prestazioni del sistema ed anche per la continuità del servizio. Un computer

dedicato, senza alcuna risorsa condivisa, consente infatti di impedire accessi ai dati di Notes via sistema

operativo dalle altre macchine di rete e permette di restringere l'accesso fisico alla macchina a pochi

utenti ed anche di essere indipendenti dal file server per il funzionamento di Notes, dato che la sua

architettura non necessita affatto di un file server per il funzionamento. E' inoltre evidente che, ove il

file server sia ospite di applicazioni che assorbano una aliquota sensibile delle risorse macchina, gli

utenti Notes potranno sperimentare fastidiosi ritardi nell'accesso ai dati.

Uso delle risorse di rete.

Pur non necessitando di un file server, chiaramente Notes ne può utilizzare le risorse come stampanti

condivise, unità di backup, scanner, CD ROM eccetera. Notes, inoltre, utilizza per il trasporto i più

comuni protocolli di rete messi a disposizione dai sistemi operativi delle macchine di rete (TCP/IP, IPX

SPX, NetBeui ecc.).

Condivisione delle informazioni.

Le informazioni contenute nei database Notes possono essere condivise in svariati modi, a seconda

della configurazione del sistema e della tipologia dei dati.

I database possono essere situati in un unico server al quale sono connessi tutti gli utenti, oppure

distribuiti su più server situati in luoghi diversi. I server posso essere collegati fra di loro consentendo i

processi di replica, oppure possono essere le singole stazioni ad avere facoltà di connettersi a più di un

server. La posta elettronica è un altro veicolo per lo scambio dei dati. Anche un personal computer

portatile è in grado di accedere ai server Notes attraverso Internet e/o la rete telefonica.


Il processo di replica.

La replica è un tipico processo di Notes che consente di distribuire ed aggiornare periodicamente più

copie di uno stesso database situate su diversi server o anche su singole stazioni, visto che il processo di

replica può svolgersi fra due server oppure fra un server ed una stazione. Dato che un database

contiene, oltre alle informazioni immesse dagli utenti, anche la struttura dell'applicazione, la replica

propaga a tutte le copie del database anche eventuali cambiamenti del design operati dagli sviluppatori

di applicazioni. Illustriamo il concetto di replica con un esempio.

Supponiamo che sul server A esista un database che si desidera rendere disponibile anche su un server

B. L'amministratore del sistema crea una nuova replica del database sul server B. La replica di un

database è una copia di tipo particolare. Subito dopo la creazione, la replica è una struttura

completamente vuota. Quando viene eseguita la prima operazione di replica, l'intero contenuto del

database viene duplicato sulla replica, compresa anche l'impostazione e la lista controllo accessi. Al

termine del processo, i due database sono del tutto identici.

L'amministratore schedula il processo di replica, affinché questo avvenga automaticamente in momenti

prestabiliti. Gli utenti del server A effettuano modifiche del contenuto del database, così come gli utenti

del server B. E' chiaro che, col passar del tempo, i due database differiscono per contenuto. Al

momento in cui avviene la successiva replica, tutte le modifiche effettuate su uno dei due database

(l'originale e la replica) vengono riportate sull'altro, in modo tale che, al termine del processo, viene

ristabilita l'identità dei due archivi.

La posta elettronica

Per ogni utente registrato, Notes crea un database di posta, dove vengono memorizzati i messaggi

indirizzati all'utente ed eventualmente (se l'utente lo desidera) anche una copia di quelli inviati. Il

database di posta risiede sul server Domino sul quale l'utente è stato registrato e/o sul client. Il traffico

dei messaggi viene gestito dal router di posta di Notes che utilizza per lo smistamento un file

particolare presente sui server e denominato MAIL.BOX. Per l'indirizzamento viene invece utilizzata la

rubrica nomi e indirizzi denominata NAMES.NSF, contenente tutte le informazioni occorrenti per

rintracciare l'utente destinatario nel sistema Notes. Notes utilizza suoi protocolli proprietari per la

gestione della posta, ma il server Domino è in grado di ricevere e spedire posta anche con i protocolli

abitualmente utilizzati su Internet (SMTP, POP3, MIME ecc.), fungendo quindi da server di posta sia

per client Notes che per altri client di posta (Outlook, Eudora ecc.). I client Notes che utilizzano sia la

posta Notes che la posta Internet possono gestire tutti i messaggi in un unico database di posta Notes,

dato che Domino si fa carico di effettuare le conversioni di formato.

I domini

Un dominio Notes è costituito da un gruppo di server Domino che condividono la stessa rubrica nomi e

indirizzi. Un amministratore di sistema del dominio ha quindi il controllo degli utenti ovunque essi si

trovino, anche se il dominio comprende una vasta area geografica. La scelta del numero di domini in

cui viene suddiviso un sistema Notes non è affatto influenzata dalle dimensioni del sistema: una rete

mondiale può essere costituita da un unico dominio, mentre al limite una singola rete locale può essere


composta da più domini.

La rubrica nomi e indirizzi

La rubrica nomi e indirizzi non contiene soltanto le informazioni occorrenti per lo smistamento della

posta, ma anche le istruzioni per la gestione delle comunicazioni. In particolare, nella rubrica sono

registrati i dati occorrenti per schedulare le comunicazioni, le repliche e l'invio della posta fra server.

Quando viene installato il primo server di una organizzazione, Notes crea la rubrica nomi e indirizzi.

Ogni altro server che viene aggiunto al dominio è dotato di una replica della rubrica nomi ed indirizzi,

che così conterrà gli identificativi degli utenti del dominio su tutti i server in esso presenti. Ogni

dominio ha quindi una sua propria rubrica.

La sicurezza in Notes

La gestione della riservatezza dei dati ed il controllo degli accessi sono molto accurati in Notes. La

premessa per un'efficiente gestione da questo punto di vista sta comunque nel presupposto che i server

siano fisicamente sicuri: il posto ideale per un server Domino è una stanza chiusa a chiave ed

accessibile a poche persone. I meccanismi di sicurezza di tipo software sono sostanzialmente cinque.

Il primo livello di controllo consiste nella consegna agli utenti di un file di identificazione individuale,

il così detto file ID, che costituisce una sorta di carta di identità elettronica indispensabile per l'accesso

al sistema.

Il file ID, però, non garantisce da solo l'accesso al sistema, dato che l'identità dell'utente viene

controllata sulla lista di accesso al server.

Una volta ottenuta l'autorizzazione a collegarsi al server, l'utente deve superare specifici controlli per

poter accedere ai singoli database, ognuno dei quali dispone di una propria lista di controllo degli

accessi.

All'interno del database possono poi essere presenti altri controlli e limitazioni di accesso legati al

singolo documento o addirittura ad una specifica sezione del documento.

Infine, Notes dispone di un sistema di crittografia a chiave che consente di rendere illeggibili campi,

documenti o interi database agli utenti non in possesso della giusta chiave di cifratura. Anche le

trasmissioni via modem possono essere rese sicure mediante crittografia dei dati trasmessi.


2 Creazione di un sistema Notes

Il primo server dell'organizzazione

La nascita di un sistema Notes coincide con l'installazione del primo server. Occorre fornire una

denominazione per l'organizzazione, il dominio ed il server, quindi specificare il nominativo

dell'amministratore di sistema. Il programma di installazione provvede a creare alcuni file ID e

precisamente:

- ID del server (SERVER.ID);

- ID del certificatore (CERT.ID);

- ID dell'amministratore di sistema (USER.ID).

Questi files sono preziosi ed insostituibili. Farne subito alcune copie di sicurezza da conservare in un

posto sicuro. Si può quindi procedere alla registrazione degli utenti nella rubrica nomi e indirizzi: per

ogni utente viene creato un file ID che deve essere consegnato all'utente per consentirgli l'accesso al

sistema. Il processo di certificazione avviene utilizzando un "certificatore", ovverosia il CERT.ID

appena creato.

Aggiunta di un server nello stesso dominio

Prima di poter installare un secondo server nel dominio, occorre che il nuovo server sia registrato nella

rubrica nomi e indirizzi del primo, analogamente a come si procede per la registrazione di un utente.

Notes crea un ID per il nuovo server e lo aggiunge ad un gruppo particolare della rubrica denominato

"LocalDomainServers", contenente i dati di tutti i server del proprio dominio. Occorre fornire il

nominativo dell'amministratore di sistema, che può anche coincidere con l'amministratore del primo

server.

Al momento dell'installazione del server, occorre specificare che il server in fase di installazione è un

server aggiuntivo. Si dovrà anche specificare il nome del server da cui prelevare la rubrica nomi e

indirizzi ed il modo per raggiungerlo, se via rete o altro. L'installazione è possibile solo se il primo

server (o comunque il server che ha effettuato la certificazione) è attivo e raggiungibile.

Creazione di altri domini

Un altro dominio è come fosse un'altra organizzazione, pertanto si procede come se si stesse installando

una nuova organizzazione. Anche in questo caso verrà creato un CERT.ID ossia la carta d'identità che

consente di certificare nuovi server e nuovi utenti. Ogni CERT.ID creato installando un "primo server"

di dominio è diveso da ogni altro e tutte le ID (sia di utenti che di server) prodotte con quel CERT.ID

sono valide soltanto nell'ambito del dominio.


L'amministrazione di domini multipli

Come detto, ad ogni dominio corrisponde una specifica rubrica nomi ed indirizzi (NAMES.NSF)

replicata su tutti i server del dominio. Questo significa che gli utenti di un dominio non "conoscono" gli

utenti degli altri domini. Se quindi l'utente del dominio A vuole inviare un messaggio di posta ad un

utente del dominio B, non può semplicemente selezionarne il nome dalla rubrica, ma deve specificare

nome, cognome e dominio di appartenenza. Ciò può o meno costituire un problema, a seconda del tipo

di organizzazione. L'amministratore, comunque, può decidere di replicare le rubriche dei vari domini su

tutti i server. In tal modo ogni utente ha a disposizione tutte le rubriche sul suo server di appartenenza.

Naturalmente la comunicazione fra domini diversi presuppone che i server vengano messi in contatto.

Per registrare i server di altri domini nella propria rubrica, si inserisce un'entrata nel gruppo

"OtherDomainServers".

E’ certamente possibile comunicare fra domini diversi ed anche fra organizzazioni diverse, ma per fare

ciò occorre, oltre ovviamente al collegamento fisico (LAN, WAN o modem), che i due domini (o le due

organizzazioni) diano un assenso a tale comunicazione. L’assenso avviene attraverso la cosiddetta

“certificazione incrociata”, che verrà descritta nel seguito.

Installazione di stazioni Notes.

L’installazione di una stazione sulla LAN presuppone che l’utente che opera sul computer sia stato

certificato e quindi sia presente nella rubrica nomi e indirizzi del server. Si procederà anzitutto

all’installazione del software, che è un processo del tutto automatico. Quando il software viene lanciato

per la prima volta, occorrerà specificare il nome Notes dell’utente, il nome del server cui è fisicamente

collegato e se il file ID dell’utente è stato o meno consegnato all’utente. In ogni caso, stabilito il

collegamento col server, Notes è in grado di estrarre automaticamente l’ID dalla rubrica nomi e

indirizzi. In tal caso, però, occorre fare attenzione a che il nome venga digitato esattamente.

Il ruolo della password in Notes

Ogni ID, fra gli altri dati, contiene la password che permette l’accesso al sistema. La password è però

soltanto uno dei tanti strumenti di sicurezza di cui Notes è dotato e serve esclusivamente a garantire che

la persona che sta usando un certo ID sia effettivamente chi dice di essere. In altre parole, l’immissione

della giusta password consente l’uso dell’ID, non garantendo di per sé altro. Dato che ogni ID è unico,

lo smarrimento del file ID potrebbe impedire l’accesso ad alcuni dati anche per sempre, se l’utente ha

crittografato questi dati con la propria chiave privata (contenuta nel file ID). Analoghe conseguenze si

potrebbero verificare qualora l’utente dimenticasse la propria password. E’ perciò buona norma

conservare una copia di ogni ID prodotto ed utilizzare sempre una password standard iniziale uguale

per tutti, password che poi l’utente modificherà a proprio piacimento. Questi accorgimenti mettono in

grado l’amministratore di fornire sempre una copia dell’ID ad ogni utente.


La stazione multi utente

Se una stazione è utilizzata da più utenti è sufficiente consegnare un ID ad ognuno. Questi ID possono

essere conservati su dischetto (che dovrà essere inserito ad ogni richiesta della password) oppure

copiati sul disco fisso. In tal caso ogni utente dovrà utilizzare la funzione “passa ad altro ID” quando

inizia il lavoro.

I database locali

Il client Notes (il software della stazione) è in grado di gestire database locali, residenti sul disco del

computer o su un qualsiasi disco di rete raggiungibile dall’utente. I database locali sono di proprietà

esclusiva dell’utente, che per tali archivi ha sempre il massimo livello di accesso. In particolare, questi

database possono essere delle repliche di altri residenti sul server. Tale possibilità è utilissima per

stazioni installate su computer portatili, che così sono in grado di lavorare in autonomia e quindi

connettersi al sistema per aggiornare gli archivi locali e quelli del server. Naturalmente la replica è

soggetta ai permessi di accesso che l’utente ha nel database. Ad esempio, un utente con accesso in sola

lettura ad un database, può creare una replica locale ed inserirvi nuovi documenti, ma questi documenti

non verranno mai replicati sul server. In tale situazione l’utente può replicare dati verso la sua stazione,

non verso il server. Per stazioni utilizzate da più utenti è possibile specificare nell’ID di ciascuno una

directory diversa per i dati in modo che ciascuno utilizzi i propri archivi locali. Se un database locale

contiene dati riservati, l’utente può garantirsi da accessi illeciti crittografando i database con una chiave

privata. Ciò consente l’apertura del database solo al possessore dell’ID.


3 Gestione delle repliche e smistamento della posta

Premessa

Gli argomenti qui trattati hanno importanza soltanto nel caso di sistemi costituiti da più server e nei

quali vi sia necessità di attivare processi di replica fra server.

Documenti di connessione

Nella rubrica nomi e indirizzi sono presenti documenti di connessione fra i server del sistema. Nel

documento di connessione sono presenti sia informazioni di tipo tecnico che di tipo gestionale. Le

prime riguardano le modalità del collegamento fisico (rete o modem), le seconde la gestione dei

processi di replica e di invio della posta. Si tenga presente che l’invio di posta fra server sulla stessa

rete e nello stesso dominio è automatico e quindi non ci si deve preoccuparne.

Le informazioni di tipo gestionale servono a determinare quando i server devono collegarsi e cosa

devono fare quando sono collegati. Per quanto riguarda il primo aspetto, è possibile specificare l’orario

di chiamata al server, l’intervallo di ripetizione delle chiamate e i giorni della settimana nei quali

effettuare la connessione: è così possibile ad esempio specificare diverse configurazioni per i

collegamenti effettuati nei giorni feriali e nel fine settimana, semplicemente introducendo due diversi

documenti di connessione. Per il secondo aspetto si può innanzitutto definire il tipo di attività da porre

in essere durante il collegamento (replica, inoltro posta o entrambe), specificando poi una serie di

parametri al fine di massimizzare l’efficienza delle connessioni.

La replica

Come già accennato in precedenza, Notes utilizza il processo di replica per distribuire ed aggiornare le

copie di uno stesso database che si trovino su diversi server: questi si collegano tra loro ad intervalli

periodici, come specificato nel documento di connessione, e replicano i cambiamenti effettuati sui

documenti, sulla lista controllo accessi e sull’impostazione del database. Prima dell’inizio di tale

processo, i server compongono una lista dei database che hanno in comune, provvedendo quindi al loro

riallineamento per ottenere al termine delle copie identiche tra loro.

Esiste un certo numero di fattori che influiscono sulla replica ed in particolare su quali documenti dei

database vengano effettivamente replicati; è quindi possibile, agendo su tali fattori, adattare il processo

alle proprie esigenze. In ordine di priorità avremo:

1) La lista controllo accessi del database: essa regola, come verrà più in dettaglio specificato nel

seguito, la possibilità per gli utenti e per i server di accedere ad un database e di modificarne il

contenuto. A seconda del livello di accesso che un server ha nella LCA del database che si trova sul

server con cui sta effettuando la replica, quindi, saranno definiti quali elementi del database verranno

aggiornati e quali no, in quanto non sussiste per il primo server l’autorizzazione ad effettuare tali


modifiche.

2) Le impostazioni di replica, che pemettono di definire alcune opzioni al fine di limitare

selettivamente il numero di elementi da replicare, ad es. in ordine alla data di modifica o

all’appartenenza ad una certa cartella o vista del database.

3) Le formule di replica, mediante le quali è possibile stabilire ulteriori criteri di selezione per definire

quali documenti saranno effettivamente replicati (es. tutti i documenti composti da un determinato

autore, o che trattino un certo argomento, e così via).

Le tipologie di replica

Le tipologie di replica che possono essere poste in essere tra due server sono essenzialmente quattro:

1) Push - pull

La replica viene attivata da uno dei due server, che preleva i documenti dal database dell’altro server,

dopodichè si occupa anche di mandare i propri.

2) Pull - pull

In questo caso il server chiamante manderà i suoi documenti all’altro, ma poi sarà quest’ultimo a

mandare a sua volta i suoi al primo.

3) Push

Si avrà in tale caso una replica monodirezionale, con invio di documenti solamente dal server

chiamante verso il chiamato.

4) Pull

Ultimo caso, analogo al precedente ma in direzione opposta.

La tipologia di replica prescelta viene indicata in un apposito campo nel documento di connessione

(nella terminologia italiana le tipologie vengono denominate “Invio-Ricezione”, “Ricezione-

Ricezione”, “Solo Invio” e “Solo Ricezione”).

I conflitti di replica

I conflitti di replica sono particolari situazioni che si verificano nel caso in cui lo stesso documento di

un determinato database sia stato modificato da persone diverse su due o più server nell’intervallo di

tempo intercorrente tra due repliche successive. In questo caso tale database, dopo l’ultima replica,

conserverà tutte le versioni del documento: una di esse (e precisamente quella contenente le maggiori

modifiche dal punto di vista delle dimensioni occupate) verrà considerata come documento principale,

mentre le altre verranno contrassegnate con la dicitura “Conflitto di replica o di salvataggio”. A questo

punto spetta all’amministratore il compito di risolvere tali conflitti: ciò può essere fatto scegliendo di

tenere una delle versioni e cancellando le altre, oppure di tenere tutte le modiche, ma ciò dovrà essere

fatto aggiungendole manualmente ad uno dei documenti, eliminando poi gli altri.

Un modo più efficiente di risolvere il problema consiste nel cercare di eliminare a monte la possibilità

che possano sorgere tali conflitti, principalmente agendo sugli accessi ai documenti; ad esempio si può

fornire agli utenti il livello di accesso Autore (consentendo loro di modificare solamente i documenti

creati da loro stessi), oppure si inseriranno all’interno dei documenti delle sezioni ad accesso

controllato, in modo che soggetti diversi possano modificare solamente una parte del documento,

mantenendo per la rimanente parte la sola possibilità della lettura.


Lo smistamento della posta

Per il trasferimento della posta da un utente ad un altro, Notes utilizza un programma denominato

Router di posta, che viene eseguito su tutti i server Notes; esso si avvale dei dati provenienti da due

database situati sullo stesso server sul quale è in esecuzione: MAIL.BOX (la casella postale), il quale

riceve la posta in entrata dalle stazioni di lavoro o dai Router di altri server, e NAMES.NSF (la Rubrica

nomi e indirizzi), che fornisce le informazioni sulla topologia della rete.

All’atto dell’invio di un documento da parte di un utente, viene innanzitutto effettuata una ricerca

dell’indirizzo del destinatario nella Rubrica nomi e indirizzi; l’eventuale presenza di gruppi tra i

destinatari viene risolta convertendo il nome del gruppo nell’elenco dei nomi dei suoi componenti. Al

documento viene quindi aggiunto l’indirizzo, dopodiché avviene la ricerca del file di posta del

destinatario; esso può trovarsi sullo stesso server sul quale sta girando il Router, nel qual caso si ha il

semplice spostamento del documento in tale file. C’è però la possibilità che il server di destinazione sia

diverso, e possono allora verificarsi due diverse situazioni: se i due server possono connettersi

direttamente tra loro si avrà il trasferimento del documento nel file MAIL.BOX del server destinatario

nel momento in cui si effettuerà il collegamento, secondo quanto stabilito dal documento di

connessione; se ci sono invece dei server di passaggio, il trasferimento avverrà nella casella postale del

primo server intermedio e poi via via verso i successivi, fino a raggiungere il destinatario. In

quest’ultimo caso, se dovessero esistere più percorsi alternativi per il raggiungimento del server di

destinazione, verrà preferito quello che implica il minor costo totale di trasferimento, calcolato dal

Router sulla base dei parametri immessi nei documenti relativi a server, connessioni e domini nella

Rubrica nomi e indirizzi.

Nell’ipotesi di smistamento di posta tra domini diversi, il documento verrà dapprima trasferito verso il

server del dominio di origine che ha la possibilità di connettersi al dominio di destinazione; all’atto di

tale connessione il documento raggiungerà quindi un server del nuovo dominio, dopodiché si ripeterà il

procedimento visto prima per la ricerca del destinatario.

Per la gestione della posta SMTP (Internet), viene utilizzato un secondo router ed una diversa casella di

posta. Le necessarie conversioni di formato vengono effettuate automaticamente da Domino, in modo

tale che la posta SMTP possa essere ricevuta in un database di posta Notes e viceversa.


4 La sicurezza in Notes

Introduzione

In questa sezione verranno affrontate le tematiche relative alla sicurezza delle informazioni

immagazzinate nei database Notes, sia in relazione ai soggetti che dovranno occuparsi di garantire tale

sicurezza che ai metodi per ottenerla.

Sotto quest’ultimo punto di vista, si può dire che la sicurezza in Notes si presenta sotto tre diversi

aspetti:

� assicurare la protezione fisica del server;

� stabilire le identità mediante i file ID e i certificati;

� utilizzare le liste di accesso al server e le liste controllo accessi (ACL) per proteggere il server e i

database che vi sono immagazzinati.

La sicurezza fisica

Notes è stato dotato di un sistema di sicurezza molto sofisticato, ma alla base è indispensabile che

venga garantita la sicurezza fisica del server, altrimenti chi ha libero accesso al server stesso potrebbe

in qualche modo “saltare” i metodi di sicurezza di Notes, come ad esempio le ACL, ottenendo l’accesso

ai dati contenuti nei database.

Per evitare queste eventualità possono essere presi alcuni semplici accorgimenti, tra i quali il più

immediato consiste nel tenere il server in una stanza chiusa a chiave, trattandolo alla stregua di un

qualsiasi archivio contenente informazioni riservate; se ciò non fosse possibile, si consiglia almeno di

togliere il mouse e bloccare la tastiera. In sostanza si deve evitare il più possibile accessi via sistema

operativo al server Domino.

I file ID utente

Per stabilire l’identità di un utente o di un server, Notes utilizza una procedura di autenticazione in base

alla quale chiunque voglia accedere ad un database su un server deve preventivamente “esibire” un ID

Notes e passare un controllo di identità.

I file ID utente di Notes sono file binari che hanno appunto la funzione di identificare un utente, sia

esso persona o server. Le informazioni contenute in un file ID, che sarà naturalmente unico per ogni

utente, sono sufficienti ad identificarlo, ma non a garantirgli l’accesso ai server: questa funzione, come

si vedrà successivamente, viene svolta in altro modo.


Un file ID contiene:

� il nome del proprietario;

� un numero di licenza Notes, che identifica l’utente come legittimato all’utilizzo del software Notes:

tale numero è associato permanentemente all’ID e non può essere cambiato;

� una chiave pubblica ed una chiave privata, utilizzate durante l’autenticazione e per la decifrazione

dei messaggi di posta crittografati;

� una o più chiavi di crittografia, utilizzate per crittografare e decifrare i campi di un documento;

� almeno un certificato di un certificatore.

All’atto della registrazione di un utente, c’è un’opzione che consente di decidere se il suo file ID debba

essere allegato al documento a lui relativo contenuto nella Rubrica nomi e indirizzi (è l’opzione di

default), oppure salvato su file, o entrambe le cose. Anche nel primo caso sarà comunque sempre

possibile, in un momento successivo, estrarre il file come si farebbe con un qualunque allegato e dargli

il nome che si desidera.

E’ importante ricordarsi di proteggere il proprio file ID con una password, altrimenti chiunque ne venga

in possesso potrebbe liberalmente utilizzarlo, con la possibilità di compromettere la sicurezza del

sistema.

La gestione delle password è di competenza esclusiva dell’utente. In tal caso la password serve

esclusivamente per autorizzare l’uso dell’ID. E’ però possibile attivare sul server Domino il controllo

delle password immesse dagli utenti. In tal caso il server possiede un elenco delle password di ciascun

utente.

Il controllo degli accessi da utenti Web

Dato che Domino è anche un server Web, esiste un meccanismo di controllo degli accesso di utenti

Web, che viene effettuato attraverso il solo controllo della password oppure tramite i certificati

standard. La password internet è però diversa dalla password Notes ed è contenuta nel documento

persona della lista controllo accessi. E’ anche possibile consentire l’accesso a utenti Web anonimi.

Si osservi che col termine “utenti Web” ci si riferisce ad utenti che si collegano al server tramite un

browser Internet, indipendentemente dal mezzo fisico utilizzato per la connessione. Un utente che si

collega attraverso la rete Internet utilizzando un client Notes non è un utente Web, ma un ordinario

utente Notes.

Il file ID del certificatore

L’ID del certificatore è analogo ad un bollo che viene apposto sugli altri ID per attestarne la validità,

confermando così che essi appartengono alle persone o ai server che li presentano.

L’importanza del ruolo ricoperto da questo file ne rende consigliabile la protezione con una password,

l’accesso al minor numero possibile di persone e la conservazione in un posto sicuro.

La certificazione degli ID utente è un processo che avviene automaticamente all’atto della registrazione

di un nuovo server o di una nuova persona, ma a volte può porsi la necessità di effettuare una ri-


certificazione; ciò può accadere ad esempio a causa del cambiamento del nome del server o della

persona, o per la scadenza della precedente certificazione, o ancora per la necessità di essere certificati

da un diverso ID per ottenere l’accesso a server aggiuntivi.

La lista di accesso al server

La lista di accesso al server è un metodo altamente raccomandato per controllare l’accesso ad un server;

tale tecnica fornisce infatti un ulteriore livello di sicurezza, in quanto anche ad utenti certificati può

essere negato l’accesso ad un server o a certe sue funzioni.

L’abilitazione della lista avviene per mezzo di un’apposita sezione all’interno del documento,

contenuto nella Rubrica nomi e indirizzi, relativo al server rispetto al quale si vuole circoscrivere

l’accesso; tale sezione, dal titolo “Limitazioni”, permette per l’appunto di porre dei limiti all’uso diretto

del server, potendo specificare i nomi degli utenti ai quali l’accesso è consentito o quelli a cui è negato,

anche relativamente alla sola creazione o replica di database. E’ altresì possibile porre limitazioni al suo

utilizzo come server di passaggio, sia relativamente all’accesso da parte degli utenti che alle

destinazioni consentite.

La lista controllo accessi

La lista controllo accessi è il metodo utilizzato per garantire la sicurezza dei singoli database. Ciascuna

ACL elenca le persone, i server ed i gruppi cui è consentito l’accesso al database, specificando altresì il

livello di accesso ed i privilegi attribuiti a ciascuno di essi.

I livelli di accesso definiti sono sette, come di seguito specificato in ordine crescente di importanza:

1) Nessun accesso

Non si ha nessun tipo di accesso al database. All’utente non è neppure permesso di aggiungere l’icona

del database nella propria area di lavoro.

2) Composizione

L’utente può solamente comporre documenti, ma non può leggerne nessuno, nemmeno quelli composti

da lui stesso.

3) Lettura

L’utente può solamente leggere documenti, ma non può comporne. Possono essere specificate delle

opzioni in base alle quali è consentita o meno la creazione di cartelle, viste ed agenti personali.

4) Redazione

L’utente può comporre e leggere documenti, e può modificare quelli da lui creati. E’ inoltre possibile

stabilire se possa anche cancellare documenti dal database.

5) Revisione

Come il livello precedente, ma è consentita la modifica a qualunque documento, chiunque ne sia

l’autore. Può inoltre essergli permessa la creazione di cartelle e viste condivise.

6) Impostazione

Come il livello precedemte, con in più la possibilità di modificare tutti gli elementi di impostazione

(campi, moduli, viste, navigatori), compresa l’cona del database e i documenti “Informazioni su questo

database” e “Uso di questo database”.

7) Gestione


E’ il massimo livello di accesso, che consente di definire le impostazioni di replica, modificare la lista

controllo accessi e cancellare il database.

Si ricorda che la lista controllo accessi è valida solamente con riguardo ai database presenti sul server;

per i database locali si ha sempre il livello di accesso Gestione.

Nella lista controllo accessi è possibile indicare un utente virtuale denominato “Anonymous” e che

identifica l’utente (sia Web che Notes) che non è registrato nella lista utenti. L’accesso di utenti non

registrati deve essere autorizzato in fase di configurazione del server.


5 I compiti dell’amministratore

Introduzione

In questa sezione verranno trattati alcuni compiti che un amministratore è tenuto a svolgere, anche se

non quotidianamente, per assicurare il miglior funzionamento del sistema. Tali attività possono essere

fatte ricadere sotto tre categorie principali:

� amministrazione dei database, concernente la manutenzione dei database che risiedono sul server;

� amministrazione degli utenti e degli ID all’interno della comunità Notes;

� amministrazione del server.

Amministrazione dei database

Una delle maggiori responsabilità di un amministratore è il mantenimento ad un livello ottimale delle

funzionalità del server, cosicché gli utenti possano accedere rapidamente ai database per la ricerca delle

informazioni che necessitano loro. Tra le attività che più comunemente saranno poste in essere per il

raggiungimento di tale obiettivo possiamo ricordare: la cancellazione dei documenti obsoleti dai

database, la compattazione, la creazione di repliche e la risoluzione dei conflitti di replica, la

cancellazione e lo spostamento di interi database, il monitoraggio del loro utilizzo da parte degli utenti,

il controllo delle dimensioni, l’aggiornamento degli indici di ricerca, l’utilizzo dei modelli di

impostazione. Nel seguito verranno brevemente delineate le principali caratteristiche di alcune di

queste attività.

La cancellazione dei documenti obsoleti

La cancellazione dei documenti obsoleti è un procedimento che tende ad eliminare automaticamente dal

database quei documenti che sono stati creati o modificati anteriormente ad una certa data; ciò porterà

nel tempo ad un significativo risparmio dello spazio occupato sul disco fisso del server, soprattutto con

riguardo a quei database che tendono a crescere molto rapidamente (es. forum di discussione).

Questa attività viene eseguita indirettamente all’atto della replica del database, selezionando tra le

impostazioni della replica quella indicante la rimozione dei documenti non modificati entro un certo

periodo di tempo, che può essere impostato a piacimento.

La compattazione dei database

Un database Notes contiene spesso una notevole quantità di spazio inutilizzato, soprattutto a causa

della cancellazione di documenti. E’ buona norma, per liberare spazio su disco, eseguire

periodicamente una compattazione del database: ciò dovrebbe essere fatto ogniqualvolta la percentuale

di spazio utilizzato scende al di sotto del 90% (il controllo può essere effettuato visualizzando le


proprietà del database).

C’è da notare che durante il processo di compattazione viene eseguita una copia del database, per cui è

necessario disporre di sufficiente spazio libero sul disco fisso per immagazzinare tale copia. Fino alla

versione 4.6 di Domino, la compattazione richiedeva uno spazio libero pari alla dimensione del

database ed impediva qualsiasi accesso al database durante la compattazione. Dalla versione 5 il

processo di compattazione viene effettuato a passi successivi, non blocca l’uso del database e richiede

meno spazio disponibile.

In effetti anche la semplice copia ha come effetto quello di compattare il database, ma in questo caso

non verrà mantenuta l’indicazione riguardante i documenti già letti.

La compattazione può riguardare il singolo database, ed in tal caso potrà essere attivata dalla finestra

delle proprietà del database stesso. Per compattare tutti i database di un server occorre invece un

apposito comando dalla console del server, o la composizione di un documento “Programma” nella

rubrica nomi e e indirizzi per eseguire il processo automaticamente in momenti prefissati. Questo

metodo è senza dubbio il più conveniente, dato che può essere schedulato nelle ore notturne in modo da

non recare disagio agli utenti. Si noti che i database NAMES.NSF (rubrica nomi e indirizzi),

MAIL.BOX (file di posta) e STATREP.NSF (storico di notes) possono essere compattati soltanto

previa chiusura del server.

Creazione di una replica

Una replica viene creata semplicemente utilizzando il comando "Nuova replica". Per poter fare ciò,

occorre ovviamente avere accesso al server ove risiederà la replica ed occorre anche essere abilitati a

creare repliche. Nel documento che descrive il server nella rubrica nomi e indirizzi, esiste un campo

apposito che autorizza a ciò.

Occorre poi accertarsi che i server interessati al processo abbiano i giusti permessi di accesso al

database, controllando la lista controllo accessi. Anche i server, come gli utenti, hanno un loro file ID,

pertanto ad essi si applicano tutti i controlli sugli accessi visti per gli utenti.

Fatto ciò, si può creare il documento di connessione fra i due server, nel quale si stabilirà la periodicità

della connessione ed il tipo di attività da eseguire, cioè se solo scambio di posta, solo replica dei

database o entrambe le cose.

Se si avverte l'esigenza di una replica immediata, comunque, tale operazione può essere eseguita

manualmente dalla scrivania Notes senza pregiudicare le attività schedulate, così come la

programmazione può essere temporaneamente sospesa agendo sul documento di connessione.

La replica è anche il metodo migliore per spostare un database da un server ad un altro. In tal caso,

subito dopo il termine di una replica completa, basta cancellare il database originale.

La replica fra server e stazione

Il processo sopra descritto si riferisce ad una replica fra due server, ma gli utenti possono creare delle


repliche locali dei database sulla loro stazione utilizzando il comando "Nuova replica" ed indicando

come server di destinazione "Locale". Si può quindi procedere all'esecuzione della replica in modo

manuale oppure utilizzando il replicatore in background presente nell'ultima area di lavoro sulla destra

della scrivania. Il replicatore può essere programmato per l'esecuzione automatica delle repliche ad

orari prestabiliti, avendo anche la possibilità di selezionare i database da replicare. Tale funzionalità è

particolarmente utile per stazioni portatili connesse al server via modem, dato che il processo chiamata

del server - replica - disconnessione può essere del tutto automatizzato. Il collegamento, poi, può essere

programmato in ore notturne sfruttando le tariffe telefoniche ridotte ed in modo non presidiato.

Risoluzione dei conflitti di replica o di salvataggio

Un conflitto si può verificare nel corso di una replica o della modifica di un documento. Come visto, la

replica consiste nel riportare su una copia del database tutte le modifiche effettuate su un'altra copia.

Gli aggiornamenti vengono effettuati campo per campo, quindi non esistono problemi qualora utenti

diversi abbiano modificato campi diversi dello stesso documento. Se invece le modifiche riguardano lo

stesso campo, Notes non può sapere quale sia la versione giusta, quindi crea due o più copie dello

stesso documento, evidenziando l'evento con la dicitura "conflitto di replica o di salvataggio". Come

già accennato, l'amministratore dovrà esaminare le varie versioni del documento e scegliere quella da

mantenere, quindi cancellare le altre.

Lo stesso tipo di problema può verificarsi anche qualora più utenti aprano lo stesso documento dello

stesso database ed effettuino modifiche sullo stesso campo. Il primo utente ad effettuare il salvataggio

applicherà le sue modifiche, mentre gli altri utenti vedranno apparire un messaggio informativo e

potranno rinunciare ad effettuare il salvataggio oppure salvare il documento modificato creando una

propria versione e quindi generando un conflitto analogo al precedente.

Il problema dei conflitti può essere evitato o almeno minimizzato con un'accorta progettazione

dell'applicazione ed evitando di attribuire agli utenti permessi di accesso eccessivi rispetto alle

necessità.

Il file storico di Notes (Log)

Sul server è possibile attivare la funzione di storicizzazione (log) semplicemente creando il database

relativo. Questo database è di grande utilità per l'amministratore, dato che riporta una serie assai

interessante di statistiche sull'utilizzo del sistema. Controllando questo archivio è possibile essere

informati sul tempo di utilizzo e sulle dimensioni di ogni database, sulle attività di ciascun utente, sui

collegamenti remoti ed altre ancora. Tra l'altro, le informazioni contenute nel log consentono di reperire

tutti i dati occorrenti per fatturare il tempo di collegamento a ciascun utente. L'unico svantaggio del log

consiste in un'ulteriore occupazione di spazio sul server, ma i vantaggi, specie in sistemi assai vasti e

con un elevato numero di utenti, sono tali da giustificare senza dubbio questo piccolo sacrificio.

Il catalogo dei database


E' possibile creare su un server un database di nome CATALOG.NSF che contiene alcune informazioni

sui database contenuti nel server. Notes aggiorna automaticamente questi dati. La creazione di questo

database è utile soprattutto in sistemi molto vasti. Creando repliche del database su altri server,

l'amministratore può avere sotto controllo la situazione di un sistema composto da molti server.

Manutenzione dell'indice "full text"

Su ogni database di Notes è possibile creare e manutenere il cosiddetto indice full text, che consente

agli utenti di effettuare ricerche di documenti in dase al testo in essi contenuto, allegati compresi.

L'indice è costituito da alcuni files che Notes pone in una directory avente lo stesso nome del database

ed estensione FT. L'indice può occupare uno spazio anche considerevole a seconda della quantità di

testo contenuto nel database e delle opzioni scelte al momento della creazione dell'indice (che viene

effettuata da "proprietà" del database). In particolare è possibile escludere dall'indice le parole poco

significative come gli articoli, le preposizioni eccetera. Con Notes viene fornito un file di esclusioni

standard che è opportuno utilizzare sempre al fine di limitare lo spazio occupato. E' anche possibile

scegliere se indicizzare o meno gli allegati eventualmente presenti.

Per i database locali, l'aggiornamento dell'indice deve essere eseguito manualmente, mentre per quelli

su server può essere eseguito automaticamente in base a quanto viene specificato al momento della

creazione dell'indice. Si può optare per un aggiornamento immediato oppure orario o giornaliero, ma si

può anche schedulare l'aggiornmento dell'indice con un agente specifico e quindi con qualunque

periodicità. Si tenga presente che l'aggiornamento dell'indice è un lavoro abbastanza gravoso per

l'elaboratore, pertanto non si dovrebbe usare l'aggiornamento immediato ove la potenza a disposizione

non sia adeguata e non vi sia necessità di un aggiornamento costante.

Amministrazione dei file ID

Come detto in precedenza, in Notes esistono dei file con estensione ID che vengono utilizzati per

autenticare l'identità di utenti, server e certificatori. Al momento dell'installazione del primo server,

Notes crea l'ID del server (SERVER.ID), del certificatore (CERT.ID) e dell'amministratore di sistema

(USER.ID). Quando verranno creati gli ID dei singoli utenti e degli altri server, questi dovranno essere

certificati utilizzando l'ID del certificatore, che garantisce l'identità di chi certifica, proprio come l'ID

utente garantisce l'identità dell'utente. In effetti è proprio il fatto di avere lo stesso certitificatore che

consente a Notes di riconoscere questi ID come appartenenti alla stessa organizzazione. Il primo

CERT.ID è di "proprietà" dell'amministratore, che però può crearne altri, delegando in tal modo la

produzione degli ID ad altre persone. Tutti i CERT.ID prodotti a partire dal primo vengono riconosciuti

come certificatori dell'organizzazione e quindi gli ID prodotti con questi saranno riconosciuti come ID

dell'organizzazione. ID creati da altre organizzazioni non vengono riconosciuti e quindi non consentono

l'accesso al sistema.

Le certificazioni gerarchiche


Quando viene creato un nuovo certificatore, ciò può esser fatto in modo gerarchico o non gerarchico. Di

solito un'organizzazione è suddivisa in dipartimenti ed unità operative su più livelli. In Notes è

possibile indicare tale gerarchia utilizzando nomi che sono la concatenazione di più livelli, separati dal

segno "/". Ad esempio, un'organizzazione denominata ACME che sia costituita dai dipartimenti

VENDITE, AMMINISTRAZIONE, LOGISTICA, potrà utilizzare nomi così composti:

Giovanni Bianchi/AMMINISTRAZIONE/ACME

Mario Rossi/VENDITE/ACME.

Un CERT.ID non gerarchico sarà valido ovunque nell'organizzazione, mentre un CERT.ID gerarchico,

rilasciato per LOGISTICA/ACME avrà validità soltanto all'interno dell'unità operativa LOGISTICA.

Certificazioni di un ID

La prima certificazione di un utente comporta la creazione di un file ID dell'utente. E' possibile che

l'utente necessiti di altre certificazioni per svariati motivi.

Anzitutto, l'ID utente ha una validità limitata: alla scadenza (di solito due anni), occorre certificare di

nuovo l'ID. Se poi l'utente desidera collegarsi ad un server di un'altra organizzazione o comunque un

server che ha un certificatore diverso (si pensi alla certificazione gerarchica), occorre che il suo ID sia a

ciò abilitato.

Il processo di certificazione di un ID esistente può essere eseguito in vari modi, ma fondamentalmente

le fasi sono le seguenti.

1) L'utente crea una "safe copy" del suo ID.

2) L'utente invia la safe copy al certificatore assieme alla richiesta di certificazione.

3) Il certificatore certifica la safe copy.

4) Il certificatore invia la safe copy all'utente.

5) L'utente fonde la safe copy al suo ID.

Le differenze riguardano soprattutto le modalità scelte per la trasmissione delle safe copy che può

avvenire via supporto (dischetto) o allegandolo ad un messaggio di posta elettronica.

La safe copy è una copia dell'ID che contiene tutte le informazioni atte ad eseguire la certificazione, ma

che non consente di collegarsi al sistema.

Amministrazione degli utenti

Tra i compiti dell’amministratore c’è anche quello di tenere costantemente aggiornata la comunità degli

utenti Notes, modificando tempestivamente la Rubrica nomi e indirizzi in modo che rifletta i

cambiamenti che potrebbero essere causati ad esempio dall’ingresso di nuovi utenti o dall’uscita di altri

dall’organizzazione, oppure da semplici mutamenti dei dati riguardanti gli utenti già presenti. La

maggior parte del lavoro, in questi casi, viene fatta sul documento Persona nella Rubrica nomi e


indirizzi, il quale contiene le informazioni relative all’identificazione dell’utente e i dati che lo

interessano per quello che riguarda lo scambio di messaggi di posta elettronica.

Il documento Persona viene creato automaticamente all’atto della registrazione di un nuovo utente; per

l’eliminazione di un utente, ricordarsi di cancellare, oltre a tale documento, anche il suo file di posta.

Per ogni modifica effettuata sulla Rubrica nomi e indirizzi ci si deve inoltre ricordare di effettuarne la

replica, in modo da propagare i cambiamenti effettuati.

Amministrazione del server

Con il passare del tempo ed il diffondersi di Notes nella propria organizzazione, può rendersi

necessario effettuare delle modifiche ad un server. Tali modifiche potrebbero ad esempio riguardare il

cambiamento del nome o dell’amministratore del server, la rimozione del server o il suo spostamento

in un altro dominio, o ancora la modifica del documento relativo al server nella Rubrica nomi e

indirizzi, con particolare riferimento alla lista di accesso.

Cambiamento dell’amministratore o del nome

Mentre il cambiamento dell’amministratore è un procedimento abbastanza semplice, che può risolversi

principalmente nella modifica del documento riguardante il server nella Rubrica nomi e indirizzi con

l’inserimento del nome del nuovo amministratore al posto del vecchio, il cambiamento del nome del

server è un processo alquanto complesso. Essendo infatti il nome legato all’ID del server, sarà

necessario passare attraverso la ricertificazione dell’ID; inoltre, essendo il nome stesso riportato in una

serie di documenti e liste (quali ad esempio, oltre naturalmente al documento Server, i vari documenti

di connessione che possono interessare il server o le liste controllo accessi nelle quali esso è

menzionato) bisognerà effettuare in tutti questi la sostituzione del nome; a tale proposito si consiglia,

ove possibile, di utilizzare degli agenti.

Un metodo alternativo che può essere seguito è quello di registrare un nuovo server con il nuovo nome,

cancellando poi il vecchio nome ovunque esso appare, come si farebbe nell’ipotesi della semplice

eliminazione di un server. Anche in tal caso, naturalmente, i documenti e le liste interessati possono

essere in numero notevole e quindi, per questo aspetto, la complessità risulta analoga a quella del

metodo precedente.

Il documento Server nella Rubrica nomi e indirizzi

Nel documento relativo al server sono immagazzinate una serie di informazioni che dovrebbero essere

tenute costantemente aggiornate in seguito ad ogni cambiamento che dovesse verificarsi riguardo al

server, in quanto Notes utilizza tale documento come base per lo svolgimento di molte delle attività che

vengono compiute da e verso il server al quale il documento si riferisce.

Tale documento è suddiviso in un certo numero di sezioni di cui la prima, non comprimibile, presenta

le informazioni di base. Nelle sezioni successive possiamo trovare, tra le altre, le informazioni relative

alla località, con particolare riferimento ad eventuali connessioni telefoniche e alla specificazione del

server di posta e del server Internet; alla configurazione di rete, con la specificazione delle porte

abilitate per il server e la rete alla quale appartiene; alle limitazioni, in cui viene in pratica definita


quella che è stata chiamata lista di accesso al server, e di cui si è gia accennato nella precedente

sezione.


Amministrazione di un sistema Lotus Notes

Documents

Transcript of Amministrazione di un sistema Lotus Notes