Exercise 3: Why Audit Logs Need a Separate, Append-Only Home — Possible Solution
====================================================================

Storing audit logs inside the SAME database they're auditing means the
audit trail's trustworthiness depends entirely on that same database
never being compromised — but the audit log's whole purpose is to be
useful WHEN a compromise happens. If an attacker gains sufficient
access to the database being audited (a compromised account, a
successful exploit), they typically have exactly the same level of
access needed to also read, modify, or outright DELETE the audit log
sitting right there inside it.

THE SPECIFIC ATTACK THIS PROTECTS AGAINST: an attacker covering their
own tracks. This chapter's warning box names it directly — one of the
first things a genuinely successful attacker does after gaining
database access is erase or alter the evidence of how they got in and
what they did, exactly the "tampered logs" failure mode owasp1-9
already named as a logging failure at the application layer. If the
audit log lives inside the compromised database itself, deleting the
incriminating rows from that log is just another query the attacker's
already-obtained access lets them run.

Shipping audit records to a SEPARATE, append-only (or write-once)
system — one the compromised database account has no ability to
reach or modify at all — means that even a fully successful database
compromise still leaves a genuine, untampered record of what happened,
because deleting or altering that record would require a completely
different, independent compromise of the separate logging system
itself.