Re: Enquiry about TDE with PgSQL

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Enquiry about TDE with PgSQL
Дата
Msg-id aQjFXwQxDU70EEdW@momjian.us
обсуждение исходный текст
Ответ на Re: Enquiry about TDE with PgSQL  (Rainer Duffner <rainer@ultra-secure.de>)
Ответы Re: Enquiry about TDE with PgSQL
Список pgsql-general
On Sat, Nov 1, 2025 at 09:07:01PM +0100, Rainer Duffner wrote:
> Do you actually have HSMs with your TDE (assuming you use it
> elsewhere?  We run, for a customer, an Oracle DataGuard configuration
> with TDE with a HSM.

There were some interesting ideas in this email I want to reply to.

> We have a support-contract with a 3rd party company that helps us
> with the more obscure problems on Oracle that we don’t encounter
> every day and they told us of all their clients (banks, insurance
> companies), we are the only ones with TDE. They loath working with it
> ;-)

Is it the Oracle API they don't like, that Postgres can improve upon, or
something fundamental they don't like, or don't see the value in?

> There’s apparently another non-disclosed customer that uses it.
>
> It may be that a lot of people now use „cloud HSMs“ - but I’m
> a bit of a purist for these kinds of things in that I believe that
> unless you own the hardware (HSMs are usually tamper-proof enough so
> you can deploy them in 3rd-party datacenters that aren’t your own),
> you don’t really control the keys.
>
> In our case, the databases are backed up with rman to an NFS share
> that is provided by a virtualized linux server - the severs itself are
> hardware.
>
> If you don’t have TDE, your backups aren’t encrypted and they end
> up on the veeam server like everything else, where an admin could copy
> them somewhere else and potentially take them elsewhere.
>
> With the HSM, we don’t actually know the secret to decrypt the data
> (there may be a way to get it, I don’t know). We know the secret
> to unseal the wallet (that sits on the HSM, I believe) so that the
> database actually mounts and starts.
>
> It’s pretty bullet-proof (I believe there’s techniques to prevent
> sniffing out the secret from RAM and HSMs usually implement those in
> their client software).  In fact, it’s so bullet-proof that should
> you lose the keys on the HSM, your data is gone if you have no other
> backups or backups of the HSM.

As far as I know, there are two ways to generate the data encryption
key.  One is for the HSM to generate it, and then only the HSM knows it.
The other method is to create the encryption key on a USB memory stick,
copy the key into the HSM, and then remove the USB memory stick and
store it in a secure location like a safe.  The second method seems like
a better option to me.  Oh, and make a second copy of the USB memory
stick.

> If the amount of data is small enough, you can GPG encrypt a
> „normal“ full dump - but that become unfeasible as database size
> grows.

This is a good point.  For TDE storage, the data is encrypted once on
write, and then can be backed up as many times as needed without
re-encryption.  With storage-level encryption, the data has to be
encrypted for every backup.  However, considering how much TLS is used,
I assumed the encryption overhead would be minimal compared to the
transfer overhead.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.



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