Re: PostgreSQL Auditing

On Tue, Feb 02, 2016 at 01:05:46AM +0000, Curtis Ruck wrote:
> So Auditing, it seems that some people want auditing (myself, David Steele,
> 2nd quadrant, and probably others). I personally love postgresql, but
> until it can meet my annoying compliance requirements, I can't leverage it
> fully as my organization spends more time on meeting compliance, than
> actually doing development and engineering.

> So, in summary, what would it take to get the core PostgreSQL team to
> actually let auditing patches into the next version?

[PostgreSQL has a "core team" (pgsql-core@) that rarely rules on specific
features. I'm interpreting "core PostgreSQL team" more broadly as "people who
determine whether to accept patches".]

Based on the last discussion, I expect it would take resolving these concerns:

1. Does PostgreSQL gain enough by having the extension in core instead of
leaving the same extension in Github? (Tom)

2. Will the feature set stand the test of time as the one core auditing
feature set, pleasing to most of the PostgreSQL users who seek auditing?
It's fine if the initial patch has a subset of the eventual feature set,
but it's bad if we later wish to undo UI decisions. (Tom, Heikki, Robert)

Your own input would be especially helpful on this point. Would you
describe the compliance requirements you have faced lately? References to
external standards are fine, and lists of private requirements are also
fine. If you can annotate a requirements list with the pgaudit feature
used to meet each requirement, that would be even more helpful.

3. Does the implementation do what it claims to do, correctly? Any defects
are likely to be security vulnerabilities, which amplifies the cost of
fixing them after release. (Noah, Robert)

Points (1) and (2) relax considerably for narrow core changes to support an
external auditing system. For example, David's errhidefromclient() proposal
faces a simpler journey, because it raises far fewer design questions.

> P.S., do you know what sucks, having a highly performant PostGIS database
> that works great, and being told to move to Oracle or SQL Server (because
> they have auditing). Even though they charge extra for Geospatial support

In the same sense that PostgreSQL has geospatial support, PostgreSQL 9.3 and
later do have auditing. Get it from https://github.com/2ndQuadrant/pgaudit,
just like you get PostGIS separately. I realize some sites forbid extensions
like pgaudit and PostGIS, but this particular case you describe is fortunate
not to have that problem.

Thanks,
nm