From: Stephen Frost <sfrost@snowman.net>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Subject: Re: Proposed patch for key managment
Date: Wed, 9 Dec 2020 17:18:37 -0500
Message-ID: <20201209221837.GH16415@tamriel.snowman.net> (raw)
In-Reply-To: <86B6F63B-9594-44F4-AFD8-144BA7FFBC9E@yesql.se>
References: <20201202213814.GG20285@momjian.us>
<86B6F63B-9594-44F4-AFD8-144BA7FFBC9E@yesql.se>
Greetings,
* Daniel Gustafsson (daniel@yesql.se) wrote:
> > On 2 Dec 2020, at 22:38, Bruce Momjian <bruce@momjian.us> wrote:
> > Attached is a patch for key management, which will eventually be part of
> > cluster file encryption (CFE), called TDE (Transparent Data Encryption)
> > by Oracle.
>
> The attackvector protected against seems to be operating systems users
> (*without* any legitimate database access) gaining access to the data files.
That isn't the only attack vector that this addresses (though it is one
that this is envisioned to help with- to wit, someone rsync'ing the DB
directory). TDE also helps with traditional data at rest requirements,
in environments where you don't trust the storage layer to handle that
(for whatever reason), and it's at least imagined that backups with
pg_basebackup would also be encrypted, helping protect against backup
theft.
There's, further, certainly no shortage of folks asking for this.
> Such an attacker would also gain access to postgresql.conf and therefore may
> have the cluster passphrase command in case it's stored there. That would
> imply the attacker is likely (or perhaps better phrased "not entirely
> unlikely") to be able to run that command and decrypt the data *iff* there is
> no interactive/2fa aspect to the passphrase command. Is that an accurate
> interpretation? Do Oracle TDE et.al use a similar setup where an database
> restart require manual intervention?
This is very much an 'it depends' as other products have different
capabilities in this area. The most similar implementation to what is
being contemplated for PG today would be the big O's "tablespace" TDE,
which offers options of either "Password-based software keystores" (you
have to provide a password when you want to bring that tablespace
online), or "Auto-login software keystores" (there's a "system generated
password" that's used to encrypt the keystore, which seems to be
more-or-less the username and hostname of the system), or HSM based
options. As such, a DB restart might require manual intervention (if
the keystore is password based, or an HSM that requires manual
involvement) or it might not (auto-login keystore of some kind).
> Admittedly I haven't read the other threads on the topic so if it's discussed
> somewhere else then I'd appreciate a whacking with a cluestick.
I'm sure it was, but hopefully the above helps you avoid having to dig
through the very (very (very)) long threads on this topic.
Thanks,
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, daniel@yesql.se, bruce@momjian.us, masahiko.sawada@2ndquadrant.com
Subject: Re: Proposed patch for key managment
In-Reply-To: <20201209221837.GH16415@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox