Użytkownicy, role i uprawnienia w PostgreSQL

W tym artykule przejdziemy przez praktyczne aspekty pracy z użytkownikami, rolami i uprawnieniami w PostgreSQL. Zobaczysz, jak tworzyć konta, nadawać prawa do baz, schematów i tabel, jak działają GRANT i REVOKE, oraz jak konfigurować dostęp w pliku pg_hba.conf. Na koniec — zestaw dobrych praktyk bezpieczeństwa, dzięki którym Twoja baza będzie nie tylko działać, ale też będzie bezpieczna.

System ról w PostgreSQL

PostgreSQL używa jednego pojęcia: rola. Rola może mieć atrybut LOGIN (wtedy reprezentuje użytkownika), ale równie dobrze może być „grupą” bez logowania. Role w PostgreSQL mogą należeć do innych ról i dziedziczyć ich uprawnienia (INHERIT domyślnie włączone). Dostępne atrybuty to m.in. SUPERUSER, CREATEDB, CREATEROLE, REPLICATION, BYPASSRLS. Taki model upraszcza kontrolę dostępu i skalowanie zespołów.

Uprawnienia w PostgreSQL są nadawane per obiekt: DATABASE, SCHEMA, TABLE, SEQUENCE, FUNCTION, TYPE, LANGUAGE i inne. Obok własnych ról można użyć predefiniowanych jak pg_read_all_data lub pg_write_all_data, ale tylko świadomie. Jeśli dopiero zaczynasz, zobacz też: PostgreSQL: wprowadzenie, instalacja i pierwsza baza danych. To kontekst do tego, jak działają użytkownicy PostgreSQL i uprawnienia w PostgreSQL.

Tworzenie użytkowników i nadawanie uprawnień

Do tworzenia kont używaj ról z LOGIN. Hasła przechowuj w SCRAM (domyślnie od v14). Zwykle rozdziela się właściciela obiektów (owner) od kont aplikacyjnych. Poniżej minimalny szkielet: utworzenie ról, schematu i nadanie praw do schematu oraz istniejących i przyszłych tabel/sekwencji (grant on schema postgresql i default privileges).

SQL
Kopiuj
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
-- role aplikacyjne
CREATE ROLE app_owner LOGIN PASSWORD 'Zm!enTo' NOSUPERUSER NOCREATEDB NOCREATEROLE;
CREATE ROLE app_user  LOGIN PASSWORD 'JesCze1e' NOSUPERUSER NOCREATEDB NOCREATEROLE;

-- schemat i właściciel
CREATE SCHEMA app AUTHORIZATION app_owner;

-- dostęp użytkownika do bazy, schematu i obiektów
GRANT CONNECT ON DATABASE current_database() TO app_user;
GRANT USAGE ON SCHEMA app TO app_user;

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app TO app_user;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA app TO app_user;

-- domyślne prawa dla nowych obiektów tworzonych przez ownera
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_user;
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT USAGE, SELECT ON SEQUENCES TO app_user;

Takie podejście ogranicza potrzebę ręcznego GRANT po każdym DDL. Dla składni i różnic dialektu SQL zobacz: Dialekt SQL w PostgreSQL: najważniejsze różnice i rozszerzenia. To praktyczny fundament pod użytkownicy postgresql i nadawanie uprawnień PostgreSQL.

Role grupowe i dziedziczenie

Role grupowe (NOLOGIN) agregują uprawnienia i upraszczają zarządzanie. Tworzysz role „biznesowe” (np. app_readonly, app_rw), przypisujesz im uprawnienia w PostgreSQL do schematów/tabel, a następnie dołączasz użytkowników. Dzięki INHERIT członkowie automatycznie korzystają z praw grupy; NOINHERIT wymaga SET ROLE do wejścia w kontekst grupy.

Przykład: rola tylko do odczytu, domyślne prawa do przyszłych tabel i przypisanie użytkownika. To kanoniczny wzorzec „role w postgresql” dla dużych zespołów.

