GCS buckets with no access-log destination configured

Two different logs, one finding

Cloud Storage has two separate answers to “who touched this object”, and the remediation depends on which one you actually need. Usage logs are the per-bucket feature this rule observes: hourly HTTP-style access records delivered to a destination bucket you name via logging.logBucket. Data Access audit logs are a different mechanism: project-wide Cloud Audit Logs entries recording GCS API calls, configured under IAM & Admin rather than on the bucket. The discoverer reads the bucket resource, so what ZopNight can see is the first kind: a bucket with no log destination configured fires the rule, even if project-level audit logs happen to cover it. Treat the finding as a prompt to decide which trail the bucket needs, not as proof that neither exists.

The trail you cannot backfill

Every logging gap has the same failure mode: the day you need the data is the day after the incident. If a credential leaks and a bucket holding exports or backups is read out, the questions are immediate: which objects, from which IP, starting when. With no access records, the honest answer to a regulator or customer is “we cannot determine scope”, which usually forces you to treat the entire bucket as breached. Compliance frameworks such as PCI-DSS and HIPAA expect object-access auditing for exactly this reason. Logging is one of the few controls that is worthless to enable retroactively.

See which buckets ship logs

gcloud storage buckets list --format="table(name, logging_config.logBucket)"

An empty logBucket column is the state this rule flags. To fix one bucket:

gcloud storage buckets update gs://BUCKET \
  --log-bucket=gs://LOG_BUCKET --log-object-prefix=BUCKET

Detection mechanics and abstention

The discoverer writes access_logging_enabled in both polarities, true when a log bucket is configured and an explicit false otherwise. The rule fires on anything but true, but only after confirming the resource was actually enriched as a GCS bucket (the storage_class key, stamped by the same enricher, acts as the anchor). A resource that discovery never enriched abstains instead of firing. Severity is low and the saving is $0: log storage costs slightly more than nothing, and the point of the finding is audit readiness. All the evidence comes from read-only enrichment (storage.buckets.get); nothing in ZopNight writes logging configuration on your behalf.