Hur designar du en audit-logg för års spårbarhet?

Question

IT Interview Practice · Accepted Answer

Gör den **append-only och oföränderlig**, kedja varje post till den föregående med en **hash** så att manipulation är upptäckbar, **partitionera på tid** så att gammal data åldras ut billigt, och arkivera förseglade partitioner till **WORM-objektlagring** (write-once) med en retention-policy — tillåt aldrig `UPDATE`/`DELETE` på live-poster.

```text
service ──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
```

## Append-only & manipulationsbevis

En audit-loggs hela värde är att du kan **lita på den senare**, så schemat måste förbjuda mutation. Ge appen enbart `INSERT` — ingen `UPDATE`/`DELETE` — och upprätthåll det på DB-rollnivå, inte bara i kod. Ovanpå det, bygg en **hash-kedja**: varje rad lagrar `hash = SHA256(prev_hash || this_row)`. Ändra en historisk rad och varje efterföljande hash bryts, så manipulation är *upptäckbar* även av någon med DB-åtkomst. **Förankra** periodiskt den senaste hashen någonstans du inte kontrollerar (en notarie, en publik ledger, ett signerat mejl) så att även en admin som skriver om hela kedjan inte kan matcha det förankrade värdet.

## Tidspartitionering & retention

Fleråriga loggar växer obegränsat, så **partitionera på tid** (t.ex. månatliga range-partitioner). Fördelar: frågor filtrerar på partition, och att pensionera gammal data är en metadata-`DETACH`/`DROP PARTITION` — omedelbart, inte en gigantisk `DELETE` som sväller tabellen. Förseglade partitioner flyttas till **WORM-lagring** — S3 Object Lock i *compliance mode* förhindrar fysiskt radering till retention-datumet, vilket uppfyller regler som SOX/HIPAA. Håll färska månader heta i Postgres för snabba frågor; allt äldre är kallt i objektlagring, frågat på begäran.

## Intervjuperspektiv

Undersökningen är om du förstår att "audit-logg" betyder **oföränderlighet och bevisbarhet**, inte bara "en tabell med en tidsstämpel". Bra: append-only-tabell. Utmärkt: append-only *upprätthållet av DB-roll*, hash-kedja med extern förankring, tidspartitionering för retention, WORM för efterlevnad. Vanlig fälla: att lagra audit-rader i samma muterbara app-tabell (en bugg eller en illvillig DBA kan tyst skriva om historik) — revisorer kommer att avvisa det.

## Avvägningar & felmoder

- **Hash-kedjan serialiserar skrivningar** — varje post behöver den föregående hashen, så en naiv design flaskhalsar. Batcha poster eller kedja per-shard och korslänka periodiskt.
- **Lagring växer för evigt**; utan partitionering + nivåindelning till billig objektlagring exploderar kostnad och frågelatens.
- **WORM compliance mode är irreversibel** — en felaktig retention-inställning låser data (eller låter den expirera) utan ångra; testa i governance mode först.
- **Clock skew / out-of-order-händelser** korrumperar tidsbaserat resonemang — registrera både event time och ingest time, och lita aldrig på klientklockor för ordning.

Append-only & manipulationsbevis

Tidspartitionering & retention

Intervjuperspektiv

Avvägningar & felmoder

Relaterade frågor