On Tue, Oct 1, 2019 at 03:43:05PM +0200, Tomas Vondra wrote:
> On Mon, Sep 30, 2019 at 05:40:52PM -0400, Bruce Momjian wrote:
> Maybe. I think this is approaching the problem from the wrong angle.
> Encryption is more a means of achieving something. OK, for compliance
> purposes it's useful to be able to tick "encryption" checkbox. But other
> than that, people really care about threat models and how encryption
> improves them (or does not).
Yes, that is what I am trying to do with this email thread.
> So I think it'd be valuable to improve the "thread models" section on
> that wiki page, with more detailed cases. We need to explain what
> capabilities the attacker has (can he read files?can he interact with
> the database? can he read memory? ..) and then explain how that works
> with encrypted cluster.
>
>
> > * perhaps easier to implement than file system encryption
> >
>
> Not sure. IMO filesystem encryption is fairly simple to use, to the
> extent that it's hard to beat. The problem is usually people can't use
> it for various reasons - lack of support on their OS, no access to the
> block device, problems with obtaining the privileges etc.
Right, that's the "perhaps easier" part of my text above.
> Having it built into the database menas you can sidestep most of those
> issue (e.g. you can deploy it as a DBA, on arbitrary OS, ...).
>
> Plus it allows features you can't easily achieve with fs encryption,
> because the filesystem only sees opaque data files. So having keys per
> database/user/... is easier from within the database.
Yes, but we will not be doing that for the first release because of the
complexity related to handling this in WAL and requiring crash recovery
to be able to unlock all the keys for replay. I personally think that
database/user/... keys are best done at the SQL level, with proper
locking. pgcryptokey (http://momjian.us/download/pgcryptokey/) is an
example of that.
--
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 +