Przejdź do treści

Tłumaczenie maszynowe. Wersja angielska jest wiążąca; weryfikacja przez native speakera jeszcze nie nastąpiła.

Poradniki

Podlacz PostgreSQL (pgaudit)

Szczegolowy przewodnik konektora do obserwacji dostepu do bazy danych PostgreSQL przez pgAudit — konfiguracja formatu logow, strumieniowe pochlaniane.

Ostatnia aktualizacja:

Konektor pgAudit sledzi strukturalny log audytu PostgreSQL i emituje jedna krawedz mapy dostepu na audytowany dostep do danych. Tryb odczyt/zapis jest pobierany doslownie z klasy pgAudit (READ, WRITE, DDL) — nigdy nie jest wnioskowany z tekstu SQL. Konektor jest tylko-do-odczytu nad plikiem logu i nigdy nie otwiera polaczenia do bazy danych.

Dla ogolnego modelu zrodel i struktury konfiguracji zacznij od Podlacz zrodlo. Ta strona obejmuje wymagania wstepne po stronie PostgreSQL, pelna powierzchnie konfiguracji, mechanike atrybucji i rozwiazania operacyjne dla produkcyjnych infrastruktur.

Wymagania wstepne PostgreSQL

Konektor czyta wyjscie pgAudit, wiec PostgreSQL musi byc skonfigurowany do jego produkcji. Zainstaluj rozszerzenie (apt install postgresql-<version>-pgaudit na Debian/Ubuntu), zaladuj je przez shared_preload_libraries, zrestartuj, nastepnie CREATE EXTENSION pgaudit w kazdej bazie danych, ktora chcesz obserwowac.

Minimalne ustawienia postgresql.conf dla uzytecznego wyjscia:

shared_preload_libraries = 'pgaudit'
pgaudit.log = 'read, write'       # READ i WRITE obejmuja dostep do danych
log_destination = 'jsonlog'        # zalecane dla streamingu; csvlog tez dziala
logging_collector = on
log_directory = '/var/log/postgresql'
log_filename = 'postgresql.json'

Zrestartuj po shared_preload_libraries; przeladuj (SELECT pg_reload_conf()) po reszcie. Zweryfikuj uruchamiajac zapytanie i potwierdzajac, ze wpis pgAudit pojawia sie w logu — pole message wpisu zawiera strukturalna linie pgAudit (klasa, polecenie, nazwa obiektu). Jesli pojawiaja sie tylko standardowe komunikaty PostgreSQL, rozszerzenie nie jest zaladowane lub nie jest skonfigurowane.

Konfiguracja

Konektor jest wybierany przez kind: "pgaudit" w pliku JSON OLIVARES_SOURCES_CONFIG. Pelny przyklad:

{
  "sources": [
    {
      "name": "prod-postgres",
      "kind": "pgaudit",
      "tenant": "acme",
      "config": {
        "log_path": "/var/log/postgresql/postgresql.json",
        "format": "jsonlog",
        "follow": "true",
        "shared_accounts": "app_pool,reporting"
      }
    }
  ]
}

Wszystkie wartosci config sa lancuchami. Klucze sa wlasnoscia konektora pgAudit:

  • log_path (wymagany) — bezwzgledna sciezka do pliku logu PostgreSQL. Konektor czyta ten plik; nie odkrywa plikow logu wedlug konwencji.
  • format — csvlog lub jsonlog. Domyslnie csvlog. Kontroluje parser, ktorego uzywa konektor; musi odpowiadac log_destination, ktory PostgreSQL faktycznie zapisuje.
  • follow — gdy "true", sledz plik ciagly (tryb strumieniowy). Dotyczy tylko jsonlog. Plik csvlog jest czytany jako wsad, poniewaz rekordy CSV moga obejmowac wiele linii, co sprawia, ze strumieniowe sledzenie jest zawodne. Zobacz Wsad vs streaming ponizej.
  • shared_accounts — oddzielona przecinkami lista rol PostgreSQL lub wartosci application_name, ktore sa pulowane lub wspoldzielone miedzy wieloma wywolujacymi. Dostep przypisany do ktorejkolwiek z nich jest celowo oznaczany approximate. Zobacz Atrybucja i wspoldzielone konta.

Nie wymyslaj kluczy konfiguracji poza tymi czterema. Powierzchnia konfiguracji konektora jest celowo waska — czyta plik logu, nie zarzadza PostgreSQL.

Atrybucja i wspoldzielone konta

Mapa dostepu musi odpowiedziec “ktory agent to zrobil.” Wpisy logu pgAudit niosza role PostgreSQL (uzytkownika) i, gdy jest ustawiony, application_name sesji. Konektor uzywa obu do budowania pochodzenia krawedzi.

Tozsamosc per-agent zapewnia pewna krawedz. Gdy kazdy agent ustawia odrebny application_name na swoim polaczeniu (lub uzywa dedykowanej roli), konektor przypisuje kazdy dostep jednoznacznie i krawedz jest firm.

