Automating S3 bucket compliance check & remediation with AWS Config
Tags: aws, s3, security, databreach
Published: 2021-01-07 12:16:27

In the last post, we explored the most common S3 security breaches and how to remediate them ([if you missed it, you can read it here](https://mklein.io/2020/12/17/protect-against-s3-breaches/)).

Better than knowing how to protect your data is to automate the entire process, so whenever 
a similar situation arises, you can rest assured that the problem will be automatically fixed.

Today, I'll present how to automate the monitoring and remediation for the four 
recommended bucket configurations mentioned in the last post:

- Bucket versioning
- Block public read/write access
- Bucket logging
- Server-side encryption

By the end of this post, you will know how to automate the compliance check of your S3 buckets and automatically 
remediate them back to safety.

## AWS Config

The first step to automate your S3 bucket configuration is monitoring. We need to have a 
way to continuously monitor the state of our buckets and compare them 
against our defined rules.

AWS provides a service exactly for this purpose: [AWS Config](https://aws.amazon.com/config/).

AWS Config allows us to monitor and audit not only S3 buckets, but many other resource types. Resources
are monitored by a recorder, that checks their states periodically and compares them against our 
defined rules. These rules inform AWS Config about the desired state of the resource and, in case it diverges, 
the resource is reported as `non-compliant`.

AWS Config provides a set of managed rules that can be used to monitor common scenarios. For example, the managed rule 
`s3-bucket-server-side-encryption-enabled` can be used to verify if SSE (_server-side encryption_) is enabled in a S3 
bucket. [Here's the full list of managed rules provided by AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html).

Whenever a non-complying resource is discovered, AWS Config can execute an action in response to the 
event. Among the supported actions, the one that we will use in today's experiment is the _auto-remediation_.

![](https://d1.awsstatic.com/Products/product-name/diagrams/product-page-diagram-Config_how-it-works.bd28728a9066c55d7ee69c0a655109001462e25b.png)
*AWS Config diagram ([source: AWS](https://d1.awsstatic.com/Products/product-name/diagrams/product-page-diagram-Config_how-it-works.bd28728a9066c55d7ee69c0a655109001462e25b.png))*

## AWS System Manager (SSM)

AWS Config itself doesn't know how to remediate a resource. This task is delegated to [AWS System Manager](https://aws.amazon.com/systems-manager/).
It provides a set of runbooks that can be executed to modify a resource. For example, the runbook `AWS-EnableS3BucketEncryption` can be executed to enable
SSE in an S3 bucket. [A list of all SSM managed runbooks can be found here](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents-reference-details.html).

## Hands-on

Today, we will focus on the CloudFormation template to automate the entire process.

***[[Continue reading on mklein.io]](https://mklein.io/2021/01/06/bucket-compliance-and-remediation-with-aws-config/#hands-on)***