Re: Transparent Data Encryption (TDE) and encrypted files

Поиск
Список
Период
Сортировка
От Moon, Insung
Тема Re: Transparent Data Encryption (TDE) and encrypted files
Дата
Msg-id CAEMmqBtaCbYw_vj4Ksef-Q-zSvinXut1e22TJBLhHydhLc8hFg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Transparent Data Encryption (TDE) and encrypted files  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: Transparent Data Encryption (TDE) and encrypted files  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
Dear  Magnus Hagander.

On Tue, Oct 1, 2019 at 5:37 PM Magnus Hagander <magnus@hagander.net> wrote:
>
>
>
> On Tue, Oct 1, 2019 at 9:33 AM Tels <nospam-pg-abuse@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
lotfrom that. (E.g. by whether transactions are using multixacts or not you can potentially determine which transaction
theyare, if you know what type of transactions are being issued by the application. In the simplest case, there might
bea single pattern where multixacts end up actually being used, and in that case being able to see the multixact data
tellsyou 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*
ofsensitive 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.

Best regards.
Moon.


>
> --
>  Magnus Hagander
>  Me: https://www.hagander.net/
>  Work: https://www.redpill-linpro.com/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Attempt to consolidate reading of XLOG page
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Modest proposal for making bpchar less inconsistent