Open source database software support and services company Percona has announced its Transparent Data Encryption (TDE) extension for PostgreSQL. Designed to provide a method to secure sensitive data at rest (and meet strict compliance requirements), the technology performs without licensing fees and usage restrictions.
What is transparent encryption?
But what is Transparent Data Encryption? Specifically aligned for data at rest (information on a persistent storage volume or disk of some kind), TDE offers automatic encryption and decryption at the database layer without requiring changes to an application or other extraneous service. Usually associated with database protection, TDE can also be applied to backups and transaction logs. TDE encryption keys are stored separately from the data and may be protected by certificates or other security mechanisms.
Percona says it is bringing enterprise-grade encryption to open source PostgreSQL, making it possible to encrypt data at rest in a way that is “automatic and transparent” to the application.
Built for risk management and compliance, the pg_tde extension by Percona protects sensitive data from unauthorised access, helping meet regulations such as GDPR, HIPAA, SOX and PCI DSS v4.0, where storage encryption alone is agreed to no longer be sufficient to protect “cardholder data” at rest.
An increasingly standardised term today, cardholder data (or CHD) denotes Personally Identifiable Information (PII) related to a payment card including the Primary Account Number (PAN), cardholder name, expiration date and service code.
Key functionalities
The central functionalities on offer here from Percona for PostgreSQL include the ability to get the only open source TDE solution for PostgreSQL ready for production i.e. there are no “gated features” or other license, subscriptions or closed source shortcomings.
Users can encrypt all database files on disk, make use of multi-tenant support and the ability to encrypt at the database table level itself and use unique keys for each database. Database administrators retain full control over their encryption strategy, choosing precisely what to protect without being forced into cluster-wide encryption
Teams can deploy TDE without any changes to application code and also streamline key lifecycle management with integrations to leading Key Management Services (KMS) providers such as Hashicorp, Thales, Fortanix and OpenBao, making it easier to enforce security policies and manage encryption keys securely.
Inside track from CTO
According to Liz Warner, CTO of Percona, data at rest encryption is a requirement of a range of standards, regulations and policies. While some like PCI DSS require it directly, others like GDPR recommend encrypting data by creating penalties for the exposure of unscrambled data and still others like ISO generally recommend encryption of sensitive information. Over the years a lot of databases organizations globally rely on have added the capability for DBAs to encrypt the data they store.
“However, TDE has not been available as standard in the open source community version of the PostgreSQL i.e. if you wanted TDE, then you had to look at a commercial product. In our view at Percona, we saw that as a big miss that was holding back customers from moving over to the database, so we worked on pg_tde to provide that functionality in a fully open source project. This means that users can choose Postgres and be compliant with regulations without having to rewrite their applications or falling into vendor-lock in by using a single vendor’s proprietary approach to TDE,” said Warner, speaking to Techzine this month in London.
So how does pg_tde fit into the wider PostgreSQL ecosystem?
Well says Warner, pg_tde currently requires a patched PostgreSQL server. Percona ships that server together with a selection of other extensions in its open source Percona Distribution for PostgreSQL. This fills the gap that exists for teams that want a fully open source database but also need encryption at rest.
How it works
“The requirement to use Percona Server for PostgreSQL for pg_tde comes from the fact that to make TDE possible, we have to hook into the Storage Manager (SMGR) API, which allows PostgreSQL extensions to integrate custom storage managers and the Write Ahead Logging (WAL) Read/Write API to hook into WAL read and write functions. They are required to enable WAL encryption of indexes,” explained Warner.
Percona would like to make pg_tde available to Community PostgreSQL , but this requires making the patches that the company has proposed available there. This takes time. Some of the code to achieve this has been contributed upstream to the PostgreSQL Community and is in review.
But why should developers/DBAs care about compliance in the first place, when, often, they might consider this consideration to be part of their responsibility?
“Modern application developers care very much about applications – and by extension, database – security,” she said. “Additionally, the compliance team within an organisation wants to know that their operations are compliant. That means looking at how digital services or applications work in practice. Those applications should follow established best practices on security and compliance as well as user experience or system design. But all of these asks are falling on developers’ shoulders – getting them to focus on security or compliance is tough when they are being asked to build more and more new functionality, or manage integrations with other systems and keep them up to date.”
Is data at rest safer?
While application-level encryption is often considered the most secure approach for data at rest, as it prevents even DBAs from accessing sensitive information, it comes with considerable costs. Implementing it typically requires building systems with this assumption from the ground up and incurs ongoing maintenance costs. For many organisations, particularly those dealing with legacy systems or proprietary, off-the-shelf solutions where they don’t control the code, application-level encryption isn’t a feasible option.
“In these scenarios, database-level security solutions like TDE offer a vital alternative. TDE can mitigate the lack of application-level encryption by providing a robust layer of security at the database level, effectively lifting some of the burden of needing app-level security. It provides organisations with another option, allowing them to achieve a strong security posture by accepting some inherent risks, without the extensive re-architecture required for application-level encryption,” said Warner.
Developers adore automation
Developers are always looking for ways to automate tasks… and compliance is no different. Approaches like policy as code or security as code allow teams to streamline compliance management needs over time. But without that base understanding of how compliance fits into existing infrastructure and stack, it can be harder to achieve this automation in practice or keep that compliance approach up to date. This adds to that burden over time, which ultimately will come back to developers.
“Ideally, developers can get ahead of these requirements using open source projects that support their needs, like pg_tde. But this also has to be part of a broader approach to compliance that makes things simpler for developers rather than adding yet another burden to them,” concluded Warner.
Today, the pg_tde extension is part of the Percona Distribution for PostgreSQL. Percona also supports TDE as a part of Percona Support for PostgreSQL, Managed Services and Consulting services to set up and configure the extension.