Audit log az első commit-tól — nem utólagos címke
A legtöbb audit log projekt akkor születik, amikor már késő. Nálunk az első migrációval együtt megy — és 200 sor TypeScript a teljes pattern.
Egy audit log-ot nem lehet "majd betenni" — vagy az első naptól ott van, vagy sosem lesz teljes.
Amikor ügyfélhez érkezünk, gyakran halljuk a mondatot: "kell nekünk audit log, majd a compliance sprintben betesszük". Ez a mondat majdnem mindig egy eltöltött 6 hónap után jön, amikor kiderül, hogy a compliance sprint nem lesz — vagy lesz, és a retrofit 3x annyi idő, mint amennyi az első naptól való bevezetés lett volna.
Mit jelent a "day-one" audit log
- Az első migrációban már ott a "audit_logs" tábla
- Minden írási endpoint egy egységes interceptor-on megy át
- Az interceptor rögzít: tenantId, userId, action, resourceType, resourceId, before, after
- A "before/after" JSON-ok PII-maszkolva vannak, ha a mező érzékeny
- A tábla particionálva van hónaponként — nincs gigantikus indextáblázat
- Retenció: 7 év a GDPR és a számviteli törvény keresztmetszetében
A 200 soros pattern
Az egész audit pattern egy NestJS interceptor (kb. 120 sor), egy TypeORM entity (kb. 40 sor) és egy masking helper (kb. 40 sor). Ennyi. Minden írási útvonal automatikusan loggolva van, anélkül hogy a controller-t bármikor módosítani kellene. Ezt a patternt öt saját termékünkben és három ügyfelünknél is ugyanúgy futtatjuk — és minden auditot sikeresen átvitt.
A legolcsóbb audit log az, amit az első migrációban megírtál. A legdrágább az, amit a harmadik ügyfélkérdés után retrofitálsz.
Partícionálás: miért nem egy végtelen tábla
Az audit log havonta particionált táblában él. Minden hónap egy partíciót kap, és a 7 évnél régebbi partíciókat automatikusan archiváljuk S3-ba Parquet formátumban. Ez három dolgot old meg egyszerre: a napi írás nem lassul 3 év után, a compliance-t teljesíteni tudjuk (7 év retenció), és a BI riportok olvashatják a historikus adatot anélkül, hogy a live DB-t terhelnék.
Amit a mi audit log-unk nem tesz
- Nem logolunk GET kéréseket (túl sok zaj, kevés érték)
- Nem tárolunk jelszó vagy API kulcs plain formában soha
- Nem logolunk egészségügyi adatot retention periódus nélkül
- Nem logolunk teljes request body-t, csak a változott mezőket
- Nem használjuk a logot "debugging-ra" — erre külön observability stack van
A különbség egy "valódi" audit log és egy "mindenre loggolok" rendszer között pontosan ebben van: a valódi audit log minden belekerülő sora egy üzleti esemény, ami valós jogi vagy ügyfélbizalmi értékkel bír. A debug log egy külön célú eszköz, és soha nem szabad őket összekeverni — különben mindkettő használhatatlan lesz.