S3 buckets serving requests with no access log trail
What does ZopNight detect here?
Server access logging writes a record of every request an S3 bucket serves into a log bucket you designate, at no charge beyond the log storage itself. ZopNight reads each bucket's logging configuration at discovery and flags confirmed-off buckets only. A 403 or throttled read produces no finding.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-173 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | s3_access_logging.go |
Where it applies
The question access logs answer
When a bucket is involved in an incident, the first question is who read what, and when. Server access logs are the native answer: one log line per request, including requester, object key, response code and bytes sent, delivered to a second bucket you choose. CloudTrail management events will not answer it: they record bucket-level API calls, not object reads, unless you additionally pay for S3 data events. Access logging covers object-level traffic with no enablement fee; you pay only for the storage the logs consume, at ordinary S3 rates.
The evidence standard
Discovery reads each bucket’s logging configuration and records a plain boolean: enabled or not. The rule fires only when that boolean is present and false. When the configuration read failed (throttling, or a 403 from a restrictive bucket policy), the boolean is never recorded and the rule abstains, so a permissions gap in discovery cannot masquerade as a logging gap in your estate.
Check one bucket
aws s3api get-bucket-logging --bucket my-bucketAn empty response is this finding: logging is off. When enabled, the response names the target bucket and prefix the logs flow to.
Turning it on without a cost trap
- Pick or create a target bucket in the same region and grant the S3 logging service permission to write to it.
- Enable logging on the source bucket, pointing at that target with a distinct prefix per source.
- Put a lifecycle rule on the log bucket. This is the step people skip: access logs on a busy bucket accrue forever, and the audit trail quietly becomes its own storage bill.
- Never point a bucket’s logs at itself, since every delivered log line would generate another log line.
Limits worth knowing
Log delivery is best-effort and can lag by hours, so access logs are an audit trail, not a real-time alarm. The finding carries no dollar figure; logging is a security posture, not a saving. And the rule checks only that logging is configured on the source; it does not verify the target bucket is actually receiving log objects.