Thiết kế audit log truy vết được qua nhiều năm ra sao?

Question

IT Interview Practice · Accepted Answer

Làm nó **append-only và immutable**, nối mỗi entry với entry trước bằng một **hash** để phát hiện được can thiệp, **partition theo thời gian** để dữ liệu cũ hết hạn rẻ tiền, và archive các partition đã niêm phong sang **WORM object storage** (ghi-một-lần) kèm chính sách retention — không bao giờ cho phép `UPDATE`/`DELETE` trên bản ghi live.

```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 & bằng chứng chống can thiệp

Toàn bộ giá trị của audit log là **về sau vẫn tin được nó**, nên schema phải cấm sửa đổi. Chỉ cấp cho app quyền `INSERT` — không `UPDATE`/`DELETE` — và ép ở mức DB role, không chỉ trong code. Trên nền đó, dựng một **hash chain**: mỗi dòng lưu `hash = SHA256(prev_hash || this_row)`. Đổi bất kỳ dòng lịch sử nào thì mọi hash phía sau đều gãy, nên can thiệp *phát hiện được* kể cả bởi người có quyền truy cập DB. Định kỳ **anchor** hash mới nhất vào nơi bạn không kiểm soát (một notary, một public ledger, một email đã ký) để cả admin viết lại toàn bộ chain cũng không khớp được giá trị đã anchor.

## Partition theo thời gian & retention

Log nhiều năm phình vô hạn, nên **partition theo thời gian** (vd. range partition theo tháng). Lợi ích: query lọc theo partition, và loại bỏ dữ liệu cũ chỉ là metadata `DETACH`/`DROP PARTITION` — tức thời, không phải một `DELETE` khổng lồ làm phình bảng. Các partition đã niêm phong chuyển sang **WORM storage** — S3 Object Lock ở *compliance mode* chặn xoá về mặt vật lý cho tới ngày hết hạn retention, thoả các quy định như SOX/HIPAA. Giữ vài tháng gần đây nóng trong Postgres để query nhanh; mọi thứ cũ hơn nằm lạnh trong object storage, query khi cần.

## Góc nhìn phỏng vấn

Điều được dò là bạn có hiểu "audit log" nghĩa là **immutable và chứng minh được** không, chứ không chỉ "một bảng có timestamp". Khá: bảng append-only. Xuất sắc: append-only *ép bằng DB role*, hash chain có anchor bên ngoài, partition theo thời gian cho retention, WORM cho compliance. Bẫy hay gặp: lưu dòng audit trong chính bảng app có thể sửa (một bug hoặc một DBA xấu có thể lặng lẽ viết lại lịch sử) — auditor sẽ bác.

## Đánh đổi & kịch bản hỏng

- **Hash chain nối tiếp việc ghi** — mỗi entry cần hash trước đó, nên thiết kế ngây thơ sẽ nghẽn cổ chai. Gom batch entry hoặc chain theo từng shard rồi định kỳ cross-link.
- **Storage phình mãi mãi**; không partition + phân tầng sang object storage rẻ thì chi phí và độ trễ query bùng nổ.
- **WORM compliance mode không đảo được** — cấu hình retention sai sẽ khoá cứng dữ liệu (hoặc để nó hết hạn) mà không undo được; thử ở governance mode trước.
- **Lệch clock / event ra ngoài thứ tự** làm hỏng lập luận theo thời gian — ghi cả event time lẫn ingest time, và đừng bao giờ tin clock của client để sắp thứ tự.

Append-only & bằng chứng chống can thiệp

Partition theo thời gian & retention

Góc nhìn phỏng vấn

Đánh đổi & kịch bản hỏng

Câu hỏi liên quan