Πώς σχεδιάζετε ένα audit log για χρόνια ιχνηλασιμότητας;

Question

IT Interview Practice · Accepted Answer

Κάντε το **append-only και immutable**, αλυσοδέστε κάθε entry με το προηγούμενο μέσω ενός **hash** ώστε το tampering να είναι ανιχνεύσιμο, κάντε **partition κατά χρόνο** ώστε τα παλιά δεδομένα να γερνάνε φθηνά, και αρχειοθετήστε τα σφραγισμένα partitions σε **WORM object storage** (write-once) με μια retention policy — μην επιτρέπετε ποτέ `UPDATE`/`DELETE` σε live records.

```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 & ανιχνευσιμότητα παραποίησης

Η ολόκληρη αξία ενός audit log είναι ότι μπορείτε να το **εμπιστευτείτε αργότερα**, οπότε το schema πρέπει να απαγορεύει τη μεταβολή. Δώστε στην app μόνο `INSERT` — όχι `UPDATE`/`DELETE` — και επιβάλετέ το σε επίπεδο DB role, όχι μόνο στον κώδικα. Πάνω σε αυτό, χτίστε μια **hash chain**: κάθε row αποθηκεύει `hash = SHA256(prev_hash || this_row)`. Αλλάξτε οποιαδήποτε historical row και κάθε επόμενο hash σπάει, οπότε το tampering είναι *ανιχνεύσιμο* ακόμα και από κάποιον με DB access. Περιοδικά **anchor** το τελευταίο hash κάπου που δεν ελέγχετε (έναν notary, ένα public ledger, ένα signed email) ώστε ακόμα κι ένας admin που ξαναγράφει ολόκληρη την αλυσίδα να μην μπορεί να ταιριάξει την anchored τιμή.

## Time partitioning & retention

Τα πολυετή logs μεγαλώνουν χωρίς όριο, οπότε κάντε **partition κατά χρόνο** (π.χ. μηνιαία range partitions). Οφέλη: τα queries φιλτράρουν κατά partition, και η απόσυρση παλιών δεδομένων είναι ένα metadata `DETACH`/`DROP PARTITION` — ακαριαία, όχι ένα γιγαντιαίο `DELETE` που φουσκώνει τον πίνακα. Τα σφραγισμένα partitions μετακινούνται σε **WORM storage** — το S3 Object Lock σε *compliance mode* φυσικά αποτρέπει τη διαγραφή μέχρι την ημερομηνία retention, ικανοποιώντας κανονισμούς όπως SOX/HIPAA. Κρατήστε τους πρόσφατους μήνες hot στην Postgres για γρήγορα queries· ό,τι παλαιότερο είναι cold σε object storage, queried on demand.

## Οπτική συνέντευξης

Η διερεύνηση είναι αν καταλαβαίνετε ότι "audit log" σημαίνει **immutability και provability**, όχι απλώς "ένας πίνακας με ένα timestamp". Καλό: append-only πίνακας. Εξαιρετικό: append-only *επιβαλλόμενο από DB role*, hash chain με external anchoring, time partitioning για retention, WORM για compliance. Συνηθισμένη παγίδα: να αποθηκεύετε audit rows στον ίδιο mutable app πίνακα (ένα bug ή ένας κακόβουλος DBA μπορεί σιωπηλά να ξαναγράψει την ιστορία) — οι auditors θα το απορρίψουν.

## Trade-offs & τρόποι αποτυχίας

- **Η hash chain σειριοποιεί τα writes** — κάθε entry χρειάζεται το προηγούμενο hash, οπότε ένας αφελής σχεδιασμός γίνεται bottleneck. Κάντε batch entries ή αλυσοδέστε per-shard και περιοδικά cross-link.
- **Το storage μεγαλώνει για πάντα**· χωρίς partitioning + tiering σε φθηνό object storage, το κόστος και το query latency εκρήγνυνται.
- **Το WORM compliance mode είναι μη αναστρέψιμο** — ένα λάθος retention setting κλειδώνει δεδομένα (ή τα αφήνει να λήξουν) χωρίς undo· δοκιμάστε πρώτα σε governance mode.
- **Clock skew / out-of-order events** διαφθείρουν τη χρονική συλλογιστική — καταγράψτε και event time και ingest time, και μην εμπιστεύεστε ποτέ τα client clocks για ordering.

Append-only & ανιχνευσιμότητα παραποίησης

Time partitioning & retention

Οπτική συνέντευξης

Trade-offs & τρόποι αποτυχίας

Σχετικές ερωτήσεις