Photo by Caspar Camille Rubin on Unsplash
PostgreSQL may be the world’s most advanced open source database, but its 82 documented security vulnerabilities per the CVE database also make it highly exploitable. The popular object-relational database is considered superior to others regarding out-of-the-box security. However, proper measures are still required to protect web applications and underlying data. The following are 5 common ways to secure your PostgreSQL implementation from cyber attacks.
1. Do Not Use Trust Security.
When using Trust security, PostgreSQL assumes that anyone connected to the server is authorized to access the database with the database username specified (i.e., the DB trusts that they are who they say they are). To lock this down, edit your pg_hba.conf to use a non-trust authentication method like MD5. Additionally, template1 and PostgreSQL default databases should be revoked remote login access.
2. Use Hash-Based Column encryption for values that don’t need to be decrypted
Encryption methods such as AES are two-way—they can be decrypted—while hash-based encryption methods such as MD5 are one-way. For values that only need to be checked for a match, such as passwords, use one-way encryption for an added layer of security if table data is compromised.
3. Use Physical Separation to Isolate Datasets that Need to be Kept Apart
Using pg_hba and RBAC to control access to physically disparate databases ensures that data in two tables cannot be accessed/viewed simultaneously. Of course, this will break SQL joins, so only use in appropriate scenarios that require physical access separation during the life of a login session.
4. Consider Disabling Remote Access to PostgreSQL
This action alone eliminates a host of substantial attack vectors. Again, this can be set in the pg_hba.conf. If remote access to the database is required, SSH to the server housing the database and use a local connection afterward. Alternatively, you can set up tunnel access to PostgreSQL through SSH, effectively giving client machines access to remote databases as if they were local.9. Assign a Distinct Role for Each Application.
5. Use pg_hba.conf to Specify Which Hosts Can Use SSL-Encrypted and Unencrypted Connections
This can be accomplished by adding and removing the appropriate entries in the pg_hba.conf file. Generally speaking, all clients should be forced to connect with SSL by adding the necessary hostel entries. Using this model, all host entries should be removed (aside from localhost).
