Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) - Mailing list pgsql-hackers

On Mon, Jul  8, 2019 at 06:04:28PM +0900, Masahiko Sawada wrote:
> On Sun, Jul 7, 2019 at 1:05 AM Bruce Momjian <bruce@momjian.us> wrote:
> > What about referential integrity constraints that need to check primary
> > keys in the encrypted tables?  I also don't see a way of delaying that,
> > and if you can't do referential integrity into the encrypted tables, it
> > reduces the value of having encrypted data in the same database rather
> > than in another database or cluster?
> 
> I just thought that PostgreSQL's auxiliary processes such as
> autovacuum, startup, checkpointer, bgwriter should always be able to
> access all keys because there are already in inside database. Even
> today these processes don't check any privileges when accessing to
> data. What security threats we can protect data from by requiring
> privileges even for auxiliary processes? If this is a security problem
> isn't it also true for cluster-wide encryption? I guess that processes
> who have an access privilege on the table can always get the
> corresponding encryption key. And any processes cannot access an
> encryption key directly without accessing to a database object.

Well, see my list of three things that users want in an earlier email:

    https://www.postgresql.org/message-id/20190706160514.b67q4f7abcxfdahk@momjian.us

When people are asking for multiple keys (not just for key rotation),
they are asking to have multiple keys that can be supplied by users only
when they need to access the data.  Yes, the keys are always in the
datbase, but the feature request is that they are only unlocked when the
user needs to access the data.  Obviously, that will not work for
autovacuum when the encryption is at the block level.

If the key is always unlocked, there is questionable security value of
having multiple keys, beyond key rotation.

> > I still feel we have not clearly described what the options are:
> >
> > 1.  Encrypt everything
> >
> > 2.  Encrypt only some tables (for performance reasons), and use only one
> > key, or use multiple keys to allow for key rotation.  All keys are
> > always unlocked.
> >
> > 3.  Encrypt only some tables with different keys, and the keys are not
> > always unlocked.
> >
> > As Tomas already stated, using tablespaces to distinguish encrypted from
> > non-encrypted tables doesn't make sense since the file system used for
> > the storage is immaterial to the encryptions status. An easier way would
> > be to just add a bit to WAL that would indicate if the rest of the WAL
> > record is encrypted, though I doubt the performance boost is worth the
> > complexity.
> 
> Okay, instead of using tablespaces we can create groups grouping
> tables being encrypted with the same key. I think the one of the most
> important point here is to provide a granular encryption feature and

Why is this important?  What are you trying to accomplish?

> have less the number of keys in database cluster, not to provide per
> tablespace encryption feature. I'm not going to insist it should be
> per tablespace encryption.

It is unclear which item you are looking for.  Which number are you
suggesting from the three listed above in the email URL?

-- 
  Bruce Momjian  <bruce@momjian.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 +