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

Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:

> On Wed, Mar 6, 2019 at 12:09 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Mon, Mar 4, 2019 at 1:01 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > I think that there is no need to use the same key for both the spill
> > > files and WAL because only one process encrypt/decrypt spill files. We
> > > can use something like temporary key for that use case, which is used
> > > by only one process and lives during process lifetime (or transaction
> > > lifetime). The same is true for for other temporary files such as
> > > tuplesort and tuplestore, although maybe we need tricks for shared
> > > tuplestore.
> >
> > Agreed. For a shared tuplestore you need a key that is shared between
> > the processes involved, but it doesn't need to be the same as any
> > other key. For anything that is accessed by only a single process,
> > that process can just generate any old key and, as long as it's
> > secure, it's fine.
>
> Thank you for the advice. Understood.
>
> >
> > For the WAL, you could potentially create a new WAL record type that
> > is basically an encrypted wrapper around another WAL record. So if
> > table X is encrypted with key K1, then all of the WAL records for
> > table X are wrapped inside of an encrypted-record WAL record that is
> > encrypted with key K1. That's useful for people who want fine-grained
> > encryption only of certain data.
> >
> > But for people who want to just encrypt everything, you need to
> > encrypt the entire WAL stream, all SLRU data, etc. and that pretty
> > much all has to be one key (or sub-keys derived from that one key
> > somehow).
>
> 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.

--
Antonin Houska
https://www.cybertec-postgresql.com