On Tue, Mar 5, 2019 at 3:46 AM Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > > > > On 3/4/19 6:40 AM, Masahiko Sawada wrote: > > On Sat, Mar 2, 2019 at 5:27 AM Robert Haas <robertmh...@gmail.com> wrote: > >> > >> On Thu, Feb 7, 2019 at 3:28 AM Masahiko Sawada <sawada.m...@gmail.com> > >> wrote: > >>> WAL encryption will follow as an additional feature. > >> > >> I don't think WAL encryption is an optional feature. You can argue > >> about whether it's useful to encrypt the disk files in the first place > >> given that there's no privilege boundary between the OS user and the > >> database, but a lot of people seem to think it is and maybe they're > >> right. However, who can justify encrypting only SOME of the disk > >> files and not others? I mean, maybe you could justify not encryption > >> the SLRU files on the grounds that they probably don't leak much in > >> the way of interesting information, but the WAL files certainly do -- > >> your data is there, just as much as in the data files themselves. > >> > > > > Agreed. > > > >> To be honest, I think there is a lot to like about the patches > >> Cybertec has proposed. Those patches don't have all of the fancy > >> key-management stuff that you are proposing here, but maybe that > >> stuff, if we want it, could be added, rather than starting over from > >> scratch. It seems to me that those patches get a lot of things right. > >> In particular, it looked to me when I looked at them like they made a > >> pretty determined effort to encrypt every byte that might go down to > >> the disk. It seems to me that you if you want encryption, you want > >> that. > >> > > > > Agreed. I think the patch lacks the key management stuff: 2-tier key > > architecture and integration of postgres with key management systems. > > I'd like to work together and can propose the patch of key management > > stuff to the proposed patch. > > > > Sounds like a plan. It'd be nice to come up with a unified version of > those two patches, combining the good pieces from both. > > I wonder how other databases deal with key management? Surely we're not > the first/only database that tries to do transparent encryption, so > perhaps we could learn something from others? For example, do they use > this 2-tier key architecture? How do they do key management? etc. > > I don't say we should copy from them, but it'd allow us to (a) avoid > making the same mistakes and (b) build a solution the users are already > somewhat familiar with. > > May I suggest creating a page on the PostgreSQL wiki, explaining the > design and updating it as the discussion develops?
Understood. I've been researching transparent encryption of other databases and been considering the architecture. I'll write down them to the wiki. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
