From: Nico Williams [mailto:nico@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
onlyuser 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
