Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Дата
Msg-id CAD21AoD4W6SMP21rpa+sD6zY0E1cBXtGmHapdVVLYW7JdhMUOQ@mail.gmail.com
обсуждение исходный текст
Ответ на RE: [Proposal] Table-level Transparent Data Encryption (TDE) andKey Management Service (KMS)  ("Smith, Peter" <peters@fast.au.fujitsu.com>)
Список pgsql-hackers
On Mon, May 13, 2019 at 2:09 PM Smith, Peter <peters@fast.au.fujitsu.com> wrote:
>
> Hi Masahiko,
>
> > Let me briefly explain the current design I'm thinking. The design employees 2-tier key architecture. That is, a
databasecluster has one 
> > master key and per-tablespace keys which are encrypted with the master key before storing to disk. Each tablespace
keysare generated 
> > randomly inside database when CREATE TABLESPACE. The all encrypted tablespace keys are stored together with the
masterkey ID to the 
> > file (say, $PGDATA/base/pg_tblsp_keys). That way, the startup process can easily get all tablespace keys and the
masterkey ID before 
> > starting recovery, and therefore can get the all decrypted tablespace keys.
>
> Your design idea sounds very similar to the current Fujitsu Enterprise Postgres (FEP) implementation of TDE.
>

Yeah, I studied the design of TDE from FEP as well as other database
supporting TDE.

> FEP uses a master encryption key (MEK) for the database cluster. This MEK is stored in a file at some GUC variable
location.This file is encrypted using a “passphrase” known only to the administrator. 
>
> There are also per-tablespace keys, which are randomly generated at the time of CREATE TABLESPACE and stored in
files.There is one tablespace key file per tablespace. These tablespace key files are encrypted by the MEK and stored
atthe location specified by CREATE TABLESPACE. 
>
> Not all tablespaces use TDE. An FEP extension of the CREATE TABLESPACE syntax, creates the tablespace key file only
whenencryption was requested. 
> e.g. CREATE TABLESPACE my_secure_tablespace LOCATION '/home/postgre/FEP/TESTING/tablespacedir' WITH
(tablespace_encryption_algorithm= 'AES256'); 
>
> The MEK is not currently got from a third party. It is randomly generated when the master key file is first created
byanother added function. 
> e.g. select pgx_set_master_key('passphrase');

Thank you for explaining!

I think that the main difference between FEP and our proposal is the
master key management. In our proposal postgres can get the master key
from the external key management server or services such as AWS KMS,
Gemalto KeySecure and an encrypted file by using the corresponding
plugin. We believe that this extensible architecture would be useful
for applying postgres to various systems.


Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center



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

Предыдущее
От: Kuntal Ghosh
Дата:
Сообщение: Re: PANIC :Call AbortTransaction when transaction id is no normal
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: PANIC :Call AbortTransaction when transaction id is no normal