Re: pgaudit - an auditing extension for PostgreSQL

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: pgaudit - an auditing extension for PostgreSQL
Дата
Msg-id 54CFE2BF.9030000@pgmasters.net
обсуждение исходный текст
Ответ на Re: pgaudit - an auditing extension for PostgreSQL  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Ответы Re: pgaudit - an auditing extension for PostgreSQL
Список pgsql-hackers
On 1/27/15 4:08 AM, Abhijit Menon-Sen wrote:

> Anyway, I think it's reasonably clear now that pgaudit is unlikely to
> make it into 9.5 in any form, so I'll find something else to do.

That's unfortunate.  I've been following this thread for a while with
some interest (and anticipation).

The role-base approach being considered may strike some as a misuse of
the role system, but to my eye it is syntactically very close to how
Oracle does auditing prior to 12c.  Say you wanted to audit selects on
the table hr.employee:

Oracle: AUDIT SELECT ON hr.employee;
pgaudit: GRANT SELECT ON hr.employee TO audit; (assuming audit is the
role defined by pgaudit.roles)

Object-based auditing in Oracle would be very easy to migrate to the
grants needed for pgaudit.  In addition, if an AUDIT command were
introduced later in core, it would be easy to migrate from pgaudit to
AUDIT assuming the syntax was similar to grant, which seems plausible.

Unified auditing in 12c brings together the AUDIT command and DBMS_FGA
under the concept of audit polices.  That type of granularity might be
something to shoot for eventually, but I think having a way to do
auditing similar to what is available in pre-12c covers most use cases
and would certainly be a big step forward for Postgres.

--
- David Steele
david@pgmasters.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_check_dir comments and implementation mismatch
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Odd behavior of updatable security barrier views on foreign tables