Horton

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

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Bruce Momjian <bruce@momjian.us>, Joe Conway <mail@joeconway.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Antonin Houska <ah@cybertec.at>, Haribabu Kommi <kommi.haribabu@gmail.com>, "Moon, Insung" <Moon_Insung_i3@lab.ntt.co.jp>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-07-05T20:05:22Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revamp the WAL record format.

On 2019-Jul-05, Stephen Frost wrote:

> I had been specifically thinking of tablespaces because we might be able
> to do something exactly along these lines- keep which tablespace the
> data is in directly in the WAL (and not encrypted), but then have the
> data itself be encrypted, and with the key for that tablespace.

Hmm, I was imagining that the user-level data is encrypted, while the
metadata such as the containing relfilenode is not encrypted and thus
can be read by system processes such as checkpointer or WAL-apply
without needing to decrypt anything.  Maybe I'm just lacking imagination
for an attack that uses that unencrypted metadata, though.

> Splitting the WAL by tablespace would be even nicer, of course... :)

Hmm, I think you would have to synchronize the apply anyway (i.e. not
replay in one tablespace ahead of a record in another tablespace with an
earlier LSN.)  What are you thinking are the gains of doing that, anyway?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services