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

Поиск
Список
Период
Сортировка
От Sehrope Sarkuni
Тема Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Дата
Msg-id CAH7T-aoyrneqy1xuhJJQx=Jq2oN4zDP0N7akYHWiMc50d7zCtA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Thu, Aug 8, 2019 at 6:31 PM Stephen Frost <sfrost@snowman.net> wrote:
Strictly speaking, that isn't actually crash recovery, it's physical
replication / HA, and while those are certainly nice to have it's no
guarantee that they're required or that you'd want to have the same keys
for them- conceptually, at least, you could have WAL with one key that
both sides know and then different keys for the actual data files, if we
go with the approach where the WAL is encrypted with one key and then
otherwise is plaintext.

I like the idea of separating the WAL key from the rest of the data files.  It'd all be unlocked by the MDEK and you'd still need derived keys per WAL-file, but disconnecting all that from the data files solves a lot of the problems with promoted replicas.

This would complicate cloning a replica as using a different MDEK would involve decrypting / encrypting everything rather than just copying the files. Even if that's not baked in a first version, the separation allows for eventually supporting that.
 
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/

 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sehrope Sarkuni
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Small patch to fix build on Windows