Fă-l append-only și imutabil, înlănțuie fiecare intrare de cea anterioară cu un hash, astfel încât manipularea să fie detectabilă, partiționează după timp, astfel încât datele vechi să iasă ieftin din uz, și arhivează partițiile sigilate în stocare de obiecte WORM (write-once) cu o politică de retenție — nu permite niciodată / pe înregistrările live.
UPDATEDELETEservice ──emit event──▶ append-only writer
│ hash = H(prev_hash || payload)
▼
audit_2026_07 (hot partition) ◀── query by actor/time
│ month sealed
▼
WORM object store (S3 Object Lock) ── retention: 7y
│
periodic anchor: publish latest hash externally
Întreaga valoare a unui audit log este că poți avea încredere în el mai târziu, deci schema trebuie să interzică mutația. Acordă aplicației doar INSERT — fără UPDATE/DELETE — și aplică asta la nivel de rol de DB, nu doar în cod. Pe deasupra, construiește un hash chain: fiecare rând stochează hash = SHA256(prev_hash || this_row). Schimbă orice rând istoric și fiecare hash ulterior se rupe, deci manipularea este detectabilă chiar și de cineva cu acces la DB. Ancorează periodic ultimul hash undeva ce nu controlezi (un notar, un ledger public, un email semnat), astfel încât chiar și un admin care rescrie tot lanțul să nu poată potrivi valoarea ancorată.
Log-urile pe mai mulți ani cresc nelimitat, deci partiționează după timp (de ex. partiții de range lunare). Beneficii: interogările filtrează după partiție, iar retragerea datelor vechi este un DETACH/DROP PARTITION de metadate — instantaneu, nu un DELETE gigantic care umflă tabela. Partițiile sigilate se mută în stocare WORM — S3 Object Lock în compliance mode împiedică fizic ștergerea până la data de retenție, satisfăcând reglementări precum SOX/HIPAA. Ține lunile recente hot în Postgres pentru interogări rapide; tot ce e mai vechi este cold în stocare de obiecte, interogat la cerere.
Sondajul este dacă înțelegi că "audit log" înseamnă imutabilitate și demonstrabilitate, nu doar "o tabelă cu un timestamp". Bine: tabelă append-only. Excelent: append-only aplicat prin rolul de DB, hash chain cu ancorare externă, partiționare după timp pentru retenție, WORM pentru conformitate. Capcană obișnuită: stocarea rândurilor de audit în aceeași tabelă mutabilă a aplicației (un bug sau un DBA rău-intenționat poate rescrie silențios istoricul) — auditorii o vor respinge.
O bibliotecă de întrebări de interviu IT cu răspunsuri detaliate — de la Junior la Senior.
Donează