Solved: Detecting S3 Bucket Public Access Changes with AWS Config & SNS

#devops #programming #tutorial #cloud

🚀 Executive Summary

TL;DR: Accidental public S3 buckets pose a significant security risk due to data exposure and reputational damage, with manual checks being unreliable. This guide provides an automated, real-time solution using AWS Config to monitor S3 bucket public access changes, triggering immediate alerts via SNS and EventBridge for swift remediation.

🎯 Key Takeaways

AWS Config continuously monitors S3 buckets using the S3\_BUCKET\_PUBLIC\_READ\_PROHIBITED rule to detect any configuration changes granting public read access.
Amazon EventBridge acts as the central orchestrator, listening for Config Rules Compliance Change events and forwarding NON\_COMPLIANT S3 bucket events to an SNS topic.
The entire monitoring and alerting system can be deployed as Infrastructure as Code using a single CloudFormation template, ensuring repeatability and adherence to DevOps practices.

Detecting S3 Bucket Public Access Changes with AWS Config & SNS

Introduction

In the world of cloud infrastructure, an accidentally public S3 bucket is one of the most common and damaging security vulnerabilities. A single misconfiguration can expose sensitive data, leading to breaches, reputational damage, and significant financial loss. While AWS provides robust tools like S3 Block Public Access, changes can still occur through manual error or automated scripts. Relying on periodic manual checks is simply not scalable or reliable.

This tutorial provides a robust, automated solution to this critical problem. We will create a real-time alerting system by integrating AWS Config with the Simple Notification Service (SNS). AWS Config will continuously monitor your S3 buckets for any configuration changes that grant public access. When a non-compliant change is detected, it will trigger an immediate notification via SNS to your team, allowing you to take swift corrective action. Let’s build a proactive security shield for your S3 data.

Prerequisites

Before you begin, ensure you have the following:

An active AWS account with administrative privileges (or at least permissions for IAM, S3, AWS Config, SNS, and CloudFormation).
Basic familiarity with the AWS Management Console.
An email address where you can receive security alerts.
(Optional) The AWS CLI installed and configured on your local machine for verification.

Step-by-Step Guide

We will use AWS CloudFormation to deploy the entire solution in a single, automated step. This Infrastructure as Code (IaC) approach is repeatable, version-controlled, and aligns with modern DevOps practices.

Step 1: Understand the CloudFormation Template

Our solution is defined in a single YAML template. This template will create four key resources that work together:

SNS Topic: A central communication channel named s3-public-access-alerts. All security notifications will be published to this topic.
SNS Subscription: Subscribes your email address to the SNS topic so you receive the alerts.
AWS Config Rule: An AWS-managed rule (S3_BUCKET_PUBLIC_READ_PROHIBITED) that continuously checks if any S3 bucket in your account allows public read access. When a bucket violates this policy, it is marked as “NON_COMPLIANT”.
Amazon EventBridge Rule: A rule that acts as the glue. It listens for compliance change events from AWS Config. When a resource becomes “NON_COMPLIANT” for our specific S3 rule, this rule forwards the detailed event to our SNS topic.

Here is the complete CloudFormation template. We will deploy it in the next step.

# CloudFormation Template (YAML)
AWSTemplateFormatVersion: '2010-09-09'
Description: >
  Sets up AWS Config rule to detect public S3 buckets and sends alerts via SNS.

Parameters:
  NotificationEmail:
    Type: String
    Description: The email address to receive security notifications.
    AllowedPattern: ".+@.+"
    ConstraintDescription: Must be a valid email address.

Resources:
  AlertsSNSTopic:
    Type: AWS::SNS::Topic
    Properties:
      DisplayName: "S3 Public Access Alerts"
      TopicName: "s3-public-access-alerts"

  SNSEmailSubscription:
    Type: AWS::SNS::Subscription
    Properties:
      Protocol: email
      Endpoint: !Ref NotificationEmail
      TopicArn: !Ref AlertsSNSTopic

  S3PublicReadProhibitedRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: "s3-bucket-public-read-prohibited"
      Description: "Checks that your S3 buckets do not allow public read access."
      Source:
        Owner: AWS
        SourceIdentifier: S3_BUCKET_PUBLIC_READ_PROHIBITED
      Scope:
        ComplianceResourceTypes:
          - "AWS::S3::Bucket"

  ConfigComplianceEventRule:
    Type: AWS::Events::Rule
    Properties:
      Name: "NotifyOnS3PublicAccessChange"
      Description: "Forwards AWS Config non-compliance events for S3 to an SNS topic."
      EventPattern:
        source:
          - "aws.config"
        detail-type:
          - "Config Rules Compliance Change"
        detail:
          configRuleName:
            - !Ref S3PublicReadProhibitedRule
          newEvaluationResult:
            complianceType:
              - "NON_COMPLIANT"
      Targets:
        - Arn: !Ref AlertsSNSTopic
          Id: "S3PublicAlertsSNSTarget"

  SNSTopicPolicy:
    Type: AWS::SNS::TopicPolicy
    Properties:
      PolicyDocument:
        Statement:
          - Effect: Allow
            Principal:
              Service: events.amazonaws.com
            Action: 'sns:Publish'
            Resource: !Ref AlertsSNSTopic
      Topics:
        - !Ref AlertsSNSTopic

