Kaip suprojektuoti audito žurnalą metų atsekamumui?

Question

IT Interview Practice · Accepted Answer

Padarykite jį **append-only ir nekintamą**, susiekite kiekvieną įrašą su ankstesniu **hash**, kad klastojimas būtų aptinkamas, **skaidykite pagal laiką**, kad seni duomenys pigiai išnyktų, ir archyvuokite užantspauduotas partition į **WORM objektų saugyklą** (write-once) su saugojimo politika — niekada neleiskite `UPDATE`/`DELETE` gyviems įrašams.

```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 ir klastojimo aptikimas

Visa audito žurnalo vertė yra ta, kad galite juo **pasitikėti vėliau**, tad schema privalo drausti keitimą. Suteikite aplikacijai tik `INSERT` — jokio `UPDATE`/`DELETE` — ir vykdykite tai DB rolės lygiu, ne tik kode. Ant to sukurkite **hash grandinę**: kiekviena eilutė saugo `hash = SHA256(prev_hash || this_row)`. Pakeiskite bet kurią istorinę eilutę ir kiekvienas paskesnis hash sugenda, tad klastojimas *aptinkamas* net turinčiam DB prieigą. Periodiškai **įtvirtinkite (anchor)** naujausią hash kažkur, ko nekontroliuojate (notaras, viešas ledger, pasirašytas el. laiškas), kad net administratorius, perrašantis visą grandinę, negalėtų atitikti įtvirtintos reikšmės.

## Laiko skaidymas ir saugojimas

Daugelio metų žurnalai auga be ribų, tad **skaidykite pagal laiką** (pvz. mėnesinės range partition). Privalumai: užklausos filtruoja pagal partition, o senų duomenų pašalinimas yra metaduomenų `DETACH`/`DROP PARTITION` — akimirksniu, ne milžiniškas `DELETE`, kuris išpučia lentelę. Užantspauduotos partition perkeliamos į **WORM saugyklą** — S3 Object Lock *compliance mode* fiziškai neleidžia ištrynimo iki saugojimo datos, tenkindamas reguliavimus kaip SOX/HIPAA. Laikykite naujausius mėnesius karštus Postgres greitoms užklausoms; viskas senesnio šalta objektų saugykloje, užklausiama pagal poreikį.

## Interviu perspektyva

Tiriama, ar suprantate, kad „audito žurnalas" reiškia **nekintamumą ir įrodomumą**, o ne tik „lentelę su laiko žyma". Gerai: append-only lentelė. Puikiai: append-only *vykdomas DB rolės*, hash grandinė su išoriniu įtvirtinimu, laiko skaidymas saugojimui, WORM atitikčiai. Dažni spąstai: audito eilučių laikymas toje pačioje kintamoje aplikacijos lentelėje (klaida ar piktavališkas DBA gali tyliai perrašyti istoriją) — auditoriai tai atmes.

## Kompromisai ir gedimai

- **Hash grandinė serializuoja įrašymus** — kiekvienam įrašui reikia ankstesnio hash, tad naivus dizainas tampa kliūtimi. Grupuokite įrašus arba grandinę darykite per-shard ir periodiškai kryžmiškai susiekite.
- **Saugykla auga amžinai**; be skaidymo + tiering į pigią objektų saugyklą kaina ir užklausų latency sprogsta.
- **WORM compliance mode neatšaukiamas** — neteisingas saugojimo nustatymas užrakina duomenis (ar leidžia jiems pasibaigti) be undo; testuokite governance mode pirma.
- **Clock skew / ne iš eilės įvykiai** gadina laiko pagrindu paremtą samprotavimą — įrašykite ir įvykio laiką, ir priėmimo laiką, ir niekada nepasitikėkite kliento laikrodžiais eiliškumui.

Append-only ir klastojimo aptikimas

Laiko skaidymas ir saugojimas

Interviu perspektyva

Kompromisai ir gedimai

Susiję klausimai