GCP projects with no Data Access audit log configuration
What does ZopNight detect here?
GCP projects whose IAM policy carries no auditConfigs block are flagged by RC-1254 as high severity: Data Access audit logs are off, so reads of user data leave no trail. Admin Activity logs stay on regardless, so the gap is data access. Detection fires only on an explicit false from the project scan.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1254 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | audit_log.go |
Admin Activity is always logged, Data Access is not
Google keeps Admin Activity audit logs on for every project and will not let you disable them, which lulls teams into believing “audit logging is on.” What is off by default is the other half: Data Access audit logs, the records of who read what. Without them, a service-account key used to dump a storage bucket or query a database leaves no entry anywhere. An auditor asking “show me who accessed customer data in March” gets an honest answer of “we cannot know”, which is the actual finding behind this rule’s high severity.
What a forensics gap looks like
Compromises are usually investigated backwards: an alert fires, then someone reconstructs what the credential touched before detection. Admin Activity logs show resources created and IAM grants changed, but the reads, the part that constitutes the breach, only exist if Data Access logging was configured before the incident. Enabling it afterwards documents the next breach, not this one. That asymmetry is why the rule flags the gap even for projects that have never had an incident.
How the project scan proves the condition
During ZopNight’s IAM walk of each project (the same read-only pass that powers the
Gmail-account and service-account findings, running under roles/iam.securityReviewer),
the project’s IAM policy is fetched, and that policy carries the auditConfigs section. If
any policy asset in the project has a non-empty auditConfigs, audit logging counts as
configured; the result is stamped as an explicit true or false on a synthetic per-project
resource. The rule fires only on the explicit false, so a partially scanned or cancelled
walk abstains rather than accusing a project it never finished reading.
Read your project’s auditConfigs
gcloud projects get-iam-policy PROJECT_ID --format="yaml(auditConfigs)"Empty output reproduces the finding. A configured project lists services with their enabled
log types (DATA_READ, DATA_WRITE, ADMIN_READ).
Enabling Data Access logs, and the cost caveat
Turn Data Access logs on per service under IAM & Admin → Audit Logs, or set an
allServices block in the policy for blanket coverage. One honest warning: on busy projects
these logs are voluminous: BigQuery and Cloud Storage reads can generate significant
logging volume and cost. Start with the services that hold sensitive data, add exemptions
for known-noisy service accounts, and route entries to a sink with a retention policy so
the trail survives longer than the default 30 days.