The audit trail
Every action anyone attempts against the vault is recorded — allowed,
refused, or quarantined alike. Refusals carry their real reason in the
trail even though the person refused sees only a uniform denial, and
attempts by strangers with no identity at all are recorded too. Delivered
entries live in a physically separate audit database that a compromise of
the primary store cannot rewrite.
A refused sign-in is recorded with its reasonstack
- Given an enrolled vault member
- When someone starts a sign-in for them with the wrong password
- Then the refusal is recorded in the audit trail with its reason
A stranger's attempt to open the vault is recordedstack
- Given a stranger with no session at all
- When they attempt to open the vault
- Then the anonymous attempt is recorded as denied
Changing a password is recordedstack
- Given an enrolled vault member
- When they change their password through the vault
- Then the change is recorded as a success in the audit trail
Recorded events reach the separate audit database by themselvesstackrelay_live
- Given an enrolled vault member
- When someone starts a sign-in for them with the wrong password
- Then the refusal becomes a delivered entry in the separate audit database without anyone asking
An unreachable audit database never crashes the vault or loses events
- Given the separate audit database is unreachable
- When the vault attempts its periodic audit delivery
- Then the vault keeps running and the service log names the delivery failure