On Fri, Feb 16, 2024 at 4:04 PM sud <suds1...@gmail.com> wrote: > On Fri, Feb 16, 2024 at 10:50 PM Greg Sabino Mullane <htamf...@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. > 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 <ronljohnso...@gmail.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 >
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.
