DEV Community

Cover image for Setting up Amazon Macie for S3 Buckets
Adepitan Adetunji
Adepitan Adetunji

Posted on

Setting up Amazon Macie for S3 Buckets

Amazon S3 misconfigurations remain among the most frequent and damaging cloud vulnerabilities, regularly exposing organizations to severe data breaches, regulatory penalties, and reputational fallout.

To mitigate these risks, Amazon Macie delivers fully managed data security and privacy capabilities powered by machine learning. Macie continuously audits your Amazon S3 footprint to evaluate access permissions, flagging world-readable and world-writable buckets, while automatically discovering, classifying, and protecting sensitive information like Personally Identifiable Information (PII) and hardcoded credentials.

In this hands-on lab, you will configure Amazon Macie, create and scope automated discovery jobs, and analyze generated security findings to remediate exposed sensitive assets across your S3 buckets.

NB. This hands-on was practiced from pwned labs.

Working with Amazon Macie for S3

Start by navigating to Amazon Macie in your console, click on “get started” and select “create a job” under “analyze public buckets”

On the next page (choose s3 buckets), select "Specify bucket criteria" and click Next. This includes all S3 buckets in the AWS account, if you prefer to select specific buckets you can choose this option instead. However, this walkthrough uses the all s3 buckets option.

Click Next on the Review S3 bucket criteria page.

Here, to refine scope, you can specify whether this is a scheduled or just a one-time job. If you run a one-time job, you will be able to establish a baseline or to test a new configuration, while a scheduled job allows you to get the current security health of your S3 buckets at a frequency that is useful to you.

Select Recommended under managed data identifier options. Unless you have a need to use specific identifiers.

Unless you chose custom in previous step, do not make any changes in this present step, click next

There may be certain data patterns that you don't want to be alerted on, even if they match and you can define allow lists on this step .

Now select a name for your job:

You will be asked to configure a repository which will include a bucket and KMS Key ARN, go ahead and click on the configuration to do the following:

Image credit to pwned_labs

First we need a key to encrypt our data. AWS Key Management Service (KMS) is a managed service that makes it easy for users to create and manage cryptographic keys. Create a key if needed by navigating to the Create key page below, selecting the appropriate settings and click Next.

Image credit to pwned_labs

Next we provide an alias and optionally a description for the key.

Image credit to pwned_labs

Returning to the repository settings page create a new bucket if needed, select your AWS KMS key and click Next.

Image credit to pwned_labs

If you encounter any issues with configuring the repository, then you may need to add the statement below to the existing KMS key policy:

{
"Sid": "Allow Macie to use the key",
"Effect": "Allow",
"Principal": {
"Service": "macie.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Encrypt"
],
"Resource": "*"
}

On the Macie summary page we see a high-level summary of our S3 security posture. There are a number of public buckets, including one that contains sensitive information! We also have a classification error that requires our attention.

Clicking on the 1 under Sensitive, we see the page below. Click the triangle to see further details.

It reports that the hlogistics-beta bucket contains AWS credentials. Click AWS_CREDENTIALS.

On the findings page, select the resource that's affected to bring up a details container window.

Then click on the Resource URL in the Overview section, and on the S3 page click the Object URL to view the file.

Returning to the Macie summary page we also see a high-level overview of our data security. Macie has identified that five our our public buckets are world-readable, and one is world-writable! With this access, any malicious actor would potentially be able to tamper with or delete our data, steal our data and hold it to ransom, use it to host malicious content and upload a large amount of data, potentially resulting in large storage costs. If the S3 bucket hosts a website it is also possible to backdoor existing JavaScript files, and steal the cookies of site visitors, including administrators.

Top comments (0)