Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
От | Joe Conway |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Дата | |
Msg-id | 9afccb0f-c668-a061-03de-cc91d3ff8b30@joeconway.com обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
On 7/10/19 2:38 AM, Masahiko Sawada wrote: > On Tue, Jul 9, 2019 at 9:01 PM Joe Conway <mail@joeconway.com> wrote: >> >> On 7/9/19 6:07 AM, Peter Eisentraut wrote: >> > On 2019-07-08 18:09, Joe Conway wrote: >> >> In my mind, and in practice to a >> >> large extent, a postgres tablespace == a unique mount point. >> > >> > But a critical difference is that in file systems, a separate mount >> > point has its own journal. >> >> While it would be ideal to have separate WAL, and even separate shared >> buffer pools, per tablespace, I think that is too much complexity for >> the first implementation and we could have a single separate key for all >> WAL for now. > > If we encrypt different tables with different keys I think we need to > encrypt WAL with the same keys as we used for tables, as per > discussion so far. And we would need to encrypt each WAL records, not > whole WAL 8k pages. That is not a technical requirement to be sure. We may decide we want that from a security perspective, but that point is debatable. There have been different goals expressed on this thread: 1. Keep user 1 from decrypting data A and user 2 from decrypting data B 2. Limit the amount of data encrypted with key Kn We can use K1 for A, K2 for B, and K3 for WAL and achieve goal #2. As Stephen pointed out, goal #1 would be great to have, but I am not sure there is consensus that it is required, at least not for the initial implementation. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Вложения
В списке pgsql-hackers по дате отправления: