Re: WIP: Data at rest encryption - Mailing list pgsql-hackers

From Ants Aasma
Subject Re: WIP: Data at rest encryption
Date
Msg-id CA+CSw_tREjU3Y20+91tHXLcORvKxRYNXKCMjwfLxKbK6L89fow@mail.gmail.com
Whole thread Raw
In response to Re: WIP: Data at rest encryption  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Mon, Jun 13, 2016 at 5:17 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Sun, Jun 12, 2016 at 4:13 PM, Ants Aasma <ants.aasma@gmail.com> wrote:
>>> I feel separate file is better to include the key data instead of pg_control
>>> file.
>>
>> I guess that would be more flexible. However I think at least the fact
>> that the database is encrypted should remain in the control file to
>> provide useful error messages for faulty backup procedures.
>
> Another possibility could be always to do some encryption at data-type
> level for text data. For example I recalled the following thing while
> going through this thread:
> https://github.com/nec-postgres/tdeforpg
> Though I don't quite understand the use for encrypt.enable in this
> code... This has the advantage to not patch upstream.

While certainly possible, this does not cover the requirements I want
to satisfy - user data never gets stored on disk unencrypted without
making changes to the application or schema. This seems to be mostly
about separating administrator roles, specifically that centralised
storage and backup administrators should not have access to database
contents. I see this as orthogonal to per column encryption, which in
my opinion is better done in the application.

Regards,
Ants Aasma



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Why we don't have checksums on clog files
Next
From: Albe Laurenz
Date:
Subject: Re: Prepared statements and generic plans