From: Nico Williams [mailto:n...@cryptonector.com] > Let's start with a set of threat models then. I'll go first:
Thank you so much for summarizing the current situation. I'd appreciate it if you could write this on the PostgreSQL wiki, when the discussion has settled somehow. > - local adversaries (addressed by standard OS user process isolation) Does this also mean that we don't have to worry about the following? * unencrypted data in the server process memory and core files * passwords in .pgpass and recovery.conf (someone familiar with PCI DSS audit said this is a problem) * user data in server logs > One shortcoming of relying on OS functionality for protection against > malicious storage is that not all OSes may provide such functionality. > This could be an argument for implementing full, transparent encryption > for an entire DB in the postgres server. Not a very compelling > argument, but that's just my opinion -- reasonable people could differ > on this. Yes, this is one reason I developed TDE in our product. And in-database encryption allows optimization by encrypting only user data. > So I think for (3) the best answer is to just not have that problem: > just reduce and audit admin access. > > Still, if anyone wants to cover (3), I argue that PG gives you > everything you need right now: FDW and pgcrypto. Just build a > solution where you have a PG server proxy that acts as a smart > client to untrusted servers: Does sepgsql help? Should a malfunctioning or buggy application be considered as as a threat? That's what sql_firewall extension addresses. Regards Takayuki Tsunakawa
