Database auditing exists largely to hold privileged users accountable — yet those same users administer the database that produces the audit records. How do you design an audit trail they cannot quietly edit or switch off?

## Start from the threat model Most audit designs quietly assume an external attacker. The interesting adversary for database auditing is the **privileged insider or an attacker who has become one**: a DBA, a superuser account, a compromised service credential with administrative rights. That actor can typically read and write any table, change audit configuration, stop the auditing component, and delete files on the host. If the audit trail is produced by, stored on, and administered by the system that actor controls, it is not evidence — it is a diary the suspect keeps. Everything that follows is about breaking that circle. ## Get the records out of reach quickly The single most effective control is **distance in the delivery path**. Configure the audit facility to emit to the host's log daemon or a local collector agent that immediately forwards to a remote destination — a log pipeline, SIEM, or object store — rather than accumulating records in a database table or a file the DBA owns. The window of tamperability shrinks to whatever has not yet been shipped, typically seconds. Storing audit records inside the audited database is the anti-pattern: a superuser can DELETE from an audit table, and depending on how you built it, that deletion may itself be unaudited. If operational convenience demands a queryable copy in the database, treat it as a *copy* and make the forwarded stream authoritative. ## Separation of duties over the destination The destination must be administered by people who do not administer the database. The security or compliance function owns the retention policy, the deletion rights and the access control on the audit store; the DBA has, at most, read access to their own activity. Storage should be **append-only**: object storage with object-lock/WORM retention, or a log system where writes are immutable and deletion requires a separate privileged path with its own audit. This is an organisational control as much as a technical one, and interviewers reward candidates who say so. A technically perfect pipeline whose keys and buckets are administered by the same person under scrutiny buys nothing. ## Make deletion and silence detectable Append-only storage stops edits; you still need to detect **removal** and **suppression**. - **Sequence numbers per source** make a removed record show as a gap. - **Hash chaining** — each record includes a hash of the previous record — makes any edit or deletion break the chain from that point on. Periodically anchor the chain by signing or publishing the current head somewhere the DBA does not control; without an external anchor, an attacker who removes records can recompute the whole chain. - **Heartbeats.** An audit stream that goes quiet must be indistinguishable from a database that has stopped receiving traffic — unless the source emits periodic heartbeat records. With heartbeats, silence becomes an alert instead of an assumption. - **Alert on the meta-events**: audit policy changed, audit extension or agent stopped, log destination reconfigured, host clock stepped, retention shortened. These are the actions taken immediately before the activity somebody wants hidden. ## Clocks and ordering Evidence is only usable if it can be ordered and correlated across systems. Keep hosts on synchronised time, record timestamps with an explicit time zone or in UTC, and prefer a monotonic sequence or transaction id alongside the wall-clock time so that a clock adjustment does not scramble the story. Record clock-step events too — moving the clock is a tampering technique. ## Availability: fail-open or fail-closed When the audit destination is unreachable or its disk is full, the database faces a choice: continue serving requests without an audit trail (fail-open) or refuse the in-scope work (fail-closed). Some regulated environments require fail-closed, because unaudited access to that data is worse than downtime. Fail-closed converts your log pipeline into a hard availability dependency of the database — a slow SIEM becomes a production outage. The right answer is not universal; the right *behaviour* in an interview is to name the trade-off, say it is a business decision recorded with the control owner, and describe the middle ground: a bounded local spool on separate storage that absorbs short outages, with alerting on spool depth and an explicit rule for what happens when it fills. ## The audit trail is itself sensitive data Statement text and bind parameters routinely contain exactly the personal or financial data the audit exists to protect, so the audit store inherits that sensitivity: restricted access, protection in transit and at rest, and a retention policy that satisfies the regulation without hoarding personal data forever. A common concrete control is to record parameterised statement text without literal values for high-sensitivity objects, accepting reduced forensic detail in exchange for not creating a second copy of the crown jewels; whether that trade is acceptable belongs to the data-protection owner, not to the DBA. ## Verification Controls that are never tested are assumptions. Periodically exercise the trail end to end: perform a known privileged action, confirm the record arrives at the destination within the expected window, confirm the chain verifies, and confirm that stopping the audit agent raises an alert. Sample restores from cold archive as well — retention that cannot be read back is not retention. ## How to pitch it Name the insider threat model first, then the four controls (off-box fast, separated duties over append-only storage, audit the audit config, detect gaps and silence), then the fail-open/fail-closed decision and the fact that the audit store is a new crown jewel.