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

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.

>
> > > Or what do you do
> > > about SLRUs or other global structures? If you just exclude that
> > > stuff from the scope of encryption, then you aren't helping the people
> > > who want to Just Encrypt Everything.
> >
> > Why do people want to just encrypt everything? For satisfying some
> > security compliance?
>
> Yeah, I think so. Perhaps an encrypted filesystem is a better way to
> go, but some people want something that is built into the database
> server. The motivation seems to be mostly that they have a compliance
> requirement -- either the database itself encrypts everything, or they
> cannot use the software.
>

Understood. Maybe we need a option to control encrypting database
including all meta data or excluding them.

Regards,

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