RE: Threat models for DB cryptography (Re: [Proposal] Table-levelTransparent Data Encryption (TDE) and Key) Management Service (KMS)
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: Threat models for DB cryptography (Re: [Proposal] Table-levelTransparent Data Encryption (TDE) and Key) Management Service (KMS) |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FA23388@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Threat models for DB cryptography (Re: [Proposal] Table-levelTransparent Data Encryption (TDE) and Key) Management Service (KMS) (Nico Williams <nico@cryptonector.com>) |
Ответы |
Re: Threat models for DB cryptography (Re: [Proposal] Table-levelTransparent Data Encryption (TDE) and Key) Management Service (KMS)
Re: Threat models for DB cryptography (Re: [Proposal] Table-levelTransparent Data Encryption (TDE) and Key) Management Service (KMS) |
Список | pgsql-hackers |
From: Nico Williams [mailto:nico@cryptonector.com] > Let's start with a set of threat models then. I'll go first: Thank you so much for summarizing the current situation. I'd appreciate it if you could write this on the PostgreSQL wiki,when the discussion has settled somehow. > - local adversaries (addressed by standard OS user process isolation) Does this also mean that we don't have to worry about the following? * unencrypted data in the server process memory and core files * passwords in .pgpass and recovery.conf (someone familiar with PCI DSS audit said this is a problem) * user data in server logs > 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 onlyuser data. > So I think for (3) the best answer is to just not have that problem: > just reduce and audit admin access. > > Still, if anyone wants to cover (3), I argue that PG gives you > everything you need right now: FDW and pgcrypto. Just build a > solution where you have a PG server proxy that acts as a smart > client to untrusted servers: Does sepgsql help? Should a malfunctioning or buggy application be considered as as a threat? That's what sql_firewall extension addresses. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: