GCP projects with no Data Access audit logs configured

What Google logs by default and what it leaves off

Cloud Audit Logs come in several types. The audit logs overview states that Admin Activity logs, covering configuration changes such as creating a VM or changing IAM permissions, are always written and cannot be disabled. Data Access logs are different: except for BigQuery, they are disabled by default because they can generate large volumes of data, and you must enable them explicitly.

That leaves a gap most teams only discover during an incident. The log will show who changed a bucket’s permissions, but not who then read the objects in it, or which service account queried a Cloud SQL instance. Many compliance frameworks expect both.

Checking a project’s audit configuration

The audit settings live in the auditConfigs section of the project’s IAM policy:

gcloud projects get-iam-policy PROJECT_ID --format="yaml(auditConfigs)"

An empty result means the project sets no Data Access logging of its own. Google notes that this command returns only the policy set on the project, not policies inherited from a folder or the organization.

What ZopNight reads before flagging a project

When ZopNight walks a project’s IAM policy, it also reads the auditConfigs block and records whether audit logging is configured. The rule fires on the project only when that record is explicitly “not configured” and the resource is a Google Cloud project. There is no threshold and no time window.

Situations that do not raise a finding

If the policy could not be read, or the result is unclear, ZopNight does not guess, and no finding appears. Projects with any audit configuration present are silent; the rule does not grade which services or log types you chose. Because only the project’s own policy is read, logging enabled higher in the hierarchy can still produce a finding, as the false-positive note says. Per-bucket access logs for Cloud Storage are a separate check, GCP GCS Bucket Access Logging Disabled.

Forensics gap, no saving

The finding has no saving. Enabling Data Access logs usually adds cost: Google warns the project may be charged for the additional log volume. The trade is visibility. Without these logs, a data exfiltration investigation has no record of which identity read what.

Enabling Data Access logs

1. Save the current policy: gcloud projects get-iam-policy PROJECT_ID > /tmp/policy.yaml.
2. Add an auditConfigs section for the services you care about, for example DATA_READ and DATA_WRITE for cloudsql.googleapis.com and storage.googleapis.com, following Google’s configuration guide.
3. Leave bindings and etag exactly as they were, then write it back with gcloud projects set-iam-policy PROJECT_ID /tmp/policy.yaml.
4. Route the logs to a sink with the retention your compliance regime requires.