PostgreSQL Encryption, Tokenization, and Masking

Baffle’s Data Protection Service is the easiest to implement and most comprehensive solution for protecting sensitive information in your PostgreSQL database.

Schedule a Demo

Overview

PostgreSQL is growing exponentially because it is open-source and has enterprise capabilities. However, it lacks an easy way to implement protection of sensitive data.

Without application code changes, Baffle’s solution enables field-level encryption or tokenization and implements least privilege access to that data – including the DBA.

Meet your compliance requirements. Make data breaches irrelevant.

Key benefits

Easy

No application code modification required

Fast

Deploy in hours not weeks

Comprehensive

One solution for masking, tokenization, and encryption

Secure

AES cryptographic protection

Flexible

No impact to user experience

Key Capabilities

No-code Changes

Legacy Applications can be migrated without expensive and time-consuming code changes.
Third-party apps like Tableau work out of the box.

Protect data-in-use (Least privileges) with dynamic data masking

Masking using role-based access control (RBAC) can be set per application or even per user.
Even the DBA can be denied access to sensitive data.

Real query-able encryption

Database-side operations like sort, search, math, and indexing can still be accomplished on encrypted data with negligible change in performance

GenAI and pgvector Ready

Encrypt sensitive PII values in text chunks and embeddings
Perform similarity searches and other vector operations directly on encrypted values
Prevent data breaches through embeddings when using PostgreSQL as vector database with pgvector

Tokenization without additional infrastructure.

Many applications can’t handle the ciphertext of traditional encryption. Format preserving encryption (FPE) generates ciphertext that matches the datatype (down to the characters) and length of the plaintext.

SaaS multi-tenant data isolation

If tenants (your customers) demand that they get their own table or database to protect and isolate their data, then the scale advantage of SaaS is lost. Use Baffle record-level keying (RLK) or logical database-level keying (LDK) to isolate tenant data but maintain the SaaS scale.

Tenants can even provide access to their own encryption keys. This provides them more confidence in the security of their data and if hey ever remove access to their keys, their data is effectively “shredded”, so they don’t have to worry about ensuring the data is disposed of properly.

Learn More

Compliance

NIST.FIPS.197 AES Encryption Standard
NIST 800-38G Format Preserving Encryption

3.5.1 PAN (credit card data) is rendered unreadable anywhere it is stored by using…strong cryptography
3.5.1.2 If disk-level or partition-level encryption (FDE) … is used to render PAN unreadable…(it must) also (be) rendered unreadable via another mechanism that meets Requirement 3.5.1.
3.4.1 PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN
3.4.2 When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate,defined business need.
Third-party service - Where a third-party service provider (TPSP) receives and/or stores only data encrypted by another entity, and where they do not have the ability to decrypt the data, the TPSP may be able to consider the encrypted data out of scope if certain conditions are met.

GDPR Article 34: Data subject notification required unless “…rendered personal data unintelligible….such as encryption”

Frequently asked questions

What about Transparent Data Encryption (TDE)?

Open-source PostgreSQL doesn’t support TDE but it isn’t an ideal solution in any case. TDE was created a long time ago to protect against physical theft of the database hard-drives. The idea is simply to encrypt the data before it is saved to disk. While physical security is critical, it isn’t the threat vector that keeps CISOs up at night in modern datacenters. Encrypt laptop and phone drives to protect against physical theft, but modern enterprise databases require more.

What about Full Disk Encryption (FDE)?

What about pgcrypto?

Pgcrypto is a plug-in that is controlled by the application but implemented by the database. This puts the burden of managing sensitive data and key management all on the application, so code changes are required. Centralization of policies or key management across applications requires more effort. The keys are in storage, retrieved by the application, and sent to the database, so they are exposed in many locations. Once encrypted, then database-side operations won’t work.

Are there other ways to do real query-able encryption?

The industry calls operations on encrypted data “Privacy Enhanced Computation.” There are three major approaches.

The first is homomorphic encryption, where algorithms are performed on the encrypted data itself. This is computation intense, and therefore slows operations by orders of magnitude.

The next is secure multi-party computation, where the data is broken-up into parts that can’t reveal the data individually and those parts are stored in separate locations. When needed, the separate parts are brought together to perform the operations.

The complexity of this approach says everything about its performance and ability to scale. The last one is “secure enclaves” where specialized hardware is used to pull the encrypted data in a secure location in a processor, perform the operations and sent the results. This is performant, but locks in a vendor and doesn’t scale horizontally because the data can’t be spread across multiple instances.

Can’t I do tokenization with a simple look-up table?

Could I create an API to do encryption?

Can I put agents on the application that intercept the data and encrypt it as it goes to the database?