Introduction

Misconfigured Amazon S3 buckets are a leading cause of accidental data exposure in the cloud, resulting in regulatory fines, reputational damage, and costly data breaches. In this lab, we will look at a scenario that uses AWS Config and AWS Systems Manager Automation to automatically detect and remediate Amazon S3 buckets when Public Access Block settings are disabled.

If Block Public Access is disabled on a bucket, either accidentally or unauthorized, AWS will automatically detect the non-compliant configuration and restore the secure settings.

Prerequisites

An AWS account with an IAM user that has AdministratorAccess.

🔧Implementation

First, we create a non-compliant S3 bucket. (Since this lab tests for missing Block Public Access settings, start by deliberately misconfiguring a bucket):

• Log in to the AWS Console using your IAM credentials.
• Navigate to Services ▶ S3 ▶ Create bucket.

Under Bucket name, enter a globally unique name (in my case, mynewlab-bucket).

• Disable Block Public Access by unchecking the checkbox and confirming.

Note: You may see an access denied error (User is not authorized to perform s3:PutEncryptionConfiguration), but you can ignore it as it is not relevant to our scenario.

Enable & Configure AWS Config

• Now, let's navigate over to AWS Config, go to Rules ▶ Add rule ▶ Select Add AWS managed rule. then search for s3-bucket-level-public-access-prohibited(This rule looks for any form of bucket-level public access and flags it as non-compliant).

Under “Evaluation mode” select Resources for the scope of changes.

For the “Resource category” leave as is.

• Then, for the “Resource type” search for and select AWS S3 Bucket.

• Go back to the dashboard ▶rules, we see that the recently created s3 bucket has been flagged as non-compliant.

• The next step is remediation, but before we do that, we need to create an IAM role.

Create the Remediation Role & Policy

• Go to IAM, create a role and select Systems Manager as the trusted service(this allows SSM Automation to assume the role).

Rather than broad SSM permissions, we attach a custom, least-privilege policy that only allows starting and monitoring automation executions.

In the JSON tab and paste in the JSON tab that allows only:
ssm:StartAutomationExecution
ssm:GetAutomationExecution
s3:GetAccountPublicAccessBlock
s3:PutAccountPublicAccessBlock
s3:GetBucketPublicAccessBlock
s3:PutBucketPublicAccessBlock

Name the policy AWSConfigRemediationPolicy and save it.

• Back on the role’s Permissions page, search for the recently created role and select AWSConfigRemediationPolicy, click on it, Retrieve the Role ARN and copy somewhere which we will need this in the next step to for the automated remediation.

Enable Automated Remediation on AWS Config

• In Config ▶ Rules, click your s3-bucket-level-public-access-prohibited rule you recently created, select it and click on Actions -> Manage remediation. Select Automatic remediation.

Choose remediation action: AWSConfigRemediation-ConfigureS3BucketPublicAccessBlock. (This instructs Config to automatically pass in the resource ID of the noncompliant resource as a parameter of the remediation action, that way the automation knows which bucket to modify).

• Scroll down until you see “Resource ID parameter.” Click on the dropdown and select BucketName.

• Then, below that, we have a “Parameters” section. You’ll notice the BucketName portion is already filled in for you and you can’t modify it.

• For the other options, put true for everything except the final one, which is the AutomationAssumeRole input which is the role ARN that enables the automation to perform actions on your behalf.
• Paste in the AutomatedS3Remediation role ARN from the iam role created earlier. Leave other inputs at true, click Save.

Testing the automated remediation

• In AWS Config ▶ Rules ▶ Actions ▶ Re-evaluate

• Wait few minutes—Config marks NON_COMPLIANT, remediation runs, then COMPLIANT.

• Verify in S3 that Block Public Access is re-enabled.

• Now, let's check the resource timeline, we can see the log changes, cloudtrail and the details of the configuration, when the resource was dine and when the resource was created.

• Block Public Access is re-enabled within minutes of any change, with a full history of detection and remediation in AWS Config and AWS Systems Manager, applying automatically to all existing and future S3 buckets.

Conclusion

Using Automated S3 Remediation to Enforce Block Public Access is a proactive approach to maintaining the security of your Amazon S3 buckets. By automating the detection and remediation of non-compliant configurations, you can prevent data exposure and ensure compliance with security best practices. Take advantage of AWS Config and Systems Manager Automation to enhance the security of your cloud infrastructure.
Optimize the security of your Amazon S3 buckets with automated remediation for Block Public Access settings. Stay ahead of potential data exposure and maintain compliance effortlessly.

Also as a security best practice, buckets should always start off completely private. Only in specific use cases should buckets be made public, such as if you are deploying a public static website or sharing public objects.
Even then, you should always keep private buckets and public buckets in entirely different AWS accounts. This helps prevent misconfiguration, and it also enables you to enforce settings like Block Public Access at the account level instead of the bucket level.