From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Moon, Insung" <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Date: | 2019-03-01 21:23:31 |
Message-ID: | CA+TgmobkBAn73ay2ZEOAtLxTTNa0xP-NNNL4wp53Q7DTqvXdYg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 1, 2019 at 3:52 PM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> wrote:
> The Cybertec proposed patches are doing the encryption at the instance
> level, AFAIK, the current discussion is also trying to reduce the scope of the
> encryption to object level like (tablesapce, database or table) to avoid the encryption
> performance impact for the databases, tables that don't need it.
The trick there is that it becomes difficult to figure out which keys
to use for certain things. For example, you could say, well, this WAL
record is for a table that is encrypted with key 123, so let's use key
123 to encrypt the WAL record also. So far, so good. But then how do
you encrypt, say, a logical decoding spill file? That could have data
in it mixed together from multiple relations, IIUC. Or what do you do
about SLRUs or other global structures? If you just exclude that
stuff from the scope of encryption, then you aren't helping the people
who want to Just Encrypt Everything.
Now that having been said I bet a lot of people would find it pretty
cool if we could make this work on a per-table basis. And I'm not
opposed to that. I just think it's really hard.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-03-01 21:27:47 | Re: Refactoring the checkpointer's fsync request queue |
Previous Message | Robert Haas | 2019-03-01 21:17:15 | Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3 |