Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Rainer Duffner <rainer(at)ultra-secure(dot)de>
Cc: "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration
Date: 2023-01-07 03:26:32
Message-ID: Y7jmaGFvaY99abEA@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Dec 22, 2022 at 11:15:57AM +0100, Rainer Duffner wrote:
> I wasn’t involved in setting it up here, but AFAIK you need to „enroll“ the
> client to the HSM.
>
> That is a one-time process that requires HSM credentials (via certificates and
> pass-phrases).
>
> Then, that client can talk to the HSM.
>
> The HSM-client is (or should be) engineered in such a way that you can’t
> extract the encryption-secret easily.
>
> I am not sure, but IIRC, you should not even be able to clone the VM without
> the HSM noticing or the clone not working at all to begin with (for lack of
> enrollment). Though most production databases are too large to just „clone“.
>
> Maybe someone who knows more about this subject can chime in before I make a
> fool of myself?

This wiki should help:

https://wiki.postgresql.org/wiki/Transparent_Data_Encryption

Also, the first two patches in this email are doc patches which explain
the benefits:

https://www.postgresql.org/message-id/20210625212204.GA7256@momjian.us

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Embrace your flaws. They make you human, rather than perfect,
which you will never be.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Brad White 2023-01-07 04:14:47 Re: Updating column default values in code
Previous Message Ken Tanzer 2023-01-07 01:44:37 Re: Updating column default values in code