CodeGym /Corsi /SQL SELF /Limitare l'accesso tramite IP e configurazione di pg_hba...

Limitare l'accesso tramite IP e configurazione di pg_hba.conf

SQL SELF
Livello 47, Lezione 4
Disponibile

pg_hba.conf è un file di configurazione di PostgreSQL pensato per gestire le connessioni e l’autenticazione. HBA sta per Host-Based Authentication (autenticazione basata sull’host). Questo file fa da “barriera” di rete e decide:

  • Chi può collegarsi al server (indirizzi IP, ruolo, database).
  • Quale metodo di autenticazione serve per collegarsi.

Se vogliamo fare un paragone con la vita reale, pg_hba.conf è come il portinaio all’ingresso di un palazzo. Decide chi può entrare e chi no, controllando non solo i tuoi documenti (la password), ma anche la residenza (l’indirizzo IP).

Struttura del file pg_hba.conf

Il file pg_hba.conf è fatto di righe, ognuna delle quali descrive una regola di accesso. La struttura di una riga è così:

<tipo di connessione> <database> <utente> <sorgente> <metodo di autenticazione>

Vediamo i componenti:

Tipo di connessione (connection type): indica come il client si collegherà.

  • local: connessione tramite socket Unix (per utenti locali su server Linux).
  • host: connessione tramite TCP/IP.
  • hostssl: connessione tramite TCP/IP, ma solo usando SSL.
  • hostnossl: connessione tramite TCP/IP senza SSL.

Database: elenca i database a cui è permesso l’accesso. Puoi mettere un database specifico, più database separati da virgola, oppure parole chiave:

  • all: Permetti l’accesso a tutti i database.

Utente: indica quali utenti possono collegarsi.

  • Puoi mettere un nome utente specifico o usare all per permettere a tutti.

Sorgente (address): indica l’indirizzo IP del client o un intervallo di indirizzi.

  • Per IPv4 si usa il formato x.x.x.x o x.x.x.x/y (dove /y è la subnet mask, tipo /24).
  • Per IPv6 si usa il formato ::/y.
  • La parola chiave all vuol dire permesso per tutti gli IP.

Metodo di autenticazione: indica quale metodo di autenticazione viene usato.

Esempi:

  • trust: permette la connessione senza password (non sicuro, solo per test).
  • md5: usa la password (hashata).
  • scram-sha-256: autenticazione più sicura con SHA-256.
  • reject: vieta l’accesso.

Esempi di riga in pg_hba.conf

La configurazione del file può essere flessibile. Ecco qualche esempio:

  1. Permettere connessioni locali tramite socket Unix

    local   all             all                                     trust
    

    Tutti gli utenti possono collegarsi a tutti i database sul server locale senza password.

  2. Permettere connessioni da un solo indirizzo IP

    host    my_database     my_user        192.168.1.100/32         md5
    

    L’utente my_user può collegarsi al database my_database solo dall’IP 192.168.1.100, usando la password.

  3. Permettere l’accesso al database da tutta una subnet

    host    my_database     all            192.168.1.0/24           scram-sha-256
    

    Qualsiasi utente dalla subnet 192.168.1.0/24 può collegarsi al database my_database, ma solo con autenticazione SHA-256.

  4. Vietare connessioni da una certa subnet

    host    all             all            192.168.2.0/24           reject
    

    Le connessioni dalla subnet 192.168.2.0/24 sono completamente vietate.

Configurare l’accesso tramite indirizzi IP

Ora che abbiamo capito la struttura del file, vediamo come gestire le connessioni.

Proviamo a limitare l’accesso al server da certi indirizzi IP. Supponiamo di avere un server PostgreSQL e vogliamo permettere l’accesso solo dal localhost (127.0.0.1) e dalla subnet dell’ufficio (192.168.10.0/24). Per farlo aggiungiamo queste righe in pg_hba.conf:

# Accesso locale
host    all             all            127.0.0.1/32             trust

# Accesso dall’ufficio
host    all             all            192.168.10.0/24          md5

# Vietare tutto il resto
host    all             all            0.0.0.0/0                reject

Qui la regola 0.0.0.0/0 vuol dire “tutti gli indirizzi IP”. Stiamo vietando esplicitamente l’accesso da ovunque, tranne che dagli indirizzi specificati.

Configurare l’accesso per utenti remoti

Se il tuo server PostgreSQL gira nel cloud o su un server remoto, potresti voler permettere le connessioni solo da certi IP esterni. Per esempio:

# Accesso per l’amministratore da casa
host    all             admin_user     203.0.113.10/32          md5

In questo esempio solo l’utente admin_user dall’IP 203.0.113.10 potrà collegarsi.

Ricaricare la configurazione

Dopo aver cambiato il file pg_hba.conf PostgreSQL deve applicare le modifiche. Usa questo comando:

sudo systemctl reload postgresql

Il reload è sicuro e non farà crashare il server.

Se ti sei dimenticato dove si trova pg_hba.conf, puoi scoprirlo via SQL:

SHOW hba_file;

Errori tipici con pg_hba.conf

Lavorare con pg_hba.conf è abbastanza semplice, ma chi è alle prime armi a volte fa degli errori. Tipo:

  1. Dimenticato di ricaricare il server. Tutte le modifiche a pg_hba.conf entrano in vigore solo dopo il reload della configurazione.
  2. Regole in conflitto. PostgreSQL processa le regole dall’alto verso il basso. Appena una regola scatta, le altre vengono ignorate. Le regole più generiche devono stare più in basso.
  3. Subnet mask sbagliata. Per esempio, se metti /0 apri l’accesso a tutti, che può essere una vulnerabilità seria.

Esempi di scenari reali

Testare un’applicazione su server locale.

Permettere l’accesso solo dal localhost:

local   all   all   trust

Lavorare con client remoti.

Permettere l’accesso a un client da un certo IP:

host    all   client_user   203.0.113.42/32   scram-sha-256

Limitare l’accesso dalla rete pubblica.

Vietare le connessioni da Internet (ma permettere all’ufficio):

host    all   all   0.0.0.0/0   reject
host    all   all   192.168.10.0/24   md5

A questo punto dovresti già avere un’idea di come usare pg_hba.conf per limitare l’accesso a PostgreSQL. Questo file è uno degli strumenti chiave per la sicurezza del database. Assicurati che le impostazioni siano logiche, testate e in linea con le esigenze del business. Non vorremmo forse vivere in un mondo dove i dati sono al sicuro dagli hacker? Beh, certo, a meno che l’hacker non sia tu :)

2
Compito
SQL SELF, livello 47, lezione 4
Bloccato
Abilitare l'accesso locale
Abilitare l'accesso locale
1
Sondaggio/quiz
Gestione degli accessi e sicurezza, livello 47, lezione 4
Non disponibile
Gestione degli accessi e sicurezza
Gestione degli accessi e sicurezza
Commenti
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION