Ashnik Database Solution Architect, Sameer Kumar, an Open Source database evangelist talked about the "Security Best Practices for your Postgres Deployment" at the recent pgDAy Asia event held in Singapore in March 2016. Key areas he presented were: - Security Model - Security Features in Postgres - Securing the access - Avoiding common attacks - Access Control and Securing data - Logging and Auditing - Patching – OS and PostgreSQL

1. Security Best Practices for
your Postgres Deployment
Presented by
Sameer Kumar, DB Solution Architect, Ashnik
“By default PostgreSQL is Possibly the most
security – aware database available…”
- Database Hacker’s Handbook

2. pgDayAsia2016,Singapore
• Security Model
• Security Features in Postgres
• Securing the access
• Avoiding common attacks
• Access Control and Securing data
• Logging and Auditing
• Patching – OS and PostgreSQL
Agenda
2

3. pgDayAsia2016,Singapore
• A random Oracle-DB2 DBA who started working on PostgreSQL
• And found it absolutely great
• Works for Ashnik Pte Ltd – Open Source Solutions and consulting
• Who also works on noSQL databases
• Hobbies – Cycling and Photography
3
About Me

4. Postgres Security

5. pgDayAsia2016,Singapore
Secure access is a two step process:
• Authentication
• Ensures a user is who he/she claims to be
• Authorization
• Ensures an authenticated user has access to only the data for which
he/she has been granted the appropriate privileges.
Security Model: Authentication and Authorization
5

6. pgDayAsia2016,Singapore
• Object level privileges assigned to roles and users
• Virtual Private Database- Row level security
• Kerberos and LDAP authentication
• Host base authentication
• SSL communication
• Data Level Encryption (AES, 3DES, etc)
• Ability to utilize 3rd party Key Stores in a full PKI Infrastructure
• Foundation for full compliance with the strictest of security
standards (PCI Data Security Standard)
• Flexible field level encryption and row level security
High Level Features
6

7. pgDayAsia2016,Singapore
• Kerberos : Kerberos based encrypted "ticket" for authentication
• Password : md5 and plain text
• LDAP authentication : It uses LDAP as the password verification
method
• Trust : Authentication without password or Auth token
• RADIUS: Use radius server for authentication
Different Authentication Methods
7

8. Securing Postgres

9. pgDayAsia2016,Singapore
• Override the default port of Postgres
• Use a non-default name for the superuser
• Can be specified during “initdb”
• While initializing the cluster with “initdb” use -A to specify
authentication mode
• By default each new DB has connect privilege granted to public
• revoke connect on my_new_db from public;
• grant connect on my_new_db to my_app_user;
Override the defaults
9

10. pgDayAsia2016,Singapore
• Use listen_addresses to control where you Database is listening for
connections
• Make sure that you don’t listen on public network interface
• Control who can connect from where
• Use pg_hba.conf to control which user can connect to specific databases from
specific IP addresses
• Avoid using general rules e.g. Database name “all” or IP Address range –
“0.0.0.0/0”
• Restrict superuser access
• Allow superuser to make connections only from the localhost/unix domain
• Avoid using “trust” authentication
• Effectively use “reject”
• reject the connections from blacklist/exception IP addresses/users
Secure the access
10

11. pgDayAsia2016,Singapore
• Use different users for different purpose
• A separate user for owning application database and schema
• Use a different user for making DB connection from application
• Allow DBAs to use their personal users (e.g. DBA Sameer uses a
user “sameer”)
• Use a different (non-superuser) user for physical backup and
replication
• Allow replication connection using specific user from specific hosts
• Use a different user for logical backup
Separating users as per their role
11

12. pgDayAsia2016,Singapore
• Password hacks are vulnerable to
• Weak passwords
• Re-use of old passwords
• Brute-force password attack
• These attacks can be avoided by
• Maintaining strong passwords or enforcing password policy
• Enforce password expiry and reuse policy
• Enforce account lock policy on consecutive authentication failures
• These can be enforced with external authentication methods e.g. LDAP,
PAM etc
Avoid Password Hacks
12

