The audit record: the answer to "who did it", not "what happened"

Monitoring and an audit record are two different things, and they get confused. Monitoring answers "what happened": the disk filled, a service fell over, load went up. An audit record answers who did it. The value of the second shows up on days you hope never come.

Three moments

Something changed and nobody remembers changing it. The answer is usually "you, three weeks ago", and that is a relief rather than an accusation: an unknown change is far more unsettling than a known one.

Two people work on the same machine and each assumes the other did it. In that situation the only thing that ends the discussion is the record.

Something genuinely went wrong and you need the order of events. The end state tells you what happened; the order tells you how. Without the second, the same thing repeats.

"Root did it" is not an answer

If everyone signs in with the same account, the name in the record is the same for everyone. The record keeps answering "what happened" but stops answering "who did it". That is why an audit record is unimportant on a one person setup and becomes critical the day a second person arrives.

What must not be in the record

The request body. Passwords, keys and tokens travel through there. A record that captures everything means a new place your secrets live, and that place is usually less protected because it counts as "just a log".

An audit record needs five things: who, what, when, to what, and the result. When you want to add a sixth, first ask whether it carries a secret.

Where it sits decides whether it is evidence

A record that only the application can write and rewrite is a diary, not evidence. If the application itself is compromised, it fixes the record too.

That is why the record also has to land somewhere the application cannot reach. The system's own log exists for this: the application writes there but cannot delete from there.

Retention

An audit record kept for three days answers "who did it yesterday" and nothing else. Yet most of these questions arrive weeks later, because the effect of a change is usually not visible immediately. Keep the audit record on different reasoning from your backups: it takes little space and stays valuable for a long time.

What Atlas does

Atlas writes only five things to the audit record: who, what, when, to what, and the result. The request body is never written, because a login request carries a password and there is no benefit to that password existing a second time in a log file.

The record lands in two places at once. One is the system's own log: Atlas writes there but cannot take from there or change it. The other is a file in the product's data folder that is not deleted by updates. So you do not have to descend into the system log to read the record, but it is there when you need it.

A small but meaningful detail: the timestamp is written at the very end of the record. That way, even if the side creating the record passes its own timestamp, it cannot overwrite it. Nothing tries that today, but in an audit record the order being right is in the nature of the thing.

And refused requests are recorded too, not only the ones that ran. So the information "someone tried and it did not work" also sits in the record; more often than not, that is the sentence you were looking for.