On Mon, Sep 30, 2019 at 05:40:52PM -0400, Bruce Momjian wrote:
>For plan for full-cluster Transparent Data Encryption (TDE) is here:
>
> https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#TODO_for_Full-Cluster_Encryption
>
>The values it has, I think, are:
>
>* encrypts data for anyone with read-access to the file system (but not
> memory)
>
> * I think write access would allow access to the encryption keys
> by modifying postgresql.conf or other files
>
> * This is particularly useful if the storage is remote
>
>* encrypts non-logical/non-pg_dump-like backups
>
>* fulfills several security compliance requirements
>
>* encrypts storage
>
Maybe. I think this is approaching the problem from the wrong angle.
Encryption is more a means of achieving something. OK, for compliance
purposes it's useful to be able to tick "encryption" checkbox. But other
than that, people really care about threat models and how encryption
improves them (or does not).
So I think it'd be valuable to improve the "thread models" section on
that wiki page, with more detailed cases. We need to explain what
capabilities the attacker has (can he read files?can he interact with
the database? can he read memory? ..) and then explain how that works
with encrypted cluster.
>* perhaps easier to implement than file system encryption
>
Not sure. IMO filesystem encryption is fairly simple to use, to the
extent that it's hard to beat. The problem is usually people can't use
it for various reasons - lack of support on their OS, no access to the
block device, problems with obtaining the privileges etc.
Having it built into the database menas you can sidestep most of those
issue (e.g. you can deploy it as a DBA, on arbitrary OS, ...).
Plus it allows features you can't easily achieve with fs encryption,
because the filesystem only sees opaque data files. So having keys per
database/user/... is easier from within the database.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services