On Wed, Jun 13, 2018 at 10:20 PM, Joe Conway <m...@joeconway.com> wrote: > On 06/11/2018 05:22 AM, Masahiko Sawada wrote: >> As per discussion at PGCon unconference, I think that firstly we need >> to discuss what threats we want to defend database data against. > > Exactly. While certainly there is demand for encryption for the sake of > "checking a box", different designs will defend against different > threats, and we should be clear on which ones we are trying to protect > against for any particular design. > >> Also, if I understand correctly, at unconference session there also >> were two suggestions about the design other than the suggestion by >> Alexander: implementing TDE at column level using POLICY, and >> implementing TDE at table-space level. The former was suggested by Joe >> but I'm not sure the detail of that suggestion. I'd love to hear the >> deal of that suggestion. > > The idea has not been extensively fleshed out yet, but the thought was > that we create column level POLICY, which would transparently apply some > kind of transform on input and/or output. The transforms would > presumably be expressions, which in turn could use functions (extension > or builtin) to do their work. That would allow encryption/decryption, > DLP (data loss prevention) schemes (masking, redacting), etc. to be > applied based on the policies.
It seems good idea. Which does this design encrypt data on, buffer or both buffer and disk? And does this design (per-column encryption) aim to satisfy something specific security compliance? > This, in and of itself, would not address key management. There is > probably a separate need for some kind of built in key management -- > perhaps a flexible way to integrate with external systems such as Vault > for example, or maybe something self contained, or perhaps both. I agree to have a flexible way in order to address different requirements. I thought that having a GUC parameter to which we store a shell command to get encryption key is enough but considering integration with various key managements seamlessly I think that we need to have APIs for key managements. (fetching key, storing key, generating key etc) > Or > maybe key management is really tied into the separately discussed effort > to create SQL VARIABLEs somehow. > Could you elaborate on how key management is tied into SQL VARIABLEs? Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
