Audit logs & immutable trails

Aggregated sinks to a locked logging project.

You cannot respond to what you cannot see, and you cannot trust evidence an attacker could edit. The foundation of GCP detection and incident response is a complete, centralized, tamper-resistant audit trail — captured org-wide via an aggregated sink and protected in a locked bucket almost nobody can touch.

Know the log types

Cloud Audit Logs come in four streams. Admin Activity (always on) records configuration and permission changes. Data Access (opt-in, except BigQuery) records reads and writes to resource data — enable it where you need data-plane visibility, accepting the volume. System Event records Google-initiated changes, and Policy Denied records requests blocked by security controls like VPC Service Controls. Together they answer "who did what, to which resource, when, and from where".

# Route every project's logs to a central bucket in the logging project.
gcloud logging sinks create org-audit \
  storage.googleapis.com/acme-org-audit \
  --organization=ORG_ID --include-children \
  --log-filter='logName:"cloudaudit.googleapis.com"'
 
# Lock the log bucket's retention so nobody — including admins — can delete
# entries before retention expires (tamper-resistant evidence).
gcloud logging buckets update _Default --location=global \
  --retention-days=400 --locked

Segregate and alert on blinding

Deliver logs to a dedicated logging project (or an external SIEM) with minimal human access, so a workload compromise cannot reach its own audit record, and lock the destination’s retention so the trail is write-once. Then alert on the meta-events — a sink being deleted, Data Access logging being disabled, retention being unlocked — because an attacker who understands the trail tries to blind it first. "Someone changed logging configuration" is one of the highest-signal detections you can have.