Re: Transparent Data Encryption (TDE) and encrypted files - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: Transparent Data Encryption (TDE) and encrypted files |
Date | |
Msg-id | 20191004014239.GG6962@tamriel.snowman.net Whole thread Raw |
In response to | Re: Transparent Data Encryption (TDE) and encrypted files (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Transparent Data Encryption (TDE) and encrypted files
Re: Transparent Data Encryption (TDE) and encrypted files |
List | pgsql-hackers |
Greetings, * Robert Haas (robertmhaas@gmail.com) wrote: > On Thu, Oct 3, 2019 at 1:29 PM Stephen Frost <sfrost@snowman.net> wrote: > > I don't think I was arguing specifically about VM/FSM in particular but > > rather about things which, for us, are cluster level. Admittedly, some > > other database systems put more things into tablespaces or databases > > than we do (it'd sure be nice if we did in some cases too, but we > > don't...), but they do also have things *outside* of those, such that > > you can at least bring the system up, to some extent, even if you can't > > access a given tablespace or database. > > It sounds like you're making this up as you go along. I'm not surprised, and I doubt that's really got much to do with the actual topic. > The security > ramifications of encrypting a file don't depend on whether that file > is database-level or cluster-level, but rather on whether the contents > could be useful to an attacker. I don't believe that I claimed otherwise. I agree with this. > It doesn't seem like it would require > much work at all to construct an argument that a hacker might enjoy > having unfettered access to pg_clog even if no other part of the > database can be read. The question isn't about what hackers would like to have access to, it's about what would actually provide them with a channel to get information that's sensitive, and at what rate. Perhaps there's an argument to be made that clog would provide a high enough rate of information that could be used to glean sensitive information, but that's certainly not an argument that's been put forth, instead it's the knee-jerk reaction of "oh goodness, if anything isn't encrypted then hackers will be able to get access to everything" and that's just not a real argument. > My perspective on this feature is, and has always been, that there are > two different things somebody might want, both of which we seem to be > calling "TDE." One is to encrypt every single data page in the cluster > (and possibly things other than data pages, but at least those) with a > single encryption key, much as filesystem encryption would do, but > internal to the database. Making it all up as I go along notwithstanding, I did go look at other database systems which I considered on-par with PG, shared that information here, and am basing my comments on that review. Which database systems have you looked at which have the properties you're describing above that we should be working hard towards? > The other thing people sometimes want is to encrypt some of the data > within the database but not all of it. In my view, trying to implement > this is not a great idea, because it's vastly more complicated than > just encrypting everything with one key. Which database systems that you'd consider to be on-par with PG, and which do have TDE, don't have some mechanism for supporting multiple keys and for encrypting only a subset of the data? Thanks, Stephen
Attachment
pgsql-hackers by date: