Greetings,
* Bruce Momjian (bruce@momjian.us) wrote:
> On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote:
> > * Bruce Momjian (bruce@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
