S3 buckets with server access logging turned off
What does ZopNight detect here?
ZopNight flags an S3 bucket whose server access logging is off, confirmed by an empty `LoggingEnabled` block from `GetBucketLogging`. Without it there is no per-request record of who read, wrote or deleted objects. Enabling logging carries no extra S3 charge beyond storing the log files, so this advisory finding shows a $0 saving.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-173 |
| Category | compliance |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | access logging disabled |
| Source | ZopNight |
| Permissions used | s3:ListAllMyBuckets · s3:GetBucketLogging |
Where it applies
What server access logs record
S3 server access logging writes a record for every request made to a bucket: the requester, the operation, the object key, the response status and the time. Those records answer questions such as “who downloaded this file last Tuesday?” or “which client is issuing all these failed requests?”, and they are kept in a bucket you control.
Without logging, the bucket keeps no request history of its own. Anything you want to reconstruct later has to come from CloudTrail, and only if data events were enabled beforehand.
Checking a bucket’s logging status
aws s3api get-bucket-logging --bucket my-bucketAn empty response means logging is off. When it is on, the output contains a LoggingEnabled
block naming the TargetBucket and TargetPrefix. To survey an account, loop over
aws s3api list-buckets --query 'Buckets[].Name' --output text.
What ZopNight records
For each bucket, discovery records whether server access logging is enabled. The rule fires when
that value is explicitly false. It does not read tags, so a stale logging tag can no longer hide a
bucket that has logging off.
Buckets that are not flagged
When the logging status could not be read, for example because the scanning role lacks
s3:GetBucketLogging on that bucket, no finding is raised. The rule also does not check whether
CloudTrail data events cover the bucket; if they do, you may decide the finding is already
addressed.
An audit lever, not a cost lever
ZopNight treats this as advisory and reports $0. AWS states there is no extra charge for enabling server access logging; the delivered log files accrue normal storage charges, and reading them later costs the usual data transfer rate. A lifecycle rule on the log bucket keeps that storage from growing forever.
Turning logging on
- Pick or create a destination bucket. It must be in the same AWS Region and account as the source bucket, and it should not have logging enabled itself.
- Allow the logging service principal
logging.s3.amazonaws.comto write to it with a bucket policy; AWS recommends a policy over ACLs. - Enable logging on the source bucket:
aws s3api put-bucket-logging --bucket my-bucket \ --bucket-logging-status '{"LoggingEnabled":{"TargetBucket":"my-log-bucket","TargetPrefix":"my-bucket/"}}'- Add a lifecycle expiration on the log bucket that matches your retention policy.