Tamper-Evident Audit Logging

Overview

An audit log is a security record, distinct from application logs. Its value rests on completeness, integrity and access control. Every entry must answer who, what, which resource, when, from where and with what result, including denied attempts.

Define a small common event schema early, with stable action names and resource identifiers, so events from different services can be queried together. Give security and compliance teams a read-only query interface, and test your retention and legal-hold procedures before an auditor asks for them.

How it works

service -> outbox table (same transaction as the change)
relay   -> durable queue -> audit writer
writer  -> append to WORM store (object lock, 7y)
         entry = { id, ts, actor, action, resource, outcome, ip,
                   prevHash, hash = SHA256(prevHash + body) }
verifier job: recompute chain daily, alert on mismatch or gap

Writing the event to an outbox in the same transaction as the business change avoids both lost and phantom events.

Pitfalls

• Fire-and-forget logging that silently drops events under load.
• Logging secrets, tokens or full personal records. Log identifiers and field names instead.
• Letting application admins hold delete rights on the audit store.
• Using local server clocks without synchronization.
• No review process; unread logs deter nothing.
• Forgetting read access: auditing who viewed sensitive records matters as much as writes.

Key takeaways

• Treat audit events as a first-class, schema-controlled product.
• Write atomically via an outbox and store immutably.
• Make tampering and gaps detectable, and alert on them.
• Minimize sensitive content and restrict who can read or delete.