Reviewing Audit Logs for Security Investigations

Overview and What You Will Learn

In this lab, you will trigger administrative actions that generate Admin Activity audit logs, enable Data Access logging for a service, and query both log types to reconstruct exactly who did what and when - the foundational skill for any real security investigation.

Why This Matters in Production

A security incident requires answering "who deleted this IAM policy binding, and when" - a question that's impossible to answer without Audit Logs, since regular application logs have no visibility into administrative actions taken through the Console, gcloud, or the API. Audit Logs exist specifically to make this exact question answerable.

Core Principles

GCP Audit Logs come in distinct categories, and knowing which one to check matters as much as knowing Audit Logs exist at all.

Detailed Step-by-Step Practical Lab

1. Create a project:

2. Perform an administrative action - creating a VM - which automatically generates an Admin Activity log entry:

3. Query the Admin Activity log to confirm this action was recorded:

4. Enable Data Access logging for Cloud Storage specifically, since it's disabled by default for most services:

5. Create a bucket and upload an object, then read it back - these actions will now generate Data Access log entries:

6. Query the Data Access log to see the read and write actions recorded:

7. Query specifically for who has been granted or modified IAM permissions - a common, high-value security investigation query:

8. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Assuming Data Access logs are captured by default the same way Admin Activity logs are. Admin Activity logs (configuration changes) are always enabled and cannot be turned off, but Data Access logs (who read or wrote actual data) are disabled by default for most services and must be explicitly enabled - a security investigation assuming data access history exists can be disappointed to find it was never being recorded.

Tip

Enable Data Access logging proactively for any service handling sensitive data, before an incident makes you wish you had that history - logs only exist from the point logging was actually enabled, never retroactively.

• Admin Activity logs cannot be disabled, by design - this is a deliberate guarantee that administrative actions are always auditable, regardless of any configuration choice.
• Route audit logs to a separate, access-restricted project or Log Sink for genuinely sensitive environments, so even someone with permissions in the audited project cannot tamper with or delete the audit trail of their own actions.

Quick Reference & Troubleshooting Commands