On Fri, Feb 16, 2024 at 10:50 PM Greg Sabino Mullane <htamfids@gmail.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.
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?
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
Per minute? Hour? Day? Month? Year? Decade?
Continuous? In waves?
, will these encryption add significant overhead?
"Significant" is relative, and depends on the CPU.
It would be great, if you can suggest some doc to follow, for implementing these.
Google "pgcrypto".
Not sure if the same would work for aurora too.
This list avoids giving help on Aurora, since it's very different from Postgresql. AWS RDS Postgresql is much closer to vanilla Postgresql, so we can help with that.