Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Nico Williams <nico@cryptonector.com>, "Moon, Insung" <Moon_Insung_i3@lab.ntt.co.jp>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Joe Conway <mail@joeconway.com>
Date: 2018-06-21T15:09:27Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revamp the WAL record format.
- 2c03216d8311 9.5.0 cited
On Thu, Jun 21, 2018 at 04:49:34PM +0900, Masahiko Sawada wrote: > >> On Thu, Jun 21, 2018 at 6:57 AM, Nico Williams <nico@cryptonector.com> wrote: > >> So on the whole I think that crypto is a poor fit for the DBAs-are-the- > >> threat threat model. It's better to reduce the number of DBAs/sysadmins > >> and audit all privileged (and, for good measure, unprivileged) access. > > I agree with this. The in-database data encryption can defend mainly > the threat of storage theft and the threat of memory dump attack. I'm > sure this design had been proposed for the former purpose. If we want > to defend the latter we must encrypt data even on database memory. To > be honest, I'm not sure that there is needs in practice that is user > want to defend the memory dump attack. What user often needs is to > defend the threat of storage theft with minimum performance overhead. > It's known that client-side encryption or encryption on database > memory increase additional performance overheads. So it would be > better to have several ways to defend different threats as Joe > mentioned. If you can view memory you can't really trust the server and have to do encryption client-side. -- 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 +