Ograniczanie dostępu po IP i konfiguracja pg_hba.conf

pg_hba.conf — to plik konfiguracyjny PostgreSQL, który służy do zarządzania połączeniami i autentykacją. HBA to skrót od Host-Based Authentication (autentykacja na podstawie hosta). Ten plik działa jak taki sieciowy "szlaban", który określa:

• Kto może się łączyć z serwerem (adresy IP, rola, baza danych).
• Jaka metoda autentykacji jest wymagana do połączenia.

Jakby to porównać do życia, pg_hba.conf to taki ochroniarz przy wejściu do budynku. Decyduje, kogo wpuścić, a kogo nie, sprawdzając nie tylko twoje dokumenty (hasło), ale też meldunek (adres IP).

Struktura pliku pg_hba.conf

Plik pg_hba.conf składa się z linii, gdzie każda linia opisuje regułę dostępu. Struktura linii wygląda tak:

<typ połączenia> <baza danych> <użytkownik> <źródło> <metoda autentykacji>

Rozbijmy to na części:

Typ połączenia (connection type): określa, jak klient będzie się łączył.

• local: połączenie przez Unix-sockety (dla lokalnych użytkowników na serwerze Linux).
• host: połączenie przez TCP/IP.
• hostssl: połączenie przez TCP/IP, ale tylko z użyciem SSL.
• hostnossl: połączenie przez TCP/IP bez SSL.

Baza danych: wymienia bazy, do których jest dostęp. Możesz podać konkretną bazę, kilka baz oddzielonych przecinkiem, albo słowa kluczowe:

• all: Pozwól na dostęp do wszystkich baz danych.

Użytkownik: określa, którym użytkownikom wolno się łączyć.

• Możesz podać konkretną nazwę użytkownika albo użyć all, żeby pozwolić wszystkim.

Źródło (address): określa adres IP klienta lub zakres adresów.

• Dla IPv4 używamy formatu x.x.x.x lub x.x.x.x/y (gdzie /y to maska podsieci, np. /24).
• Dla IPv6 format to ::/y.
• Słowo kluczowe all oznacza pozwolenie dla wszystkich adresów IP.

Metoda autentykacji: określa, jakiego sposobu autentykacji użyć.

Przykłady:

• trust: pozwól na połączenie bez hasła (niebezpieczne, tylko do testów).
• md5: użyj hasła (zahashowanego).
• scram-sha-256: bezpieczniejsza autentykacja z użyciem SHA-256.
• reject: zabroń dostępu.

Przykłady linii w pg_hba.conf

Konfiguracja pliku może być elastyczna. Oto kilka przykładów:

1. Pozwól na lokalne połączenia przez Unix-socket

   local   all             all                                     trust
   

   Wszyscy użytkownicy mogą się łączyć do wszystkich baz na lokalnym serwerze bez hasła.

2. Pozwól na połączenia z jednego adresu IP

   host    my_database     my_user        192.168.1.100/32         md5
   

   Użytkownik my_user może się łączyć do bazy my_database tylko z adresu 192.168.1.100, używając hasła.

3. Pozwól na dostęp do bazy z całej podsieci

   host    my_database     all            192.168.1.0/24           scram-sha-256
   

   Każdy użytkownik z podsieci 192.168.1.0/24 może się łączyć do bazy my_database, ale tylko przez autentykację SHA-256.

4. Zabroń połączeń z określonej podsieci

   host    all             all            192.168.2.0/24           reject
   

   Połączenia z podsieci 192.168.2.0/24 są całkowicie zabronione.

Konfiguracja dostępu po adresach IP

Teraz, gdy już ogarniamy strukturę pliku, zobaczmy jak zarządzać połączeniami.

Spróbujmy ograniczyć dostęp do serwera tylko z określonych adresów IP. Załóżmy, że mamy serwer PostgreSQL i chcemy pozwolić na dostęp tylko z localhosta (127.0.0.1) i z podsieci biura (192.168.10.0/24). W tym celu dodajemy takie linie do pg_hba.conf:

# Dostęp lokalny
host    all             all            127.0.0.1/32             trust

# Dostęp z biura
host    all             all            192.168.10.0/24          md5

# Zabroń wszystko inne
host    all             all            0.0.0.0/0                reject

Tu reguła 0.0.0.0/0 oznacza "wszystkie adresy IP". Wyraźnie zabraniasz dostępu skądkolwiek poza wskazanymi adresami.

Konfiguracja dostępu dla zdalnych użytkowników

Jeśli twój serwer PostgreSQL działa w chmurze albo na zdalnym serwerze, możesz chcieć pozwolić na połączenia tylko z określonych zewnętrznych IP. Na przykład:

# Dostęp dla administratora z domu
host    all             admin_user     203.0.113.10/32          md5

W tym przykładzie tylko użytkownik admin_user z IP 203.0.113.10 będzie mógł się połączyć.

Przeładowanie konfiguracji

Po zmianach w pliku pg_hba.conf PostgreSQL musi je zastosować. Użyj do tego komendy:

sudo systemctl reload postgresql

Przeładowanie jest bezpieczne i nie wywali serwera.

Jeśli zapomniałeś, gdzie leży pg_hba.conf, możesz sprawdzić ścieżkę przez SQL:

SHOW hba_file;

Typowe błędy przy pracy z pg_hba.conf

Praca z pg_hba.conf jest dość prosta, ale początkujący admini czasem robią błędy. Na przykład:

1. Zapomnieli przeładować serwer. Wszystkie zmiany w pg_hba.conf wchodzą w życie dopiero po przeładowaniu konfiguracji.
2. Konfliktujące reguły. PostgreSQL przetwarza reguły od góry do dołu. Jak tylko jakaś zadziała, reszta jest ignorowana. Bardziej ogólne reguły powinny być niżej.
3. Zła maska podsieci. Na przykład, jeśli wpiszesz /0, otwierasz dostęp wszystkim, co może być poważną dziurą w bezpieczeństwie.

Przykłady realnych scenariuszy użycia

Testowanie aplikacji na lokalnym serwerze.

Pozwól na dostęp tylko z localhosta:

local   all   all   trust

Praca ze zdalnymi klientami.

Pozwól na dostęp klientowi z określonego IP:

host    all   client_user   203.0.113.42/32   scram-sha-256

Ograniczanie dostępu w publicznej sieci.

Zabroń połączeń z Internetu (ale pozwól biuru):

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

Na tym etapie powinieneś już kumać, jak używać pg_hba.conf do ograniczania dostępu do PostgreSQL. Ten plik to jeden z kluczowych narzędzi do zabezpieczania bazy danych. Dbaj o to, żeby ustawienia były logiczne, sprawdzone i zgodne z potrzebami biznesu. Chyba wszyscy chcemy żyć w świecie, gdzie dane są chronione przed hakerami? No chyba, że tym hakerem jesteś ty :)