# GCP GCS Bucket Access Logging Disabled

> GCS buckets with no logging.logBucket configured are flagged low-severity by ZopNight rule RC-142. Without usage logs or Data Access audit logs there is no record of who read which object (the trail PCI-DSS and HIPAA audits ask for), and logs cannot be reconstructed after an incident.

Source: https://zop.dev/integrations/gcp/recommendations/gcp-gcs-bucket-access-logging-disabled
Updated: 2026-08-19

---

## 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

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

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

```bash
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.