Wspoldzielone role skladaja sie do approximate. Gdy wielu agentow dzieli pule polaczen, wspolne konto serwisowe lub ogolny application_name, konektor nie moze rozdzielic wywolujacych. Kazdy dostep przez te tozsamosc jest oznaczany approximate, a produkt mowi o tym otwarcie zamiast udawac, ze potrafi odroznic agentow, ktorych nie potrafi. Dlatego shared_accounts istnieje: deklarowanie pulowanych tozsamosci z gory mowi konektorowi, by oznaczal je approximate natychmiast.

Implikacja zarzadcza jest bezposrednia: krawedz approximate nie moze wspierac pewnego odkrycia najnizszych uprawnien. Jesli potrzebujesz zarzadzania per-agent nad dostepem do bazy danych, wydaj poswiadczenia lub wartosci application_name per-agent. Zobacz Wiernosc dla pelnego modelu atrybucji.

Poziom pokrycia

pgAudit to pokrycie na poziomie clean. Klasy READ, WRITE i DDL sa autorytatywne — podsystem audytu PostgreSQL klasyfikuje instrukcje, a konektor bierze te klasyfikacje doslownie. Nie ma wnioskowania, parsowania SQL ani heurystyki.

mode krawedzi to R (odczyt), RW (odczyt-zapis, dla klas WRITE i DDL) lub pozostawiony jak dyktuje klasa. Konektor nigdy nie podnosi ani nie obniza tego, co pgAudit zaraportowalo. Zobacz Wiernosc — pokrycie jak clean porownuje sie do zrodel lossy i opaque.

Wsad vs streaming

  • csvlog — wsad. Rekordy CSV moga obejmowac wiele linii (zapytanie z osadzonymi nowymi liniami produkuje wieloliniowy wiersz), wiec strumieniowe sledzenie nie moze niezawodnie rozdzielac rekordow. Konektor czyta plik jako pelny wsad; ustaw poll_seconds na wpisie zrodla, by ponownie uruchamiac w interwale.
  • jsonlog z follow: "true" — streaming. Kazdy wpis JSON to pojedyncza linia, wiec sledzenie jest bezpieczne. Konektor trzyma plik otwarty i emituje krawedzie w miare jak PostgreSQL je zapisuje.

Dla krawedzi niemal w czasie rzeczywistym, jsonlog z follow jest zalecaną konfiguracją. Dla okresowych audytow lub baz danych o mniejszym wolumenie, wsad csvlog jest wystarczajacy.

Jak wygladaja krawedzie

Kazdy wpis logu pgAudit, ktory konektor parsuje, produkuje jedna krawedz mapy dostepu z tymi polami:

  • Pochodzenie — rola PostgreSQL, kwalifikowana przez application_name gdy jest obecna. Przyklad: reporting_agent lub app_pool/invoice-service.
  • Zasob — w pelni kwalifikowany obiekt: database.schema.table. Przyklad: prod.public.orders.
  • Tryb — R (z klasy pgAudit READ) lub RW (z klasy pgAudit WRITE lub DDL).
  • Atrybucja — firm jesli pochodzenie rozwiazuje sie do pojedynczej tozsamosci agenta, approximate jesli pasuje do wpisu shared_accounts lub nie moze byc rozrozniione.
  • Zrodlo — identyfikuje te instancje konektora po nazwie.

Krawedz nie niesie tekstu SQL, danych wierszy ani parametrow zapytania. Rejestruje tylko strukturalny fakt, ze tozsamosc uzyskala dostep do obiektu w danym trybie.

Uwagi operacyjne

Rotacja logow. Gdy PostgreSQL rotuje swoj plik logu (przez log_rotation_age lub log_rotation_size), konektor musi byc skierowany na biezacy plik. Jesli twoja rotacja zmienia nazwe aktywnego pliku, sledzenie follow bedzie kontynuowac czytanie starego deskryptora pliku az sie wyczerpie, a nastepnie zatrzyma. Skieruj log_path na stabilny symlink lub uzyj konwencji nazewnictwa, ktora konektor moze sledzic. Konektor nie zarzadza rotacja sam.

Infrastruktury o duzym wolumenie. pgAudit moze produkowac znaczny wolumen logow na zajetych bazach danych, szczegolnie z pgaudit.log = 'all'. Ogranicz pgaudit.log do klas, ktorych potrzebujesz (typowo read, write) i rozważ filtrowanie per-baza-danych lub per-rola przez pgaudit.log_relation, by zredukowac szum bez utraty pokrycia.

Wiele instancji PostgreSQL. Kazda instancja potrzebuje wlasnego wpisu zrodla w OLIVARES_SOURCES_CONFIG z odrębna name i wlasnym log_path. Nie ma odkrywania wielu instancji — kazde zrodlo obserwuje dokladnie jeden plik logu.

Uprawnienia. Proces kolektora potrzebuje dostepu do odczytu pliku logu PostgreSQL. Nie potrzebuje polaczenia z baza danych, roli PostgreSQL ani jakiegokolwiek dostepu sieciowego do serwera bazy danych. Uprawnienie do odczytu systemu plikow to jedyne wymaganie.

Powiazane

Wyszukiwanie w dokumentacji