S3 Activity Monitoring Audit

I set out to find monitoring blind spots on an S3 data store, check whether object-level access was being recorded, and turn on the logging needed to see it.

A customer keeps sensitive data mostly in S3. The bucket was not public and ACLs were disabled, but object activity such as GetObject, PutObject and DeleteObject might be happening with no record. I wanted to know whether that activity could be detected and traced to whoever did it.

1. 01
   Reviewed the bucket

   I identified it and listed its contents.

2. 02
   Checked server access logging

   It returned no configuration.

3. 03
   Read the trail's event selectors

   Management events only, no data resources.

4. 04
   Queried for object activity

   CloudTrail and CloudWatch Logs showed no object-level records.

5. 05
   Turned on S3 data events

   I added the bucket's objects to the trail's event selectors, keeping management events on.

6. 06
   Turned on server access logging

   I pointed it at a separate logging bucket with a prefix per source bucket.

aws cloudtrail put-event-selectors --trail-name "$TRAIL_NAME" --event-selectors "[{
  \"ReadWriteType\": \"All\", \"IncludeManagementEvents\": true,
  \"DataResources\": [{ \"Type\": \"AWS::S3::Object\", \"Values\": [\"arn:aws:s3:::${BUCKET_NAME}/\"] }]
}]"

aws s3api put-bucket-logging --bucket "$BUCKET_NAME" --bucket-logging-status "{
  \"LoggingEnabled\": { \"TargetBucket\": \"$LOGGING_BUCKET\", \"TargetPrefix\": \"${BUCKET_NAME}/\" }
}"

The trail now selects the bucket's objects, server access logging is on, and a test read showed up as a data event tied to an identity (account details masked):

Event selector:   Type AWS::S3::Object, Values arn:aws:s3:::blind-bucket/
Data event:       eventName GetObject, key flag.txt, userIdentity.arn arn:aws:iam::<ACCOUNT_ID>:user/<USER>
Access logging:   TargetBucket blind-bucket-logs, TargetPrefix blind-bucket/

1. 01Turn on CloudTrail S3 data events for sensitive or business-critical buckets.
2. 02Add server access logging where you need HTTP-level detail.
3. 03Send logs to a dedicated, locked-down logging destination with set retention.
4. 04Watch GetObject, PutObject and DeleteObject on sensitive data, with saved queries or alerts.
5. 05Review logging coverage so new buckets do not reopen the gap.