Re: Encryption Options

On Fri, Feb 16, 2024 at 10:50 PM Greg Sabino Mullane <htamfids(at)gmail(dot)com>
wrote:

> You need to clearly define your threat model. What exactly are you
> defending against? What scenario do you want to avoid?
>
> Also, your decision of on-premise or Aurora is extremely relevant to your
> range of options.
>
>
Thank you.

Yes these are Account number/PCI data and "data at rest" encryption is
something management is asking to have irrespective of whether we encrypt
those before storing in the database or not. And this system needs to
adhere to PCI 4.0 standards , so it looks like we can't persist the PCI
data as is in th database even if the 'data at rest' encryption is there,
it has to be encrypted before storing into the database.
https://www.varonis.com/blog/pci-dss-requirements

Agreed. The on-premise vs aurora will take a different approach for
catering to above needs. We are currently evaluating , what would be the
possible options in each of these cases? and if this would be a factor in
choosing the on-premise postgres vs aurora postgres?

On Sat, Feb 17, 2024 at 12:40 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
wrote:

> The problem with encrypting "account number" is that you can't JOIN or
> WHERE on it. That's not always necessary, though. The pgcrypto module does
> what it says, but requires application-level changes,
>
> Encryption at rest can be accomplished with filesystem-level encryption,
> and backup encryption. (PgBackRest has that feature, using AES-256. Don't
> know about BarMan.)
>
>
Will try to verify these options. Considering these system processes 100's
of millions of transactions, will these encryption add significant
overhead? It would be great, if you can suggest some doc to follow, for
implementing these. Not sure if the same would work for aurora too.

Regards
Sud