| From: | Kai Wagner <kai(dot)wagner(at)percona(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Ron Johnson <ronljohnsonjr(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Enquiry about TDE with PgSQL |
| Date: | 2025-10-31 14:01:48 |
| Message-ID: | CAG0qCNhL=SEB4vc4v48PxN1F-t8htC463TpX7KDNWQ-s3s8dtA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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 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.
On Thu, Oct 30, 2025 at 9:00 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Fri, Oct 17, 2025 at 09:01:52AM +0200, Laurenz Albe wrote:
> > On Fri, 2025-10-17 at 00:49 -0400, Ron Johnson wrote:
> > > On Thu, Oct 16, 2025 at 6:05 PM Greg Sabino Mullane <
> htamfids(at)gmail(dot)com> wrote:
> > > >
> > > > TDE, on the other hand, is a very complex and difficult thing to add
> into Postgres.
> > >
> > > TDE was added to SQL Server, with (to us, at least) minimally-noticed
> overhead.
> > > Oracle has it, too, but I don't know the details.
> > >
> > > The bottom line is that requirements for TDE are escalating, whether
> you like it or
> > > not, as Yet Another Layer Of Defense against hackers exfiltrating
> data, and then
> > > threatening to leak it to the public.
> >
> > Bruce Momjian has interesting things to say about that in
> >
> https://url.avanan.click/v2/r01/___https://compiledconversations.com/6/___.YXAzOnBlcmNvbmE6YTpnOjMxNTMyOGQ0MzIyODAzOTU2M2E4OWUxZjNjZmMyYTRlOjc6MDJjZDplMmZkOGI3NTExNjAzNDI4YzZlZTZjMDQwNjU1YWQyZTVlYzU4NmQ4NjMzYzQxZGVjNzUxMGM5MmM0YThkM2M5OnA6VDpO
> (unfortunately I don't remember where
> > exactly in this 84 minute piece).
>
> Here is my most recent blog about TDE:
>
>
> https://url.avanan.click/v2/r01/___https://momjian.us/main/blogs/pgblog/2025.html%23February_22_2025___.YXAzOnBlcmNvbmE6YTpnOjMxNTMyOGQ0MzIyODAzOTU2M2E4OWUxZjNjZmMyYTRlOjc6ODI4Nzo4OTUwMTcwNDljNjA0OGYxNzU3MDhlMjhiNDIwZjNiNzNjYTZmNWJjZmM2MmNmNWJkMGFhNTllOTMzNjA2Y2EyOnA6VDpO
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us>
> https://url.avanan.click/v2/r01/___https://momjian.us___.YXAzOnBlcmNvbmE6YTpnOjMxNTMyOGQ0MzIyODAzOTU2M2E4OWUxZjNjZmMyYTRlOjc6ZTBkOTozZDU5MmRlNGI0YTU5ZmIxM2UzNmE1NTgzY2U1YjBjNmZlZWMwNmEyNzBhYjdlYTlhNDhlZTU4MGVjMDQ4MTk5OnA6VDpO
> EDB
> https://url.avanan.click/v2/r01/___https://enterprisedb.com___.YXAzOnBlcmNvbmE6YTpnOjMxNTMyOGQ0MzIyODAzOTU2M2E4OWUxZjNjZmMyYTRlOjc6ZWFlNjoyYWE0NWVmY2EwZTBhNGM3Y2Q2NzQwNDQ5NmM5OGMwODkxNDUxYzY2YmI4NWZhNzM0NmUwZjI1Mzg4NzE4ZDhhOnA6VDpO
>
> Do not let urgent matters crowd out time for investment in the future.
>
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fernando Laudares Camargos | 2025-10-31 14:41:40 | Re: Enquiry about TDE with PgSQL |
| Previous Message | DINESH NAIR | 2025-10-31 06:38:54 | Re: Why isn't my table auto-analyzed/vacuumed? |