CodeParkAn audit log records who did what to which resource, when, from where, and whether it worked. Teams use it to investigate incidents, to pass compliance checks such as SOC 2, and to show customers an activity history.
How it differs from application logs:
- Application logs help debugging. They are noisy, kept for a short time, and may be sampled or dropped.
- Audit logs record business events. They must be complete, never sampled, kept for a long time and hard to change.
What each entry holds:
- Actor: user id, service name, and the real admin if they were impersonating someone
- Action: a stable name like
user.role.changed - Target: resource type, id and tenant
- When and where: UTC time, IP address, user agent and request id
- Result: success or denied, plus before and after values for changed fields
What to audit: logins and MFA changes, permission changes, data exports, admin actions, deletes, and API key creation.
How to build it:
- Write the entry in the same transaction as the change, or through an outbox table, so none are lost.
- Make it append-only: the app's database role has no
UPDATEorDELETEon it. Or ship it to write-once storage such as S3 Object Lock. - Limit who can read it, and audit those reads too.
- Never put passwords, tokens or full card numbers in it.
- An audit log records actor, action, target, time, source and result.
- Audit logs must be complete and long-lived, unlike debug logs.
- Write audit entries in the same transaction as the change.
- Make the log append-only or use write-once storage.
- Limit who can read it, and never store secrets in it.
Read more
- Logging Cheat Sheet (OWASP) (https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)cheatsheetseries.owasp.org