Re: Enquiry about TDE with PgSQL - Mailing list pgsql-general

On Fri, Oct 31, 2025 at 03:01:48PM +0100, Kai Wagner wrote:
> As I personally believe, there is no real way around TDE in the future, either
> by extensibility of the core (start with the storage manager and move your way
> on from there), to make an extension possible, or by directly adding it to the
> core, there are more reasons coming or are already on their way.
> 
> With the PCI DSS v4.1 standard, one key rule to comply with is, that "If PAN is

Uh, I think you mean the 4.0.1 standard, which became active on January
1, 2025.  I am surprised this is only being mentioned now:

    https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1
    
    When will PCI DSS v4.0 be retired?
    
    As with all new versions of PCI DSS, there will be a period where both
    the current and updated version will be active at the same time. PCI DSS
-->    v4.0 will be retired on 31 December 2024. After that point, PCI DSS
-->    v4.0.1 will be the only active version of the standard supported by PCI
    SSC.

While it was active on Jan 1, it became effective on March 31, 2025:

    Does PCI DSS v4.0.1 change the 31 March 2025 effective date for the new
    requirements?
    
    No. This limited revision does not impact the effective date of these
    new requirements. 

> stored, it must be rendered unreadable". Of course there are other ways, like
> tokenization, hashing etc. but this regulation is pushing towards at rest
> encryption in the long run, and not only disk encryption. We can dislike it,
> but we are already seeing the need coming from large industries and companies
> that they cannot work around this anymore, as the auditors doing the checkboxes
> do not really care about "good alternatives", as they do not even technically
> understand what this is about. They do compare postgres simply against other
> already in use databases at these orgs (MySQL or MongoDB), and as such, we are
> currently the only one that cannot be used in such a use case, at least not
> without the willingness of the auditor to make it happen.

I see the new specification that disk-level encryption is insufficient,
starting on page 93 (page 97 in the PDF URL):

    https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf#page=97

-->    3.5.1.2 If disk-level or partition-level encryption (rather than
    file-, column-, or field-level database encryption) is used to
    render PAN unreadable, it is implemented only as follows:
    
    • On removable electronic media
    
    OR
    
    • If used for non-removable electronic media, PAN is also
-->    rendered unreadable via another mechanism that meets Requirement
    3.5.1.

    ...

    While disk or partition encryption may still be present on these
    types of devices, it cannot be the only mechanism used to protect
    PAN stored on those systems. Any stored PAN must also be rendered
    unreadable per Requirement 3.5.1—for example, through truncation
    or a data-level encryption mechanism. Full disk encryption helps
    to protect data in the event of physical loss of a disk and
    therefore its use is appropriate only for removable electronic
    media storage devices.

    Purpose

    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.

PAN is:

    https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf#page=391    
    
    PAN Acronym for “primary account number.” Unique payment card
    number (credit, debit, or prepaid cards, etc.) that identifies
    the issuer and the cardholder account.

So it seems we have somewhat of a stand-off, with the Postgres project
questioning the value of TDE and the PCI writers doubling-down on
specifying disk-level encryption as insufficient.

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.

The fact that it has been seven months since PCI 4.0.1 was effective,
with little to no discussion or movement on adding TDE to community
Postgres means to me that we are unlikely to see TDE added to community
Postgres anytime soon.  I have a small hope that adding compression to
the writing of temporary files will reduce the code changes needed to
encrypt temporary files, thus reducing the amount of TDE code changes
needed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.