Audit log to nie to samo co logi aplikacji

“Przecież mamy logi” nie odpowiada na pytanie o audyt operacji biznesowych.

Log techniczny pomaga ustalić, dlaczego request zakończył się błędem, ile trwało zapytanie albo gdzie integracja zwróciła timeout. Audit log odpowiada na inne pytania: kto podjął decyzję, w jakiej organizacji, czego dotyczyła zmiana i jaki proces ją spowodował.

To nie jest różnica w nazwie tabeli. To różnica w gwarancjach.

Trzy rodzaje historii

W dojrzałym systemie warto rozdzielić:

• telemetrię techniczną - wyjątki, opóźnienia, retry i stan infrastruktury;
• aktywność produktu - historię zrozumiałą dla użytkownika, np. komentarze czy postęp procesu;
• autorytatywny audyt - dowody decyzji, zmian uprawnień i krytycznych operacji.

Jedno zdarzenie może mieć reprezentację w więcej niż jednym miejscu, lecz każdy zapis ma inny cel. Feed aktywności może być zoptymalizowany pod UX. Audyt musi zachować integralność i jednoznaczne pochodzenie.

Jedna operacja, jedna transakcja

W krytycznym procesie stan biznesowy i zdarzenie audytowe powinny zostać zapisane w tej samej transakcji głównej bazy.

Validate business command
          ↓
Change business state
          ↓
Record audit event
          ↓
Commit one transaction

Jeżeli zdarzenia nie da się utrwalić, zmiana nie zostaje zatwierdzona. Kolejka działająca w osobnej bazie może później wyeksportować zdarzenie do SIEM lub magazynu WORM, ale nie powinna być jedynym miejscem tworzenia autorytatywnego dowodu.

Kontrakt zdarzenia

Dobre zdarzenie posiada:

• stabilny typ i wersję schematu,
• publiczny, unikalny identyfikator,
• organizację albo jawny zakres platformowy,
• rodzaj aktora i jego identyfikator,
• źródło wywołania,
• podmiot i opcjonalny kontekst biznesowy,
• correlation ID i opcjonalną przyczynę,
• ograniczone metadane,
• czas zdarzenia i czas zapisu.

Dowolny JSON nie jest kontraktem. Dla każdego typu zdarzenia warto zdefiniować dozwolone klucze, wymagane wartości, limit rozmiaru oraz wersję. Dzięki temu konsument wie, co otrzyma, a przypadkowy parametr requestu nie trafia do trwałej historii.

Do audytu nie powinny trafiać hasła, tokeny, identyfikatory sesji, pełne dokumenty, prompty ani dane osobowe bez określonego celu. Integralność zaczyna się od minimalizacji.

Ochrona poniżej Rails

readonly? w modelu chroni przed pomyłką w kodzie, ale nie zatrzyma bezpośredniego SQL. Jeśli runtime jest właścicielem tabeli lub superuserem, może zmienić dane albo wyłączyć zabezpieczenia.

Lepsza granica rozdziela właściciela obiektów, migratora i runtime. Proces aplikacji dostaje tylko uprawnienia potrzebne do odczytu oraz dopisywania. Aktualizacja, usuwanie i TRUNCATE są blokowane zarówno ACL, jak i triggerem kontrolowanym przez właściciela.

To nadal nie chroni przed administratorem całej bazy lub hosta. Wymóg wykrywania takiej ingerencji potrzebuje niezależnej granicy zaufania: podpisanych checkpointów albo eksportu do osobno administrowanego magazynu append-only.

Audit log nie daje compliance automatycznie

Technologia może zapewnić integralność, identyfikowalność i kontrolę dostępu. Compliance wymaga również celu przetwarzania, retencji, legal hold, procedur awaryjnych, autoryzacji odczytu oraz regularnych testów odtwarzania.

Najważniejsze rozróżnienie pozostaje proste: logi techniczne opisują działanie systemu. Audit log dokumentuje odpowiedzialność za zdarzenia biznesowe.

Więcej o takich granicach opisujemy w standardach technologicznych i podejściu do infrastruktury produkcyjnej. Jeśli potrzebujesz uporządkować audyt istniejącego systemu, zacznij rozmowę.