वर्षानुवर्षे traceability साठी audit log तुम्ही कसा डिझाईन कराल?

Question

IT Interview Practice · Accepted Answer

तो **append-only आणि immutable** बनवा, प्रत्येक entry ला मागील एकाशी एका **hash** ने साखळा जेणेकरून tampering detectable होते, **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` grant करा — `UPDATE`/`DELETE` नाही — आणि ते फक्त code मध्ये नव्हे तर DB role पातळीवर लागू करा. त्यावर, एक **hash chain** बांधा: प्रत्येक row `hash = SHA256(prev_hash || this_row)` साठवते. कोणतीही historical row बदला आणि प्रत्येक पुढील hash तुटते, त्यामुळे DB access असलेल्या व्यक्तीलाही tampering *detectable* आहे. नियमितपणे latest hash तुम्ही नियंत्रित न करणाऱ्या ठिकाणी **anchor** करा (एक notary, एक public ledger, एक signed email) जेणेकरून संपूर्ण chain पुन्हा लिहिणारा admin देखील anchored value शी जुळवू शकत नाही.

## Time partitioning & retention

बहु-वर्ष logs अमर्याद वाढतात, म्हणून **time नुसार partition करा** (उदा. monthly range partitions). फायदे: queries partition नुसार filter करतात, आणि जुना data retire करणे एक metadata `DETACH`/`DROP PARTITION` आहे — तत्काळ, table फुगवणारा एक विशाल `DELETE` नव्हे. Sealed partitions **WORM storage** कडे हलतात — S3 Object Lock *compliance mode* मध्ये retention date पर्यंत deletion physically प्रतिबंधित करते, SOX/HIPAA सारख्या नियमांचे समाधान करते. अलीकडील महिने जलद queries साठी Postgres मध्ये hot ठेवा; बाकी सर्व जुने object storage मध्ये cold, मागणीनुसार queried.

## मुलाखतीचा दृष्टिकोन

तपासणी अशी आहे की तुम्हाला समजते का की "audit log" म्हणजे **immutability आणि provability**, फक्त "timestamp असलेली एक table" नाही. चांगले: 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 + स्वस्त 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 दोन्ही record करा, आणि ordering साठी client clocks वर कधीही विश्वास ठेवू नका.

Append-only & tamper-evidence

Time partitioning & retention

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

संबंधित प्रश्न