Re: Threat models for DB cryptography (Re: [Proposal] Table-levelTransparent Data Encryption (TDE) and Key) Management Service (KMS)
От | Nico Williams |
---|---|
Тема | Re: Threat models for DB cryptography (Re: [Proposal] Table-levelTransparent Data Encryption (TDE) and Key) Management Service (KMS) |
Дата | |
Msg-id | 20180702221651.GC6568@localhost обсуждение исходный текст |
Ответ на | Re: Threat models for DB cryptography (Re: [Proposal] Table-levelTransparent Data Encryption (TDE) and Key) Management Service (KMS) (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Threat models for DB cryptography (Re: [Proposal] Table-levelTransparent Data Encryption (TDE) and Key) Management Service (KMS)
|
Список | pgsql-hackers |
On Mon, Jul 02, 2018 at 06:22:46PM +0900, Masahiko Sawada wrote: > On Fri, Jun 22, 2018 at 2:31 PM, Tsunakawa, Takayuki > <tsunakawa.takay@jp.fujitsu.com> wrote: > > From: Nico Williams [mailto:nico@cryptonector.com] > > > >> One shortcoming of relying on OS functionality for protection against > >> malicious storage is that not all OSes may provide such functionality. > >> This could be an argument for implementing full, transparent encryption > >> for an entire DB in the postgres server. Not a very compelling > >> argument, but that's just my opinion -- reasonable people could differ > >> on this. > > > > Yes, this is one reason I developed TDE in our product. And > > in-database encryption allows optimization by encrypting only user > > data. You're likely getting some things terribly wrong. E.g., integrity protection. Most likely you're getting a false sense of security. > Me too. In-database encryption is helpful in practice. I think 1) and > 2) seem to cover the thread models which the data encryption in > database needs to defend. Yes, but piecemeal encryption seems like a bad idea to me. Nico --
В списке pgsql-hackers по дате отправления: