Auditer PostgreSQL avec pgAudit

L'audit des technologies de l'information (TI) est un processus d'examen de l'infrastructure informatique d'une organisation afin de garantir la conformité aux exigences imposées par les normes reconnues ou les politiques établies. Les règles de protection des données, telles que les nouvelles réglementations GDPR, deviennent de plus en plus strictes pour protéger les données des utilisateurs. Il est donc important que vos audits de base de données soient correctement configurés pour garantir que vos données d'application et d'utilisateur sont à l'abri des vulnérabilités. Dans cet article de blog, nous discuterons de pgAudit - un outil qui génère les journaux d'audit nécessaires pour faciliter l'audit de PostgreSQL.

Qu'est-ce que pgAudit ?

L'extension d'audit PostgreSQL, pgAudit, est une extension open source qui consigne les événements dans une base de données PostgreSQL dans un journal d'audit détaillé. Il utilise la fonction de journalisation native de PostgreSQL, de sorte que les journaux d'audit feront partie des journaux PostgreSQL. L'extension est basée sur le projet 2ndQuadrant pgAudit rédigé par Simon Riggs, Abhijit Menon-Sen et Ian Barwick, et inclut des améliorations par David Steele de Crunchy Data.

Pourquoi pgAudit plutôt que log_statement=all ?

Nous pouvons enregistrer toutes les instructions dans PostgreSQL simplement en définissant log_statement=all . Alors pourquoi utiliser pgAudit ? La journalisation des instructions de base (à l'aide de log_statement ) répertorie uniquement les opérations effectuées sur la base de données. Il ne fournira pas la possibilité de filtrer les opérations et les journaux ne seront pas au format approprié requis pour l'audit. pgAudit fournit en outre une granularité pour la journalisation de classes spécifiques d'instructions telles que READ (SELECT et COPY ), WRITE (INSERT , UPDATE , DELETE , etc.), DDL etc. De plus, il fournit un audit au niveau de l'objet où seules les opérations sur des relations spécifiques seront enregistrées.

Un autre avantage de pgAudit par rapport à la journalisation des instructions de base est qu'il fournit les détails de l'opération effectuée au lieu de simplement journaliser l'opération demandée. Par exemple, envisagez d'exécuter le bloc de code anonyme à l'aide d'une instruction DO.

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

La journalisation des instructions de base se traduira par :

2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  statement: DO $$
        BEGIN
            EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
        END $$;

pgAudit enregistrera la même opération que :

2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  AUDIT: SESSION,4,1,FUNCTION,DO,,,"DO $$
        BEGIN
            EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
        END $$;",<not logged>
2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  AUDIT: SESSION,4,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT),<not logged>

Ce qui précède indique clairement la fonctionnalité pgAudit qui enregistre l'opération et ses éléments internes avec une sortie structurée qui facilite la recherche.

Comment installer pgAudit ?

pgAudit est une extension disponible en téléchargement à partir du référentiel PostgreSQL, ou qui peut être compilée et construite à partir de la source. Dans un premier temps, le package doit être téléchargé et installé sur la machine exécutant PostgreSQL (ce package d'extension est préinstallé sur tous les déploiements ScaleGrid PostgreSQL).

Une fois installé, il doit être chargé dans PostgreSQL. Ceci est réalisé en ajoutant pgaudit aux shared_preload_libraries paramètre de configuration. Un redémarrage de PostgreSQL est nécessaire pour que ce changement de configuration soit effectif. L'étape suivante consiste à activer l'extension sur la base de données en exécutant CREATE EXTENSION pgaudit .

Maintenant que l'extension est prête, nous devons nous assurer de définir les paramètres de configuration pour que l'extension démarre la journalisation. Cela peut être aussi simple que de définir le paramètre pgaudit.log valoriser all et le pgAudit commencera à se connecter en session mode.

Maintenant que nous savons comment installer et activer pgAudit, discutons des deux modes de journalisation d'audit qu'il propose, session et objet.

Journalisation d'audit de session

En mode session, pgAudit enregistrera toutes les opérations effectuées par un utilisateur. Définition de pgaudit.log paramètre à l'une des valeurs définies, autre que NONE , activera la journalisation d'audit de session. Le pgaudit.log Le paramètre spécifie les classes d'instructions qui seront consignées en mode session. Les valeurs possibles sont :READ , WRITE , FUNCTION , ROLE , DDL , MISC , MISC_SET , ALL et NONE .

Définition du pgaudit.log paramètre à ALL enregistrera toutes les déclarations. Le paramètre peut accepter plusieurs classes à l'aide d'une liste séparée par des virgules et des classes spécifiques peuvent être exclues avec un signe -. Par exemple, si vous souhaitez enregistrer toutes les instructions sauf MISC classe, la valeur de pgaudit.log sera ALL, -MISC, -MISC_SET . Vous pouvez également permettre à pgAudit de créer une entrée de journal distincte pour chaque référence de relation dans une instruction en définissant pgaudit.log_relation sur.

Prenons un exemple de création d'un tableau. L'instruction SQL serait :

CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));

