On Fri, Jun 22, 2018 at 2:31 PM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> 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.
>
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