How to audit who did what

Topic: Security basics

Use logs and audit trails to see who accessed what and when. Enable audit logging for auth, admin actions, and data access; centralize and protect logs so they survive and are usable after an incident. Use this when investigating an incident or building auditability.

Intent: How-to

Quick answer

  • Enable audit logs for login (success and failure), privilege changes, and sensitive data access. Include user or service identity, timestamp, action, and resource in each event.
  • Send logs to a central store (SIEM, log aggregation) that is separate from the systems being audited so attackers cannot delete local logs. Retain logs per policy (e.g. 90 days or 1 year).
  • Search by user, time range, resource, or action when investigating. Alert on high-risk events (failed logins, permission changes, bulk export) so you can respond quickly.

Prerequisites

Steps

  1. Enable audit sources

    Turn on auth logs (login, logout, failures), admin action logs (user create, role change, config change), and data access logs where required (e.g. DB audit, object storage access). Include identity, time, action, resource.

  2. Centralize and protect

    Forward logs to a central system (SIEM or log aggregation). Restrict write access so only the logging pipeline can write; restrict delete so logs cannot be erased by a compromised host.

  3. Retain and search

    Retain logs per policy; index by user, time, resource, action so you can search. Run periodic drills to find a sample event and confirm retention and search work.

  4. Alert on high risk

    Create alerts for many failed logins, privilege escalation, bulk delete, or config change. Tune to reduce noise; review alerts and update rules as threats evolve.

Summary

Enable audit logging for auth, admin, and sensitive access; centralize and protect logs; retain and search by identity, time, and action; alert on high-risk events. Use this to investigate incidents and meet audit requirements.

Prerequisites

Steps

Step 1: Enable audit sources

Enable logs for login, admin actions, and sensitive data access. Include identity, timestamp, action, and resource.

Step 2: Centralize and protect

Send logs to a central store; restrict who can write or delete so logs survive compromise.

Retain per policy; index for search. Test periodically that you can find a given event.

Step 4: Alert on high risk

Alert on failed logins, privilege changes, bulk actions. Tune and review alerts regularly.

Verification

Audit events are logged, centralized, and searchable; retention is met; high-risk alerts are configured and tested.

Troubleshooting

Too much noise — Filter or sample; alert only on aggregated or high-severity events. Logs missing — Check forwarding and retention; ensure no one can delete audit logs.

Next steps

Continue to