Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
От | Tomas Vondra |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Дата | |
Msg-id | d3ba7439-c65a-008e-c68e-d5097b49f134@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
RE: [Proposal] Table-level Transparent Data Encryption (TDE) andKey Management Service (KMS)
("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Masahiko Sawada <sawada.mshk@gmail.com>) RE: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) ("Moon, Insung" <Moon_Insung_i3@lab.ntt.co.jp>) |
Список | pgsql-hackers |
On 06/11/2018 11:22 AM, Masahiko Sawada wrote: > On Fri, May 25, 2018 at 8:41 PM, Moon, Insung > <Moon_Insung_i3@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). 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. 4) all filesystem access (basebackups/rsync) is encrypted anyway 5) solves key management (the main challenge with pgcrypto) 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
В списке pgsql-hackers по дате отправления: