Audit trail missing

Audit trail missing
Type: incident simulation · Topic: Security & Access · Level: L3 · Duration: 10–15 min
Launch: ride postgres start stage-10/10-audit-trail-missing

POSTMORTEM (root cause · how it was found · the fix · lesson)
Root cause: access to `sensitive_customer_data` (and privilege changes around it) was
not being audited — `security_audit_config.access_audit_enabled` was `false` and the
`access_audit` table was empty. Access control without an audit trail is incomplete:
you can't answer who changed privileges or who touched sensitive data.

How it was found: the audit config marker showed auditing disabled and the audit
table held no events.

The fix (simplified local audit model): enable auditing and record the event:
  UPDATE security_audit_config SET value = 'true' WHERE key = 'access_audit_enabled';
  INSERT INTO access_audit (actor, action, object_name)
  VALUES ('admin_user', 'enabled_access_audit', 'sensitive_customer_data');

NOTE: this capstone models auditability with config + an audit table rather than a
full pgaudit / event-trigger implementation, which is out of scope here.

Lesson: an access-control posture isn't complete until access decisions are
auditable — enable and verify the audit trail. Never "tidy up" by deleting the audit
table, and never paper over the gap by granting superuser.

INVESTIGATION HINTS (the staged path to diagnose and fix)
1. A security review found there's no audit trail for access to sensitive_customer_data. Check the audit state: SELECT * FROM security_audit_config; and SELECT * FROM access_audit;
2. access_audit_enabled = false and the access_audit table is empty — privilege/access changes aren't being recorded. Access control without auditability is incomplete.
3. Enable auditing and record an event: UPDATE security_audit_config SET value = 'true' WHERE key = 'access_audit_enabled'; then INSERT a row into access_audit. Don't delete the audit table, don't grant superuser.