On Fri, Jun 22, 2018 at 2:31 PM, Tsunakawa, Takayuki <tsunakawa.ta...@jp.fujitsu.com> wrote: > 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. >
Me too. In-database encryption is helpful in practice. I think 1) and 2) seem to cover the thread models which the data encryption in database needs to defend. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