Outputs:
  SNSTopicArn:
    Description: "ARN of the SNS topic for alerts."
    Value: !Ref AlertsSNSTopic

Step 2: Deploy the CloudFormation Stack

Now, let’s bring our infrastructure to life.

Navigate to the AWS CloudFormation service in the AWS Management Console.
Click Create stack and select With new resources (standard).
Under “Specify template”, choose Upload a template file. Save the YAML code above into a file named s3-alert-stack.yaml on your computer and upload it.
Click Next.
Give the stack a name, for example, S3-Security-Alerting-System.
In the Parameters section, enter the email address where you want to receive notifications.
Click Next, and on the “Configure stack options” page, you can leave the defaults and click Next again.
On the final review page, scroll to the bottom and check the box that says “I acknowledge that AWS CloudFormation might create IAM resources.” Then, click Create stack.

The stack creation will take a few minutes. While it’s deploying, check your email inbox. You will receive an email from AWS Notifications with a link to confirm your SNS subscription. You must click this link to activate the alert delivery.

Step 3: Test the Alerting System

With our monitoring system active, let’s test it by intentionally creating a non-compliant resource.

Navigate to the S3 service in the AWS Console.
Click Create bucket. Give it a globally unique name (e.g., techresolve-test-bucket-[your-initials]-[date]).
In the “Block Public Access settings for this bucket” section, uncheck the “Block all public access” checkbox.
Acknowledge the warning that this will make the bucket public, and then click Create bucket.
Navigate into your newly created bucket, go to the Permissions tab, and click Edit next to “Bucket policy”.
Paste the following policy, which grants public read access. Replace [YOUR-BUCKET-NAME] with your actual bucket name.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::[YOUR-BUCKET-NAME]/*"
        }
    ]
}

Click Save changes.

Now, wait. AWS Config can take several minutes to detect the configuration change and evaluate the resource against the rule. Once it marks the bucket as “NON_COMPLIANT”, the EventBridge rule will fire, and you will receive an email notification containing a detailed JSON payload about the event.

The JSON in the email will look something like this, clearly identifying the non-compliant bucket:

{
  "Type" : "Notification",
  "MessageId" : "...",
  "TopicArn" : "arn:aws:sns:us-east-1:[ACCOUNT_ID]:s3-public-access-alerts",
  "Subject" : "AWS Config Notification",
  "Message" : "{\"version\":\"0\",\"id\":\"...\",\"detail-type\":\"Config Rules Compliance Change\",\"source\":\"aws.config\",\"account\":\"[ACCOUNT_ID]\",\"time\":\"...\",\"region\":\"us-east-1\",\"resources\":[\"arn:aws:s3:::techresolve-test-bucket-...\"] ... }"
}

Common Pitfalls

Unconfirmed SNS Subscription: The most common reason for not receiving alerts is forgetting to confirm the email subscription. When the CloudFormation stack is deployed, AWS sends a confirmation email. If you don’t click the link in that email, notifications will not be delivered. Always check your inbox (and spam folder) for this confirmation request.
Insufficient AWS Config Permissions: If you set up AWS Config manually for the first time, it creates a service-linked IAM role. If this role’s permissions are modified or restricted, it may not be able to access S3 bucket policies or ACLs, causing the evaluation to fail. Using the provided CloudFormation template avoids this by relying on standard roles, but be mindful of any global Service Control Policies (SCPs) that might restrict Config’s access.

Conclusion

Congratulations! You have successfully deployed an automated, event-driven security monitoring system for your S3 buckets. By leveraging the power of AWS Config, SNS, and EventBridge, you’ve moved from a reactive to a proactive security posture. This setup provides immediate visibility into risky configurations, drastically reducing the window of exposure for one of your most critical data assets.

As a next step, consider enhancing this solution with automated remediation. You could trigger an AWS Lambda function from the SNS topic to automatically re-apply the “Block Public Access” settings to any non-compliant bucket, closing the security loop entirely.