Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
От | Robert Haas |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Дата | |
Msg-id | CA+TgmoY6Nf3xpB2p1TCDqHJwpbVBUqzjrz1OgJb_YgkKgBs7AQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
|
Список | pgsql-hackers |
On Wed, Mar 6, 2019 at 6:32 PM Bruce Momjian <bruce@momjian.us> wrote: > On Wed, Mar 6, 2019 at 10:49:17AM -0800, Jeremy Schneider wrote: > > Might it make sense to generalize a little bit to secret management? It > > would be *great* if PostgreSQL could have a standard "secrets" API which > > could then use plugins or extensions to provide an internal > > implementation (software or hardware based) and/or plug in to an > > external secret management service, whether an OSS package installed on > > the box or some 3rd party service off the box. > > > > The two obvious use cases are encryption keys (mentioned here) and > > passwords for things like logical replication, FDWs, dblinks, other > > extensions, etc. Aside from adding new encryption key secrets, the way > > PostgreSQL handles the existing secrets it already has today leaves room > > for improvement. > > See this email for a possible implementation: > > https://www.postgresql.org/message-id/20190222035816.uozqvc4wjyag3pme@momjian.us I don't think that actually does what would be needed here. pgcryptokey can manage the keys themselves, but the secrets (i.e. passwords) that are used to access those keys are and must be revealed to everyone who uses them. I think we can imagine a secrets-management solution where that's not the case -- where you can access an encrypted database cluster or an encrypted table or an encrypted column or an FDW on another server without being able to access either the encryption key or the password for that key. Generally, I think our interest should be less in how secrets are stored inside the database than in how we can integrate with an external secrets-management solution, and I think that's what Jeremy is talking about here. I don't know exactly how that would work, but you can imagine having a way to tell an FDW "hey, there's a password for this server, but it's not stored here -- instead go fetch secret d41d8cd98f00b204e9800998ecf8427e" and the server does that and uses that password for the connection. But we don't need to solve the FDW problem for this effort to move forward. We do, however, need a solution that's good enough for whatever we want to do in terms of TDE. If we imagine whole-database TDE, then there's really only one secret, so there's not much to design. We can just have a command that is configured via a GUC that has to return the secret, and a user can put whatever script they like in there. But if we want to have fine-grained TDE where different bits are encrypted with different keys, then we have to have a way to request whichever key is needed for a certain bit of data. I don't know whether it's good enough to just run a script and pass it some identifier and let it return the corresponding key, or whether we should try to do something more ambitious than that in the hopes of meeting more use case. Sometimes the perfect can be the enemy of the good, but half-baked solutions are no good either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления:
Следующее
От: Robert HaasДата:
Сообщение: Re: Binary upgrade from <12 to 12 creates toast table for partitioned tables