<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>Database-SQL-RDBMS HOW-TO document for Linux (PostgreSQL Object Relational Database System): Protezione del Database </TITLE>
<LINK HREF="PostgreSQL-HOWTO-12.html" REL=next>
<LINK HREF="PostgreSQL-HOWTO-10.html" REL=previous>
<LINK HREF="PostgreSQL-HOWTO.html#toc11" REL=contents>
</HEAD>
<BODY>
<A HREF="PostgreSQL-HOWTO-12.html">Avanti</A>
<A HREF="PostgreSQL-HOWTO-10.html">Indietro</A>
<A HREF="PostgreSQL-HOWTO.html#toc11">Indice</A>
<HR>
<H2><A NAME="protezione"></A> <A NAME="s11">11. Protezione del Database </A></H2>
<P>La protezione del Database è distribuita su diversi livelli:
<UL>
<LI> Protezione dei file del Database. Tutti i file, archiviati internamente al database, sono
protetti dalla lettura di qualsiasi altro account che non sia l'account del superuser
<I>postgres</I></LI>
<LI> Come impostazione predefinita, le connessioni da un client al server database sono
ammesse solo attraverso socket UNIX locali, e non attraverso socket TCP/IT. Il back-end
deve essere stato lanciato con l'opzione -i, per permettere ai client non locali di connettersi.</LI>
<LI> Le connessioni dei client possono essere ristrette secondo l'indirizzo IP e/o lo username,
mediante il file <B>pg_hba.conf</B> in <B>$PG_DATA</B>.</LI>
<LI> Le connessioni dei client possono essere autenticate mediante uso di altri pacchetti esterni.</LI>
<LI> Ad ogni utente di PostgreSQL è assegnato uno username e (facoltativamente) una password.
Come impostazione predefinita, gli utenti non hanno accesso in scrittura su database non creati da loro.</LI>
<LI> Gli utenti possono essere assegnati a dei gruppi, e l'accesso alle tabelle può essere ristretto in base
ai privilegi del gruppo.</LI>
</UL>
<H2><A NAME="ss11.1">11.1 Autenticazione degli Utenti</A>
</H2>
<P>L'Autenticazione è il processo con cui il server backend ed il postmaster
si assicurano che il richiedente l'accesso ai dati corrisponda effettivamente all'utente di cui
afferma l'identità. Tutti gli utenti che richiedono i servizi di Postgres sono messi a confronto con il contenuto
della classe <B>pg_user</B>, per accertare che siano autorizzati a farlo. Tuttavia,
la verifica dell'effettiva identità dell'utente è effettuata in diversi
modi:
<UL>
<LI> <B>Dalla shell dell'utente:</B> Un server backend, lanciato dalla shell di un utente,
conserva lo user-id dell'utente (reale) prima di effettuare un
<B>setuid</B> allo user-id dell'utente <B>postgres</B>. Lo user-id reale è usato come
dato fondamentale per le verifiche relative al controllo d'accesso. Nessun'altra autenticazione viene effettuata.</LI>
<LI> <B>Dalla rete:</B> Se il sistema Postgres è stato installato direttamente dai suoi pacchetti di distribuzione, l'accesso alla
porta TCP Internet, del processo postmaster, è utilizzabile da chiunque. Il DBA (Data Base Administrator = Amministratore del database)
configura il file <B>pg_hba.conf</B>, situato nella directory <B>$PGDATA</B>, per specificare quale
sistema di autenticazione verrà usato concordemente con l'host che effettua la connessione,
e a quale database verrà connesso.
Leggete <B>pg_hba.conf(5)</B> (man 5 pg_hba.conf)
per consultare la descrizione
dei sistemi di autenticazione disponibili. Naturalmente, l'autenticazione basata su host
non è infallibile, neanche in Unix. Per ostacolare i malintenzionati risoluti
è possibile anche mascherare l'host di origine. Tali questioni sulla sicurezza vanno oltre
la competenza di Postgres.</LI>
</UL>
<H2><A NAME="ss11.2">11.2 Controllo d'Accesso basato su host (host-based)</A>
</H2>
<P>Il controllo d'accesso host-based, è il nome per i controlli elementari che PostgreSQL
effettua su quale parte del database
sia concessa ai client, e su come gli utenti di questi client devono
accreditarsi.
Ogni sistema di database contiene un file chiamato <B>pg_hba.conf</B>, nella sua
directory <B>$PGDATA</B>, che controlla chi
può connettersi ad ogni database.
Ogni client che accede ad un database, deve essere citato nel gruppo degli
iscritti in <B>pg_hba.conf</B>. Altrimenti tutti
i tentativi di connessione da quel client saranno respinti, e daranno il
messaggio d'errore <B>"User authentication failed"</B>.
<P>Leggete le pagine di manuale in linea di <B>pg_hba.conf(5)</B> (man 5 pg_hba.conf).
<P>Il formato generale del file <B>pg_hba.conf</B>, è costituito da un insieme di record, uno
per ogni riga. Le righe vuote, e quelle
che iniziano con il carattere "#", sono ignorate. Un record è composto da
un gruppo di campi
separati da spazi e/o tabulazioni.
<P>I client possono effettuare le connessioni usando socket di dominio Unix, o socket
di dominio Internet (ad esempio
TCP/IP). Le connessioni, effettuate mediante socket di dominio Unix, sono controllate usando
record del seguente
formato:
<HR>
<PRE>
database_locale metodo_di_autenticazione
</PRE>
<HR>
dove
<P><B>database_locale</B> specifica il database cui è riferito il record. Il valore
<B>all</B> specifica che quanto segue verrà applicato a
tutti i database.
<P><B>metodo_di_autenticazione</B> specifica il metodo che un utente deve usare per autenticare
sé stesso, quando
si connette a quel database usando socket di dominio Unix. I diversi
metodi sono descritti
più avanti.
<P>Le connessioni, effettuate usando i socket di dominio Internet, sono controllate usando
record con il seguente formato.
<P>
<HR>
<PRE>
host database indirizzo-TCP/IP maschera-TCP/IP metodo_di_autenticazione
</PRE>
<HR>
<P>L'indirizzo <B>TCP/IP</B> viene <I>moltiplicato logicamente</I> (mediante l'operatore binario AND) sia alla maschera TCP/IP specificata,
sia all'indirizzo TCP/IP del
client connesso. Se i due valori risultanti sono uguali, il record
viene usato per la connessione. Se ad una
connessione corrispondessero più record validi, viene usato il primo che
appare nel file. Sia l'indirizzo
TCP/IP, sia la maschera TCP/IP, sono espressi nella notazione decimale puntata.
Se per una connessione non viene trovato un record corrispondente, tra i metodi di autenticazione viene applicato
il 'reject' (vedere
<A HREF="#auth_method">Metodi di Autenticazione</A>).
<H2><A NAME="auth_method"></A> <A NAME="ss11.3">11.3 Metodi di Autenticazione </A>
</H2>
<P>I seguenti metodi di autenticazione sono supportati sia da Unix che dai socket di dominio TCP/IP:
<UL>
<LI> <B>trust</B>
La connessione è permessa incondizionatamente.</LI>
<LI> <B>reject</B>
La connessione è rifiutata incondizionatamente.</LI>
<LI> <B>crypt</B>
Al client viene chiesta una password per l'utente. Questa viene inviata cifrata (usando crypt(3)), e confrontata
con la password contenuta nella tabella pg_shadow. Se le password sono coincidenti, la connessione viene permessa.</LI>
<LI> <B>password</B>
Al client viene chiesta una password per l'utente. Questa viene inviata in chiaro e confrontata
con la password contenuta nella tabella <B>pg_shadow</B>. Se le password sono coincidenti, la connessione viene permessa.
Dopo la parola chiave 'password' può essere specificato un file di password facoltativo, da usarsi in alternativa
alla tabella <B>pg_shadow</B> per il confronto delle password fornite. Vedere <B>pg_passwd</B>.</LI>
</UL>
<P>I seguenti metodi di autenticazione sono supportati soltanto per i socket di dominio TCP/IP:
<UL>
<LI> <B>krb4</B>
Kerberos V4 è usato per autenticare l'utente.</LI>
<LI> <B>krb5</B>
Kerberos V5 è usato per autenticare l'utente.</LI>
<LI> <B>ident</B>
Il server ident è usato sul client per autenticare l'utente (RFC 1413). Un nome di mappa opzionale
può essere specificato dopo la parola chiave <B>ident</B>; questo nome permette ai nomi utente ident di essere mappati tra i nomi
degli utenti di Postgres. Le mappe sono conservate nel file <B>$PGDATA/pg_ident.conf</B>.</LI>
</UL>
<P>Ecco alcuni esempi:
<HR>
<PRE>
# Ci fidiamo di qualsiasi connessione via socket di dominio Unix.
local trust
# Ci fidiamo di qualsiasi connessione via TCP/IP da questa macchina.
host all 127.0.0.1 255.255.255.255 trust
# Questa macchina non è desiderata.
host all 192.168.0.10 255.255.255.0 reject
# Questa macchina non può cifrare, quindi le chiediamo le password in chiaro.
host all 192.168.0.3 255.255.255.0 password
# Il resto di questo gruppo di macchine dovrebbe fornire password cifrate.
host all 192.168.0.0 255.255.255.0 crypt
</PRE>
<HR>
<H2><A NAME="ss11.4">11.4 Controllo dell'Accesso</A>
</H2>
<P>Postgres fornisce meccanismi per consentire agli utenti, che mettono i loro dati a disposizione di altri utenti,
di limitarne l'accesso.
<P>
<UL>
<LI> <B>Superutenti del Database</B>
I super-utenti del Database (cioè gli utenti che hanno impostato <B>pg_user.usesuper</B>) saltano tranquillamente tutti i controlli
d'accesso descritti più avanti, con due eccezioni: gli aggiornamenti manuali del catalogo di sistema non sono permessi, se
l'utente non ha impostato <B>pg_user.usecatupd</B>; inoltre la cancellazione dei cataloghi dei sistemi (o le modifiche dei loro
schemi) non è mai concessa.</LI>
<LI> <B>Privilegio d'Accesso</B>
L'uso del privilegio d'accesso per limitare lettura, scrittura e impostazione di regole sulle
classi, è previsto nei comandi SQL <B>grant/revoke(l)</B>.</LI>
<LI> <B>Soppressione di classe e modifiche di schema</B>
I comandi per cancellare o modificare le strutture di una classe esistente, come alter, drop table, e
drop index, hanno effetto solo per il proprietario della classe. Come
è già stato precedentemente segnalato, queste operazioni non sono mai
consentite sui cataloghi di sistema.</LI>
</UL>
<H2><A NAME="ss11.5">11.5 Connessioni TCP/IP Protette mediante SSH</A>
</H2>
<P>Potete usare <B>ssh</B> per cifrare la connessione di rete tra i client e il server Postgres. Se fatto correttamente,
ciò dovrebbe portare ad una connessione di rete adeguatamente sicura.
<P>La documentazione per <B>ssh</B> fornisce la maggior parte delle informazioni per cominciare ad operare. Riferitevi all'url
<A HREF="http://www.heimhardt.de/htdocs/ssh.html">http://www.heimhardt.de/htdocs/ssh.html</A> per approfondire.
La realizzazione di una connessione con SSL può essere fatta in sole due fasi.
<P><B>Lanciare un tunnel sicuro mediante ssh: </B>
La realizzazione di una connessione con SSL può essere fatta in sole due fasi.
<UL>
<LI> Collegatevi con un tunnel, alla macchina back-end, come segue:
<HR>
<PRE>
ssh -L 3333:wit.mcs.anl.gov:5432 postgres@wit.mcs.anl.gov
</PRE>
<HR>
</LI>
<LI> Il numero <B>3333</B>, posto subito dopo l'argomento <B>-L</B>, è il numero della porta della vostra estremità del tunnel. Il
secondo numero, <B>5432</B>, è l'altra estremità remota del tunnel (il numero di porta che sta usando il vostro backend).
Il nome o l'indirizzo, posti tra i numeri delle porte, appartengono al server della macchina; questo vale anche
per l'ultimo argomento di <B>ssh</B>, che comprende anche il nome dell'utente opzionale. Senza il nome dell'utente, <B>ssh</B> proverà
con il nome col quale siete al momento connessi sulla macchina client. Potete usare qualsiasi nome-utente
accettabile per la macchina server, e questo nome-utente non è necessariamente correlato a postgres.</LI>
<LI> Con una sessione <B>ssh</B> attiva potete connettervi, con un client postgres, al vostro host locale, sul numero
di porta da voi specificato nella fase precedente. Se il client è <B>psql</B>, avrete bisogno di un'altra shell; infatti la
sessione di shell da voi usata, nella fase 1, è ora occupata da <B>ssh</B>.
<HR>
<PRE>
psql -h localhost -p 3333 -d mpw
</PRE>
<HR>
</LI>
<LI> Notate che avete specificato l'argomento <B>-h</B> per forzare il client ad usare il socket TCP/IP, invece
del socket Unix. Potete omettere l'argomento relativo alla porta, se scegliete <B>5432</B> come quella relativa alla vostra estremità del tunnel.</LI>
</UL>
<H2><A NAME="ss11.6">11.6 Autenticazione Kerberos</A>
</H2>
<P>Kerberos è un sistema standard di autenticazione sicura; è diffuso tra le aziende, ed è adatto a reti pubbliche
per il calcolo distribuito.
<P><B>Disponibilità: </B>
Il sistema di autenticazione Kerberos non viene distribuito insieme a Postgres. Le versioni di Kerberos sono solitamente
rese disponibili, come software opzionale, dal rivenditore del sistema operativo. In aggiunta, una distribuzione del codice sorgente può
essere ottenuta direttamente dal Progetto Athena del MIT.
<P>
<HR>
<PRE>
Nota: Potreste voler ottenere la versione del MIT anche se il vostro rivenditore ne fornisce
una sua versione; infatti le versioni di qualche rivenditore possono essere state storpiate o rese
non-interoperanti con la versione del MIT.
</PRE>
<HR>
<P>Le richieste di informazioni, riguardanti il 'vostro' Kerberos, dovrebbero essere rivolte al vostro rivenditore, o al Progetto Athena del MIT. Notate che
le FAQL (Frequently-Asked Questions Lists) sono periodicamente pubblicate sulla mailing list di Kerberos (mandate una mail
per sottoscrivervi), e sui news group USENET.
<P><B>Installazione: </B>
L'installazione di Kerberos è descritta in dettaglio nelle 'Kerberos Installation Notes'. Assicuratevi che
il file chiave del server (<B>srvtab</B> o <B>keytab</B>) sia leggibile, in un modo o nell'altro, dall'account di Postgres.
Postgres, ed i suoi client, possono essere compilati per usare o la Version 4, o la Version 5 dei protocolli Kerberos MIT;
per farlo, si imposta la variabile KRBVERS, nel file <B>src/Makefile.global</B>, al valore corretto.
Potete anche cambiare la collocazione in cui Postgres si aspetta di trovare le librerie associate, i file header
e il
file chiave del server.
A compilazione completata, Postgres deve essere registrato come un servizio di Kerberos. Leggete le 'Kerberos
Operations Notes', e le relative pagine di manuale, per avere maggiori dettagli sulla registrazione dei servizi.
<P><B>Funzionamento: </B>
Dopo le operazioni di installazione, Postgres dovrebbe operare in tutti i modi consueti per un normale servizio Kerberos. Per i dettagli sull'uso
dell'autenticazione, leggete la <I>PostgreSQL User's Guide</I>, e precisamente le sezioni relative a <B>postmaster</B> e <B>psql</B>.
Nella modalità di connessione della Version 5 di Kerberos, sono state adottate le seguenti convenzioni sulla nomenclatura degli utenti e dei servizi (vedere anche la tabella più sotto):
<UL>
<LI> Si assume che, tra i nomi principali dell'utente (i cosiddetti 'aname'), sia compreso l'effettivo nome utente di Unix/Postgres come
primo componente.</LI>
<LI> Si assume che il servizio Postgres abbia due componenti: il nome del servizio ed un nome di host,
rispettando un uso consolidato dalla Version 4 (ciò significa che tutti i suffissi di dominio sono soppressi).</LI>
</UL>
<P>
<HR>
<PRE>
Tabella: Esempi di Parametri di Kerberos
------------------------------------------------------
Parametro Esempio
------------------------------------------------------
user frew@S2K.ORG
user aoki/HOST=miyu.S2K.Berkeley.EDU@S2K.ORG
host postgres_dbms/ucbvax@S2K.ORG
------------------------------------------------------
</PRE>
<HR>
<HR>
<A HREF="PostgreSQL-HOWTO-12.html">Avanti</A>
<A HREF="PostgreSQL-HOWTO-10.html">Indietro</A>
<A HREF="PostgreSQL-HOWTO.html#toc11">Indice</A>
</BODY>
</HTML>
