Recently, an unnamed car rental agency experienced every organization’s worst nightmare. As reported by VentureBeat, cloud-incident response business Mitiga discovered that 51 columns and 10,000 rows of rental transactions had been exfiltrated from the agency’s MySQL database via Amazon RDS/EBS snapshots. Contained in these snapshots was a massive amount of personally identifiable information (PII), including names, contact information, marital status and more. If the sheer amount of PII isn’t enough to send a chill down your security team’s spine, the fact that the snapshots had been leaked for over a month prior to Mitiga’s discovery should.
And this is only one example of enterprises losing control of highly-sensitive PII. In recent years, it seems like not a month goes by without the story of a high-profile data leak, forcing companies to reassess how they’re handling their own PII to prevent their name from appearing in the next headline. After all, these incidents have major consequences—damaging revenue, reputations and potentially opening businesses up to legal repercussions if it comes to light they were negligent or non-compliant in their storage approach.
That’s why EDB decided to put together this blog, offering a range of best practices that Postgres administrators and users can employ to ensure they don’t become the next PII horror story. Not only will we discuss how to prevent the specific instance of exfiltration that befell the anonymous car rental agency, but also general strategies to make sure bad actors cannot get ahold of your PII.
How to prevent PII leaks from database snapshots
For IT teams and administrators, database snapshots can be a valuable tool for sharing relevant information within an organization, especially when it comes to auditing and reporting. Rest assured, in order to protect yourself from exfiltration, you don’t need to abandon database snapshots altogether.
But you do need to be constantly aware of and vigilant about the information those snapshots contain.
If you’re using Community PostgreSQL, you have a variety of ways to protect that information. First, if you’re using volumes—such as an EBS volume—you should always encrypt the volumes which contain PII and WAL files. Even if you were to take a snapshot of said files, those snapshots wouldn’t be able to convey any valuable information due to their encryption.
For an additional layer of encryption, EDB recommends using the pgcrypto module or DBMS_CRYPTO—which was built off pgcrypto and includes Oracle database compatibility. Both of these modules can encrypt specific columns or data, such as those that contain PII. This level of flexibility is incredibly valuable both for security and performance, as it ensures that applications that require certain pieces of data are not hamstrung by encryption.
To ensure the total protection of your PII, make sure that you apply these same encryption protocols to your backups.
Taking PII protection to another level
Here at EDB, we take security very seriously. That’s why EDB Postgres Advanced Server (EPAS) comes with DBMS_CRYPTO built, saving your organization the time it might take to download and integrate it into your PostgreSQL. Additionally, EPAS includes a robust obfuscation option designed specifically to obfuscate procedures/database codes that might have important logic for processing PII information and obfuscating passwords in the Postgres log files. We highly recommend taking advantage of this setting.
These capabilities will only expand with the release of EPAS version 15, which launches in Q2 of 2023. Among its many features, this update will include extra layers of encryption, including Transparent Data Encryption. Transparent Data Encryption provides encryption for data files, Write Ahead Log (WAL) and temporary files. It solves the problem of protecting data at rest, encrypting databases on storage like EBS volume and, consequently, on backup media. Using TDE, enterprises can prevent unauthorized accessing or viewing of data at the operating system file system level and on backup storage.
For enterprises who might want to find alternatives to database snapshots when possible, EDB’s Backup and Recovery Manager (BARMAN) can backup PostgreSQL/EDB Postgres Advanced Server, and backups can be encrypted using tools like GPG. Enterprises can also use encrypted volumes/object storage for storing their backups or pgBackrest for encrypted backup that teams can share in place of a snapshot. Finally, solutions and services like EDB Postgres Distributed and EDB Community 360 provide extreme database high availability and enterprise-grade support for Community Postgres respectively. These offerings ensure you always have access to your most vital data and can quickly address issues that may impact security.
Data protection best practices
Of course, EBS and RDS snapshots are not the only way in which PII and other sensitive types of data can make it out into the world. While cataloging every possible exfiltration scenario might be enough to drive your IT manager insane, EDB also has a number of best practices to help keep your data where it belongs.
When you’re logging sensitive information, you should ask yourself a few questions:
- How am I logging this? As a general rule, sensitive information like PII should not be in log files. By tuning your logging and audit parameters, you can prevent this information from being stored in a way that leaves it vulnerable to leakage.
- Am I using prepared statements or procedures with prepared statements? Another easy way to avoid the risk of a data leak is to leverage procedures that automatically prevent the improper logging of sensitive information. With tools like EPAS, you can further obfuscate these procedures for additional security.
- The last question is both the most important and the most fundamental: who has access to this data, and do they really need that access?
While businesses often pride themselves on running a tight ship when it comes to data access and permissions, we’ve encountered many organizations where unnecessary privileges have been given to team members who have no need for them—a practice which leaves PII extremely vulnerable.
Why? Well, in most of these cases IT teams believe it’s easier to grant Postgres Superuser privileges than adding and removing permissions over and over, which they see as a drain on their time. The problem is that the majority of personnel don’t need that level of access and—even if they themselves are not bad actors—every time it's granted, your grip on your most sensitive data loosens ever so slightly, until you risk total exposure.
By being conscious and strategic with who has access to what and how your procedures and parameters are tailored, you’re 80% of the way to top-notch security for your PII. With the additional help of tools like EPAS DBMS_CRYPTO or pgcrypto, you can get yourself as close to 100% as is possible nowadays.
Protect your business’ PII, have peace of mind
Recently, one of our customers told us something that really resonated: “One of the things we really like here is getting a good night’s sleep. Working with a team that can assure that is brilliant.”
With these best practices and strategies, you can achieve that. Whether you’re running Community PostgreSQL or enterprise Postgres, by deploying the right solutions, the proper strategies and the appropriate mindset, you can protect your most sensitive data, and move forward with total peace of mind.