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 the official pgAudit documentation.

Supported Versions

You can run the following SQL statement to check whether your DB instance supports this extension:

SELECT * FROM pg_available_extension_versions WHERE name = 'pgaudit';

If this extension is not supported, upgrade the major version using dump and restore.

To see more extensions supported by RDS for PostgreSQL, go to Supported Extensions.

Extension Installation and Uninstallation

• Installing the extension

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

• Deleting the extension

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

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

How to Use

Configuring the pgAudit

1. 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)

2. After the extension is loaded, install it by referring to Extension Installation and Uninstallation.
3. After the extension is installed, enable audit logging.
   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.
4. 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

1. Execute SQL statements.

   create table t1 (id int);
   
   insert into t1 values (1);
   
   select * from t1;
    id
   ----
     1
   
   (1 rows)

2. 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.