ஆண்டுக்கணக்கான traceability-க்கு ஒரு audit log-ஐ எப்படி வடிவமைப்பீர்கள்?

Question

IT Interview Practice · Accepted Answer

அதை **append-only மற்றும் immutable** ஆக்குங்கள், ஒவ்வொரு entry-ஐயும் ஒரு **hash** மூலம் முந்தையதற்குச் chain செய்யுங்கள், இதனால் tampering கண்டறியக்கூடியதாகிறது, **time-ஆல் partition** செய்யுங்கள், இதனால் பழைய data மலிவாக age out ஆகிறது, மேலும் sealed partitions-ஐ ஒரு retention policy உடன் **WORM object storage** (write-once)-க்கு archive செய்யுங்கள் — live records மீது `UPDATE`/`DELETE`-ஐ ஒருபோதும் அனுமதிக்காதீர்கள்.

```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 mutation-ஐத் தடுக்க வேண்டும். app-க்கு `INSERT` மட்டும் வழங்குங்கள் — `UPDATE`/`DELETE` இல்லை — மேலும் அதை code-இல் மட்டுமல்ல, DB role level-இல் அமல்படுத்துங்கள். அதன் மேல், ஒரு **hash chain** கட்டுங்கள்: ஒவ்வொரு row-ம் `hash = SHA256(prev_hash || this_row)` சேமிக்கிறது. எந்த historical row-ஐயும் மாற்றினால் அடுத்தடுத்த ஒவ்வொரு hash-ம் உடைகிறது, எனவே tampering DB access உள்ள ஒருவருக்கும் கூட *கண்டறியக்கூடியது*. அவ்வப்போது latest hash-ஐ நீங்கள் கட்டுப்படுத்தாத எங்காவது **anchor** செய்யுங்கள் (ஒரு notary, ஒரு public ledger, ஒரு signed email), இதனால் முழு chain-ஐயும் மீண்டும் எழுதும் ஒரு admin கூட anchored மதிப்பைப் பொருத்த முடியாது.

## Time partitioning & retention

பல ஆண்டு logs வரம்பின்றி வளர்கின்றன, எனவே **time-ஆல் partition** செய்யுங்கள் (எ.கா. monthly range partitions). நன்மைகள்: queries partition-ஆல் filter செய்கின்றன, மேலும் பழைய data-ஐ retire செய்வது ஒரு metadata `DETACH`/`DROP PARTITION` — உடனடி, table-ஐ bloat செய்யும் ஒரு பெரிய `DELETE` அல்ல. Sealed partitions **WORM storage**-க்கு நகர்கின்றன — S3 Object Lock *compliance mode*-இல் retention date வரை deletion-ஐ physically தடுக்கிறது, SOX/HIPAA போன்ற விதிமுறைகளைப் பூர்த்தி செய்கிறது. சமீபத்திய மாதங்களை விரைவான queries-க்கு Postgres-இல் hot-ஆக வைத்திருங்கள்; அதற்கும் பழையது object storage-இல் cold-ஆக, on demand query செய்யப்படுகிறது.

## நேர்காணல் கண்ணோட்டம்

"audit log" என்றால் வெறும் "ஒரு timestamp கொண்ட table" அல்ல, **immutability மற்றும் provability** என்பதை நீங்கள் புரிந்துகொள்கிறீர்களா என்பது ஆய்வு. நல்லது: append-only table. சிறந்தது: **DB role-ஆல் அமல்படுத்தப்பட்ட** append-only, external anchoring கொண்ட hash chain, retention-க்கு time partitioning, compliance-க்கு WORM. பொதுவான பொறி: audit rows-ஐ அதே mutable app table-இல் சேமிப்பது (ஒரு bug அல்லது ஒரு தீங்கிழைக்கும் DBA அமைதியாக history-ஐ மீண்டும் எழுதலாம்) — auditors அதை நிராகரிப்பார்கள்.

## சமரசங்களும் தோல்வி முறைகளும்

- **Hash chain writes-ஐ serialise செய்கிறது** — ஒவ்வொரு entry-க்கும் முந்தைய hash தேவை, எனவே ஒரு naive design bottleneck ஆகிறது. entries-ஐ batch செய்யுங்கள் அல்லது per-shard chain செய்து அவ்வப்போது cross-link செய்யுங்கள்.
- **Storage என்றென்றும் வளர்கிறது**; partitioning + cheap object storage-க்கு tiering இல்லாமல், cost மற்றும் query latency வெடிக்கின்றன.
- **WORM compliance mode irreversible** — ஒரு தவறான retention setting data-ஐ lock செய்கிறது (அல்லது அதை expire ஆக விடுகிறது) undo இல்லாமல்; முதலில் governance mode-இல் test செய்யுங்கள்.
- **Clock skew / out-of-order events** time-based reasoning-ஐ corrupt செய்கின்றன — event time மற்றும் ingest time இரண்டையும் பதிவு செய்யுங்கள், மேலும் ordering-க்கு client clocks-ஐ ஒருபோதும் நம்பாதீர்கள்.

Append-only & tamper-evidence

Time partitioning & retention

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் தோல்வி முறைகளும்

தொடர்புடைய கேள்விகள்