postgresql extension pgAudit - ghdrako/doc_snipets GitHub Wiki

• https://www.pgaudit.org/
• https://github.com/pgaudit/pgaudit/blob/master/README.md
• https://cloud.google.com/sql/docs/postgres/pg-audit
• https://severalnines.com/blog/postgresql-audit-logging-best-practices/
• https://severalnines.com/blog/how-to-audit-postgresql-database/
• https://www.postgresql.org/docs/15/runtime-config-logging.html#RUNTIME-CONFIG-SEVERITY-LEVELS
• https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e5f1a4f1e350f1e72531d032eaa9095ba5baeb51

Settings can be specified:

• globally (in postgresql.conf or using ALTER SYSTEM ... SET),
• at the database level (using ALTER DATABASE ... SET), or
• at the role level (using ALTER ROLE ... SET). Note that settings are not inherited through normal role inheritance and SET ROLE will not alter a user's pgAudit settings. This is a limitation of the roles system and not inherent to pgAudit.

Generally with pgaudit we can have two modes of operation or use them combined:

• SESSION audit logging
• OBJECT audit logging

Supports most DML, DDL, privilege and misc commands via classes:

• READ (select, copy from)
• WRITE (insert, update, delete, truncate, copy to)
• FUNCTION (function calls and DO blocks)
• ROLE (grant, revoke, create/alter/drop role)
• DDL (all DDL except those in ROLE)
• MISC (discard, fetch, checkpoint, vacuum)

Metaclass all includes all classes. – excludes a class.

Example - configure Session audit logging for all except MISC

pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'

Using session audit logging will give us audit log entries for all operations belonging to the classes defined by pgaudit.log parameter on all tables.

Exclude user from auditin. Set global audit log and:

ALTER ROLE acp_bth SET   pgaudit.log="none"

Gives us fine grained criteria to selected tables/columns via the PostgreSQL’s privilege system. In order to start using Object audit logging we must first configure the pgaudit.role parameter which defines the master role that pgaudit will use. It makes sense not to give this user any login rights.

CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;

The we specify this value for pgaudit.role in postgresql.conf:

pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditor

Pgaudit OBJECT logging will work by finding if user auditor is granted (directly or inherited) the right to execute the specified action performed on the relations/columns used in a statement. So if we need to ignore all tables, but have detailed logging to table orders, this is the way to do it:

grant ALL on orders to auditor ;

By the above grant we enable full SELECT, INSERT, UPDATE and DELETE logging on table orders.

One caveat with OBJECT logging is that TRUNCATEs are not logged. We have to resort to SESSION logging for this. But in this case we end up getting all WRITE activity for all tables.

Another thing to keep in mind is that in the case of inheritance if we GRANT access to the auditor on some child table, and not the parent,** actions on the parent table which translate to actions on rows of the child table will not be logged.**

Since logs are generally stored with the OS this may lead to disk space being exhausted very quickly. In cases where it is not possible to limit audit logging to certain tables, be sure to assess the performance impact while testing and allocate plenty of space on the log volume. This may also be true for OLTP environments. Even if the insert volume is not as high, the performance impact of audit logging may still noticeably affect latency.

To limit the number of relations audit logged for SELECT and DML statements, consider using object audit logging (see Object Auditing). Object audit logging allows selection of the relations to be logged allowing for reduction of the overall log volume. However, when new relations are added they must be explicitly added to object audit logging. A programmatic solution where specified tables are excluded from logging and all others are included may be a good option in this case.

0. Install extension

$ yum install pgaudit14_12

1. The pgAudit extension must be loaded in shared_preload_libraries. It will need restart instance.

shared_preload_libraries = 'pgaudit, pg_stat_statements'

$ psql -c "show shared_preload_libraries;" # checked first what is the shared_preload_libraries, because if there was anything there (like pg_stat_statements), I should keep it and set new value accordingly.
$ psql -c "alter system set shared_preload_libraries = 'pg_audit';"
$ pg_ctl restart # or $ sudo systemctl restart postgresql.service
$ psql -c 'show shared_preload_libraries'

2. CREATE EXTENSION pgaudit - The extension installs event triggers which add additional auditing for DDL. pgAudit will work without the extension installed but DDL statements will not have information about the object type and name.

CREATE EXTENSION pgaudit;

3. pgaudit.log

set pgaudit.log = 'read, ddl';

$ set pg_audit.log = 'all';
$ set pg_audit.log_relation = on;

ALTER SYSTEM SET pgaudit.log_catalog = off;
ALTER SYSTEM SET pgaudit.log = 'all, -misc';
ALTER SYSTEM SET pgaudit.log_relation = 'on';
ALTER SYSTEM SET pgaudit.log_parameter = 'on';
SELECT pg_reload_conf();

4. Verify pbAudit configuration:

SELECT name,setting FROM pg_settings WHERE name LIKE 'pgaudit%';

5. Configures log record to include user and host

$ alter system set log_line_prefix to '%m [%p] %u %h';
$ select pg_reload_conf();

This GUC variable will change all log lines of PostgreSQL, not only pgaudit's.

• https://github.com/pgaudit/pgaudit#format
• https://www.postgresql.org/docs/10/static/runtime-config-logging.html#guc-log-line-prefix

Opis parametrow w https://github.com/pgaudit/pgaudit/blob/master/README.md

Object audit logging logs statements that affect a particular relation. Only SELECT, INSERT, UPDATE and DELETE commands are supported. TRUNCATE is not included in object audit logging.

Object audit logging is intended to be a finer-grained replacement for pgaudit.log = 'read, write'.

$ create role auditor;
$ grant select, insert, update, delete on test to auditor;
$ ALTER SYSTEM set pg_audit.role = 'auditor';
$ select pg_reload_conf();
$ grant auditor to myuser;
$ grant select secret_col on test2 to auditor;  # audit specific column in table
$ select id from test2; # will not be loged
$ select secret_col from test2; # will be loged
$ select * from test2; # will be loged

The steps for audit logging using the pgAudit extension include:

1. Enabling the cloudsql.enable_pgaudit flag in Cloud SQL - Note: Changing the value of the cloudsql.enable_pgaudit flag restarts the instance.

gcloud sql instances patch [INSTANCE_NAME] --database-flags cloudsql.enable_pgaudit=on

2. Running a command to create the pgAudit extension.

CREATE EXTENSION pgaudit;
SELECT * FROM pg_extension;

3. Setting values for the pgaudit.log flag.

gcloud sql instances patch [INSTANCE_NAME] --database-flags \
  cloudsql.enable_pgaudit=on,pgaudit.log=all

Note The database instance is restarted whenever the database flag value for cloudsql.enable_pgaudit is changed.

The generated pgAudit logs for a given instance are sent to Cloud Logging as Data Access audit logs. Users can view the generated pgAudit logs through the Logs Explorer application.

In the Logs Explorer application, the pgAudit logs can be viewed by selecting the cloudaudit.googleapis.com/data_access log filter.

Alternatively, you can use the following query to show all pgAudit logs for a given Cloud SQL project:

resource.type="cloudsql_database"
resource.labels.database_id="<project-name>:<instance-name>"
logName="projects/<your-project-name>/logs/cloudaudit.googleapis.com%2Fdata_access"
protoPayload.request.@type="type.googleapis.com/google.cloud.sql.audit.v1.PgAuditEntry"
protoPayload.request.user="<user_name>"