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).
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
