Best Practices for Postgres Security
Start supercharging your PostgreSQL today.
Written by Juan José Gouvêa
As a PostgreSQL user, you will have to dig into many topics to get the most from your PostgreSQL database, from replication to schemas and performance. None, however, is as critical as Postgres security. Ensuring the security of databases is paramount in protecting your organization’s data assets. This means not only safeguarding data integrity and thwarting malicious threats but also adhering to legal obligations related to access permissions and privacy regulations.
In this article, we’ll look at some best practices for securing your PostgreSQL database, mitigating risks, and ensuring the safety of your data from unauthorized access and potential breaches.
PostgreSQL Access Control
To ensure that only authorized processes and remote connections have access to your PostgreSQL database—providing a foundational layer of security for all your PostgreSQL deployments—you need to secure access via Unix Domain Sockets (UDS) and TCP/IP. Both require careful configuration of socket parameters and firewall rules.
Unix Domain Sockets
Unix Domain Sockets (UDS) provide a file-based access control system, managing permissions between processes on the same host. They facilitate data exchange between processes, establishing a secure and efficient method for local inter-process communication.
PostgreSQL UDS configuration: PostgreSQL allows configuration of Unix Domain Sockets through parameters such as unix_socket_directories, unix_socket_group, and unix_socket_permissions. These parameters enable precise control over the location, access group, and permissions of the socket files, enhancing security for database connections.
unix_socket_directories: Defines the directories where Unix-domain sockets for client connections will be placed.
unix_socket_group: Sets the owning group of the Unix-domain sockets.
unix_socket_permissions: Specifies the access permissions for the Unix-domain sockets.
TCP/IP
TCP/IP protocol is pivotal for managing remote database connections, defining how data is transmitted over networks. It includes specifying port access to ensure secure and controlled access to PostgreSQL databases.
Firewall configuration: By default, PostgreSQL listens on port 5432 for incoming connections. Configuring a firewall to restrict access to this port is essential for preventing unauthorized access. Only known and trusted IP addresses should be allowed to connect, significantly reducing the risk of external attacks.
Example firewall rule:
sudo iptables -A INPUT -p tcp --dport 5432 -s trusted_ip_address -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 5432 -j DROP
This setup allows connections to port 5432 from a trusted IP address while dropping requests from unknown sources.
PostgreSQL User Roles and Groups
Creating users
Creating users in PostgreSQL is fundamental for database access management. Users are distinct from operating system users, having global scope across a database cluster rather than being restricted to individual databases. The primary SQL command for this operation is CREATE USER, which allows specifying the username and optionally, a password for the user. The process is straightforward:
CREATE USER username WITH PASSWORD 'password';
This command creates a new database user with login capabilities, setting the groundwork for defining access levels and permissions specific to database operations.
Creating roles
Roles in PostgreSQL serve as a versatile mechanism for managing database permissions. They can represent individual users, groups of users, or a set of permissions. Essentially, roles allow for the assignment of access rights and responsibilities within the database system. Creating a role is done using the CREATE ROLE command and it can include attributes such as login permissions, database creation rights, and role management capabilities:
CREATE ROLE role_name WITH LOGIN CREATEDB;
This example demonstrates the creation of a role with the ability to log in and create databases. Roles streamline the management of permissions, making it easier to enforce security policies through a centralized role-based access control system.
Row-level permission
PostgreSQL's Row-Level Security (RLS) feature adds a finer granularity of access control, allowing administrators to define policies that restrict access to specific rows within a table. This is particularly useful in multi-tenant environments where users should only see their data. To enable RLS, you use the ALTER TABLE command:
ALTER TABLE table_name ENABLE ROW LEVEL SECURITY;
Following this, policies can be defined to specify the conditions under which rows are visible or modifiable by a particular role or user, using the CREATE POLICY command. This enables precise control over who can access or modify individual rows within a table, enhancing the security and privacy of the data stored in PostgreSQL databases.
Implementing comprehensive user roles and groups, alongside row-level permissions, is pivotal in securing PostgreSQL databases. These mechanisms together provide a robust framework for managing access control, ensuring that users have appropriate permissions tailored to their roles within an organization.
PostgreSQL Encryption
SSL encryption
SSL (Secure Sockets Layer) encryption is a fundamental security feature for safeguarding data in transit, providing end-to-end security to prevent man-in-the-middle attacks. While PostgreSQL does not natively implement SSL, it supports SSL connections to encrypt data between clients and servers. This ensures that sensitive information remains secure during transmission. A full tutorial on configuring SSL for PostgreSQL would be too extensive for this blog post, but an overview involves generating SSL certificates, configuring the PostgreSQL server for SSL, and enforcing SSL connections for clients.
Database encryption with pgcrypto
The pgcrypto extension adds robust encryption capabilities directly within PostgreSQL, allowing for the encryption of individual fields, entire tables, or data transactions. This is particularly useful for sensitive data that requires encryption at rest, such as healthcare records or personal identification information.
Basic example of using pgcrypto: To encrypt data without specifying a key explicitly, you can use the pgp_sym_encrypt function. Here's a simple example that encrypts a text string:
SELECT pgp_sym_encrypt('Sensitive data here', 'encryption_key_here') AS encrypted_data;
Decrypting the data can be done with the corresponding pgp_sym_decrypt function:
SELECT pgp_sym_decrypt(encrypted_data, 'encryption_key_here') AS original_data
FROM (SELECT pgp_sym_encrypt('Sensitive data here', 'encryption_key_here') AS encrypted_data) AS subquery;
These examples highlight PostgreSQL's flexibility in managing data security, offering tools for both securing data in transit with SSL and protecting data at rest using pgcrypto. Implementing these security measures can significantly enhance the overall security posture of PostgreSQL databases, ensuring sensitive information is adequately protected against unauthorized access or exposure.
PostgreSQL Security With Timescale
PostgreSQL security support
Timescale enhances PostgreSQL by seamlessly integrating with it, inheriting its robust security framework while introducing its own advanced features. This integration ensures that users benefit from the foundational security measures PostgreSQL is known for, including authentication, authorization, and data encryption capabilities.
Using pgcrypto with Timescale
The pgcrypto extension is a key component of PostgreSQL's security, offering cryptographic functions such as encryption, decryption, and hashing directly within the database. Timescale fully supports pgcrypto, enabling users to secure time-series data efficiently. Implementing pgcrypto with Timescale involves simple steps that greatly enhance data security.
How to use pgcrypto with Timescale
After ensuring Timescale and PostgreSQL are properly installed, you can activate pgcrypto by executing the command:
CREATE EXTENSION IF NOT EXISTS pgcrypto;
This allows the use of various cryptographic operations within your Timescale database environment. For example, to encrypt sensor readings in a hypertable, you could use the following approach:
-- Create a table for sensor readings
CREATE TABLE sensor_readings (
time TIMESTAMPTZ NOT NULL,
device_id BIGINT,
reading BYTEA
);
-- Convert the table into a hypertable
SELECT create_hypertable('sensor_readings', 'time');
-- Insert an encrypted reading
INSERT INTO sensor_readings (time, device_id, reading)
VALUES (NOW(), 1, pgp_sym_encrypt('20.5', 'supersecretkey'));
To decrypt the data for use, you would use:
SELECT time, device_id, pgp_sym_decrypt(reading, 'supersecretkey') AS reading
FROM sensor_readings
WHERE device_id = 1;
These examples showcase the straightforward application of pgcrypto functions to encrypt and decrypt data, ensuring that sensitive information remains secure even when stored in backups or dumps.
Timescale Security Features
Timescale goes beyond the baseline security provided by PostgreSQL to offer several advanced features that ensure comprehensive protection for your data:
Data encryption: Data in Timescale is always encrypted, both in transit and at rest, using industry-standard algorithms. This includes active databases and backups, with encryption keys managed securely by AWS Key Management Service (KMS).
Networking security: Access to Timescale services is strictly over TLS-encrypted connections, with no option for unencrypted plaintext connections. This applies to all customer interactions with Timescale services.
Maintenance access protocol: Timescale employs a rigorous protocol for maintenance access, with all operator actions audit logged. This ensures that any necessary troubleshooting is conducted securely and transparently.
Privacy compliance: Timescale is committed to customer data privacy, complying with regulations such as GDPR. This commitment is reflected in Timescale's privacy policy and terms of service, ensuring that customer data is handled with the utmost care and respect.
SOC 2 Type 2 compliance: Timescale is SOC 2 Type 2 compliant, and our SOC 2 report is available for all the customers in our Enterprise Tier.
VPC peering: With Virtual Private Cloud (VPC) peering, you can replicate (as much as possible) the isolation of a self-hosted deployment and access your cloud data without the risk of having your services exposed to the public internet.
Check out our Docs or the Security at Timescale page to learn more.
Conclusion
In this article, we've explored essential best practices for securing a PostgreSQL database. We delved into access control, user roles and groups, and encryption techniques, providing a foundation to safeguard your data effectively. By understanding how to configure Unix Domain Sockets, TCP/IP protocols, implement row-level security, and utilize pgcrypto for encryption, you can mitigate risks and enhance the overall security posture of your PostgreSQL databases.
Timescale further extends PostgreSQL's robust security framework, offering advanced features like seamless integration of pgcrypto for cryptographic functions and comprehensive data protection strategies that encompass both data in transit and at rest. These enhancements are crucial for managing time-series data securely, ensuring that your sensitive information is protected against unauthorized access or exposure.
If you want to maximize your time-series data with top-of-the-line security, try Timescale today.