pgAudit
Journalisation d'audit open source pour PostgreSQL

Introduction

L'extension d'audit PostgreSQL (pgAudit) fournit une journalisation d'audit détaillée de session et/ou d'objet via le mécanisme standard de journalisation de PostgreSQL.

L'objectif de pgAudit est de fournir aux utilisateurs de PostgreSQL la capacité de produire des journaux d'audit souvent requis pour se conformer aux certifications gouvernementales, financières ou ISO.

Un audit est une inspection officielle des comptes d'un individu ou d'une organisation, généralement par un organisme indépendant. Les informations recueillies par pgAudit sont correctement appelées une piste d'audit ou un journal d'audit. Le terme journal d'audit est utilisé dans cette documentation.

Pourquoi pgAudit ?

La journalisation de base des instructions peut être fournie par le mécanisme de journalisation standard avec log_statement = all. Cela est acceptable pour la surveillance et d'autres usages, mais ne fournit pas le niveau de détail généralement requis pour un audit. Il ne suffit pas d'avoir une liste de toutes les opérations effectuées sur la base de données. Il doit également être possible de trouver des instructions particulières qui intéressent un auditeur. Le mécanisme de journalisation standard montre ce que l'utilisateur a demandé, tandis que pgAudit se concentre sur les détails de ce qui s'est passé pendant que la base de données satisfaisait la demande.

Par exemple, un auditeur peut vouloir vérifier qu'une table particulière a été créée dans une fenêtre de maintenance documentée. Cela peut sembler une tâche simple pour grep, mais que faire si vous êtes confronté à quelque chose comme cet exemple (volontairement obscurci) :

DO $$
BEGIN
    EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;

La journalisation standard vous donnera ceci :

LOG:  statement: DO $$
BEGIN
    EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;

Il semble que trouver la table d'intérêt puisse nécessiter une certaine connaissance du code dans les cas où les tables sont créées dynamiquement. Ce n'est pas idéal car il serait préférable de simplement rechercher le nom de la table. C'est là que pgAudit intervient. Pour la même entrée, il produira cette sortie dans le journal :

AUDIT: SESSION,33,1,FUNCTION,DO,,,"DO $$
BEGIN
    EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;"
AUDIT: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

Non seulement le bloc DO est journalisé, mais la sous-instruction 2 contient le texte complet du CREATE TABLE avec le type d'instruction, le type d'objet et le nom complet qualifié pour faciliter les recherches.

Lors de la journalisation des instructions SELECT et DML, pgAudit peut être configuré pour journaliser une entrée distincte pour chaque relation référencée dans une instruction. Aucune analyse syntaxique n'est requise pour trouver toutes les instructions qui touchent une table particulière. En fait, l'objectif est que le texte de l'instruction soit fourni principalement pour des investigations approfondies et ne devrait pas être requis pour un audit.

Considérations d'utilisation

Selon les paramètres, il est possible que pgAudit génère un volume énorme de journalisation. Soyez prudent pour déterminer exactement ce qui doit être journalisé pour l'audit dans votre environnement afin d'éviter de journaliser trop.

Par exemple, dans un environnement OLAP, il ne serait probablement pas judicieux de journaliser les insertions dans une grande table de faits. La taille du fichier journal sera probablement plusieurs fois la taille réelle des données des insertions car le fichier journal est exprimé en texte. Comme les journaux sont généralement stockés avec le système d'exploitation, cela peut conduire à un épuisement très rapide de l'espace disque. Dans les cas où il n'est pas possible de limiter la journalisation d'audit à certaines tables, assurez-vous d'évaluer l'impact sur les performances pendant les tests et allouez beaucoup d'espace sur le volume des journaux. Cela peut également être vrai pour les environnements OLTP. Même si le volume d'insertions n'est pas aussi élevé, l'impact sur les performances de la journalisation d'audit peut néanmoins affecter sensiblement la latence.

Pour limiter le nombre de relations journalisées pour l'audit des instructions SELECT et DML, envisagez d'utiliser la journalisation d'audit d'objets (voir Audit d'objets). La journalisation d'audit d'objets permet de sélectionner les relations à journaliser, ce qui permet de réduire le volume global des journaux. Cependant, lorsque de nouvelles relations sont ajoutées, elles doivent être explicitement ajoutées à la journalisation d'audit d'objets. Une solution programmatique où des tables spécifiées sont exclues de la journalisation et toutes les autres sont incluses peut être une bonne option dans ce cas.

Compatibilité des versions de PostgreSQL

pgAudit prend en charge PostgreSQL 14 ou supérieur.

Afin de prendre en charge les nouvelles fonctionnalités introduites dans chaque version de PostgreSQL, pgAudit maintient une branche séparée pour chaque version majeure de PostgreSQL (actuellement PostgreSQL 14 - 19) qui sera maintenue d'une manière similaire au projet PostgreSQL.

En dehors des corrections de bogues, aucun développement supplémentaire n'est autorisé pour les branches stables. Les nouveaux développements, s'il y en a, seront strictement pour la prochaine version majeure non publiée de PostgreSQL.

Les versions de pgAudit correspondent aux versions majeures de PostgreSQL comme suit :

• pgAudit v19.X est destiné à prendre en charge PostgreSQL 19.

• pgAudit v18.X est destiné à prendre en charge PostgreSQL 18.

• pgAudit v17.X est destiné à prendre en charge PostgreSQL 17.

• pgAudit v16.X est destiné à prendre en charge PostgreSQL 16.

• pgAudit v1.7.X est destiné à prendre en charge PostgreSQL 15.

• pgAudit v1.6.X est destiné à prendre en charge PostgreSQL 14.

Compilation et installation

pgAudit peut être compilé contre une copie installée de PostgreSQL avec les paquets de développement en utilisant PGXS. Les instructions suivantes devraient fonctionner sur la plupart des systèmes d'exploitation de type Unix.

Clonez l'extension pgAudit :

git clone https://github.com/pgaudit/pgaudit.git

Déplacez-vous dans le répertoire pgAudit :

cd pgaudit

Extrayez la branche REL_19_STABLE (notez que la branche stable peut ne pas exister pour les versions non publiées de PostgreSQL) :

git checkout REL_19_STABLE

Compilez et installez pgAudit :

make install USE_PGXS=1 PG_CONFIG=/usr/pgsql-19/bin/pg_config

Les instructions pour les tests et le développement se trouvent dans test.

Paramètres

Les paramètres ne peuvent être modifiés que par un superutilisateur. Autoriser les utilisateurs normaux à modifier leurs paramètres irait à l'encontre de l'objectif d'un journal d'audit.

Les paramètres peuvent être spécifiés globalement (dans postgresql.conf ou en utilisant ALTER SYSTEM ... SET), au niveau de la base de données (en utilisant ALTER DATABASE ... SET), ou au niveau du rôle (en utilisant ALTER ROLE ... SET). Notez que les paramètres ne sont pas hérités par l'héritage normal des rôles et que SET ROLE ne modifiera pas les paramètres pgAudit d'un utilisateur. Il s'agit d'une limitation du système de rôles et non inhérente à pgAudit.

L'extension pgAudit doit être chargée dans shared_preload_libraries. Sinon, une erreur sera levée au moment du chargement et aucune journalisation d'audit n'aura lieu.