Database-SQL-RDBMS HOW-TO document for Linux (PostgreSQL Object Relational Database System): Protezione del database

11. Protezione del database

La protezione del database è distribuita su diversi livelli:

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 postgres
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.
Le connessioni dei client possono essere ristrette secondo l'indirizzo IP e/o lo username, mediante il file pg_hba.conf in $PG_DATA.
Le connessioni dei client possono essere autenticate mediante uso di altri pacchetti esterni.
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.
Gli utenti possono essere assegnati a dei gruppi, e l'accesso alle tabelle può essere ristretto in base ai privilegi del gruppo.

11.1 Autenticazione degli utenti

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 pg_user, per accertare che siano autorizzati a farlo. Tuttavia, la verifica dell'effettiva identità dell'utente è effettuata in diversi modi:

Dalla shell dell'utente: Un server backend, lanciato dalla shell di un utente, conserva lo user-id dell'utente (reale) prima di effettuare un setuid allo user-id dell'utente postgres. Lo user-id reale è usato come dato fondamentale per le verifiche relative al controllo d'accesso. Nessun'altra autenticazione viene effettuata.
Dalla rete: 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 pg_hba.conf, situato nella directory $PGDATA, per specificare quale sistema di autenticazione verrà usato concordemente con l'host che effettua la connessione, e a quale database verrà connesso. Leggete pg_hba.conf(5) (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.

11.2 Controllo d'accesso basato su host (host-based)

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 pg_hba.conf, nella sua directory $PGDATA, che controlla chi può connettersi ad ogni database. Ogni client che accede ad un database, deve essere citato nel gruppo degli iscritti in pg_hba.conf. Altrimenti tutti i tentativi di connessione da quel client saranno respinti, e daranno il messaggio d'errore "User authentication failed".

Leggete le pagine di manuale in linea di pg_hba.conf(5) (man 5 pg_hba.conf).

Il formato generale del file pg_hba.conf, è 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.

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:

database_locale metodo_di_autenticazione

dove

database_locale specifica il database cui è riferito il record. Il valore all specifica che quanto segue verrà applicato a tutti i database.

metodo_di_autenticazione 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.

Le connessioni, effettuate usando i socket di dominio Internet, sono controllate usando record con il seguente formato.

host database indirizzo-TCP/IP maschera-TCP/IP metodo_di_autenticazione

L'indirizzo TCP/IP viene moltiplicato logicamente (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 corrispondo 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 Metodi di Autenticazione).

11.3 Metodi di autenticazione

I seguenti metodi di autenticazione sono supportati sia da Unix che dai socket di dominio TCP/IP:

trust: la connessione è permessa incondizionatamente.
reject: la connessione è rifiutata incondizionatamente.
crypt: 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.
password: al client viene chiesta una password per l'utente. Questa viene inviata in chiaro e confrontata con la password contenuta nella tabella pg_shadow. 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 pg_shadow per il confronto delle password fornite. Vedere pg_passwd.

I seguenti metodi di autenticazione sono supportati soltanto per i socket di dominio TCP/IP:

krb4: l'autenticazione dell'utente si effettua con Kerberos V4.
krb5: l'autenticazione dell'utente si effettua con Kerberos V5.
ident: il server ident è usato sul client per autenticare l'utente (RFC 1413). Un nome di mappa opzionale può essere specificato dopo la parola chiave ident; questo nome permette ai nomi utente ident di essere mappati tra i nomi degli utenti di Postgres. Le mappe sono conservate nel file $PGDATA/pg_ident.conf.

Ecco alcuni esempi:

# 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

11.4 Controllo dell'accesso

Postgres fornisce meccanismi per consentire agli utenti, che mettono i loro dati a disposizione di altri utenti, di limitarne l'accesso.

Superutenti del database I super-utenti del database (cioè gli utenti che hanno impostato pg_user.usesuper) 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 pg_user.usecatupd; inoltre la cancellazione dei cataloghi dei sistemi (o le modifiche dei loro schemi) non è mai concessa.
Privilegio d'accesso L'uso del privilegio d'accesso per limitare lettura, scrittura e impostazione di regole sulle classi, è previsto nei comandi SQL grant/revoke(l).
Soppressione di classe e modifiche di schema 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.

11.5 Connessioni TCP/IP protette mediante SSH

Potete usare ssh 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.

La documentazione per ssh fornisce la maggior parte delle informazioni per cominciare ad operare. Riferitevi all'url http://www.heimhardt.de/htdocs/ssh.html per approfondimenti. La realizzazione di una connessione con SSL può essere fatta in sole due fasi.

Lanciare un tunnel sicuro mediante ssh: La realizzazione di una connessione con SSL può essere fatta in sole due fasi.

Collegatevi con un tunnel, alla macchina back-end, come segue:
```
ssh -L 3333:wit.mcs.anl.gov:5432 postgres@wit.mcs.anl.gov
```
Il numero 3333, posto subito dopo l'argomento -L, è il numero della porta della vostra estremità del tunnel. Il secondo numero, 5432, è 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 ssh, che comprende anche il nome dell'utente opzionale. Senza il nome dell'utente, ssh 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.
Con una sessione ssh attiva potete connettervi, con un client postgres, al vostro host locale, sul numero di porta da voi specificato nella fase precedente. Se il client è psql, avrete bisogno di un'altra shell; infatti la sessione di shell da voi usata, nella fase 1, è ora occupata da ssh.
```
psql -h localhost -p 3333 -d mpw
```
Notate che avete specificato l'argomento -h per forzare il client ad usare il socket TCP/IP, invece del socket Unix. Potete omettere l'argomento relativo alla porta, se scegliete 5432 come quella relativa alla vostra estremità del tunnel.

11.6 Autenticazione Kerberos

Kerberos è un sistema standard di autenticazione sicura; è diffuso tra le aziende, ed è adatto a reti pubbliche per il calcolo distribuito.

Disponibilità: 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.

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.

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 pubblicate periodicamente sulla mailing list di Kerberos (mandate una mail per iscrivervi), e sui news group USENET.

Installazione: L'installazione di Kerberos è descritta in dettaglio nelle 'Kerberos Installation Notes'. Assicuratevi che il file chiave del server (srvtab o keytab) 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 src/Makefile.global, 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.

Funzionamento: 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 PostgreSQL User's Guide, e precisamente le sezioni relative a postmaster e psql. 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):

Si assume che, tra i nomi principali dell'utente (i cosiddetti 'aname'), sia compreso l'effettivo nome utente di Unix/Postgres come primo componente.
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).

                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
 ------------------------------------------------------

Next Previous Contents