Les entrées de journal d'audit correspondantes sont :

2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE SEQUENCE,SEQUENCE,public.persons_id_seq,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE TABLE,TABLE,public.persons,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE INDEX,INDEX,public.persons_pkey,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,ALTER SEQUENCE,SEQUENCE,public.persons_id_seq,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>

Journalisation d'audit d'objets

Dans des cas particuliers, il peut être nécessaire de n'auditer qu'un ensemble spécifique de relations. Dans de tels cas, l'utilisation du mode session n'entraînera qu'un nombre inutilement élevé de journaux d'audit ne correspondant pas aux relations requises. Le mode objet est particulièrement adapté à cette fin et ne peut auditer qu'un ensemble spécifique de relations.

La journalisation d'audit d'objet est réalisée à l'aide des rôles PostgreSQL. Un rôle peut être créé et attribué les autorisations pour accéder uniquement à un ensemble spécifique de relations. Ce rôle doit être spécifié dans le paramètre de configuration pgaudit.role . Le mode objet ne prend en charge que SELECT , INSERT , UPDATE et DELETE déclarations. Les classes d'instructions consignées dépendent des autorisations accordées au rôle. Par exemple, si le rôle est autorisé à effectuer uniquement SELECT , alors seulement SELECT les déclarations seront enregistrées.

Ci-dessous, un exemple de journalisation d'audit d'objet :

Créez un rôle et accordez uniquement SELECT autorisations. Définissez le pgaudit.role à ce rôle et exécutez le SELECT Instruction SQL :

CREATE ROLE audit_person;
GRANT SELECT ON persons TO audit_person;
SET pgaudit.role = 'audit_person';
SELECT * FROM persons WHERE ID=404;

L'instruction de sélection ci-dessus sera enregistrée en tant que :

2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: LOG:  AUDIT: OBJECT,10,1,READ,SELECT,TABLE,public.persons,select * from persons where ID=404;,<not logged>

Comment interpréter l'entrée du journal d'audit ?

Jusqu'à présent, nous avons fourni des détails sur l'apparence de l'entrée du journal d'audit. Examinons maintenant le format de l'entrée du journal d'audit. Chaque entrée commence par le log_line_prefix mentionné pour la journalisation PostgreSQL, puis le reste de la sortie sera au format CSV. Considérez l'entrée de journal d'audit simple suivante :

2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: LOG:  AUDIT: OBJECT,10,1,READ,SELECT,TABLE,public.persons,select * from persons where ID=404;,<not logged>

Dans l'entrée ci-dessus, la valeur

2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: 

provient du format log_line_prefix %t:%r:%u@%d:[%p]: . Le contenu de l'entrée d'audit commence à partir de LOG: AUDIT: valeur et il suit le format CSV. Le format de la valeur est de la forme :

AUDIT_TYPE,STATEMENT_ID,SUBSTATEMENT_ID,CLASS,COMMAND,OBJECT_TYPE,OBJECT_NAME,STATEMENT,PARAMETER

Regardons chacun des champs un par un :

Inférence

pgAudit, avec toutes ses fonctionnalités, simplifie le processus d'audit en générant le journal de piste d'audit. Bien qu'il y ait quelques mises en garde, comme la journalisation des objets renommés sous le même nom, il s'agit toujours d'un outil robuste qui fournit les fonctionnalités requises. Cependant, les informations d'audit écrites dans les journaux peuvent ne pas être simplement idéales pour le processus d'audit - le processus d'audit est encore meilleur lorsque ces journaux peuvent être convertis en un schéma de base de données et que les données d'audit peuvent être chargées dans la base de données afin que vous puissiez facilement interroger le information. C'est là que l'analyseur de journaux d'audit PostgreSQL (pgAudit Analyze) est utile. Pour plus d'informations, consultez les pages github de pgAudit et pgAudit Analyze.