SQL
Kopiuj
1
2
3
4
5
6
7
8
9
10
-- rola grupowa tylko do odczytu
CREATE ROLE app_readonly NOLOGIN;

GRANT USAGE ON SCHEMA app TO app_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_readonly;
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT SELECT ON TABLES TO app_readonly;

-- członkostwo
GRANT app_readonly TO app_user; -- domyślnie INHERIT czynny

GRANT, REVOKE i ograniczenia dostępu

GRANT/REVOKE są transakcyjne, więc możesz bezpiecznie testować zmiany i w razie potrzeby zrobić ROLLBACK. Działają per obiekt i precyzują operacje (SELECT, INSERT, UPDATE(kolumny), DELETE, TRUNCATE, REFERENCES, TRIGGER, USAGE). W praktyce „grant revoke postgresql” to codzienne narzędzia do kontroli, a ALTER DEFAULT PRIVILEGES domyka lukę dla przyszłych obiektów.

Poniżej krótkie przykłady oraz włączenie RLS dla izolacji wierszy. RLS nie zastępuje GRANT/REVOKE, tylko je uzupełnia. Więcej o transakcjach i atomowości: Transakcje i poziomy izolacji w SQL.

SQL
Kopiuj
1
2
3
4
5
6
7
8
9
10
11
12
13
-- nadawanie i odbieranie praw
GRANT USAGE ON SCHEMA app TO app_user;
GRANT SELECT, INSERT ON app.invoices TO app_user;
REVOKE UPDATE ON app.invoices FROM app_user;

-- domyślne prawa dla nowych obiektów
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT SELECT ON TABLES TO app_readonly;

-- prosta polityka RLS (izolacja najemcy)
ALTER TABLE app.invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY invoices_tenant_isolation ON app.invoices
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

Najlepsze praktyki bezpieczeństwa

Stosuj zasadę najmniejszych uprawnień. Aplikacja nie powinna być SUPERUSER ani mieć CREATEROLE/CREATEDB. Rozdziel właściciela obiektów (tworzy DDL) od użytkowników runtime. Unikaj używania schematu public jako miejsca na obiekty aplikacyjne; rozważ REVOKE CREATE na schema public od PUBLIC. Kontroluj search_path i preferuj kwalifikowane nazwy.

Wymuś SCRAM-SHA-256, rotuj hasła, używaj długich haseł lub certyfikatów. Zarządzaj dostępem przez role grupowe zamiast indywidualnych GRANT dla każdej osoby. Loguj DDL i zmiany uprawnień (log_statement = 'ddl') i regularnie weryfikuj stan. I pamiętaj: testuj polityki na środowisku staging oraz utrzymuj kopie zapasowe – patrz Backup i odzyskiwanie danych w PostgreSQL.

Konfiguracja dostępu w pliku pg_hba.conf

pg_hba.conf definiuje, kto i skąd może się połączyć oraz jaką metodą uwierzytelnić (scram-sha-256, md5, peer, cert, reject, trust). Reguły są sprawdzane od góry do dołu; pierwsze dopasowanie wygrywa. Precyzyjnie określaj database, user i address (CIDR), nie używaj trust poza labem. Przykład: host appdb app_user 10.0.0.0/24 scram-sha-256 ograniczy połączenia do podsieci aplikacji. To fundament kontroli dostępu PostgreSQL niezależnie od GRANT/REVOKE.

Po zmianach nie musisz restartować serwera – wystarczy przeładować konfigurację. Lokalizację pliku i przeładowanie sprawdzisz SQL-em:

SQL
Kopiuj
1
2
SHOW hba_file;
SELECT pg_reload_conf();

Spójna konfiguracja pg_hba.conf i poprawnie zaprojektowane uprawnienia w PostgreSQL zapewniają pełną ścieżkę kontroli: od bramy sieciowej po poziom wiersza w tabeli. W razie problemów z logowaniem najpierw weryfikuj kolejność reguł i dopasowanie adresu/roli, a dopiero potem same GRANT/REVOKE (grant revoke postgresql).