Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jul 9, 2019 at 08:01:35AM -0400, Joe Conway wrote: > > On 7/9/19 6:07 AM, Peter Eisentraut wrote: > > > On 2019-07-08 18:09, Joe Conway wrote: > > >> In my mind, and in practice to a > > >> large extent, a postgres tablespace == a unique mount point. > > > > > > But a critical difference is that in file systems, a separate mount > > > point has its own journal. > > > > While it would be ideal to have separate WAL, and even separate shared > > buffer pools, per tablespace, I think that is too much complexity for > > the first implementation and we could have a single separate key for all > > WAL for now.
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. > 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 main thing I don't think we want is e.g. a 50TB > > database with everything encrypted with a single key -- for the reasons > > previously stated. > > Yes, I think we need to research in which cases the nonce must be > random, and how much key space the secret+nonce gives us. Agreed on both. Thanks, Stephen
signature.asc
Description: PGP signature
