apackin
commented
1 year ago Thank you for raising this essential feature request. Security is paramount, and having granular control (or even any control) over which IPs can access resources is a foundational element of modern cybersecurity practices.
Our team has been experiencing too many unauthorized access/scanning attempts to find vulnerability in our databases hosted with Heroku Postgres with little recourse using the existing tooling.
We would greatly appreciate escalating the priority of basic firewall capabilities for Heroku Postrges before suffering a breach or being forced to move to another service that includes a basic firewall. Upvoted OP.
jbrown-heroku
Required Terms
What service(s) is this request for?
Postgres
Tell us about what you're trying to solve. What challenges are you facing?
Heroku Postgres instances are exposed to the public internet. The only authentication required is a simple password. This goes against best practices established back in the early 2000s of protecting resources behind a firewall to the limited set of origins that need access.
Salesforce currently only offers IP-based restrictions to Postgres instances if you purchase the Private Spaces product. This is a 5x cost multiplier over the standard "public Heroku" pricing. It is out of reach for almost all organizations that use Heroku and puts Heroku at a disadvantage to AWS which has offered simple Security Groups since Day #1 of their RDS product line.
The most minimal feature that should be available is a DENY ALL rule with holes punched through for Dyno access to the Postgres instance. Heroku controls the IP range that the Dynos are deployed to, presumably using AWS's VPC functionality so this should be straightforward.
Users (admins) should then be able to whitelist specific IPv4 and IPv6 addresses/ranges for ingress from the outside world.
It is acknowledged that the nature of the Dyno framework will likely not allow Heroku to deny access to the Postgres instance from other applications than the one that is containing the Postgres instance (i.e. all Heroku apps, by all customers, will likely be able to reach the Postgres instance). This is not ideal but brute force password attacks from within the Heroku infrastructure seem to be less viable than from the outside world.
It is also stipulated that this feature request only applies to dedicated Postgres instances -- it's impractical/impossible to implement this for shared Postgres.