From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] pg audit requirements |
Date: | 2017-11-13 18:43:14 |
Message-ID: | CAFj8pRBvQJ77sYp_rFTwmnebKYkr7HMSXxkFrc+_kf7Z3J7FLg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2017-11-13 19:19 GMT+01:00 David Steele <david(at)pgmasters(dot)net>:
> Hi Pavel,
>
> On 11/10/17 2:33 AM, Pavel Stehule wrote:
>
>>
>> I am sending some notes, experience about usage of pgAudit.
>>
>
> Thanks for the input! I'm not sure this is the best forum for comments,
> however, since pgAudit is not part of Postgres.
>
> Issues can be opened at the github site:
> https://github.com/pgaudit/pgaudit
>
I hope so some auditing functionality will be core feature.
> pgAudit provides basic functionality and usually is good enough. But it is
>> not good enough for some applications in financial services.
>>
>
> It's certainly being used successfully in the financial sector, but I'm
> sure there are some applications where it won't work.
>
yes, it is used there. Probably there are not too much applications, where
pgAudit is not enough. Unfortunately, these applications are usually
business critical.
> The requirements:
>>
>> 1. structured output - attached query is not good enough - column name,
>> table name, schema, database, role should be separated
>>
>
>
Have you tried using pgaudit.log_relation? That would at least get you
> table name, and schema. Database and role should really be handled by
> postgres. Role is actually pretty tricky - which one should be logged?
>
sure I did it.
Who got new rights, who lost rights, new user, dropped user, changes of
some features per user (work_mem, logging, ..)
> 2. separated log (log file) with guaranteed write - fsync after every line
>> means significant performance issue, but fsync every 1sec (or defined
>> interval) is acceptable
>>
>
> This would be better as a feature of Postgres logging. Managing log files
> in individual backends doesn't seem like a good idea.
>
I agree. The auditing can be good use case for this enhanced log system.
> 3. security issues - not enough access rights to database object should be
>> processed and logged in audit log too.
>>
>
> Postgres will generate errors on access violations. Unfortunately, there
> are currently no hooks that will allow pgAudit to log them. At least, that
> I'm aware of.
>
I have a customer, who want to collect all audit data (requires in
structured format) and store it to fraud detection software.
I am not sure if one hook helps - It looks so some security related
collector (like stats collector or log collector) it is necessary.
Currently these informations are too spread over all postgres.
Regards
Pavel
> Thanks,
> --
> -David
> david(at)pgmasters(dot)net
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2017-11-13 18:51:07 | Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization |
Previous Message | Alvaro Herrera | 2017-11-13 18:39:33 | Re: [HACKERS] No mention of CREATE STATISTICS in event trigger docs |