13. pgDayAsia2016,Singapore
• Control the number connections
• max_connection
• superuser_reserved_slots
• max_replication_slots
• max_wal_senders
• Don’t use a superuser as an application user
• For multi-user/multi-DB server set DB or user level limit
• Set temp_file_limit to control the disk usage per session for sorting
• Log long running queries
• Monitor transactions and sessions
• long running transactions
• sessions with “idle in transaction state”
• Use connection timeout
Avoid Denial of Service Attack – Set limits
13

14. pgDayAsia2016,Singapore
• Set per statement/sessions parameters wisely
• work_mem
• maintenance_work_mem
• temp_buffers
• max_prepared_transactions
• Some of these parameters can be set at user, db or session level
• Set them at appropriate granularity
Avoid Denial of Service Attack – Parameter
granularity
14

15. pgDayAsia2016,Singapore
• Typically network attacks
• Eavesdropping
• Protection against Man-in-the-middle
• Impersonation
• Postgres clients send query in plain-text format
• Data is sent is not encrypted
• Use SSL connection to encrypt client/server communication
• sslmode – prefer is not secure
• sslmode – require – data is encrypted but still exposed to impersonation and
Man-in-the-middle
• Use sslmode verify-ca or verify-full in client connection to avoid all THREE
• SSL usage must be configured on both client and sever
Avoid Network Spoofing
15

16. pgDayAsia2016,Singapore
• Control which users have access to what
• Use GRANT and REVOKE to control access to
• DATABASE
• TABLESPACE
• SCHEMA
• OBJECTS
• Use row level security to restrict access to specific rows for specific
users
Access Control
16

17. pgDayAsia2016,Singapore
• Use pg_crypto or application API for encryption/decryption
• Encrypt personal and profile data e.g. Credit Card information
• Key Maintenance
• Use an intermediate key store
• Use a hardware for key/token generation on client end
• Hash the sensitive data e.g. password, pin etc
• Matches are always done using hash of input criteria
• Use disk level or file system level encryption
Securing Data
17

18. pgDayAsia2016,Singapore
• Enable logging and auditing to ensure all events are logged
• logging_collector must be on
• log_destination
• log_directory
• Avoid overwriting log files
• Set log_truncate_on_rotation to off
• PostgreSQL does not have separate Audit handlers
• pg_audit
• EDB Audit
Logging and Auditing – Avoid pitfalls
18

19. pgDayAsia2016,Singapore
• Log important events
• Connections and Disconnections, Long running operations, Replication
commands
• Log Resource usages
• Checkpoints, Temp Files
• Control information being logged
• Statements, Hostname, Application Name
• log_line_prefix – Application Name, Hostname, DB Name, User Name etc
• PostgreSQL does not have separate Audit handlers
• pg_audit
• EDB Audit
• Triggers and Event Triggers
Logging and Auditing – Log to Track
19

20. pgDayAsia2016,Singapore
Avoid Vulnerabilities – Timely Patching
• Keep a tab on latest vulnerabilities announced by various
organizations
• Ensure that your whole stack is timely patched
• A bug or security vulnerability in OS or one of the libraries can lead
to a leak in DB as well
• Ensure you apply OS and library patches
• Ensure you apply patches released by Postgres community/your
vendor
20

21. pgDayAsia2016,Singapore
- Achieving PCI Compliance with PostgreSQL
- IBM Developer Work Article on Total Security in PostgreSQL
- Bruce Momjian’s PPT
- PostgreSQL Hardening – By OpenSGC
Further Resources
21

22. Twitter - @sameerkasi200x | @ashnikbiz
Email - sameer.kumar@ashnik.com | success@ashnik.com
LinkedIn - https://www.linkedin.com/in/samkumar150288
We are hiring!