Greetings, * Bruce Momjian (br...@momjian.us) wrote: > 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.
We'd be getting to something much better than just TDE by going down that road- we'd be able to properly leverage the kernel to enforce real MAC. I get that this would be a change but I'm not entirely convinced that it'd be as much of a fundamental change as implied here. I expect that we're going to get to a point where we want to have multiple shared buffer segments for other reasons anyway. > > > 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. Yes, constrained delegation with Kerberos would certainly be an improvement, and having a way to do something like peer auth when local, and maybe even a server-to-server trust based on certificates or similar might be an option. Thanks, Stephen
signature.asc
Description: PGP signature