Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Thu, Mar 14, 2019 at 8:30 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> So I think there is no such insider thread problem, right?

No, I think that's a really bad assumption. If there's no insider
threat, then what exactly ARE you guarding against? If somebody
steals the disk, you don't need PostgreSQL to do anything; just
encrypt the filesystem and call it good. Encryption within the
database can only provide any value when someone already has some
degree of access to the system, and we want to prevent them from
getting more access. Maybe they are legitimately allowed some access
and we want to keep them from exceeding those bounds, or maybe they
hacked something else to gain limited access and we want to keep them
from parleying that into more access. Either way, they are to some
extent an insider.

And that is why I think your idea that it's OK to encrypt the WAL with
key A while the tables are meanwhile being encrypted with keys B1, B2,
..., Bn is unsound. In such an environment, anybody who has key A
does not really need to bother compromising the other keys; they
basically get everything anyway. There is therefore little point in
having the complexity of multiple keys; just use key A for everything
and be done with it. To justify the complexity of multiple keys, they
need to be independent of each other from a security perspective; that
is, it must be that all copies of any given piece of data are
encrypted with the same key, and you can therefore get that data only
if you get that key. And that means, I believe, that fine-grained
encryption must use the same key to encrypt the WAL for table T1 --
and the indexes and TOAST table for table T1 and the WAL for those --
that it uses to encrypt table T1 itself.

If we can't make that happen, then I really don't see any advantage in
supporting multiple keys. Nobody steals the key to one office if they
can, for the same effort, steal the master key for the whole building.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company