RE: Threat models for DB cryptography (Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key) Management Service (KMS)

From: Nico Williams [mailto:nico(at)cryptonector(dot)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