Greetings,
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Tue, Oct 1, 2019 at 12:19 PM Bruce Momjian <bruce@momjian.us> wrote:
> > Just to give more detail. Initially, there was a desire to store keys
> > in only one place, either in the file system or in database tables.
> > However, it became clear that the needs of booting the server and crash
> > recovery required file system keys, and per-user/db keys were best done
> > at the SQL level, so that indexing can be used, and logical dumps
> > contain the locked keys. SQL-level storage allows databases to be
> > completely independent of other databases in terms of key storage and
> > usage.
>
> Wait, we're going to store the encryption keys with the database? It
> seems like you're debating whether to store your front door keys under
> the doormat or in a fake rock by the side of the path, when what you
> really ought to be doing is keeping them physically separated from the
> house, like in your pocket or your purse.
This isn't news and shouldn't be shocking- databases which support TDE
all have a vaulting system for managing the keys and, yes, that's stored
with the database.
> It seems to me that the right design is that there's a configurable
> mechanism for PostgreSQL to request keys from someplace outside the
> database, and that other place is responsible for storing the keys
> securely and not losing them. Probably, it's a key-server of some kind
> running on another machine, but if you really want you can do
> something insecure instead, like getting them from the local
> filesystem.
I support the option to have an external vault that's used, but I don't
believe that should be a requirement and I don't think that removes the
need to have a vaulting system of our own, so we can have a stand-alone
TDE solution.
> I admit I haven't been following the threads on this topic, but this
> just seems like a really strange idea.
It's not new and it's how TDE works in all of the other database systems
which support it.
Thanks,
Stephen