Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?

From: Tony Xu <tony(dot)xu(at)rubrik(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?
Date: 2023-05-18 17:00:42
Message-ID: CACufLfzWQT9sQ6eaycvzehV76OeWKTtG7FTv5LVxpAEgJR7f4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks for the information, Andreas, Stephen.

Our use-case is for a multi-tenancy scenario - we are considering using
different databases to store different customer's data, however, for
cost-efficiency, we want to host them in the same server (to reduce the
CPU/mem idle time and to reduce the server management efforts). Now there
is a compliance related feature that we need to let our customer control
the KEK for their databases so they can rotate their KEKs independently, so
we cannot use one KEK for the whole PG server. Conceptually, different
databases are independent of each other, it also makes sense to allow them
to have completely independent encryption facilities?

Thanks,
Tony

On Thu, May 18, 2023 at 8:54 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Greetings,
>
> * Tony Xu (tony(dot)xu(at)rubrik(dot)com) wrote:
> > The FAQ (copied below) mentioned that native transparent data encryption
> > might be included in 16. Is it fair to assume that it will support
> database
> > level encryption, that is, we can use two encryption keys for two
> databases
> > in the same server, respectively? How can one verify that?
>
> The current work to include TDE in PG isn't contemplating a per-database
> key option. What's the use-case for that? Why do you feel that you'd
> need two independent keys? Also, the general idea currently is that
> we'll have one key provided by the user which will be a KEK and then
> multiple DEKs (different ones for relation data vs. temporary data vs.
> the WAL).
>
> If you're interested in TDE in PG, we could certainly use more folks
> being involved and working to push it forward.
>
> Thanks,
>
> Stephen
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Arora, Nick 2023-05-18 17:28:38 Unrecognized Node Type Warning
Previous Message Tom Lane 2023-05-18 16:36:41 Re: JSONB operator unanticipated behaviour