State of Amazon Block Public Access and Secure by Default Design
This idea grew from a discussion in the Cloud Security Forum Slack on DynamoDB’s new release of Resource-Based Policies and a follow-up on our previous research on S3's Block Public Access. When testing DynamoDB Resource-Based Policies, it was found that AWS blocked creation of “public” resource-based policies for DynamoDB. While digging further, this was done by Amazon’s Block Public Access. This inspired us to look at the state of Amazon’s Block Public Access feature across services - a feature that aids with misconfiguration of resources and prevents resources from public access misconfiguration.
Currently, we found Block Public Access capabilities across 6 AWS Services (some which aren't as known):
- DynamoDB
- Elastic Block Store Snapshots (EBS)
- EC2 AMIs
- Elastic File System (EFS)
- Elastic Map Reduce (EMR)
- S3
We’ve categorized Block Public Access into 3 categories of secure by default and configuration options.
- Always enabled (Secure by default).
- Enabled by default, but can be disabled (Secure by default).
- Disabled by default, but can be enabled (Not secure by default).
In this blog post, we’ll dive into considerations and recommendations for configuring Block Public Access as well as some tools that help with Block Public Access. We expect AWS to continue to add secure by default settings and improve their block public access coverage across services.
Block Public Access Levels
We've categorized Block Public Access into the 3 categories based on:
- Whether they're enabled and thus secure by default.
- If they can be enabled and disabled.
Thus, the services can be grouped into the following 3 categories:
- Always Enabled
- DynamoDB
- Elastic File System (EFS)
- Enabled by Default, but can be disabled
- EC2 AMIs
- EMR
- S3
- Disabled by default, but can be enabled.
- EBS Snapshots
Block Public Access Across Services
Available Settings per Service
Services that have Block Public Access features may have differences across settings (such as blocking new or blocking existing).
S3
Account Level (Not Per Region)
Settings include 4 specific settings:
- BlockPublicAcls
- IgnorePublicAcls
- BlockPublicPolicy
- RestrictPublicBuckets
More information on these settings can be found on AWS's documentation here.
EC2 AMIs
Region Level (Settings at each Region in each AWS Account)
Settings include:
- Block New Sharing (Does not affect preivously shared AMIs)
EBS Volumes
Region Level (Settings at each Region in each AWS Account)
Settings include:
- block-all-sharing: This blocks all sharing including previously public snapshots.
- block-new-sharing: This only blocks new sharing and does not impact existing public snapshots.
EMR
Region Level (Settings at each Region in each AWS Account)
Settings include:
- On: Amazon EMR prevents launching of clusters in public subnets if the cluster has a configuration that allows inbound traffic from public IP addresses. If security group rules are modified, Amazon EMR will attempt to revoke the security group rule (if it has permissions). The EMR configuration permits setting port exceptions for block public access.
AWS Account Defaults
As of 4/20/2024, a new AWS Account will have the following configuration for Block Public Access:
- DynamoDB Block Public Access enabled.
- EFS Block Public Access enabled.
- S3 Block Public Access enabled.
- EC2 AMI Block Public Access enabled.
- EMR Block Public Access enabled with an exception for port 22.
- EBS Block Public Access disabled.
We recommend enabling EBS Snapshot Block Public Access and removing the exception for port 22 for EMR. See Best Practices section below for more information.
Note: We left off Systems Manager Document Block Public Sharing since it's not labeled as "Block Public Access." However, we'd recommend Blocking Public Sharing.
Background and History of Block Public Access
AWS has added additional support for Block Public Access across services recently including recent addition for EBS Snapshots and EC2 AMIs.
Timeline:
- March 20th, 2024: DynamoDB adds support for resource-based policies (and BPA)
- November 9th, 2023: Block Public Sharing of EBS Snapshots
- October 20th, 2023: EC2 AMI BPA enabled for all new accounts and existing accounts with no public AMIs
- September 13th, 2023: EC2 adds BPA for AMIs
- April 27th, 2023: Amazon S3 automatically enables S3 Block Public Access by default for all new S3 buckets
- November 15th, 2018: AWS introduces Amazon S3 Block Public Access
We would not be surprised to see more services in AWS with Block Public Access in the future.
Best Practices for Block Public Access
If possible, we recommend blocking all public access as an extra layer of security. Some use cases may require disabling block public access and we recommend doing so in limited accounts and adding additional security controls to prevent against misconfiguration.
Note: If there are resources in the account, ensure resources and applications will not be adversely impacted by account settings. These settings may need to be applied per each active region in your AWS Account. For resources that are public, we recommend validating to see if those need to be public - as some BPA settings may not apply to existing resources and configuration.
Note: S3 Block Public Access is a setting at the account level. Other BPA Settings may need to be configured for each active region.
Account Configuration
- Turning on EBS Snapshot Block Public Access.
aws ec2 enable-snapshot-block-public-access --state block-all-sharing
aws ec2 enable-snapshot-block-public-access --block-new-sharing
There are 2 options for EBS Snapshot Block Public Access: Blocking New Sharing and Block All sharing. We recommend using the more restrictive one if it matches with your organization's needs.
- Removing the exception for Port 22 on EMR Block Public Access.
aws emr put-block-public-access-configuration --block-public-access-configuration BlockPublicSecurityGroupRules=true
Existing Accounts: We recommend for security teams to work with application teams to ensure no adverse impact on existing infrastructure and applications as well as to understand current infrastructure needs. If possible and there's no adverse impact, we recommend securing the account and turning on Block Public Access where possible in the account prior to any application use.
New Accounts: We recommend securing the account and turning on Block Public Access where possible in the account prior to any application use. This can be done by account pipelines using tools such as Control Tower or 3rd party tools.
Identity and Access Management for Block Public Access
Additionally, permissions can be secured either via IAM (such as using a Service-Control Policy to deny disabling Block Public Access). Keep in mind that some Block Public Access permissions include both a Disable and an Enable IAM Action while some are an inclusive modification such as s3:PutAccountPublicAccessBlock.
An example policy that denies modification of block public access would be:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BlockBPAModification",
"Effect": "Deny",
"Action": [
"s3:PutAccountPublicAccessBlock",
"s3:PutBucketPublicAccessBlock",
"s3:PutAccessPointPublicAccessBlock",
"ec2:EnableSnapshotBlockPublicAccess",
"ec2:DisableSnapshotBlockPublicAccess",
"ec2:EnableImageBlockPublicAccess",
"ec2:DisableImageBlockPublicAccess",
"elasticmapreduce:PutBlockPublicAccessConfiguration"
],
"Resource": "*"
}
]
}
Conclusion
We're looking forward to seeing changes AWS makes with Block Public Access and appreciate the additional layers of security.
If you have questions or interest in what we're building and researching, subscribe to our updates below!
