Database security is an increasingly critical topic for any business handling personal data. Data breach can have serious ramifications for an organization, especially if the proper security protocols are not in place.
There are many ways to harden your database. As an example PostgreSQL addresses security using firewalls, encryption and authentication levels among other ways.
2ndQuadrant hosted a webinar on Database Security in PostgreSQL to highlight security concepts, features and architecture. The webinar was presented by Kirk Roybal, Principal Consultant at 2ndQuadrant – the recording is now available here.
Some of the questions that Kirk responded to are listed below:
Q1: What are your thoughts on performance of row-level security vs. doing that filtering via WHERE at the application level and how that affects development? I.E. now that you’re filtering via DB capabilities you lose the visibility of that being done at the application level – it becomes a bit of a black box of “it just works” for the development team.
A1: The PostgreSQL query parser is involved in evaluating the constraint either way. Since this is mostly dependent on PostgreSQL, there will be very little or no measurable difference in performance. Putting the security in the database has the advantage of being modifiable without changes to the application layer.
Q2: Do you have any suggestions for encrypting data at rest?
A2: PostgreSQL provides pgcrypto as an extension. PostgreSQL also allows you to create your own datatypes, operators and aggregates. Put the two together and you have encryption at rest.
Q3: Is it possible to configure Azure AD authentication too?
A3: Yes, if you create a bare Linux machine, you can configure anything you want.
Q4: Do you support performance tuning on AWS RDS Postgres?
A4: Yes, we do provide the Performance Tuning service for RDS. Because of the closed nature of the system, however, there might be some advanced settings that we won’t be able to tune.
Q5: What are the main differences between the PostgreSQL security model and the MySQL security one?
A5: MySQL does not enforce a security model by default, and does not delegate authentication to outside sources. Since the built-in mechanisms have known compromises, MySQL effectively provides no security that would pass a hostile audit. Needless to say, we are biased towards PostgreSQL :-)
Q6: What is your advice to start with PostgreSQL to become PostgreSQL DBA?
For any questions, comments, or feedback, please visit our website or send an email to [email protected].