RDS PubliclyAccessible Flag Hides an Open Security Group Rule

Symptom

An RDS instance configured with PubliclyAccessible set to false continued to accept connections from hosts that had never been granted explicit access, discovered during a routine network segmentation review rather than through any alert. A security engineer connected to the database’s endpoint on port 5432 from an EC2 instance in an unrelated application subnet — one with no documented business reason to reach that database — and the connection succeeded immediately, without any bastion, VPN client certificate or explicit allow-list entry in place.

False Assumption

The team treated PubliclyAccessible=false as a complete network isolation guarantee: if the flag is false, only resources that have been deliberately granted access can reach the instance. This assumption meant that security group ingress rules on the database were not reviewed as part of the standard access audit, because the PubliclyAccessible flag was believed to be the authoritative control.

In fact, PubliclyAccessible only determines whether AWS attaches a publicly routable IP address to the instance’s network interface. It says nothing about which sources within the VPC, peered VPCs, Transit Gateway attachments or VPN-connected networks are permitted to reach the instance. That boundary is set entirely by the security group (and, less commonly, network ACLs) attached to the database’s elastic network interface.

Root Cause

The database’s security group carried an inbound rule permitting TCP port 5432 from 0.0.0.0/0. The rule had been added during an early migration exercise to let a script running from an unpredictable source IP address connect temporarily, and it was never removed once the migration finished. Because a security group’s 0.0.0.0/0 rule governs every source that can route to the associated network interface — not only the public internet — the rule effectively opened the database to any subnet, peered VPC, Transit Gateway attachment or VPN client with a route to that subnet, regardless of the PubliclyAccessible flag.

Impact

Any host with network reachability to the database’s subnet, including systems outside the intended application tier, could attempt to connect and authenticate against the database without prior network-level approval. This materially widens the blast radius if database credentials are ever leaked, reused or brute-forced, and it undermines the segmentation that later security reviews assumed was already enforced by the PubliclyAccessible flag. The exposure had persisted since the original migration and had not been detected by any automated check, because most public-exposure tooling checks the PubliclyAccessible flag rather than the underlying security group rules.

Diagnosis

Confirming the exposure requires reading the actual network path rather than trusting the PubliclyAccessible flag in isolation.

1. Confirm the flag and identify the attached security groups with aws rds describe-db-instances.
2. List the ingress rules on each attached security group with aws ec2 describe-security-groups and look for CidrIp entries of 0.0.0.0/0 on the database port.
3. Confirm which networks can route to the database subnet — peered VPCs, Transit Gateway attachments, VPN connections — with aws ec2 describe-route-tables.
4. In an isolated or non-production environment only, attempt a connection from a host outside the intended access list to confirm actual reachability before making any change.

{
  "IpProtocol": "tcp",
  "FromPort": 5432,
  "ToPort": 5432,
  "IpRanges": [ { "CidrIp": "0.0.0.0/0" } ]
}

This is the shape of rule to look for: a database port opened to 0.0.0.0/0 with no accompanying source security group restriction.

Correction

Scope the ingress rule to the specific source security group of the application tier that legitimately needs database access, and remove the 0.0.0.0/0 entry entirely.

• Capture the current rule set before changing anything, so the exact prior state is available if the correction needs to be reversed.
• Revoke the overly permissive rule rather than editing it in place, so the change is auditable.
• Authorise a new rule that references the application tier’s security group ID as the source, not a CIDR block.

Commands used in verified change windows, run by an operator with change authority:

• aws ec2 revoke-security-group-ingress --group-id <sg-id> --protocol tcp --port 5432 --cidr 0.0.0.0/0
• aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 5432 --source-group <app-tier-sg-id>

Validation

Validation must show that disallowed sources lose access while approved sources retain it.

1. Attempt a connection from a host outside the approved application-tier security group; the connection must fail to complete a handshake.
2. Attempt a connection from an approved application-tier host; it must succeed as before.
3. Re-run aws ec2 describe-security-groups against the database security group and confirm no ingress rule for the database port lists 0.0.0.0/0.

Rollback

If the corrected rule blocks traffic that later proves legitimate, restore access from the saved snapshot rather than guessing at a wider rule.

• Re-authorise the exact prior rule (protocol, port and source) from the pre-change snapshot using aws ec2 authorize-security-group-ingress.
• Treat any restored rule as temporary: open a tracked change to identify the correct source security group rather than leaving 0.0.0.0/0 in place.
• Do not consider the rollback complete until the legitimate source has been identified with VPC Flow Logs and a properly scoped rule has been reapplied.

Prevention

Preventing recurrence means treating PubliclyAccessible strictly as “no public IP” rather than “network-isolated”, and auditing security groups independently of that flag.

• Add an AWS Config rule (or equivalent) that flags any database security group with an ingress rule sourced from 0.0.0.0/0, independent of the PubliclyAccessible setting.
• Require infrastructure-as-code reviews to reference source security groups rather than CIDR blocks for database access rules.
• Tag temporary access rules with an explicit expiry and review them on a fixed schedule so migration-era rules cannot persist unnoticed.
• Include the security group ingress list, not just the PubliclyAccessible flag, in every periodic network exposure review.