Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
| От | Moon, Insung |
|---|---|
| Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
| Дата | |
| Msg-id | CAEMmqBus++m=XJK_mzSJwcbV1tOjiyEf5x55bBdwyOAY-cuvRg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Bruce Momjian <bruce@momjian.us>) |
| Список | pgsql-hackers |
Dear Hackers.
It's been a long time since I sent a mail.
On Sat, Aug 24, 2019 at 9:27 AM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Aug 23, 2019 at 10:35:17AM -0400, Stephen Frost wrote:
> > Agreed. The features of other databases are a clear source for what we
> > should consider and run through the useful/reasonable filter.
>
> Following on from that- when other databases don't have something that
> we're thinking about implementing, maybe we should be contemplating if
> it really makes sense as a requirement for us.
Yes, that's a good point.
> Specifically in this case- I went back and tried to figure out what
> other database systems have an "encrypt EVERYTHING" option. I didn't
> have much luck finding one though. So I think we need to ask ourselves-
> the "check box" that we're trying to check off with TDE, do the other
> database system check that box? If so, then it looks like the "check
> box" isn't actually "encrypt EVERYTHING", it's more along the lines of
> "make sure all regular user data is encrypted automatically" or some
> such, and that's a very different requirement, which seems to be
> answered by the other systems by having a KMS + tablespace/database
> level encryption. We certainly shouldn't be putting a lot of effort
> into building something that is either overkill or won't be interesting
> to users due to limitations like "have to take the entire cluster
> offline to re-key it".
Well, I think they might do that to reduce encryption overhead. I think
tests have shown that is not an issue, but we will need to test further.
I am not sure of the downside of encrypting everything, since it leaks
the least information and has a minimal user API and code impact. What
is the value of encrypting only the user rows? Better key control?
Maybe my think can be very wrong. Please understand.
I think that the value of encrypting with granularity rather than
encrypting of all clusters. Maybe it is advantageous to manageability.
Of course, encrypting of all clusters is an excellent choice because
it has minimal impact on the code, and perhaps simply to implement and
management APIs.
But what about Database user or DBA? I thought of the example below.
Suppose we have a system with multiple tenants
(Tenant here means table, tablespace, or database.) in one database cluster.
(I think it's similar to a cloud service. I think this is going to be a common case in the future.)
(I think it's similar to a cloud service. I think this is going to be a common case in the future.)
We need to encrypt for tenant A and not need encryption for tenant B.
In this case, is there a reason to encrypt until tenant B?
It is a great advantage that the user, which is a characteristic of TDE,
is encrypted without considering encryption.
But there is no reason to encrypt even a tenant that does not require encryption.
And another example, in terms of key management, I thought to encrypt with
But there is no reason to encrypt even a tenant that does not require encryption.
And another example, in terms of key management, I thought to encrypt with
granularity was a good choice (especially key rotation).
A special situation where A and B tenants need encryption and A tenant needs to
rotate the key once every three months. And B tenant needs to rotate the key once a year.
( Of course, maybe it is a very rare case.)
If we encrypt all clusters and do not manage of granularity encryption keys by tenants.
And when they run to A tenant key rotated, the B tenant is also rotated together,
which can cause operational discomfort.
Of course, encrypting of all clusters and creating the managing of
granularity keys for each tenant will solve the problem.
But if we are implementing this part, I think it's the same as
But if we are implementing this part, I think it's the same as
the implementation of granular encryption.
Best Regards.
Moon.
> Now, that KMS has to be encrypted using a master key, of course, and we
> have to make sure that it is able to survive across a crash, and it'd
> sure be nice if it was indexed. One option for such a KMS would be
> something entirely external (which could potentially just be another PG
> database or something) but it'd be nice if we had something built-in.
> We might also want it to be replicated (or maybe we don't, as was
> discussed on the call, to allow for a replica to use an independent set
> of keys- of course that leads to issues with pg_rewind and such though).
I think the replica could use a different key for the relations, but the
WAL key would have to be the same.
> Anything built-in does seem like it'd be a fair bit of work to get it to
> address those requirements, but that does seem to be what the other
> database systems have done. Unfortunately, their documentation doesn't
> seem to really say exactly what they've done to address that.
I do like they pgcrypto key support to be per-database so pg_dump will
dump the data encrypted, and with its locked keys.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Justin PryzbyДата:
Сообщение: Re: pg11.5: ExecHashJoinNewBatch: glibc detected...double free orcorruption (!prev)