From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Enable DB level audit trail |
Date: | 2024-04-16 18:01:03 |
Message-ID: | CANzqJaCTd9a5rPURkv0OCRrx-CJMBYWFN7oH7bAmcbUnkYqy5Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"Audit tables" are tables just like any other table, which means they can
be changed by anyone with a superuser ROLE.
pgaudit and Qradar rsyslog is how you unalterably track table changes.
That, of course, means you need the Qradar software on another server, etc,
etc, etc.
But if lawyers and security compliance officers don't care... then sure,
triggers and "audit tables" work just fine. I recommend adding a timestamp
and "action code" ('I'=insert, 'U'=update, 'D'=delete) to the audit tables
in addition to cloning the base table's columns.
On Tue, Apr 16, 2024 at 1:32 PM Siraj G <tosiraj(dot)g(at)gmail(dot)com> wrote:
> Thank you Ron.
> Would it be good to use trigger based auditing or via pgAudit?
> All we want is to capture changes in a few tables.
>
> Regards
> Siraj
>
> On Mon, Apr 8, 2024 at 6:24 PM Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
> wrote:
>
>> Lots of extra stuff in the postgresql log files.
>>
>> On Mon, Apr 8, 2024 at 3:56 AM Siraj G <tosiraj(dot)g(at)gmail(dot)com> wrote:
>>
>>> Also, I would like to understand the implications of enabling the DB
>>> audit.
>>>
>>> Appreciate the help.
>>>
>>> Regards
>>> Siraj
>>>
>>> On Mon, Apr 8, 2024 at 11:30 AM Siraj G <tosiraj(dot)g(at)gmail(dot)com> wrote:
>>>
>>>> Hello Admins!
>>>>
>>>> How do we enable DB level audit trail in PgSQL?
>>>>
>>>> Regards
>>>> Siraj
>>>>
>>>
From | Date | Subject | |
---|---|---|---|
Next Message | GF | 2024-04-16 18:11:28 | Re: Enable DB level audit trail |
Previous Message | Siraj G | 2024-04-16 17:32:19 | Re: Enable DB level audit trail |