5 things people do to make postgres vulnerable
9
Click here to load reader
-
Upload
pgday-asia -
Category
Software
-
view
93 -
download
0
Transcript of 5 things people do to make postgres vulnerable
5 things people do to make Postgres
Vulnerable
2 Level Security in Postgres
• Authentication – Server, User, Database and Password
• Authorization – Access to table, data, objects
Software are not designed to be Hacked
• Convenient setup without “red-tape” bureaucracy of DBA
• “Best Practices” are not for me
• Why do I need to test dev/UAT/SIT/pre-production with hardened system?
• My ISV vendor certified Postgres on 9.4.5, it will not run on 9.4.6
Patching is not for me!
• My Postgres is working fine, why do I need this patch?
• My ISV certified Postgres on 9.4.1, what if application breaks by moving to 9.4.4?
• I upgraded OpenSSL and Linux, do I need to upgrade Postgres too?
Why added fencing with pg_hba?
• I trust all IP in my network, why do I need pg_hba.conf?
• I already have firewalls, why restrict hosts with pg_hba?
• Allow all user from all IP
host all all 0.0.0.0/0 md5
I need DBA/SUPERUSER privileges for all user
• My application needs a lot of privileges, looks like it needs a superuser
• I am tired of granting privileges one by one, let’s grant superuser
• In non-production environments, I can run with DBA user
I don’t need Auditing
• I have all the security constraints in place, then why audit?
• Auditing does not share much information
• Auditing is a huge overhead for performance and disk requirements
• Audit rules needs to be defined only once
It’s trouble to input the password multiple times
• As a DBA – ‘God of DB systems’ I need to login many times
• DB server can trust my IP address
• Only I use my machine
• My IP is never going to change or be reallocated
• My laptop password is simple, but who would try to hack it?
