S3.9: No S3 access logs, so reads and writes go unaudited

What does AWS Security Hub S3.9 check?

S3.9 checks whether server access logging is enabled on a bucket. It reports FAILED when a bucket has no logging configuration directing request records to a target log bucket.

Why does S3.9 matter?

Without access logs there is no record of who read or wrote which object, so a data-exfiltration event leaves no trail to reconstruct. In the Capital One breach the attacker's requests were captured in server access logs the whole time — the difference between a 48-hour forensic timeline and three months of guessing comes down to whether logging was on.

How do I fix S3.9?

1. Stand up a central log-archive bucket and grant the S3 log-delivery group write access to it.
2. Enable logging on each source bucket with put-bucket-logging, pointing at the archive bucket with a per-source prefix.
3. Add a lifecycle rule on the archive bucket so log storage costs stay predictable.
4. Confirm records start landing, and bake logging into your provisioning path so new buckets inherit it.

# Enable server access logging on a flagged bucket, pointing at a central archive bucket.
aws s3api put-bucket-logging \
  --bucket fintech-customer-uploads \
  --bucket-logging-status '{"LoggingEnabled":{"TargetBucket":"fintech-s3-access-logs","TargetPrefix":"customer-uploads/"}}'

# Log object-level read and write data events, scoped to the sensitive prefix only,
# on a multi-Region trail (which is what S3.22 and S3.23 require).
aws cloudtrail put-event-selectors \
  --trail-name acme-management-trail \
  --advanced-event-selectors '[{"Name":"Log read+write data events for customer-records","FieldSelectors":[{"Field":"eventCategory","Equals":["Data"]},{"Field":"resources.type","Equals":["AWS::S3::Object"]},{"Field":"resources.ARN","StartsWith":["arn:aws:s3:::acme-customer-records/"]}]}]'