From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Encryption Options |
Date: | 2024-02-16 21:21:36 |
Message-ID: | CANzqJaA5jRrOUVLAZhoZXVbKbw8zY7TtP-Vj2Eq+mNEDFZgHXw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Feb 16, 2024 at 4:04 PM sud <suds1434(at)gmail(dot)com> wrote:
> 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
>
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2024-02-16 21:22:21 | Re: Encryption Options |
Previous Message | sud | 2024-02-16 21:04:20 | Re: Encryption Options |