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 | 20190616215431.2iter54gddff2e63@development обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Список | pgsql-hackers |
On Sun, Jun 16, 2019 at 02:10:23PM -0400, Stephen Frost wrote: >Greetings, > >* Joe Conway (mail@joeconway.com) wrote: >> On 6/16/19 9:45 AM, Bruce Momjian wrote: >> > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: >> >> In any case it doesn't address my first point, which is limiting the >> >> volume encrypted with the same key. Another valid reason is you might >> >> have data at varying sensitivity levels and prefer different keys be >> >> used for each level. >> > >> > That seems quite complex. >> >> How? It is no more complex than encrypting at the tablespace level >> already gives you - in that case you get this property for free if you >> care to use it. > >Perhaps not surprising, but I'm definitely in agreement with Joe >regarding having multiple keys when possible and (reasonably) >straight-forward to do so. I also don't buy off on the OpenSSL >argument; their more severe issues certainly haven't been due to key >management issues such as what we're discussing here, so I don't think >the argument applies. > I'm not sure what exactly is the "OpenSSL argument" you're disagreeing with? IMHO Bruce is quite right that the risk of vulnerabilities grows with the complexity of the system (both due to implementation bugs and general design weaknesses). I don't think it's tied to the key management specifically, except that it's one of the parts that may contribute to the complexity. (It's often claimed that key management is one of the weakest points of current crypto systems - we have safe (a)symmetric algorithms, but safe handling of keys is an issue. I don't have data / papers supporting this claim, I kinda believe it.) Now, I'm not opposed to eventually implementing something more elaborate, but I also think just encrypting the whole cluster (not necessarily with a single key, but with one master key) would be enough for vast majority of users. Plus it's less error prone and easier to operate (backups, replicas, crash recovery, ...). But there's about 0% chance we'll get that in v1, of course, so we need s "minimum viable product" to build on anyway. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: