On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote: > * Bruce Momjian (br...@momjian.us) wrote: > I agree that all of that isn't necessary for an initial implementation, > I was rather trying to lay out how we could improve on this in the > future and why having the keying done at a tablespace level makes sense > initially because we can then potentially move forward with further > segregation to improve the situation. I do believe it's also useful in > its own right, to be clear, just not as nice since a compromised backend > could still get access to data in shared buffers that it really > shouldn't be able to, even broadly, see.
I think TDE is feature of questionable value at best and the idea that we would fundmentally change the internals of Postgres to add more features to it seems very unlikely. I realize we have to discuss it so we don't block reasonable future feature development. > > Agreed. I have thought about this some more. There is certainly value > > in layered security, so if something gets violated, it doesn't open the > > whole system. However, I think the layering has to be done at the right > > levels, and I think you want levels that have clear boundaries, like IP > > filtering or monitoring. Placing a boundary inside the database seems > > much too complex a level to be effective. Using separate encrypted and > > unencrypted clusters and allowing the encrypted cluster to query the > > unencrypted clusters using FDWs does seem like good layering, though the > > FDW queries might leak information. > > Using FDWs simply isn't a solution to this, for a few different reasons- > the first is that our solution to authentication for FDWs is to store > passwords in our catalog tables, but an FDW table also doesn't behave > like a regular table in many important cases. The FDW authentication problem is something I think we need to improve no matter what. -- Bruce Momjian <br...@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 +
