RDS DB Instances Should Not Be Provisioned in VPC Public
More Info:
No AWS RDS database instances should be provisioned inside VPC public subnets in order to protect them from direct exposure to the Internet
Risk Level
High
Address
Security
Compliance Standards
- APRA CPS 234 (Australia)
- AWS Startup Security Baseline
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- FedRAMP
- GDPR
- HITRUST CSF
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST CSF
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- PCI
- SOC2
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Using Console
To remediate the misconfiguration of having RDS DB instances provisioned in VPC public subnets in AWS, follow these steps using the AWS Management Console:
-
Identify RDS Instances in Public Subnets:
- Go to the AWS Management Console and navigate to the RDS service.
- Click on "Databases" from the left-hand menu to view all your RDS instances.
- Identify the RDS instances that are provisioned in VPC public subnets.
-
Create New Private Subnet:
- Go to the VPC service in the AWS Management Console.
- Click on "Subnets" from the left-hand menu.
- Create a new private subnet within the same VPC where the RDS instances are located. Ensure that this subnet is not associated with a route table that has an internet gateway.
-
Modify RDS Instance:
- Go back to the RDS service in the AWS Management Console.
- Select the RDS instance that you want to move to the private subnet.
- Click on the "Modify" button to change the subnet group.
- In the "Network & Security" section, select the newly created private subnet from the "Subnet group" dropdown.
- Click "Continue" and then "Modify DB Instance" to apply the changes.
-
Verify the Changes:
- Wait for the modification process to complete. This may take a few minutes.
- Once the modification is complete, verify that the RDS instance is now running in the private subnet.
-
Update Security Group Rules:
- Update the security group associated with the RDS instance to allow necessary inbound and outbound traffic from other resources within the VPC.
By following these steps, you can remediate the misconfiguration of having RDS DB instances provisioned in VPC public subnets in AWS and ensure that they are running in private subnets for improved security.
Using CLI
To remediate the misconfiguration of having RDS DB Instances provisioned in VPC public subnets in AWS using AWS CLI, follow these steps:
-
Identify the RDS DB Instances that are provisioned in VPC public subnets:
Run the following AWS CLI command to list all RDS DB Instances in your AWS account:
aws rds describe-db-instancesIdentify the RDS DB Instances that are provisioned in VPC public subnets by checking their
DBSubnetGroupandDBSubnetGroup.Subnetsvalues. -
Create a new DB subnet group with private subnets:
Create a new DB subnet group containing only private subnets where you want to move the RDS DB Instances. Replace
subnet-xxxxxxxxxxxxxxwith the IDs of your private subnets.aws rds create-db-subnet-group --db-subnet-group-name private-subnet-group --db-subnet-group-description "DB Subnet Group with Private Subnets" --subnet-ids subnet-xxxxxxxxxxxxxx subnet-xxxxxxxxxxxxxx -
Modify the RDS DB Instances to use the new DB subnet group:
Modify each RDS DB Instance to use the newly created DB subnet group. Replace
db-instance-identifierwith the identifier of the RDS DB Instance andprivate-subnet-groupwith the name of the new DB subnet group.aws rds modify-db-instance --db-instance-identifier db-instance-identifier --db-subnet-group-name private-subnet-group -
Verify the changes:
Run the following AWS CLI command to describe the modified RDS DB Instance and ensure that it is now using the new DB subnet group:
aws rds describe-db-instances --db-instance-identifier db-instance-identifier
By following these steps, you can remediate the misconfiguration of having RDS DB Instances provisioned in VPC public subnets in AWS using AWS CLI.
Using Python
To remediate the misconfiguration of having RDS DB Instances provisioned in VPC public subnets in AWS using Python, you can follow these steps:
-
Identify the RDS instances that are provisioned in the public subnets:
import boto3client = boto3.client('rds')response = client.describe_db_instances()for db_instance in response['DBInstances']:db_instance_id = db_instance['DBInstanceIdentifier']db_subnet_group = db_instance['DBSubnetGroup']['VpcId']db_instance_public = db_instance['PubliclyAccessible']if db_instance_public and db_subnet_group:print(f"RDS instance {db_instance_id} is provisioned in a public subnet.") -
Modify the RDS instance to remove the public accessibility and move it to a private subnet:
db_instance_id = 'your_rds_instance_id'response = client.modify_db_instance(DBInstanceIdentifier=db_instance_id,PubliclyAccessible=False,ApplyImmediately=True)print(f"RDS instance {db_instance_id} has been modified to not be publicly accessible.") -
Verify that the RDS instance is now in a private subnet:
response = client.describe_db_instances(DBInstanceIdentifier=db_instance_id)db_instance_public = response['DBInstances'][0]['PubliclyAccessible']db_subnet_group = response['DBInstances'][0]['DBSubnetGroup']['VpcId']if not db_instance_public and db_subnet_group:print(f"RDS instance {db_instance_id} is now in a private subnet.")
By following these steps and running the Python script, you can remediate the misconfiguration of having RDS DB Instances provisioned in VPC public subnets in AWS.
Using Terraform
# Create a DB subnet group that uses only private subnets in at least two AZs
resource "aws_db_subnet_group" "private_subnet_group_for_DB_IDENTIFIER" {
name = "private-subnet-group-for-DB_IDENTIFIER" # replace DB_IDENTIFIER with your DB instance identifier
description = "Private subnets for RDS instance DB_IDENTIFIER"
subnet_ids = [
"PRIVATE_SUBNET_ID_1", # replace with a private subnet ID in AZ 1
"PRIVATE_SUBNET_ID_2", # replace with a private subnet ID in AZ 2
# add more private subnets if needed
]
tags = {
Name = "private-subnet-group-for-DB_IDENTIFIER"
}
}
# Move the RDS instance into the private subnet group and disable public access
resource "aws_db_instance" "this" {
identifier = "DB_IDENTIFIER" # replace with your existing DB instance identifier
# ... all your existing DB settings (engine, instance_class, storage, etc.) ...
db_subnet_group_name = aws_db_subnet_group.private_subnet_group_for_DB_IDENTIFIER.name
publicly_accessible = false
# This mirrors the CLI '--apply-immediately' behavior and WILL cause a brief outage.
# Omit or set to false to defer to the next maintenance window.
apply_immediately = true
}
Changing db_subnet_group_name and publicly_accessible will modify the existing DB instance in place; it will cause downtime when apply_immediately = true but will not force resource replacement.
To verify, run terraform plan and confirm it shows:
db_subnet_group_namechanging from the old subnet group toprivate-subnet-group-for-DB_IDENTIFIERpublicly_accessiblechanging fromtruetofalseapply_immediatelyset totrue(or your chosen value)