Re: Enquiry about TDE with PgSQL
| От | Adrian Klaver |
|---|---|
| Тема | Re: Enquiry about TDE with PgSQL |
| Дата | |
| Msg-id | ebbe5b81-5e14-4273-a626-f2f49dad0b6c@aklaver.com обсуждение исходный текст |
| Ответ на | Re: Enquiry about TDE with PgSQL (Greg Sabino Mullane <htamfids@gmail.com>) |
| Список | pgsql-general |
On 10/31/25 08:25, Greg Sabino Mullane wrote: > On Fri, Oct 31, 2025 at 10:54 AM Bruce Momjian <bruce@momjian.us > <mailto:bruce@momjian.us>> wrote: > > Disk-level and partition-level encryption typically encrypts > the entire disk or partition using the same key, with all data > automatically decrypted when the system runs or when an > authorized > --> user requests it. For this reason, disk-level encryption is not > --> appropriate to protect stored PAN on computers, laptops, > servers, > storage arrays, or any other system that provides transparent > decryption upon user authentication. > > > Hmm, I read this a few times but still not sure what the technical > objection is. Yes, the entire disk is encrypted with the same key, but > why is that insufficient to protect things? Anyone care to guess what > they are thinking here? My best guess, is that the more the storage encryption is fragmented by different keys the less likely all the disk could be decrypted by a single action. The weak link is '... other system that provides transparent decryption upon user authentication.'. At some point the data needs to be decrypted for end user use. That means the point of attack is moved to the user and storage encryption does not really matter. > > The biggest possible downside of this standoff is that enterprises > that need to meet PCI compliance specifications are forced to use > specialized versions of Postgres or Postgres extensions that support > TDE. > > > Not always a downside for the companies selling those specialized > versions though. > > Cheers, > Greg > > -- > Crunchy Data - https://www.crunchydata.com <https://www.crunchydata.com> > Enterprise Postgres Software Products & Tech Support > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: