A PostgreSQL Security Baseline for Enterprise Systems
Date Published
Reduce the exposed surface
Keep PostgreSQL on private networks and allow only required application, administration, replication, monitoring, and backup paths. Firewall rules and pg_hba.conf should both enforce the design. Avoid broad CIDR ranges, wildcard database access, and public listeners. Administrative access should pass through a managed bastion, VPN, or zero-trust access layer.
Separate identities and ownership
Give each application and automation function its own login role. Use NOLOGIN owner roles for databases and schemas, then grant narrowly scoped rights to runtime roles. Revoke default CREATE privileges on the public schema when they are not required. Human administrators should use named accounts and assume elevated roles only for the duration of approved work.
Protect credentials and transport
Use SCRAM-SHA-256 rather than legacy password storage, rotate credentials, and keep them in a secrets manager instead of source code or images. Require TLS across untrusted networks and verify server identity, not just encryption. Automate certificate renewal and alert well before expiry.
Audit high-value activity
Log authentication failures, role and privilege changes, schema changes, configuration changes, and slow or failed statements according to policy. pgaudit can add structured session and object auditing where regulatory requirements justify it. Centralize logs, restrict modification, define retention, and test that alerts reach an accountable owner.
Patch and verify continuously
Track PostgreSQL, operating-system, extension, pooler, and backup-tool security updates. Rehearse minor updates and rolling maintenance on a representative environment. Regularly review superusers, memberships, unused roles, permissive pg_hba rules, vulnerable extensions, and internet exposure. Security is a maintained operating state, not a one-time hardening document.