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

On Sat, Mar 9, 2019 at 3:08 AM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
> On 3/8/19 5:38 PM, Antonin Houska wrote:
> > Antonin Houska <ah(at)cybertec(dot)at> wrote:
> >
> >> Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >>
> >>> Agreed.
> >>>
> >>> For the WAL encryption, I wonder if we can have a encryption key
> >>> dedicated for WAL. Regardless of keys of tables and indexes all WAL
> >>> are encrypted with the WAL key. During the recovery the startup
> >>> process decrypts WAL and applies it, and then the table data will be
> >>> encrypted with its table key when flushing. So we just control the
> >>> scope of encryption object: WAL of tables and indexes etc or
> >>> everything.
> >>
> >> My point of view is that different key usually means different user. The user
> >> who can decrypt WAL can effectively see all the data, even though another user
> >> put them (encrypted with another key) into tables. So in this case, different
> >> keys don't really separate users in terms of data access.
> >
> > Please ignore what I said here. You probably meant that the WAL is both
> > encrypted and decrypted using the same (dedicated) key.
> >
>
> I think this very much depends on the threat model. If the encryption is
> supposed to serve as a second access control layer (orthogonal to the
> ACL stuff we already have), then a single WAL key may not be sufficient.
>

Agreed.

> I may be misunderstanding the whole scheme, but it seems to me features
> like logical decoding do require knowledge of the WAL key. So sessions
> performing logical decoding (which are regular user sessions) would know
> the WAL key, which gives them the ability to decode everything.

Yeah, currently logical decoding requires the super user privilege and
it can decode everything if they have regardless of per table
privileges. So the session performing logical decoding will take the
WAL key and decode WAL with it, and can use the WAL key or temporary
key for spilled files.

I'm trying to implement TDE while not changing the current access
control behavior. That is, if a user has an access privilege of a
table he/she can access it as same as before and encrypts and decrypts
it transparently. I've considered a design of having two layers the
encryption and access control to access data; users might see
encrypted data if they have a access privilege but not have the
decryption privilege. But I think there would be two problems: the
access control layer will get complex and applications need to be
tolerate getting encrypted data.

>
> So if the threat model includes insider thread (someone with access to a
> subset of data, gaining unauthorized access to everything), then this
> would be an issue. Such bad actor might obtain access to WAL archive, or
> possibly just copy the WAL segments on his own ...
>

So I think there is no such insider thread problem, right?

We can think the threat simply, the access control is not changed. The
current design cannot prevent data from theft by malicious user who
have access privileges. That can be addressed by auditing or more
fine-grained access control.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center