Is Postgres Secure?

With the rise of Postgres, new organizations are evaluating how to benefit from its power and flexibility. As that evaluation progresses, Postgres advocates must address the question, "Is Postgres secure?"

There are a variety of ways to answer this question, but the short answer is a confident "Yes!"

At Crunchy Data, we often collaborate with organizational stakeholders to address this question. Many organizations have used the same collection of databases for years (maybe decades). The idea of adopting a new database often requires first brushing off the security criteria, and then evaluating whether Postgres meets these requirements.

This post provides a framework for thinking through how you can confront "security questions" as you embark on your Postgres journey.

Does Postgres Have the Security Functionality We Require?

Chances are your organization is using an alternative database today. As a result, your organization has some expectation of the security functionality that a database must provide. An initial question is often "Does Postgres have the necessary security functionality that we rely on from $OTHER_DATABASE?"

Short answer is YES.

Common Criteria for Information Technology Security is an international standard (ISO/IEC 15408) for computer security certification. Common Criteria (CC) provides database specific security guidance through the Protection Profile for Database Management Systems (DBMS PP). The DBMS PP presents the "security functional requirements" and "security assurance requirements" that representatives from industry, government, and CC Test Laboratories have determined to be applicable to databases. According to DBMS PP, in order for a database to achieve Common Criteria certification, it is necessary for the database to provide:

• Discretionary Access Control (DAC) limits access to objects based on the identity of the subjects or groups to which the subjects and objects belong, and which allows authorized users to specify how the objects that they control are protected.
• Audit Capture for creation of information on all auditable events.
• Authorized administration role to allow authorized administrators to configure the policies for discretionary access control, identification and authentication, and auditing. The TOE must enforce the authorized administration role.
• Limitation of the number of concurrent sessions and restrictions on establishing sessions.

Our team went through the initial Common Criteria certification of PostgreSQL 9.5 in 2016 and we've just completed recertification on PostgreSQL 12. We validated that PostgreSQL and several open source extensions, including PostGIS, pgaudit and the JDBC driver, support the CC certification capabilities.This is a powerful statement: while the Common Criteria certification does have some specifics to how Crunchy Data distributes PostgreSQL, all of the components are just the open source projects!

CC certification provides lab based validation that open source Postgres, with these extensions, provides the full set of security functionality required by the DBMS PP and that users can expect from a database.

How Do I Securely Deploy and Administer my Postgres Database?

The existence of security functionality alone is of course just the beginning. Using these capabilities consistent with best practices are necessary for secure use of Postgres.

In working with the Center for Internet Security (CIS) and the United States Defense Information Security Agency (DISA), we've developed security guidance for the deployment, configuration and administration of Postgres. The most recent versions of these standards bring them current with PostgreSQL 13, the most recent major release. The Security Technical Implementation Guide (STIG) in particular provides guidance on the configuration of PostgreSQL to address requirements associated with:

• Auditing

• Logging

• Data Encryption at Rest

• Data Encryption in Transit

• Access Controls

• Administration

• Authentication

• Protecting against SQL Injection

There are many things that you must consider when you want to securely manage a PostgreSQL database, but these guides provide ways you can tick the standard "checkboxes" when to securely deploy your data.

How Does Postgres Address SQL Injection?

Despite the widespread awareness of this attack vector, the risk of SQL injection attacks remains a common question. Through SQL injection attacks, bad actors “inject” data into your SQL query using destructive phrases or unescaped parameters. Hackers use this technique to gain access to business data and personal information, as well as modify or delete the content within your database.

Most modern ORMs keep you well protected and are actively tested against these vulnerabilities. A basic security tool will also tell you if you're susceptible.

For Postgres users, writing customer SQL as part of their application, specific guidance on the topic is also applicable.

The best practices from the CIS Benchmark and the DISA STIG will also provide the necessary protection.

How Can I Address My Organization's Encryption Requirements?

Data encryption is a common organizational requirement and security best practice. The general requirement typically includes both "encryption of data at rest" and "encryption of data in transit". Each has its own range of solutions, including full disk encryption, volume encryption, and folder encryption.

Postgres enables data encryption in conjunction with the broader enterprise IT environment through a number of features, including the "pgcrypto" extension, and support for FIPS validated encryption modules.

While this post will not attempt to do the subject justice, a few initial observations based on how we see our customers address these requirements:

• For "Encryption At Rest", our customers often address these requirements through the storage layer or by your infrastructure provider (such is the case on Crunchy Bridge).

• For "Encryption In Transit", Postgres enables users to connect over TLS and setting explicitly in your connection string.

Again, the CIS Benchmark and the DISA STIG also provide specific configuration guidance.

The Hot Topic of the Day: Supply Chain

Recent news has highlighted the risks and importance of understanding the software supply chain. Postgres is of course an open source software project maintained by an active global development community with a high degree of transparency. This transparency provides an important mitigation against potential security risks. That said, freely available source code is a mitigation against supply chain risk, not a cure all.

The core Postgres source code is only one consideration. Production Postgres deployments often make use of a broad range of Postgres tools and extensions. It is important to consider how you will maintain a secure supply chain for this full ecosystem of software. It is also necessary to think through the various "stops" along the software supply chain path between the Postgres source code and the binaries running on your server.

One of the values provided by open source software vendors is maintenance and certification of the software supply chain. This is where the Common Criteria come in: the CC EAL 2+ certification provides third party validation of the software supply chain and support to ensure you are installing only trusted components.

Yes, Postgres is Secure

There is no shortage of good reasons to adopt Postgres in your data management toolbox. Postgres' security capabilities are just one of them.

It is a testament to the global Postgres community that open source Postgres can stand up to the security standards developed by leading proprietary database vendors and imposed by security conscious enterprise users, and enable security conscious users to adopt Postgres consistent with industry best practices.