Dear Tomas Vondra. > -----Original Message----- > From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com] > Sent: Wednesday, June 13, 2018 10:03 PM > To: Masahiko Sawada; Moon, Insung > Cc: PostgreSQL-development; Joe Conway > Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key > Management Service (KMS) > > On 06/11/2018 11:22 AM, Masahiko Sawada wrote: > > On Fri, May 25, 2018 at 8:41 PM, Moon, Insung > > <moon_insung...@lab.ntt.co.jp> wrote: > >> Hello Hackers, > >> > >> This propose a way to develop "Table-level" Transparent Data > >> Encryption (TDE) and Key Management Service (KMS) support in > >> PostgreSQL. > >> > >> ... > > > > As per discussion at PGCon unconference, I think that firstly we need > > to discuss what threats we want to defend database data against. > > If user wants to defend against a threat that is malicious user who > > logged in OS or database steals an important data on datbase this > > design TDE would not help. Because such user can steal the data by > > getting a memory dump or by SQL. That is of course differs depending > > on system requirements or security compliance but what threats do you > > want to defend database data against? and why? > > > > I do agree with this - a description of the threat model needs to be part of > the design discussion, otherwise it's not > possible to compare it to alternative solutions (e.g. full-disk encryption > using LUKS or using existing privilege controls > and/or RLS). > > TDE was proposed/discussed repeatedly in the past, and every time it died > exactly because it was not very clear which > issue it was attempting to solve. > > Let me share some of the issues mentioned as possibly addressed by TDE (I'm > not entirely sure TDE actually solves them, > I'm just saying those were mentioned in previous discussions): > > 1) enterprise requirement - Companies want in-database encryption, for > various reasons (because "enterprise solution" > or something).
Yes. I do not know clearly about enterprise encryption requirements. Typically, identified the requirements for encryption of PCI-DSS and posted these ideas.(Storage encryptoin) Therefore, according to your opinion, I will more try to research of the enterprise encryption requirements. > > 2) like FDE, but OS/filesystem independent - Same config on any OS and > filesystem, which may make maintenance easier. > > 3) does not require special OS/filesystem setup - Does not require help from > system adminitrators, setup of LUKS devices > or whatever. Yes. We can use disk encryption like LUKS at Linux, but it does not apply to all OS's, so I'm proposed TDE. > > 4) all filesystem access (basebackups/rsync) is encrypted anyway > > 5) solves key management (the main challenge with pgcrypto) In fact, it is the biggest worry about key management. First, I think of 2-tier encryption as I wrote in my idea, and I am thinking of using KMS for management to master key. However, I am also worried about security problems when I managed of table key and master key. Therefore, I want to more discuss of Key Management and develop KMS simultaneously with TDE. Thank you and Best regards. Moon. > > 6) allows encrypting only some of the data (tables, columns) to minimize > performance impact > > IMHO it makes sense to have TDE even if it provides the same "security" > as disk-level encryption, assuming it's more convenient to setup/use from the > database. > > > 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 latter was suggested by Tsunakawa-san. > > Have you considered that? > > > > You mentioned that encryption of temporary data for query processing > > and large objects are still under the consideration. But other than > > them you should consider the temporary data generated by other > > subsystems such as reorderbuffer and transition table as well. > > > > The severity of those limitations is likely related to the threat model. > I don't think encrypting temporary data would be a big problem, assuming you > know which key to use. > > regards > > -- > Tomas Vondra http://www.2ndQuadrant.com > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
