คุณจะออกแบบ audit log สำหรับความสามารถในการตรวจสอบย้อนหลังหลายปีอย่างไร?

Question

IT Interview Practice · Accepted Answer

ทำให้มัน **append-only และ immutable**, เชื่อมแต่ละ entry เข้ากับอันก่อนหน้าด้วย **hash** เพื่อให้ตรวจจับการปลอมแปลงได้, **partition ตาม time** เพื่อให้ข้อมูลเก่าหมดอายุอย่างประหยัด และ archive partition ที่ปิดผนึกแล้วไปยัง **WORM object storage** (write-once) พร้อม retention policy — ห้ามอนุญาต `UPDATE`/`DELETE` บน record ที่ยัง 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 & tamper-evidence

คุณค่าทั้งหมดของ audit log คือคุณสามารถ **เชื่อมันได้ในภายหลัง** ดังนั้น schema ต้องห้ามการ mutate ให้สิทธิ์ app แค่ `INSERT` — ไม่มี `UPDATE`/`DELETE` — และบังคับใช้ที่ระดับ DB role ไม่ใช่แค่ในโค้ด นอกเหนือจากนั้น สร้าง **hash chain**: แต่ละ row เก็บ `hash = SHA256(prev_hash || this_row)` เปลี่ยน row ประวัติใด ๆ แล้ว hash ทุกอันถัดไปจะพัง ดังนั้นการปลอมแปลงจึง *ตรวจจับได้* แม้โดยคนที่มีสิทธิ์เข้าถึง DB **anchor** hash ล่าสุดไปยังที่ที่คุณไม่ควบคุมเป็นระยะ (notary, public ledger, signed email) เพื่อให้แม้ admin ที่เขียน chain ทั้งหมดใหม่ก็ไม่สามารถ match ค่าที่ anchor ไว้

## Time partitioning & retention

log หลายปีโตไม่มีขอบเขต ดังนั้น **partition ตาม time** (เช่น range partition รายเดือน) ประโยชน์: query filter ตาม partition และการปลดข้อมูลเก่าคือ metadata `DETACH`/`DROP PARTITION` — ทันที ไม่ใช่ `DELETE` ยักษ์ที่ทำให้ตารางบวม partition ที่ปิดผนึกย้ายไปยัง **WORM storage** — S3 Object Lock ใน *compliance mode* ป้องกันการลบทางกายภาพจนถึงวันที่ retention ตอบสนองข้อกำหนดอย่าง SOX/HIPAA เก็บเดือนล่าสุดไว้ hot ใน Postgres สำหรับ query ที่เร็ว ทุกอย่างที่เก่ากว่าอยู่ cold ใน object storage query ตามต้องการ

## มุมมองการสัมภาษณ์

สิ่งที่จี้คือคุณเข้าใจหรือไม่ว่า "audit log" หมายถึง **immutability และ provability** ไม่ใช่แค่ "ตารางที่มี timestamp" ดี: ตาราง append-only เยี่ยม: append-only *ที่บังคับใช้โดย DB role*, hash chain พร้อม external anchoring, time partitioning สำหรับ retention, WORM สำหรับ compliance กับดักที่พบบ่อย: เก็บ audit row ในตาราง app ที่ mutable เดียวกัน (bug หรือ DBA ที่ประสงค์ร้ายสามารถเขียนประวัติใหม่เงียบ ๆ) — auditor จะปฏิเสธมัน

## ข้อแลกเปลี่ยน & failure

- **Hash chain serialize การเขียน** — แต่ละ entry ต้องการ hash ก่อนหน้า ดังนั้นดีไซน์ naive จะเป็น bottleneck batch entry หรือ chain ต่อ shard แล้ว cross-link เป็นระยะ
- **Storage โตตลอดกาล** ถ้าไม่มี partitioning + tiering ไปยัง object storage ราคาถูก ต้นทุนและ query latency จะระเบิด
- **WORM compliance mode ย้อนกลับไม่ได้** — การตั้ง retention ผิดล็อกข้อมูล (หรือปล่อยให้หมดอายุ) โดยไม่มี undo ทดสอบใน governance mode ก่อน
- **Clock skew / event ผิดลำดับ** ทำลายการให้เหตุผลตาม time — บันทึกทั้ง event time และ ingest time และอย่าเชื่อ clock ของ client สำหรับการเรียงลำดับ

Append-only & tamper-evidence

Time partitioning & retention

มุมมองการสัมภาษณ์

ข้อแลกเปลี่ยน & failure

คำถามที่เกี่ยวข้อง