Audit log
The audit log records every consequential action in Overseer - who did it, what it was, when it happened, which client it concerned and on whose authority. This page explains what is recorded and how to read it.
What the audit log is
The audit log is Overseer's record of consequential actions. Each time something that matters happens, Overseer writes an entry.
It exists so that the question "who did this, and who said they could" always has an answer. That matters most in a product that acts on its own. When work runs unattended, the record is how you show that a named person authorised it.
The log is kept in full.
What an entry records
| Part | What it tells you |
|---|---|
| When | The time the action happened |
| Who | The actor, which is either a person or Overseer itself |
| What | The kind of action and its detail |
| Which client | The client the action concerned |
| On whose authority | For unattended work, the standing authorisation that allowed it |
What gets recorded
Entries cover the actions where a mistake or a misuse would matter, including:
- changes to accounts and roles
- capability grants
- deployments
- reveals and rotations of a computer's local administrator password
- computers being retired or restored
- changes to tags
- script runs
People and Overseer as actors
The actor is not always a person. When Overseer acts on its own, the entry carries Overseer's own actor name, not the name of whoever happened to be working at the time.
A standing authorisation is a named grant that lets Overseer act without asking each time, within a set scope. An action dispatched under one records which grant allowed it. So the log distinguishes two different events:
- a technician pressed a button
- Overseer acted unattended, citing a particular grant
The second leads back to the grant, and the grant leads back to the person who made it.
Reads and reveals
The audit log records actions. It does not record ordinary reads, such as opening a screen or viewing a report.
There is one deliberate exception. Reading back a computer's local administrator password is recorded every time. The entry is written before the password leaves Overseer, so a password can never reach a screen without a record that it did.
Who can read the log
Reading the audit log requires the Administrator role. People in other roles do not see it.
Using the log
- After an unexpected change. Find the entry for the action, then read the actor and the authority. They tell you whether a person did it or Overseer did, and under which grant.
- When reviewing access. Account changes and capability grants are recorded, so the log shows how a role came to hold what it holds.
- When a client asks. Each entry names the client it concerned, so you can answer for one client without exposing another.