Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/11/2018 11:22 AM, Masahiko Sawada wrote:
> On Fri, May 25, 2018 at 8:41 PM, Moon, Insung
> <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Hello Hackers,
>>
>> This propose a way to develop "Table-level" Transparent Data
>> Encryption (TDE) and Key Management Service (KMS) support in
>> PostgreSQL.
>>
>> ...
>
> As per discussion at PGCon unconference, I think that firstly we
> need to discuss what threats we want to defend database data against.
> If user wants to defend against a threat that is malicious user who
> logged in OS or database steals an important data on datbase this
> design TDE would not help. Because such user can steal the data by
> getting a memory dump or by SQL. That is of course differs depending
> on system requirements or security compliance but what threats do
> you want to defend database data against? and why?
>

I do agree with this - a description of the threat model needs to be
part of the design discussion, otherwise it's not possible to compare it
to alternative solutions (e.g. full-disk encryption using LUKS or using
existing privilege controls and/or RLS).

TDE was proposed/discussed repeatedly in the past, and every time it
died exactly because it was not very clear which issue it was attempting
to solve.

Let me share some of the issues mentioned as possibly addressed by TDE
(I'm not entirely sure TDE actually solves them, I'm just saying those
were mentioned in previous discussions):

1) enterprise requirement - Companies want in-database encryption, for
various reasons (because "enterprise solution" or something).

2) like FDE, but OS/filesystem independent - Same config on any OS and
filesystem, which may make maintenance easier.

3) does not require special OS/filesystem setup - Does not require help
from system adminitrators, setup of LUKS devices or whatever.

4) all filesystem access (basebackups/rsync) is encrypted anyway

5) solves key management (the main challenge with pgcrypto)

6) allows encrypting only some of the data (tables, columns) to minimize
performance impact

IMHO it makes sense to have TDE even if it provides the same "security"
as disk-level encryption, assuming it's more convenient to setup/use
from the database.

> Also, if I understand correctly, at unconference session there also
> were two suggestions about the design other than the suggestion by
> Alexander: implementing TDE at column level using POLICY, and
> implementing TDE at table-space level. The former was suggested by
> Joe but I'm not sure the detail of that suggestion. I'd love to hear
> the deal of that suggestion. The latter was suggested by
> Tsunakawa-san. Have you considered that?
>
> You mentioned that encryption of temporary data for query processing
> and large objects are still under the consideration. But other than
> them you should consider the temporary data generated by other
> subsystems such as reorderbuffer and transition table as well.
>

The severity of those limitations is likely related to the threat model.
I don't think encrypting temporary data would be a big problem, assuming
you know which key to use.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services