On Thu, Oct 03, 2019 at 10:40:40AM -0400, Stephen Frost wrote:
>Greetings,
>
>* Robert Haas (robertmhaas@gmail.com) wrote:
>> On Mon, Sep 30, 2019 at 5:26 PM Bruce Momjian <bruce@momjian.us> wrote:
>> > For full-cluster Transparent Data Encryption (TDE), the current plan is
>> > to encrypt all heap and index files, WAL, and all pgsql_tmp (work_mem
>> > overflow). The plan is:
>> >
>> > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#TODO_for_Full-Cluster_Encryption
>> >
>> > We don't see much value to encrypting vm, fsm, pg_xact, pg_multixact, or
>> > other files. Is that correct? Do any other PGDATA files contain user
>> > data?
>>
>> As others have said, that sounds wrong to me. I think you need to
>> encrypt everything.
>
>That isn't what other database systems do though and isn't what people
>actually asking for this feature are expecting to have or deal with.
>
>People who are looking for 'encrypt all the things' should and will be
>looking at filesytem-level encryption options. That's not what this
>feature is about.
>
That's almost certainly not true, at least not universally.
It may be true for some people, but a a lot of the people asking for
in-database encryption essentially want to do filesystem encryption but
can't use it for various reasons. E.g. because they're running in
environments that make filesystem encryption impossible to use (OS not
supporting it directly, no access to the block device, lack of admin
privileges, ...). Or maybe they worry about people with fs access.
If you look at how the two threads discussing the FDE design, both of
them pretty much started as "let's do FDE in the database".
>> I'm not sold on the comments that have been made about encrypting the
>> server log. I agree that could leak data, but that seems like somebody
>> else's problem: the log files aren't really under PostgreSQL's
>> management in the same way as pg_clog is. If you want to secure your
>> logs, send them to syslog and configure it to do whatever you need.
>
>I agree with this.
>
I don't. I know it's not an easy problem to solve, but it may contain
user data (which is what we manage). We may allow disabling that, at
which point it becomes someone else's problem.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
