security best practices for your postgres deployment
TRANSCRIPT
Security Best Practices for your Postgres Deployment
Presented bySameer Kumar, DB Solution Architect, Ashnik
“By default PostgreSQL is Possibly the most security – aware database available…”
- Database Hacker’s Handbook
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
Postgres Security
pgD
ayA
sia
20
16
, Sin
gap
ore
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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
Securing Postgres
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
• 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
pgD
ayA
sia
20
16
, Sin
gap
ore
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
pgD
ayA
sia
20
16
, Sin
gap
ore
- 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
Twitter - @sameerkasi200x | @ashnikbiz
Email - [email protected] | [email protected]
LinkedIn - https://www.linkedin.com/in/samkumar150288
We are hiring!