RE: [Proposal] Table-level Transparent Data Encryption (TDE) andKey Management Service (KMS)

Поиск
Список
Период
Сортировка
От Smith, Peter
Тема RE: [Proposal] Table-level Transparent Data Encryption (TDE) andKey Management Service (KMS)
Дата
Msg-id 201DD0641B056142AC8C6645EC1B5F62014B8796BB@SYD1217
обсуждение исходный текст
Ответ на Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
> -----Original Message-----
> From: Stephen Frost <sfrost@snowman.net> Sent: Friday, 16 August 2019 11:01 AM

> Having direct integration with a KMS would certainly be valuable, and I don't see a reason to deny users that option
ifsomeone would like to spend time 
> implementing it- in addition to a simpler mechanism such as a passphrase command, which I believe is what was being
suggestedhere. 

Yes. We recently made an internal PoC for FEP to enable it to reach out to AWS KMS whenever the MKEY was rotated or
TDKEYwas created. This was achieved by inserting some hooks in our TDE code - these hooks were implemented by a
contrib-moduleloaded by the shared_preload_libraries GUC variable. So when no special "tdekey_aws" module was loaded,
ourTDE functionality simply reverts to its default (random) MDEK/TDEK keys.  

Even if OSS community chooses not to implement any KMS integration, the TDE design could consider providing hooks in a
fewappropriate places to make it easy for people who may need to add their own later. 

Regards,
---
Peter Smith
Fujitsu Australia




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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Resume vacuum and autovacuum from interruption and cancellation
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Patch: New GUC prepared_statement_limit to limit memory usedby prepared statements