Skip to content

FND323-R - Best practices for preventing data exposure

In this session, we will learn how to configure AWS Config, Amazon CloudWatch Events, AWS Lambda and AWS Systems Manager to prevent unauthorized exposure of enterprise data. This session also provides best practices for preventing misconfiguration of resources, including Amazon S3 and other services.

Turn on AWS Config

AWS Config provides a detailed view of the configuration of AWS resources in your AWS account. This includes how the resources are related to one another and how they were configured in the past so that you can see how the configurations and relationships change over time.

  1. Search for the Config Service under the Management Tools Section in the console and click on Config.

    Get to AWS Config Console

  2. Click on Getting Started, lets follow the Setup Wizard

  3. Keep all Defaults and Click Next – This will Create an S3 Bucket, a Role for the Config Service, and will record all resources supported by Config within the region. For a list of supported Service click here.
  4. Click Next on the Next Screen, we will setup Config Rules a little later in this session.
  5. On the Last Screen Click on Confirm.

We now have AWS Config recording changes for supported resources.

Deploy AWS Resource for the Lab

Click here To Deploy Lab into your Account

This will deploy a S3 Buket, AWS Systems Manager Automation Document, AWS Lambda Function, SNS Topic and IAM Role needed for this lab.

Note: This will deploy in US-EAST-1 region, the lambda function also resides in a S3 Bucket in the US-EAST-1 Region. If you want to set this lab up in another region, please be sure to download the S3BlockPublic.zip from the www.awsmanagementweek.com S3 Bucket and place it in a bucket in your target region and put that buckt name in the LambdaLocation Parameter of the CloudFormation Template.

Creating Config Rules to Alert on Public S3 Buckets

In this step we will create a config rule using an AWS Managed rule that will evaluate if S3 Buckets are Public Read

  1. Let's go to the AWS Config Console, once there click on Rules on the left side of the console.
  2. Click on Add Rule
  3. In the Add Rule Screen in the Filter section type s3-bucket-public, click on the s3-bucket-public-read-prohibited rule.
  4. Under the Trigger Section take notice of the Trigger Type, it set to bother on configuration change and Periodic. This means that this rule will evaluate when a change is made and also on a schedule. For this lab lets Change the frequency to 1 hour, leave the rest of the settings to default.
  5. Click Save

Next, we will create a config rule using an AWS Managed rule that will evaluate if S3 Buckets are Public Write

  1. Let's go to the AWS Config Console, once there click on Rules on the left side of the console.
  2. Click on Add Rule
  3. In the Add Rule Screen in the Filter section type s3-bucket-public, click on the s3-bucket-public-write-prohibited rule.
  4. Under the Trigger Section take notice of the Trigger Type as mentioned previously this will trigger on changes and on a schedule. Change the frequency to 1 hour, leave the rest of the settings to default.
  5. Click Save

You can create config Rules to monitor a number of items within your infrastructure. Beside utilizing AWS managed Config rules you can also create custom rules using Lambda Functions. Located here in Github are same sample config rules you can create and implement in AWS Lambda.

Now that we have rules which will evaluate if we have Public access, let us now create a CloudWatch Event so that we can trigger automated remediation.

Create CloudWatch Event Rules to trigger Lambda or AWS Systems Manager Automation

Now we will create the triggers for the Lambda Function deployed by the Cfn. The Lambda Function will Block Public Access to the S3 Bucket once it become non-compliant.
Note: This step needs to be done correctly for the Lambda to Trigger.

  1. Go to CloudWatch Console, and Under Events on the left side click on Rules
    • Click Create rule
    • Under Event Source
    • Select the radio button next to Event Pattern
    • Service Name: Config
    • Event Type: Config Rules Compliance Change
    • Select the radio button next to Specific message type
      • From the Drop Down Select ComplianceChangeNotification
    • Select radio button next to Specific rule name
      • Type s3-bucket-public-read-prohibited
      • Click the Plus to add Another Rule Name
      • Type s3-bucket-public-write-prohibited
    • Under Targets
    • Select the StackName-EnforceS3NoPublicAccess* Lambda Function, which is the function deployed by the CloudFormation. Feel Free to take a look at the function code in Lambda.
  2. Click Configure details
    • Configure rule details
    • Name: S3BlockPublicAccess
    • State: Check Enabled Box
    • Click Create Rule

Testing our enforcement of No Public Access

  1. Check what our S3 Public Bucket Access Settings are set to, should be off.
  2. Go to the S3 Bucket that was created when deploying the lab, and set it for public reads.
  3. You can wait after setting the bucket to public or Go to our Config rule for s3-bucket-public-read-prohibited and re-evaluate the rule. Refresh the screen and make sure the bucket comes up as Noncompliant.
  4. Go Back to the S3 Bucket and review the Public Acccess settings, Did the setting change? Did you Get an E-mail?
  5. Update the PublicApp Tag from no to yes, reset Public Access Settings back to off and retry. What happens?

Observe Configuration Timeline and Compliance Timeline

  1. Go to AWS Config, click on Resources
  2. Select S3:Bucket, and then click Lookup
  3. Click into an Bucket we deployed in this lab, then Click on Compliance timeline
  4. Observe the Timeline, and the compliance status changes that occurred
  5. Then click on the Configuration Timelime, and observe the changes to the bucket. You can click on the event or change links to see more information.

Bonus - Another Possibility using SSM Automation Document

  1. Go to CloudWatch Events and Disable the CloudWatch Event Rule we created earlier, this will prevent the lambda from being triggered and remediating the public Bucket.
  2. Go to AWS Config, select the rules and Click on Manage Redemediation, note that the Remediation Action column is blank.
  3. Select the AWS Systems Manager Automation Document deployed by the CloudFormation template (it will be listed toward the Bottom), and Select BucketName for Resource ID.
  4. The remediation column should now be populated with the SSM Automation Document Name
  5. Follow the same steps as previously to make the bucket public, and run the config rule so the bucket comes up as non-compliant.
  6. Go back to AWS Config, click into the rule and remediate the non-compliant resource. This will execute the Automation Document.
  7. You can head over to AWS Systems Manager, and click on Automation on the right side to observe what occurred.
  8. Re-Run your complaince, of check the Block Public Settings on the S3 Bucket.

End of Lab Exercises

Thank you for using this lab.