Your SlideShare is downloading. ×
PG Day'14 Russia, Secure PostgreSQL Deployment, Magnus Hagander
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

PG Day'14 Russia, Secure PostgreSQL Deployment, Magnus Hagander

583
views

Published on

Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL. …

Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.

PostgreSQL supports several options for securing communications when deployed outside of the typical webserver/database combination, or in a high security environments. This talk will go into some details about the features that make this possible. The main areas discussed are:

Securing the PostgreSQL infrastructure and runtime environment.
Securing the channel between client and server using SSL, including an overview of the threats and how to secure against them.
Securing the login process with methods including LDAP, Kerberos or SSL certificates.

Published in: Software, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
583
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Secure PostgreSQL Deployment PGDay'14 Russia St Petersburg, Russia Magnus Hagander magnus@hagander.net PRODUCTS • CONSULTING • APPLICATION MANAGEMENT • IT OPERATIONS • SUPPORT • TRAINING
  • 2. Magnus Hagander •PostgreSQL •Core Team member •Committer •PostgreSQL Europe •Redpill Linpro •Infrastructure services •Principal database consultant
  • 3. Security
  • 4. Security •It's hard
  • 5. Security •It's hard •No, really!
  • 6. Security •There is no one solution
  • 7. Security •There is no one requirement
  • 8. Security •PostgreSQL provides a toolbox •You don't need everything •Maybe you don't need anything...
  • 9. Secure PostgreSQL Deployment •Environment •Communication •Authentication
  • 10. Secure PostgreSQL Applications •Authorization/Permissions •Roles •Security barrier views •Security definer functions •RLS •etc...
  • 11. Secure PostgreSQL Environment •Only as secure as the environment •If someone owns the OS, they own the db •Owns the server -> owns the OS •Owns the datacenter -> owns the server •Defined trust levels! •e.g. outsourcing/cloud vendors
  • 12. Operating system •Pick your operating system •Something you know •Regardless of PostgreSQL •Secure "reasonably" •No other local users!
  • 13. Operating system •Use standard installers •Don't roll your own •Usually adapted for OS •Consistent security!
  • 14. Operating system •Keep updated •Both operating system and PostgreSQL •yum/apt makes it easier •But you have to use it! •Monitor!
  • 15. Operating system •Encrypted disks? •Performance/reliability implications •Key management? •What happens on restart?
  • 16. Multi instance •Different security domains? •Different OS user •Sometimes not well packaged •Virtualization/containers?
  • 17. Securing communications
  • 18. Securing communications •Do you need it? •Attack vectors? •Overhead!
  • 19. Securing communications •(physical) •VPN •ipsec •SSL
  • 20. SSL in PostgreSQL •OpenSSL only (sorry) •Certificate/key •Like any other service •Disabled by default on server •Enabled on client!!
  • 21. Certificates •Server certificate mandatory •Does not need public ca •Probably should not use public ca •"Snakeoil" works •But no MITM protection! •Use custom (dedicated?) CA!
  • 22. Server-side SSL •Set ssl=on •server.key/server.crt in data directory •Check permissions! •Restart, done.
  • 23. SSL negotiation •SSL negotiated between client and server •Server provides •Client decides •Controlled by sslmode parameter
  • 24. SSL negotiation •sslmode default is prefer •This is stupid.... •No guarantees
  • 25. SSL negotiation
  • 26. SSL enforcement •Client decides??!!?!?! •Huh?? •Client decides, but server can reject •Using hostssl in pg_hba.conf
  • 27. SSL enforcement .. hostssl xxx yyy ... .. •Always use!
  • 28. Client certificates •Not required by default •Can be requested by server •clientcert=1 in pg_hba.conf .. hostssl xxx yyy zzz abc clientcert=1 ..
  • 29. Client certificates •Provide in PEM format file •Or through OpenSSL compatible engine •Validated against root CA on server •PostgreSQL specific root •By default just needs to exist
  • 30. Authentication
  • 31. Authentication •Make sure it's the correct user •And that they can prove it
  • 32. A step back •Authorization and roles •I know I said I wouldn't...
  • 33. Superuser •Never use superuser •Disables all security •Allows arbitrary code execution! •Allows replacement of configuration!
  • 34. Authentication •PostgreSQL supports many methods •Host Based Authentication •Combined in the same installation! •Don't just "dumb down"
  • 35. pg_hba.conf •Top-bottom file •Filter by: •Connection type •User •Database •Connection source •"Firewall" and authentication choice
  • 36. pg_hba.conf •Order by most specific local all all peer host all all 127.0.0.1/32 md5 hostnossl webdb webuser 10.1.1.0/30 md5 hostssl all +admin 192.168.0.0/24 gss •Implicit reject at end
  • 37. Authentication methods •Many choices •Internal •OS integrated •Fully external •And some really bad ones...
  • 38. trust •Trust everybody everywhere •Why would anybody claim they're someone else? •"Turn off all security" •Any use case? Maybe one...
  • 39. trust •Use it? Change it!
  • 40. peer •Only over Unix sockets •Sorry Windows, sorry Java •Local connections only •Asks OS kernel •Trustworthy!
  • 41. md5 •Simplest one? •Username/password •Double MD5-hash •Do not use "password"
  • 42. ldap •Looks like password to client •Regular prompt •Passed over to LDAP server •No special support needed •Construct URLs different ways •Prefix+suffix •Search+bind
  • 43. ldap •Cleartext! •Use with ldaptls=1 •Use with hostssl •Password policies from LDAP server •Only authentication!
  • 44. gss/sspi •Kerberos based •Including Active Directory •Single Sign-On •No password prompt! •All Kerberos supported auth methods •Secure tickets •"krb5" deprecated/removed
  • 45. radius •Looks like password to client •Use with hostssl! •Shared-secret encryption to Radius server •Common for OTP solutions
  • 46. cert •Map client certificate to login •Uses CN attribute •Any certificate "engine" supported by OpenSSL •Normally uses PEM encoded files
  • 47. User name mapping •External systems with different usernames •Peer •gss/sspi •cert •Allow static or pattern mapping
  • 48. User name mapping •pg_hba.conf local all all peer map=local hostssl all all 0.0.0.0/0 cert map=cert •pg_ident.conf local root postgres .. cert /^cn=(.*)$/ 1
  • 49. Secure PostgreSQL Deployment
  • 50. Secure PostgreSQL Deployment •Determine your requirements •Determine your trust levels •Determine your attach surface •Determine your threat vectors
  • 51. Secure PostgreSQL Deployment •Deploy correct countermeasures •"Checkbox featuring" is useless •Lock all doors •E.g. why encrypt if disks are insecure •Why require smartcards if data is cleartext
  • 52. Layered security •A firewall alone doesn't protect you •Doesn't mean you shouldn't have one
  • 53. Too simple to mention •Never use trust •(not even in testing) •Use pg_hba.conf •Mix auth methods •Restrict IP addresses •Go SSL if you have to
  • 54. Iterative process •Re-evaluate •Requirements and landscape are dynamic!
  • 55. Thank you! Magnus Hagander magnus@hagander.net @magnushagander

×