Audit records are updatable and have no integrity protection

[Bccorb]

Part of #155. Session 7. Gated on purchasing the GovRAMP Security Snapshot.

Problem

auth_events is an ordinary table with beforeUpdate and beforeSave hooks
(src/models/authEvents.ts), so records are updatable by
anything holding the application's database credentials. There is no append-only
constraint, no hash chain and no write-once storage.

An attacker who reaches the database can rewrite the record of how they got there.

Why it matters

NIST 800-53 AU-9, protection of audit information. For an authentication server
this is the control that makes every other audit control meaningful.

What to do

Options, roughly in increasing cost:

• Revoke UPDATE and DELETE on the table from the application role, and use a
  separate role for retention operations
• Add a hash chain over records so tampering is detectable after the fact
• Ship to append-only external storage, which also addresses AU-4 and AU-6

Pick after the Snapshot scores the current state. Doing the cheap AU work first
(#159, #161, #173) and then seeing what the score says is deliberate.

Acceptance

• The application role cannot modify or delete audit records in normal operation
• Tampering is detectable

Freeze status

Anticipated GovRAMP finding (exception 2). Sequenced after the Snapshot on purpose.