Using pgAudit

Introduction

Financial institutions, government agencies, and many industries need to keep audit logs to meet regulatory requirements. By using the PostgreSQL Audit Extension (pgAudit) with your RDS for PostgreSQL instance, you can capture detailed records that auditors usually need to meet compliance regulations. For example, you can use pgAudit to track changes made to specific databases and tables, as well as record users who make such changes and many other details.

For more information, see official pgAudit documentation.

Supported Versions

This plugin is available to the latest minor versions of RDS for PostgreSQL 12 and later versions. You can run the following SQL statement to check whether your DB instance supports this plugin:

SELECT * FROM pg_available_extension_versions WHERE name = 'pgaudit';

If this plugin is not supported, upgrade the minor version of your DB instance or upgrade the major version using dump and restore.

To see more plugins supported by RDS for PostgreSQL, go to Supported Plugins.

Plugin Installation and Uninstallation

Installing the plugin

SELECT control_extension ('create', 'pgaudit');

Deleting the plugin

SELECT control_extension ('drop', 'pgaudit');

For more information, see Installing and Uninstalling a Plugin on the RDS Console and Installing and Uninstalling a Plugin Using SQL Commands.

How to Use

Configuring the pgAudit

First, preload pgAudit on the Plugins page of your instance because pgAudit installs event triggers for auditing data definition language (DDL) statements. By default, pgAudit is preloaded. To check whether it is successfully loaded, you can run the following command:

show shared_preload_libraries;
                             shared_preload_libraries                             
---------------------------------------------------------------------------------
 pg_stat_statements,pgaudit,passwordcheck.so,pg_sql_history,auth_delay,pglogical
(1 row)

After the plugin is loaded, install it by referring to Plugin Installation and Uninstallation.
After the plugin is installed, enable audit logging.

To enable audit logging, contact customer service.
1. On the RDS console, click the DB instance name. On the displayed page, click SQL Audits.
2. Click Set SQL Audit.
3. In the displayed dialog box, toggle on the audit log switch and set the number of days to retain audit logs.
  Figure 1 Setting SQL audit

Configure parameters.

Go to the Parameters page, search for the pgaudit.log parameter (that specifies which types of statements will be logged by session audit logging), and set it to an appropriate value to capture log insertions, updates, deletions, and other changes. The following table explains the values of pgaudit.log.

**Table 1** Parameter description
Value	Description
NONE	(Original value) Specifies that no changes to the database will be recorded.
ALL	Specifies that all changes will be recorded, including READ, WRITE, FUNCTION, ROLE, DDL, and MISC.
DDL	Specifies that all DDL statements (excluding those in the ROLE class) will be recorded.
FUNCTION	Specifies that function calls and DO blocks will be recorded.
MISC	Specifies that commands such as DISCARD, FETCH, CHECKPOINT, VACUUM, and SET will be recorded.
READ	Specifies that SELECT and COPY will be recorded when the source is a relationship (for example, a table) or query.
role	Specifies that statements related to roles and permissions will be recorded, for example, GRANT, REVOKE, CREATE ROLE, ALTER ROLE, and DROP ROLE.
WRITE	Specifies that INSERT, UPDATE, DELETE, TRUNCATE, and COPY will be recorded when the destination is a relationship (table).

The following table lists other parameters related to pgAudit. You can set them on the console as needed.

**Table 2** Parameter description
Parameter	Description
pgaudit.log	Specifies which types of statements will be logged by session audit logs.
pgaudit.log_catalog	Specifies that session logging should be enabled if all relations in a statement are in pg_catalog.
pgaudit.log_client_authentication	Controls whether to record user authentication information.
pgaudit.log_extra_field	Controls whether to record fields such as PID, IP, user name, and database.
pgaudit.log_file_rotation_age	Sets the rotation interval for separate audit logs.
pgaudit.log_parameter	Specifies that audit logging should include the parameters that were passed with the statement.
pgaudit.log_relation	Specifies whether session audit logging should create a separate log entry for each relationship (such as a table and view) referenced in a SELECT or DML statement.
pgaudit.log_rows	Sets the retrieved or affected rows that audit logs should include.
pgaudit.log_write_txid	Controls whether to record the TXID of write operations (such as INSERT and UPDATE).
pgaudit.logstatementonce	Controls whether audit logs include statements, text, and parameters.
pgaudit.log_client	Controls whether audit logs are sent to clients.
pgaudit.log_level	Sets the log level for log entries.
pgaudit.write_into_pg_log_file	Controls whether to write audit information into PostgreSQL run logs.

To display audit logs on your client, configure the following parameters:

Set both pgaudit.write_into_pg_log_file and pgaudit.log_client to on and select a log level (for example, notice) to be displayed on the client based on the value of pgaudit.log_level. When you query audit logs on your client again, the logs of the corresponding level are displayed.
If either pgaudit.write_into_pg_log_file or pgaudit.log_client is set to off, audit logs will not be displayed on the client.
pgaudit.log_level is available only when pgaudit.log_client is set to on.

SQL Audit Verification

Execute SQL statements.

create table t1 (id int);

insert into t1 values (1);

select * from t1;
 id
----
  1

(1 rows)

On the SQL Audits page, download the audit log.
The audit log contains the following information:
```
AUDIT: OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
```
- AUDIT indicates an audit log entry.
- OBJECT indicates an object-level audit log.
- The first 1 indicates the object ID.
- The second 1 indicates the sub-ID of the object.
- READ indicates a read operation.
- SELECT indicates a SELECT query.
- TABLE indicates that the object type is table.
- public.t1 indicates the name and schema of the table.
- select * from t1 indicates the executed SQL query statement.