Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
От | Tomas Vondra |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Дата | |
Msg-id | c8fb856b-638a-dd69-fe77-430f9b1ba929@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
|
Список | pgsql-hackers |
On 3/4/19 6:40 AM, Masahiko Sawada wrote: > On Sat, Mar 2, 2019 at 5:27 AM Robert Haas <robertmhaas@gmail.com> wrote: >> >> On Thu, Feb 7, 2019 at 3:28 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: >>> WAL encryption will follow as an additional feature. >> >> I don't think WAL encryption is an optional feature. You can argue >> about whether it's useful to encrypt the disk files in the first place >> given that there's no privilege boundary between the OS user and the >> database, but a lot of people seem to think it is and maybe they're >> right. However, who can justify encrypting only SOME of the disk >> files and not others? I mean, maybe you could justify not encryption >> the SLRU files on the grounds that they probably don't leak much in >> the way of interesting information, but the WAL files certainly do -- >> your data is there, just as much as in the data files themselves. >> > > Agreed. > >> To be honest, I think there is a lot to like about the patches >> Cybertec has proposed. Those patches don't have all of the fancy >> key-management stuff that you are proposing here, but maybe that >> stuff, if we want it, could be added, rather than starting over from >> scratch. It seems to me that those patches get a lot of things right. >> In particular, it looked to me when I looked at them like they made a >> pretty determined effort to encrypt every byte that might go down to >> the disk. It seems to me that you if you want encryption, you want >> that. >> > > Agreed. I think the patch lacks the key management stuff: 2-tier key > architecture and integration of postgres with key management systems. > I'd like to work together and can propose the patch of key management > stuff to the proposed patch. > Sounds like a plan. It'd be nice to come up with a unified version of those two patches, combining the good pieces from both. I wonder how other databases deal with key management? Surely we're not the first/only database that tries to do transparent encryption, so perhaps we could learn something from others? For example, do they use this 2-tier key architecture? How do they do key management? etc. I don't say we should copy from them, but it'd allow us to (a) avoid making the same mistakes and (b) build a solution the users are already somewhat familiar with. May I suggest creating a page on the PostgreSQL wiki, explaining the design and updating it as the discussion develops? It's rather difficult to follow all the different sub-threads, and IIRC some larger patches used that successfully for this purpose. See for example: * https://wiki.postgresql.org/wiki/Parallel_External_Sort * https://wiki.postgresql.org/wiki/Parallel_Internal_Sort regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления:
Следующее
От: Alvaro HerreraДата:
Сообщение: Re: pg_partition_tree crashes for a non-defined relation