Audit log

What it is

An audit log is an append-only record of privileged actions taken against a system. Each entry captures who took the action, what they did, when, and the network context the action came from. The defining property is append-only: entries are never modified or deleted once written, so the historical record is structurally separate from anyone's ability to clean up after themselves.

Audit logs sit between two needs that almost every privileged system has. The operational need answers "what happened that explains the current state of the system?" Common cases include investigating an incident, tracing how a setting got changed, or watching for unauthorized behavior in real time. The compliance need asks the same question under regulatory pressure: "prove that access to this data is controlled and observable."

What a useful entry contains

Different systems include different fields, but a good audit entry generally has six things:

• Actor. The user, machine, or system that performed the action. For machines, this is typically a stable identifier (not the IP, which can change).
• Action. A short stable identifier for what happened (secret_create, machine_register, user_suspend). Stable strings are important for downstream alert rules and dashboards that filter by action.
• Target. What the action was performed on. A secret ID, a vault, a project, another user.
• Timestamp. Resolved to seconds at minimum, milliseconds in the better implementations.
• Source IP. The network address the request came from.
• Detail. Free-form text describing the specific change. The action and target answer "what kind of thing happened"; the detail answers "to what specifically."

Better systems also capture a severity tag so the log can be filtered for paging events vs background noise, and a context field for free-form metadata (which session, which machine, which impersonation chain).

Tamper evidence

The line between a useful audit log and a forensic one is whether the log resists deletion or modification after an attacker has the level of access that would let them try.

Common tamper-evidence patterns:

• Database-level immutability. A trigger that rejects UPDATE and DELETE on the audit table, blocking even the application's own code from rewriting history.
• Hash chains. Each entry includes the hash of the previous entry, so removing or altering a row breaks the chain at every subsequent row.
• External shipping. Entries are sent in near-real-time to a separate logging system (a SIEM, an immutable storage tier, an S3 bucket with object lock) that the primary system doesn't have credentials to modify.
• Append-only filesystems. Specialized object stores or filesystems that physically can't overwrite past data.

The right combination depends on the threat model. Database-level immutability stops a buggy admin tool from corrupting history. Hash chains stop an attacker with privileged database access. External shipping stops an attacker who's compromised the entire running system. The strongest implementations layer these.

What it does for you

The unglamorous truth about audit logs is that you almost never read them in normal operation. They earn their keep three times:

1. An incident happens and you need to answer "what did the attacker touch?" The log tells you which secrets they read, which configs they changed, which machines they registered.
2. A regulator or customer auditor asks "prove that only authorized identities accessed customer data in the last 12 months." You produce log queries; they verify the answer.
3. You catch something quietly wrong. A monthly review of "what did super-administrators do" surfaces an action that shouldn't have happened. Detection that the alerting system missed.

For these uses, the log has to be both complete (every privileged action is captured) and trustworthy (nothing has been edited after the fact). Either property without the other is half-useless.

How SikkerKey handles it

Every privileged action in SikkerKey lands in your audit log: secret reads, secret writes, grants and revocations, machine registrations and deletions, user logins and logouts, billing changes, employee impersonations. Each entry records the actor identity, action name, target, timestamp in milliseconds, source IP, free-form detail, and a severity tag.

The audit table is append-only at the database level. A trigger (sikker_audit_immutable) rejects every UPDATE and DELETE on the table unless a session-local flag is explicitly set, and that flag is only set by the retention pruner. A bug, a compromised route, or a debug tool with database access can't silently rewrite history, because the database itself refuses to do it.

Retention follows plan policy and runs as a scheduled pruner. You can filter your audit log in the dashboard by actor, action, time range, and other dimensions. Any canary secret trip lands as a CRITICAL-severity entry that drives an immediate alert.