RE: Application Level Encryption - Mailing list pgsql-general

From Zahir Lalani
Subject RE: Application Level Encryption
Date
Msg-id DB8PR06MB61877D791E62E590DE747D64A7680@DB8PR06MB6187.eurprd06.prod.outlook.com
Whole thread Raw
In response to Re: Application Level Encryption  (Michel Pelletier <pelletier.michel@gmail.com>)
List pgsql-general

From: Michel Pelletier <pelletier.michel@gmail.com>
Sent: 05 July 2020 23:32
To: Sam Gendler <sgendler@ideasculptor.com>
Cc: Zahir Lalani <ZahirLalani@oliver.agency>; pgsql-general@postgresql.org
Subject: Re: Application Level Encryption

 

 

 

On Sun, Jul 5, 2020 at 3:23 PM Sam Gendler <sgendler@ideasculptor.com> wrote:

 

 

On Sun, Jul 5, 2020 at 11:41 AM Michel Pelletier <pelletier.michel@gmail.com> wrote:

 

 

I'm working on an approach where the decrypted DEK only lives for the lifetime of a transaction, this means hitting the kms on every transaction that uses keys.  It will be slower, but the time the decrypted key stays in memory would be minimized.

 

Watch out for KMS api quotas if you go that route.  Their docs don't state what the default quotas are, so you have to go to your quotas page in the console to find out, but they likely aren't very high and might well be exceeded by the transaction rate on even a relatively small db instance.

 

Thanks for pointing that out, it's true that it's a limited route with cloud KMS.   If you control the device like a Zymkey in a secure enclosure, the cost is minimal, although the key derivation rate is very slow.

 

-Michel

 

**

Thank you for the explanation – that makes sense, but I need to read the docs to understand better. Any suggestions on how people usually deal with reporting in this scenario, considering off the shelf tools don’t usually have this mechanism?

 

Z

 

pgsql-general by date:

Previous
From: Michel Pelletier
Date:
Subject: Re: Application Level Encryption
Next
From: raf
Date:
Subject: Re: survey: psql syntax errors abort my transactions