Compliance Frameworks
BETA// Beta Mapping Disclaimer
Framework mappings are currently in beta. These references are generated based on technical specifications and common industry alignments. Mappings may be incomplete or inaccurate; always consult with a qualified auditor for official compliance validation.
Overview
Enable S3 server access logging for buckets tagged as sensitive while explicitly prohibiting logging on CloudTrail buckets to prevent infinite recursive logging loops and associated cost spikes.
AWS S3 server access logging is critical for auditing sensitive data access. However, enabling server access logging on a bucket that also serves as a target for AWS CloudTrail (or as its own logging target) creates an infinite recursive loop: every log delivery is recorded as an access event, which triggers a new log delivery. This results in massive storage growth and uncontrolled costs. This control mandates tagging for sensitive buckets to ensure audit trails exist where necessary, while enforcing a guardrail to prevent logging on the central CloudTrail log archive bucket.
Tag-driven selective logging focuses forensic visibility on critical data (PII, financial, source code) without the overhead of logging every low-risk utility bucket. Prohibiting logging on the CloudTrail bucket is a mandatory operational safety guardrail to avoid service-wide log bombardment and financial loss from recursive storage events.
Remediation Strategy
Tag sensitive buckets, enable access logging targeting the Log Archive account, and verify that the primary CloudTrail log bucket has logging disabled.
Tag sensitive buckets with SecuritySensitivity: High.
Setup a central logging bucket in the Log Archive account.
Enable server access logging on sensitive source buckets.
Ensure the CloudTrail log bucket has NO access logging enabled to prevent loops.
# ==============================================================================
# 1. IDENTIFY SENSITIVE BUCKETS MISSING LOGGING
# ==============================================================================
# Safely loop through every bucket name returned by the AWS API
for bucket in $(aws s3api list-buckets --query "Buckets[].Name" --output text); do
# 1. Fetch the sensitivity tag, hiding errors if the bucket has no tags at all
TAG=$(aws s3api get-bucket-tagging --bucket "$bucket" --query "TagSet[?Key==\`SecuritySensitivity\`].Value" --output text 2>/dev/null)
# 2. If the tag matches "High", check its logging status
if [ "$TAG" = "High" ]; then
LOG=$(aws s3api get-bucket-logging --bucket "$bucket" --query "LoggingEnabled" --output text 2>/dev/null)
# 3. Flag the bucket if logging is completely absent or returned as "None"
if [ "$LOG" = "None" ] || [ -z "$LOG" ]; then
echo "NON_COMPLIANT: $bucket"
fi
fi
done
# ==============================================================================
# 2. ENABLE LOGGING ON A SENSITIVE BUCKET
# ==============================================================================
aws s3api put-bucket-logging \
--bucket <SENSITIVE_BUCKET> \
--bucket-logging-status '{"LoggingEnabled": {"TargetBucket": "central-logs-bucket", "TargetPrefix": "s3-access-logs/<SENSITIVE_BUCKET>/"}}'
# ==============================================================================
# 3. DISABLE LOGGING ON CLOUDTRAIL BUCKET (SAFETY REMEDIATION)
# ==============================================================================
aws s3api put-bucket-logging \
--bucket <CLOUDTRAIL_LOG_BUCKET> \
--bucket-logging-status '{}'Enforcement Logic
Uses S3_BUCKET_LOGGING_ENABLED scoped via tags to sensitive buckets. Additionally, a custom check should verify the CloudTrail bucket is NOT in the compliance list.
aws s3api get-bucket-logging --bucket <CLOUDTRAIL_LOG_BUCKET>
# Expected: {} (Empty)Central logging buckets are exempt to prevent recursive loops.
Enabling server access logging on a bucket that receives its own logs or receives frequent CloudTrail logs will cause exponential log growth. Always use a separate, dedicated logging bucket that does not have logging enabled for itself.