On Tue, Oct 01, 2019 at 06:30:39PM +0900, Moon, Insung wrote:
Dear Magnus Hagander.
On Tue, Oct 1, 2019 at 5:37 PM Magnus Hagander <mag...@hagander.net> wrote:
On Tue, Oct 1, 2019 at 9:33 AM Tels <nospam-pg-ab...@bloodgate.com> wrote:
Moin,
On 2019-09-30 23:26, Bruce Momjian wrote:
> For full-cluster Transparent Data Encryption (TDE), the current plan is
> to encrypt all heap and index files, WAL, and all pgsql_tmp (work_mem
> overflow). The plan is:
>
>
https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#TODO_for_Full-Cluster_Encryption
>
> We don't see much value to encrypting vm, fsm, pg_xact, pg_multixact,
> or
> other files. Is that correct? Do any other PGDATA files contain user
> data?
IMHO the general rule in crypto is: encrypt everything, or don't bother.
If you don't encrypt some things, somebody is going to find loopholes
and sidechannels
and partial-plaintext attacks. Just a silly example: If you trick the DB
into putting only one row per page,
any "bit-per-page" map suddenly reveals information about a single
encrypted row that it shouldn't reveal.
Many people with a lot of free time on their hands will sit around,
drink a nice cup of tea and come up
with all sorts of attacks on these things that you didn't (and couldn't)
anticipate now.
So IMHO it would be much better to err on the side of caution and
encrypt everything possible.
+1.
Unless we are *absolutely* certain, I bet someone will be able to find a
side-channel that somehow leaks some data or data-about-data, if we don't
encrypt everything. If nothing else, you can get use patterns out of it, and
you can make a lot from that. (E.g. by whether transactions are using
multixacts or not you can potentially determine which transaction they are, if
you know what type of transactions are being issued by the application. In the
simplest case, there might be a single pattern where multixacts end up actually
being used, and in that case being able to see the multixact data tells you a
lot about the system).
As for other things -- by default, we store the log files in text format in the
data directory. That contains *loads* of sensitive data in a lot of cases. Will
those also be encrypted?
Maybe...as a result of the discussion so far, we are not encrypted of
the server log.
https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#What_to_encrypt.2Fdecrypt
I think Encrypting server logs can be a very difficult challenge,
and will probably need to develop another application to see the
encrypted server logs.
IMO leaks of sensitive data into the server log (say, as part of error
messages, slow queries, ...) are a serious issue. It's one of the main
issues with pgcrypto-style encryption, because it's trivial to leak e.g.
keys into the server log. Even if proper key management prevents leaking
keys, there are still user data - say, credit card numbers, and such.
So I don't see how we could not encrypt the server log, in the end.
But yes, you're right it's a challenging topis.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
