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

On Thu, May 9, 2019 at 05:49:12PM +0900, Masahiko Sawada wrote:
> In terms of keys, one advantage could be that we have less keys with
> per-tablespace keys.
>
> Let me briefly explain the current design I'm thinking. The design
> employees 2-tier key architecture. That is, a database cluster has one
> master key and per-tablespace keys which are encrypted with the master
> key before storing to disk. Each tablespace keys are generated
> randomly inside database when CREATE TABLESPACE. The all encrypted
> tablespace keys are stored together with the master key ID to the file
> (say, $PGDATA/base/pg_tblsp_keys). That way, the startup process can
> easily get all tablespace keys and the master key ID before starting
> recovery, and therefore can get the all decrypted tablespace keys. The
> reason why it doesn't store per-tablespace keys in a column of
> pg_tabelspace is that we also encrypt pg_tablespace with the
> tablespace key. We could take a way to not encrypt only pg_tablespace,
> however it instead would require to scan pg_tablespace before
> recovery, and eventually we would need to not encrypt pg_attribute
> that should be encrypted.
>
> During the recovery I'm also thinking the idea you suggested; wrapper
> WAL records have tablespace OID that is the lookup key for tablespace
> key and the startup process can get the tablespace key.
>
> Given that the above design less data keys is better. Obviously
> per-tablespace keys are less than per-table keys. And even if we
> employee per-tablespace keys we can allow user to specify per-table
> encryption by using the same encryption key within the tablespace.
>
> FYI one advantage of per-tablespace encryption from user perspective
> would be less conversion when database migration. Using
> default_tablespace parameter we need less modification of create table
> DDL.

I think we need to step back and see what we want to do. There are six
levels of possible encryption:

1. client-side column encryption
2. server-side column encryption
3. table-level
4. database-level
5. tablespace-level
6. cluster-level

1 & 2 encrypt the data in the WAL automatically, and option 6 is
encrypting the entire WAL. This leaves 3-5 as cases where there will be
mismatch between the object-level encryption and WAL. I don't think it
is very valuable to use these options so reencryption will be easier.
In many cases, taking any object offline might cause the application to
fail, and having multiple encrypted data keys active will allow key
replacement to be done on an as-needed basis.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +