Zugriffsbeschränkung nach IP und Konfiguration von pg_hba.conf

pg_hba.conf ist eine Konfigurationsdatei von PostgreSQL, die für das Management von Verbindungen und Authentifizierung zuständig ist. HBA steht für Host-Based Authentication (Host-basierte Authentifizierung). Diese Datei ist quasi die Netzwerk-"Schranke", die bestimmt:

• Wer sich mit dem Server verbinden darf (IP-Adressen, Rolle, Datenbank).
• Welche Authentifizierungsmethode für die Verbindung nötig ist.

Wenn man das mit dem echten Leben vergleicht, ist pg_hba.conf wie ein Türsteher am Eingang eines Gebäudes. Er entscheidet, wen er reinlässt und wen nicht – und prüft dabei nicht nur deine Ausweise (Passwort), sondern auch deinen Wohnort (IP-Adresse).

Aufbau der Datei pg_hba.conf

Die Datei pg_hba.conf besteht aus Zeilen, wobei jede Zeile eine Zugriffsregel beschreibt. Der Aufbau einer Zeile sieht so aus:

<Verbindungstyp> <Datenbank> <Benutzer> <Quelle> <Authentifizierungsmethode>

Schauen wir uns die Komponenten an:

Verbindungstyp (connection type): Bestimmt, wie sich der Client verbindet.

• local: Verbindung über Unix-Sockets (für lokale User auf einem Linux-Server).
• host: Verbindung über TCP/IP.
• hostssl: Verbindung über TCP/IP, aber nur mit SSL.
• hostnossl: Verbindung über TCP/IP ohne SSL.

Datenbank: Listet die Datenbanken auf, auf die Zugriff erlaubt ist. Du kannst eine bestimmte Datenbank angeben, mehrere durch Kommas getrennt oder Schlüsselwörter:

• all: Zugriff auf alle Datenbanken erlauben.

Benutzer: Gibt an, welchen Benutzern die Verbindung erlaubt ist.

• Du kannst einen bestimmten Usernamen angeben oder all nutzen, um allen Zugriff zu erlauben.

Quelle (address): Gibt die IP-Adresse des Clients oder einen Adressbereich an.

• Für IPv4 nutzt man das Format x.x.x.x oder x.x.x.x/y (wobei /y die Subnetzmaske ist, z.B. /24).
• Für IPv6 nutzt man das Format ::/y.
• Das Schlüsselwort all bedeutet, dass alle IP-Adressen erlaubt sind.

Authentifizierungsmethode: Gibt an, welche Authentifizierungsmethode verwendet wird.

Beispiele:

• trust: Verbindung ohne Passwort erlauben (unsicher, nur für Tests).
• md5: Passwort verwenden (gehasht).
• scram-sha-256: Sicherere Authentifizierung mit SHA-256.
• reject: Zugriff verweigern.

Beispiele für Zeilen in pg_hba.conf

Die Konfiguration der Datei ist ziemlich flexibel. Hier ein paar Beispiele:

1. Lokale Verbindungen über Unix-Socket erlauben

   local   all             all                                     trust
   

   Allen Usern ist es erlaubt, sich ohne Passwort mit allen Datenbanken auf dem lokalen Server zu verbinden.

2. Verbindung von einer bestimmten IP-Adresse erlauben

   host    my_database     my_user        192.168.1.100/32         md5
   

   User my_user darf sich nur von der IP 192.168.1.100 mit der Datenbank my_database verbinden – mit Passwort.

3. Zugriff auf eine Datenbank aus einem ganzen Subnetz erlauben

   host    my_database     all            192.168.1.0/24           scram-sha-256
   

   Jeder User aus dem Subnetz 192.168.1.0/24 darf sich mit my_database verbinden, aber nur mit SHA-256-Authentifizierung.

4. Verbindungen aus einem bestimmten Subnetz verbieten

   host    all             all            192.168.2.0/24           reject
   

   Verbindungen aus dem Subnetz 192.168.2.0/24 sind komplett verboten.

Zugriffskontrolle nach IP-Adressen konfigurieren

Jetzt, wo wir den Aufbau der Datei kennen, schauen wir uns an, wie man die Verbindungen steuert.

Versuchen wir mal, den Zugriff auf den Server auf bestimmte IP-Adressen zu beschränken. Angenommen, wir haben einen PostgreSQL-Server und wollen nur Zugriff vom lokalen Host (127.0.0.1) und vom Büro-Subnetz (192.168.10.0/24) erlauben. Dafür fügen wir diese Zeilen in pg_hba.conf ein:

# Lokaler Zugriff
host    all             all            127.0.0.1/32             trust

# Zugriff aus dem Büro
host    all             all            192.168.10.0/24          md5

# Alles andere verbieten
host    all             all            0.0.0.0/0                reject

Hier bedeutet die Regel 0.0.0.0/0 "alle IP-Adressen". Wir verbieten also explizit den Zugriff von überall, außer von den angegebenen Adressen.

Zugriff für entfernte User konfigurieren

Wenn dein PostgreSQL-Server in der Cloud oder auf einem Remote-Server läuft, willst du vielleicht nur bestimmten externen IPs Zugriff geben. Zum Beispiel:

# Zugriff für Admin von zu Hause
host    all             admin_user     203.0.113.10/32          md5

In diesem Beispiel kann sich nur der User admin_user von der IP 203.0.113.10 verbinden.

Konfiguration neu laden

Nachdem du Änderungen in pg_hba.conf gemacht hast, muss PostgreSQL sie übernehmen. Dafür nutzt du den Befehl:

sudo systemctl reload postgresql

Das Neuladen ist sicher und bringt den Server nicht zum Absturz.

Falls du vergessen hast, wo pg_hba.conf liegt, kannst du den Pfad per SQL rausfinden:

SHOW hba_file;

Typische Fehler beim Arbeiten mit pg_hba.conf

Mit pg_hba.conf zu arbeiten ist eigentlich easy, aber gerade am Anfang passieren schnell Fehler. Zum Beispiel:

1. Server-Neustart vergessen. Alle Änderungen in pg_hba.conf greifen erst nach dem Neuladen der Konfiguration.
2. Regeln, die sich überschneiden. PostgreSQL arbeitet die Regeln von oben nach unten ab. Sobald eine Regel greift, werden die anderen ignoriert. Allgemeinere Regeln sollten weiter unten stehen.
3. Falsche Subnetzmaske. Wenn du zum Beispiel /0 angibst, öffnest du den Zugriff für alle – das ist eine fette Sicherheitslücke.

Beispiele aus der Praxis

App-Testing auf dem lokalen Server.

Zugriff nur vom lokalen Host erlauben:

local   all   all   trust

Arbeiten mit entfernten Clients.

Zugriff für einen Client mit bestimmter IP erlauben:

host    all   client_user   203.0.113.42/32   scram-sha-256

Zugriff im öffentlichen Netz einschränken.

Verbindungen aus dem Internet verbieten (aber Büro erlauben):

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

Jetzt solltest du schon ein gutes Gefühl dafür haben, wie du pg_hba.conf nutzt, um den Zugriff auf PostgreSQL einzuschränken. Diese Datei ist eines der wichtigsten Tools, um deine Datenbank abzusichern. Achte darauf, dass deine Einstellungen logisch, getestet und auf die Anforderungen deines Business abgestimmt sind. Wir wollen doch alle in einer Welt leben, in der Daten vor Hackern geschützt sind, oder? Außer natürlich, du bist selbst der Hacker :)