How to Use AWS Config & AWS IAM Access Analyzer to Detect Public-Facing Resources in AWS

The situation: Identifying Public-Facing AWS Resources

If you have ever wanted to scan your AWS account for resources that are publicly accessible, this blog post is for you. It is preferable to implement AWS Config auto-remediation for real-time response, and tools like the Open Policy Agent and Service Control Policies to prevent public access ahead of time.

However, it is sometimes necessary to audit an account for publicly accessible resources that may have slipped through the cracks.

Tools for Detecting Public Resources

1. AWS Config

AWS Config comes with a helpful set of Managed Rules . We will use a selection of these rules to help identify resources that are available to the public.

2. Access Analyzer

AWS IAM Access Analyzer was launched in 2019. It is one of the few services that uses a mathematical form of analysis called Automated Reasoning . Although it only works with resources that have resource policies, IAM Access Analyzer offers a helpful interface for identifying unwanted public access.

Walkthrough: Using AWS Config for Public Resources Detection

The AWS config setup

AWS maintains a set of Managed Config Rules for AWS Config. At the time of this writing, there are 276 managed rules. For our use case, we are only interested in the rules that help us detect public access. Fortunately, a list of this subset of rules can be found in the Operational Best Practices For Publicly Accessible Resources conformance pack. Here they are, listed out:

 "AUTOSCALING_LAUNCH_CONFIG_PUBLIC_IP_DISABLED", 

 "DMS_REPLICATION_NOT_PUBLIC", 

 "EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK", 

 "EC2_INSTANCE_NO_PUBLIC_IP", 

 "EKS_ENDPOINT_NO_PUBLIC_ACCESS", 

 "EMR_MASTER_NO_PUBLIC_IP", 

 "LAMBDA_FUNCTION_PUBLIC_ACCESS_PROHIBITED", 

 "RDS_INSTANCE_PUBLIC_ACCESS_CHECK", 

 "RDS_SNAPSHOTS_PUBLIC_PROHIBITED", 

 "REDSHIFT_CLUSTER_PUBLIC_ACCESS_CHECK", 

 "S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS", 

 "S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS_PERIODIC", 

 "S3_BUCKET_LEVEL_PUBLIC_ACCESS_PROHIBITED", 

 "S3_BUCKET_PUBLIC_READ_PROHIBITED", 

 "S3_BUCKET_PUBLIC_WRITE_PROHIBITED", 

 "SSM_DOCUMENT_NOT_PUBLIC", 

 "SUBNET_AUTO_ASSIGN_PUBLIC_IP_DISABLED", 

 "ALB_WAF_ENABLED", 

 "API_GW_ASSOCIATED_WITH_WAF", 

 "CLOUDFRONT_ASSOCIATED_WITH_WAF", 

 "EC2_SECURITY_GROUP_ATTACHED_TO_ENI", 

 "ELASTICSEARCH_IN_VPC_ONLY", 

 "INSTANCES_IN_VPC", 

 "INTERNET_GATEWAY_AUTHORIZED_VPC_ONLY", 

 "LAMBDA_INSIDE_VPC", 

 "OPENSEARCH_IN_VPC_ONLY", 

 "RDS_DB_SECURITY_GROUP_NOT_ALLOWED", 

 "S3_BUCKET_ACL_PROHIBITED", 

 "VPC_DEFAULT_SECURITY_GROUP_CLOSED", 

AWS Config is a regional service, so you will need to create these rules in all regions. This would be tedious to do by hand, so it is recommended to use Infrastructure as Code like Terraform or CloudFormation StackSets for a multi-region rollout of the AWS Config Rules.

To address this need, I created Terraform Public Access Detection Example , which will get you started with a multi-region deployment of these config rules.

Auditing results

After enabling your config rules, the AWS Console will list the Compliance status for each rule that you enabled:

However, there is no reporting functionality built into the Console. To generate a report, you can use the AWS configservice list-discovered-resources command. See this example script which loops through AWS regions and resource types and lists any non-compliant resources:

for x in us-east-1 us-east-2 us-west-1 us-west-2; do
    for y in AWS::EC2::Instance AWS::ApiGateway::RestApi AWS::CloudFront::Distribution AWS::S3::Bucket; do
        echo $x
        aws configservice list-discovered-resources --resource-type $y --region=$x | jq -e '(select(.resourceIdentifiers | length > 0))'
    done
done

Utilizing AWS Access Analyzer to Detect Public Resources

In contrast to AWS Config, the Access Analyzer is simple to configure and use.

Again though, it is regional, so you will need to create an analyzer in every region you work in. The Access Analyzer works with a limited set of resources, which is why it works well as a complement to the AWS Config rules listed earlier. At the time of this writing, the Access Analyzer supports S3, IAM Roles, KMS keys, Lambda functions, SQS queues, and Secrets Manager secrets.

To get started, navigate to the Access Analyzer within the IAM dashboard and click Create Analyzer:

You will only have one analyzer per region. If you are a member of an organization, you can create an analyzer to monitor resources in all of your linked accounts. Once you create the analyzer you can easily search for resources that allow for public access:

Once you have a list of findings, they can easily be exported into a CSV, or you can mark them as Archived to prevent them from showing up in the result set.

Although it is better to prevent publicly accessible resources from being created in the first place, if they do get created to auto-remediate the situation, you now have a starting point for using AWS Config and Access Analyzer to detect public-facing resources that you may not be aware of. 

If you would like to see more posts similar to this one, consider following me on X.

StratusGrid Can Help with AWS Config and AWS IAM Access Analyzer!

Secure your AWS environment and ensure your resources are protected with StratusGrid's expertise. As your AWS Certified Partner, we're dedicated to helping you navigate the complexities of AWS Config and Access Analyzer, providing you with the tools and knowledge to detect and manage public-facing resources effectively.

Reach out to StratusGrid today, and let's work together to fortify your AWS environment, ensuring your data remains safe and compliant.