Jak śledzić użytkowników i zmiany na obiektach (pg_audit)

PostgreSQL

Jak śledzić użytkowników i zmiany na obiektach (pg_audit)

W skrócie

Kiedy pojawia się pytanie kto zmienił te dane albo kto przeglądał tabelę z danymi osobowymi, zwykły log wolnych zapytań nie pomoże. Do śledzenia działań na bazie służy pgAudit - rozszerzenie stworzone właśnie pod audyt. Potrafi zapisywać wybrane klasy operacji, od SELECT po zmiany schematu i nadawanie uprawnień, w sposób czytelny i możliwy do analizy. Pokazujemy, jak je włączyć i skonfigurować, żeby log audytowy był użyteczny, a nie zalał nas szumem.

Jak to wygląda w praktyce

Zapotrzebowanie na audyt przychodzi zwykle z zewnątrz: dział bezpieczeństwa, wymogi zgodności albo dochodzenie po incydencie. Administrator próbuje wtedy odtworzyć historię z log_statement, ale szybko okazuje się, że albo logów nie ma wcale, albo jest ich za dużo i nie widać w nich, która tabela została zmieniona i przez kogo. Wpisy są surowe, bez wyraźnego rozróżnienia na odczyt i zapis, bez nazwy obiektu w ustrukturyzowanej formie. Objawem braku audytu jest właśnie ta bezradność: wiemy, że coś się stało, ale nie potrafimy wskazać konkretnego użytkownika, momentu i obiektu. pgAudit został zaprojektowany, aby tej luki nie było.

Dlaczego tak się dzieje

Wbudowane logowanie w PostgreSQL powstało z myślą o diagnostyce wydajności i błędów, a nie o audycie. Parametry takie jak log_statement potrafią zapisać wszystkie polecenia, ale robią to bez klasyfikacji i bez wygodnej informacji o dotkniętym obiekcie, przez co analiza jest żmudna. pgAudit działa inaczej: podpina się do wykonania poleceń i loguje je według klas, które sami wybieramy. Klasa READ obejmuje SELECT i COPY z odczytem, WRITE obejmuje INSERT, UPDATE, DELETE, DDL obejmuje zmiany struktury, a ROLE zmiany uprawnień i ról. Dzięki temu możemy włączyć audyt tylko tam, gdzie jest potrzebny, i uniknąć zalania logu. Wpisy mają spójny format, w którym łatwo odczytać typ operacji, obiekt i pełen tekst polecenia.

Jak to rozwiązać krok po kroku

1. Zainstaluj pakiet pgAudit odpowiedni dla twojej wersji PostgreSQL, a następnie dopisz bibliotekę do preload: ALTER SYSTEM SET shared_preload_libraries = 'pgaudit'; i zrestartuj serwer.
2. Załóż rozszerzenie w bazie: CREATE EXTENSION IF NOT EXISTS pgaudit;.
3. Ustaw, które klasy operacji logować. Do audytu zmian i struktury często wystarczy: ALTER SYSTEM SET pgaudit.log = 'write, ddl, role';. Dodaj read, jeśli musisz śledzić także odczyty danych wrażliwych.
4. Przeładuj konfigurację: SELECT pg_reload_conf();. Parametry samego pgaudit.log nie wymagają restartu, tylko przeładowania.
5. Jeśli chcesz audytować dokładniej, włącz audyt na poziomie roli albo obiektu. Nadanie specjalnej roli audytującej praw do tabeli sprawia, że pgAudit zapisuje każdy dostęp do niej, bez logowania całej bazy.
6. Zadbaj o rozdzielenie logu audytu od zwykłego logu aplikacyjnego oraz o jego ochronę i rotację, aby wpisy audytowe nie zginęły i nie mógł ich skasować audytowany użytkownik.

Jak sprawdzić, że zadziałało

Wykonaj kontrolną operację z audytowanej klasy, na przykład UPDATE na testowej tabeli, a następnie zajrzyj do pliku logu serwera. Powinien pojawić się wpis oznaczony jako AUDIT z typem operacji WRITE, nazwą obiektu i pełnym tekstem polecenia oraz nazwą użytkownika, który je wykonał. Sprawdź też, że klasy, których nie włączyłeś, faktycznie nie są logowane - jeśli nie dodałeś read, zwykły SELECT nie powinien zostawiać wpisu audytowego. Zgodność zawartości logu z tym, co ustawiłeś w pgaudit.log, potwierdza, że audyt działa i jest gotowy do analizy.

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5