Hvordan designer du en audit-logg for års sporbarhet?

Question

IT Interview Practice · Accepted Answer

Gjør den **append-only og immutabel**, kjed hver oppføring til den forrige med en **hash** slik at tukling er detekterbar, **partisjoner på tid** slik at gammel data eldes ut billig, og arkiver forseglede partisjoner til **WORM object storage** (write-once) med en retention-policy — aldri tillat `UPDATE`/`DELETE` på live poster.

```text
tjeneste ──emit event──▶ append-only writer
                             │  hash = H(prev_hash || payload)
                             ▼
                     audit_2026_07 (hot partisjon)  ◀── spør på actor/tid
                             │ måned forseglet
                             ▼
                     WORM object store (S3 Object Lock)  ── retention: 7 år
                             │
                     periodisk anchor: publiser siste hash eksternt
```

## Append-only og tamper-evidence

En audit-loggs hele verdi er at du kan **stole på den senere**, så skjemaet må forby mutasjon. Gi appen `INSERT` kun — ingen `UPDATE`/`DELETE` — og håndhev det på DB-rolle-nivå, ikke bare i kode. Oppå det, bygg en **hash-kjede**: hver rad lagrer `hash = SHA256(prev_hash || this_row)`. Endre en historisk rad og hver påfølgende hash brytes, så tukling er *detekterbar* selv av noen med DB-tilgang. **Anchor** periodisk siste hash et sted du ikke kontrollerer (en notarius, en offentlig ledger, en signert e-post) slik at selv en admin som skriver om hele kjeden ikke kan matche den anchorede verdien.

## Tidspartisjonering og retention

Flerårige logger vokser uten grense, så **partisjoner på tid** (f.eks. månedlige range-partisjoner). Fordeler: spørringer filtrerer på partisjon, og å pensjonere gammel data er en metadata `DETACH`/`DROP PARTITION` — umiddelbar, ikke en gigantisk `DELETE` som blåser opp tabellen. Forseglede partisjoner flyttes til **WORM storage** — S3 Object Lock i *compliance mode* forhindrer fysisk sletting til retention-datoen, og tilfredsstiller reguleringer som SOX/HIPAA. Hold nylige måneder hot i Postgres for raske spørringer; alt eldre er cold i object storage, spurt on demand.

## Intervjuperspektiv

Undersøkelsen er om du forstår at "audit-logg" betyr **immutabilitet og beviselighet**, ikke bare "en tabell med et tidsstempel". Bra: append-only-tabell. Utmerket: append-only *håndhevet av DB-rolle*, hash-kjede med ekstern anchoring, tidspartisjonering for retention, WORM for compliance. Vanlig felle: å lagre audit-rader i samme mutable app-tabell (en bug eller en ondsinnet DBA kan stille skrive om historikk) — auditorer vil avvise det.

## Avveininger og feilmoduser

- **Hash-kjede serialiserer writes** — hver oppføring trenger den forrige hashen, så et naivt design flaskehalser. Batch oppføringer eller kjed per-shard og cross-link periodisk.
- **Lagring vokser for alltid**; uten partisjonering + tiering til billig object storage eksploderer kostnad og query-latency.
- **WORM compliance mode er irreversibel** — en feil retention-innstilling låser data (eller lar den utløpe) uten angremulighet; test i governance mode først.
- **Clock skew / out-of-order events** korrumperer tidsbasert resonnering — registrer både event-tid og ingest-tid, og stol aldri på klient-klokker for rekkefølge.

Append-only og tamper-evidence

Tidspartisjonering og retention

Intervjuperspektiv

Avveininger og feilmoduser

Relaterte spørsmål