PostgreSQL Encryption: The Available Options

Re:PostgreSQL Encryption: The Available Options by dzolob on Tuesday November 07, 2023 @09:03AM (#38176804)

We use traditional envelope encryption on a highly normalized base. At the end, only a few sensitive columns on a few sensitive tables get encrypted.

It’s kind of like a sparse matrix of encrypted vs. plain data, and works great for our scenario.

[ Parent | on HN ]

Re:PostgreSQL Encryption: The Available Options by thisisbrians on Tuesday November 07, 2023 @10:17AM (#38177742)

This is similar to what my shop is doing. Any notes on how you manage keys?

[ Parent | on HN ]

Re:PostgreSQL Encryption: The Available Options by hangonhn on Tuesday November 07, 2023 @10:54AM (#38178283)

It sounds like both of you do something very similar to what we do. Our data keys are themselves encrypted by AWS KMS. The data keys are decrypted and kept in memory on application startup. They are stored encrypted in S3.

[ Parent | on HN ]

Re:PostgreSQL Encryption: The Available Options by dzolob on Tuesday November 07, 2023 @12:31PM (#38179894)

As for now, we only need equality operator, so we use deterministic encryption for deks and handle keks in vaults. Kek rotation is kind of a pain, so we index edeks in order to improve our queries, which basically build dynamic UNION ALL or IN statements.

I’m sure is not the most secure schema in the world, but it makes retrieval fast and most analytics can be worked out with dynamic query building, while making the db a scrambled mess for those with partial access.

I guess you could call it “Security by insanity.”

[ Parent | on HN ]