Security Best Practices for your Postgres Deployment
4 likes6,802 views
The presentation outlines security best practices for PostgreSQL deployments including authentication, access control, and data encryption. Key focus areas are securing access, avoiding common attacks, implementing proper logging and auditing, and timely patching to mitigate vulnerabilities. It emphasizes the importance of using specific roles, strong password policies, and SSL connections to ensure robust security management.
Security Best Practices for your Postgres Deployment
- 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
- 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
- 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 - [email protected] | [email protected] LinkedIn - https://www.linkedin.com/in/samkumar150288 We are hiring!