Possibly stupid questions. (1) When is operating your own PostgreSQL instance desirable? (2) Isn’t this equivalent to running an RDS instance in its own VPC with public access turned off and only allowing comms with app VPC?
Securing a Postgres Database
91–100 of 104 posts
Re: Securing a Postgres Database
#92Possibly stupid questions. (1) When is operating your own PostgreSQL instance desirable? (2) Isn’t this equivalent to running an RDS instance in its own VPC with public access turned off and only allowing comms with app VPC?
Re: Securing a Postgres Database
#93It feels weird to me that this blog post would suggest acquiring Let's Encrypt certificates for certificate encryption. While it's great for something public facing that needs your CA installed by default, creating certificates for things that you probably don't want being public - like your database backend - just makes it more discoverable. For example, certificate transparency logs mean that anybody can see what c…
I don’t understand the value of Certificate Transparency: I could see triggering an email to the owner of a domain every time a certificate is issued, but what’s the value of a public log? It seems to me that it just increases attack surface of your services.
Re: Securing a Postgres Database
#94Earlier quoted context omitted.
The worst of both worlds: not accessible from the outside, yet insecure because it’s accessible to any user on the inside. What is the advantage of listening on localhost compared to using a socket, with free access control?
> What is the advantage of listening on localhost compared to using a socket, with free access control? Can install and use right away locally without figuring out where your distro puts the socket at. Edit: Also no need to play with permissions of the socket in such a case.
Re: Securing a Postgres Database
#95> log_statement = all Is this something people really do? Wouldn't these logs be enormous and/or potentially leak unwanted information?
So we use it in development but not in production.
Re: Securing a Postgres Database
#96For blog post masquerading as a how-to on securing Postgres, the fact the article only fleetingly mentions the word "function" once is not cool.
One of the biggest things you can do for Postgres (or any database for that matter) is enforce the use of stored procedures ("functions" in PG-speak) rather than direct SQL queries.
SQL Injection attacks are common as muck. Stored procedures are a quick and easy way to mitigate them.
Stored procedures also have the added bonus of allowing the DBA to remain in control and ensure a higher quality of SQL query rather than upstream devs sending all manner of unoptimised SQL queries.
Re: Securing a Postgres Database
#97Re: Securing a Postgres Database
#98Re: Securing a Postgres Database
#99Earlier quoted context omitted.
I mean, it's likely you have some other stored procedure that does enumerate users, for use by app adminstrators. Ideally it doesn't return password hashes though, since they are really not useful for humans to look at. Also ideally, the admin stored procedures are not executable by the end-user app.
Usually application uses connection pool to connect with database server. I'm not sure if that pattern could be used, when different requests need different database roles.
It's not as simple, you still have to make sure public backend user can't access web logs, that may reveal session id of an backoffice admin account or other information useful for breaking in other parts of the website.
Eventually, the attacker will gain access, but this is useful to slow him down enough, so there's a chance he'll give up, or you notice something suspicious.
For example pgbouncer allows you to connect via multiple roles/credentials to a database. It's just about how you configure your pool.
Re: Securing a Postgres Database
#100Earlier quoted context omitted.
> Not sure why the author does not advocate this. Probably because the blog post is an advertisement for their product, which already allows you to implement bastion hosts as you describe. From the bottom: > Databases do not need to be exposed on the public Internet and can safely operate in air-gapped environments using Teleport’s built-in reverse tunnel subsystem.
Did not catch that. Sneaky self promotion there :) Not sure what there reverse tunnel product is, but a bastion host is super easy to implement, just spin up an ec2 and walla. Curious as to what value they are providing
https://www.collinsdictionary.com/dictionary/french-english/...