Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
От | Bruce Momjian |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Дата | |
Msg-id | 20180621150927.GB24547@momjian.us обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
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 +
В списке pgsql-hackers по дате отправления: