Konfigurisanje pg_hba.conf na Linuxu: Bezbedno prijavljivanje na PostgreSQL

Article Image

Zašto vam pg_hba.conf direktno utiče na bezbednost PostgreSQL servera

Fajl pg_hba.conf je glavna tačka kontrole pristupa u PostgreSQL-u — on određuje ko, odakle i kako se može povezati na vašu bazu podataka. Ako ga zanemarite ili pogrešno podesite, rizikujete neovlašćeni pristup ili neželjeno izlaganje podataka. Vi kao administrator ili devops inženjer morate razumeti kako da definišete pravila tako da balansirate između upotrebljivosti i bezbednosti.

Na Linuxu, pg_hba.conf se obično nalazi u direktorijumu podataka PostgreSQL instance (npr. /etc/postgresql//main/ ili /var/lib/pgsql/data/). Nakon svake izmene, potrebno je ponovo učitati konfiguraciju (pg_ctl reload ili systemctl reload postgresql), da bi promene stupile na snagu bez restartovanja servera.

  • Bezbednost: ne dozvoljavajte pristup “trust” politikom osim u strogo kontrolisanim okruženjima.
  • Granularnost: definišite pravila po adresama, korisnicima i bazama.
  • Audit: beležite izmene i koristite kontrolu verzija za konfiguracione fajlove.

Kako je fajl strukturisan i koje vrste pravila postoje

Svaka linija u pg_hba.conf predstavlja jedno pravilo pristupa i sadrži više polja razdvojenih razmakom: tip konekcije, baza, korisnik, izvor (CIDR ili host imena), i metoda autentifikacije. U praksi ćete sresti nekoliko ključnih tipova konekcije:

  • local — Unix domain soket veze (bez IP adrese), često najpouzdaniji za lokalne aplikacije.
  • host — TCP/IP veze, zahtevaju definisanu adresu ili mrežu (npr. 192.168.1.0/24).
  • hostssl — kao host, ali zahteva SSL enkripciju na transportu.

Metode autentifikacije koje ćete najčešće koristiti su:

  • md5 — starija, ali i dalje u upotrebi (hashed lozinka).
  • scram-sha-256 — modernija i sigurnija metoda; preporučuje se za nove instalacije.
  • peer i ident — korisne za lokalnu autentifikaciju po UNIX nalogu, ali nisu prikladne za udaljeni pristup.

Priprema sistema pre izmene pg_hba.conf

Pre nego što menjate fajl, obavezno napravite rezervnu kopiju originalnog pg_hba.conf i proverite koje aplikacije koriste bazu. Takođe, planirajte promene tako da imate rezervni način pristupa (npr. lokalni shell pristup) u slučaju da greškom zaključate udaljeni pristup.

  • Napravite kopiju: cp pg_hba.conf pg_hba.conf.bak
  • Testirajte pristup s novim pravilima na testnom ili staging serveru.
  • Koristite komentare u fajlu da dokumentujete svaku promenu i razlog promene.

U sledećem delu ćemo detaljno proći kroz konkretne primere pravila, uključujući konfiguracije za md5 i scram-sha-256, pravila za VPN/korporativne mreže i primere kako postaviti hostssl za obaveznu SSL komunikaciju.

Konkrektni primeri: md5 vs. scram-sha-256

Prilikom prelaska sa md5 na scram-sha-256 važno je razumeti kako će to uticati na klijentske drivere i postojeće korisničke lozinke. Scram-sha-256 zahteva da su lozinke u bazi sačuvane u scram formatu — to ćete postići postavljanjem postgresql.conf parametra password_encryption = ‘scram-sha-256’ i menjanjem lozinki korisnika (ALTER ROLE … PASSWORD …).

Tipični pg_hba.conf unos za md5 izgleda ovako:

host    mydb    app_user    192.168.10.0/24    md5

A ekvivalentni, sigurniji unos za scram-sha-256:

host    mydb    app_user    192.168.10.0/24    scram-sha-256

Saveti:

  • Proverite da li vaši klijenti (JDBC/psycopg/libpq) podržavaju SCRAM pre promene.
  • Promenite lozinke kontrolisano — izvršite ALTER ROLE u maintenance window-u i testirajte konekcije.
  • U većim okruženjima možete privremeno dozvoliti md5 i scram paralelno za različite korisnike dok ne migrirate sve aplikacije.

Sigurna pravila za VPN i korporativne mreže

Kada se aplikacije povezuju preko VPN-a ili u okviru korporativne mreže, često želite strogo ograničiti pristup na određene mreže i usloviti jaču autentifikaciju. Primer za VPN subnet 10.8.0.0/24 koji koristi scram-sha-256:

host    all     +vpn_users    10.8.0.0/24    scram-sha-256

Objašnjenje:

  • +vpn_users — grupni naziv iz pg_ident.conf koji mapira LDAP/UNIX korisnike na PostgreSQL korisnike (ako koristite mapiranje).
  • Specifičnije pravilo (konkretan DB i korisnik) treba biti pre opštih pravila — prvo poklapanje važi.

Ako u korporativnom okruženju imate centralizovanu autentifikaciju (LDAP/AD), možete kombinovati mrečna ograničenja sa LDAP metodom:

host    all    +corp_users    10.0.0.0/16    ldap ldapserver=ldap.corp.example

Ne zaboravite: VPN mreže su češće implicitno poverljive, ali ipak tretirajte svaki host kao potencijalno kompromitovan — koristite najmanje privilegija za naloge i ograničite pristup samo potrebnim bazama.

Obavezno SSL (hostssl) i autentikacija sertifikatima

Za osetljive sisteme preporučljivo je prisiliti SSL transport i, gde je moguće, zahtevati klijentske sertifikate. Primer koji zahteva TLS i SCRAM autentikaciju:

hostssl    sensitive_db    reporting_user    172.16.5.0/24    scram-sha-256

Ako želite dodatno zahtevati klijentski sertifikat (mutual TLS), koristite auth metodu cert:

hostssl    sensitive_db    all    172.16.5.0/24    cert

Za cert metodu morate podesiti server.crt/server.key, poverenje CA u postgresql.conf (ssl_ca_file) i mapiranja u pg_ident.conf. Testirajte TLS koristeći openssl ili psql sa parametrom sslmode=require/verify-full i proverite da li su sertifikati pravilno verifikovani.

  • Uvijek testirajte promene na staging pre produkcije.
  • Dokumentujte svaki unos komentarima u fajlu kako biste znali razlog i datum promene.

Provere i testiranje promena

Pre nego što trajno primenite nova pravila, obavezno ih testirajte iz više perspektiva: lokalno, iz ciljne mreže i sa klijentskih aplikacija. Nakon izmene, izvršite ponovo učitavanje konfiguracije i verifikujte uspešne i neuspešne pokušaje prijave u log fajlovima.

  • Učitavanje bez restartovanja: systemctl reload postgresql ili pg_ctl reload.
  • Test prijave: koristite psql sa odgovarajućim parametrima (host, port, sslmode) iz svake mreže ili hosta koji bi trebalo da pristupi.
  • Proverite logove za greške autentifikacije i za poruke koje ukazuju na pogrešno poklapanje pravila.
  • Imitujte neuspeh (privremeno onemogućite mrežu ili promenite CIDR) kako biste potvrdili da ograničenja rade kako je očekivano.

Monitoring, backup i povratak na prethodnu konfiguraciju

Konfiguracioni fajl treba tretirati kao kritičan resurs — verzionisanje, auditi i rutinska provera omogućavaju brzu identifikaciju regresija. Uvek imajte plan povratka u slučaju da novo pravilo prekine produkcijske konekcije.

  • Čuvajte izmene u git repozitorijumu sa jasnim porukama i referencama na incident ili ticket broj.
  • Automatizujte monitoring grešaka autentifikacije i alertiranje za neuobičajene skokove u neuspelim prijavama.
  • Imajte pristup serveru konzolom ili lokalnom korisniku koji može vratiti prethodni pg_hba.conf ako je potrebno.
  • Planirajte maintenance window za promene koje utiču na veliki broj klijenata.

Završne preporuke

Primenom opreznih, testiranih pravila u pg_hba.conf značajno smanjujete površinu za napad bez narušavanja funkcionalnosti aplikacija. Držite konfiguracije verzionisanim, dokumentujte razloge promena i redovno proveravajte kompatibilnost klijenata pri uvođenju modernijih metoda autentifikacije. Za tehničke detalje i dodatne opcije uvek se možete obratiti zvaničnoj dokumentaciji pg_hba.conf, koja sadrži kompletan opis polja i metoda autentifikacije.

Zašto vam pg_hba.conf direktno utiče na bezbednost PostgreSQL servera

Fajl pg_hba.conf je glavna tačka kontrole pristupa u PostgreSQL-u — on određuje ko, odakle i kako se može povezati na vašu bazu podataka. Ako ga zanemarite ili pogrešno podesite, rizikujete neovlašćeni pristup ili neželjeno izlaganje podataka. Vi kao administrator ili devops inženjer morate razumeti kako da definišete pravila tako da balansirate između upotrebljivosti i bezbednosti.

Na Linuxu, pg_hba.conf se obično nalazi u direktorijumu podataka PostgreSQL instance (npr. /etc/postgresql//main/ ili /var/lib/pgsql/data/). Nakon svake izmene, potrebno je ponovo učitati konfiguraciju (pg_ctl reload ili systemctl reload postgresql), da bi promene stupile na snagu bez restartovanja servera.

  • Bezbednost: ne dozvoljavajte pristup “trust” politikom osim u strogo kontrolisanim okruženjima.
  • Granularnost: definišite pravila po adresama, korisnicima i bazama.
  • Audit: beležite izmene i koristite kontrolu verzija za konfiguracione fajlove.

Kako je fajl strukturisan i koje vrste pravila postoje

Svaka linija u pg_hba.conf predstavlja jedno pravilo pristupa i sadrži više polja razdvojenih razmakom: tip konekcije, baza, korisnik, izvor (CIDR ili host imena), i metoda autentifikacije. U praksi ćete sresti nekoliko ključnih tipova konekcije:

  • local — Unix domain soket veze (bez IP adrese), često najpouzdaniji za lokalne aplikacije.
  • host — TCP/IP veze, zahtevaju definisanu adresu ili mrežu (npr. 192.168.1.0/24).
  • hostssl — kao host, ali zahteva SSL enkripciju na transportu.

Metode autentifikacije koje ćete najčešće koristiti su:

  • md5 — starija, ali i dalje u upotrebi (hashed lozinka).
  • scram-sha-256 — modernija i sigurnija metoda; preporučuje se za nove instalacije.
  • peer i ident — korisne za lokalnu autentifikaciju po UNIX nalogu, ali nisu prikladne za udaljeni pristup.

Priprema sistema pre izmene pg_hba.conf

Pre nego što menjate fajl, obavezno napravite rezervnu kopiju originalnog pg_hba.conf i proverite koje aplikacije koriste bazu. Takođe, planirajte promene tako da imate rezervni način pristupa (npr. lokalni shell pristup) u slučaju da greškom zaključate udaljeni pristup.

  • Napravite kopiju: cp pg_hba.conf pg_hba.conf.bak
  • Testirajte pristup s novim pravilima na testnom ili staging serveru.
  • Koristite komentare u fajlu da dokumentujete svaku promenu i razlog promene.

U sledećem delu ćemo detaljno proći kroz konkretne primere pravila, uključujući konfiguracije za md5 i scram-sha-256, pravila za VPN/korporativne mreže i primere kako postaviti hostssl za obaveznu SSL komunikaciju.

Konkrektni primeri: md5 vs. scram-sha-256

Prilikom prelaska sa md5 na scram-sha-256 važno je razumeti kako će to uticati na klijentske drivere i postojeće korisničke lozinke. Scram-sha-256 zahteva da su lozinke u bazi sačuvane u scram formatu — to ćete postići postavljanjem postgresql.conf parametra password_encryption = ‘scram-sha-256’ i menjanjem lozinki korisnika (ALTER ROLE … PASSWORD …).

Tipični pg_hba.conf unos za md5 izgleda ovako:

host    mydb    app_user    192.168.10.0/24    md5

A ekvivalentni, sigurniji unos za scram-sha-256:

host    mydb    app_user    192.168.10.0/24    scram-sha-256

Saveti:

  • Proverite da li vaši klijenti (JDBC/psycopg/libpq) podržavaju SCRAM pre promene.
  • Promenite lozinke kontrolisano — izvršite ALTER ROLE u maintenance window-u i testirajte konekcije.
  • U većim okruženjima možete privremeno dozvoliti md5 i scram paralelno za različite korisnike dok ne migrirate sve aplikacije.

Sigurna pravila za VPN i korporativne mreže

Kada se aplikacije povezuju preko VPN-a ili u okviru korporativne mreže, često želite strogo ograničiti pristup na određene mreže i usloviti jaču autentifikaciju. Primer za VPN subnet 10.8.0.0/24 koji koristi scram-sha-256:

host    all     +vpn_users    10.8.0.0/24    scram-sha-256

Objašnjenje:

  • +vpn_users — grupni naziv iz pg_ident.conf koji mapira LDAP/UNIX korisnike na PostgreSQL korisnike (ako koristite mapiranje).
  • Specifičnije pravilo (konkretan DB i korisnik) treba biti pre opštih pravila — prvo poklapanje važi.

Ako u korporativnom okruženju imate centralizovanu autentifikaciju (LDAP/AD), možete kombinovati mrečna ograničenja sa LDAP metodom:

host    all    +corp_users    10.0.0.0/16    ldap ldapserver=ldap.corp.example

Ne zaboravite: VPN mreže su češće implicitno poverljive, ali ipak tretirajte svaki host kao potencijalno kompromitovan — koristite najmanje privilegija za naloge i ograničite pristup samo potrebnim bazama.

Obavezno SSL (hostssl) i autentikacija sertifikatima

Za osetljive sisteme preporučljivo je prisiliti SSL transport i, gde je moguće, zahtevati klijentske sertifikate. Primer koji zahteva TLS i SCRAM autentikaciju:

hostssl    sensitive_db    reporting_user    172.16.5.0/24    scram-sha-256

Ako želite dodatno zahtevati klijentski sertifikat (mutual TLS), koristite auth metodu cert:

hostssl    sensitive_db    all    172.16.5.0/24    cert

Za cert metodu morate podesiti server.crt/server.key, poverenje CA u postgresql.conf (ssl_ca_file) i mapiranja u pg_ident.conf. Testirajte TLS koristeći openssl ili psql sa parametrom sslmode=require/verify-full i proverite da li su sertifikati pravilno verifikovani.

  • Uvijek testirajte promene na staging pre produkcije.
  • Dokumentujte svaki unos komentarima u fajlu kako biste znali razlog i datum promene.

Provere i testiranje promena

Pre nego što trajno primenite nova pravila, obavezno ih testirajte iz više perspektiva: lokalno, iz ciljne mreže i sa klijentskih aplikacija. Nakon izmene, izvršite ponovo učitavanje konfiguracije i verifikujte uspešne i neuspešne pokušaje prijave u log fajlovima.

  • Učitavanje bez restartovanja: systemctl reload postgresql ili pg_ctl reload.
  • Test prijave: koristite psql sa odgovarajućim parametrima (host, port, sslmode) iz svake mreže ili hosta koji bi trebalo da pristupi.
  • Proverite logove za greške autentifikacije i za poruke koje ukazuju na pogrešno poklapanje pravila.
  • Imitujte neuspeh (privremeno onemogućite mrežu ili promenite CIDR) kako biste potvrdili da ograničenja rade kako je očekivano.

Monitoring, backup i povratak na prethodnu konfiguraciju

Konfiguracioni fajl treba tretirati kao kritičan resurs — verzionisanje, auditi i rutinska provera omogućavaju brzu identifikaciju regresija. Uvek imajte plan povratka u slučaju da novo pravilo prekine produkcijske konekcije.

  • Čuvajte izmene u git repozitorijumu sa jasnim porukama i referencama na incident ili ticket broj.
  • Automatizujte monitoring grešaka autentifikacije i alertiranje za neuobičajene skokove u neuspelim prijavama.
  • Imajte pristup serveru konzolom ili lokalnom korisniku koji može vratiti prethodni pg_hba.conf ako je potrebno.
  • Planirajte maintenance window za promene koje utiču na veliki broj klijenata.

Checklist i praktični koraci pre uvođenja promena u produkciju

Pre nego što primenite bilo kakvu izmenu u pg_hba.conf na produkciji, prođite kroz kontrolnu listu koja smanjuje rizik od zastoja ili neočekivanih prekida servisa. Dobar proces obuhvata pripremu, validaciju i monitoring.

  • Verzija i backup: zabeležite trenutnu verziju fajla i napravite nazadnu kopiju u sigurnom skladištu sa oznakom datuma.
  • Staging test: primenite iste izmene na testnom okruženju koje ima identičnu topologiju mreže i klijentske verzije.
  • Kompatibilnost klijenata: proverite podršku SCRAM ili drugih metoda u svim aplikacionim driverima i servisima.
  • Automatizovana validacija: koristite skripte ili CI pipeline koji proveravaju sintaksu fajla i simuliraju psql konekcije.
  • Rollback plan: definišite korake za hitan povratak (restore fajla i reload servisa) i testirajte ih unapred.
  • Logovanje i alerti: povećajte detaljnost logovanja tokom promene i podesite alarme za nagli porast neuspelih prijava.
  • Komunikacija: obavestite timove i zainteresovane strane, zakazite maintenance window i imajte kontakt osobu na raspolaganju.
  • Post-implementacioni monitoring: pratite performanse i autentifikacione logove najmanje 24-72 sata nakon promene.

Završne preporuke

Primenom opreznih, testiranih pravila u pg_hba.conf značajno smanjujete površinu za napad bez narušavanja funkcionalnosti aplikacija. Držite konfiguracije verzionisanim, dokumentujte razloge promena i redovno proveravajte kompatibilnost klijenata pri uvođenju modernijih metoda autentifikacije. Za tehničke detalje i dodatne opcije uvek se možete obratiti zvaničnoj dokumentaciji pg_hba.conf, koja sadrži kompletan opis polja i metoda autentifikacije.

By Databaze