Comment auditer une base de données PostgreSQL

L'audit est un bon moyen de garder vos données aussi sûres que possible et de savoir ce qui se passe dans vos bases de données. Il est également requis pour de nombreuses réglementations ou normes de sécurité, telles que PCI - Payment Card Industry. Ce n'est pas une exception pour votre base de données PostgreSQL.

PostgreSQL a acquis une solide réputation pour son architecture éprouvée, sa fiabilité, son intégrité des données, son ensemble de fonctionnalités robustes, son extensibilité et le dévouement de la communauté open source derrière le logiciel pour fournir constamment des solutions performantes et innovantes.

Cela dit, il devrait être possible d'auditer une base de données PostgreSQL, n'est-ce pas ? Eh bien, la réponse est oui. Dans ce blog, nous verrons ce qu'est l'extension pgAudit et comment l'installer et l'utiliser dans votre base de données PostgreSQL.

Qu'est-ce que pgAudit ?

L'extension d'audit PostgreSQL (pgAudit) fournit une journalisation détaillée de l'audit des sessions et des objets via la fonction de journalisation PostgreSQL standard.

La journalisation des instructions de base peut être fournie par la fonction de journalisation standard avec log_statement =all. Ceci est acceptable pour la surveillance et d'autres utilisations de base, mais ne fournit pas le niveau de détail généralement requis pour l'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 déclarations particulières qui intéressent un auditeur. La fonction 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.

Comment installer pgAudit sur PostgreSQL

Pour cet exemple, nous utiliserons une installation CentOS 7. À ce stade, nous supposons que votre base de données PostgreSQL est installée, sinon, vous pouvez suivre cet article de blog pour la faire fonctionner facilement à l'aide de ClusterControl.

Maintenant, vous devriez avoir le référentiel PostgreSQL dans votre système d'exploitation, quelque chose comme ceci :

$ cat /etc/yum.repos.d/postgresql.repo

# PGDG Red Hat Enterprise Linux / CentOS stable common repository for all PostgreSQL versions

[pgdg-common]

name=PostgreSQL common for RHEL/CentOS $releasever - $basearch

baseurl=http://download.postgresql.org/pub/repos/yum/common/redhat/rhel-$releasever-$basearch

enabled=1

gpgcheck=0

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG

# PGDG Red Hat Enterprise Linux / CentOS stable repositories:

[pgdg]

name=PostgreSQL 12 $releasever - $basearch

#baseurl=http://yum.postgresql.org/12/redhat/rhel-$releasever-$basearch

baseurl=http://download.postgresql.org/pub/repos/yum/12/redhat/rhel-$releasever-$basearch/

enabled=1

gpgcheck=0

[pgdg-source]

name=PostgreSQL 12 $releasever - $basearch - Source

baseurl=http://yum.postgresql.org/srpms/12/redhat/rhel-$releasever-$basearch

enabled=0

gpgcheck=0

Si vous cochez les packages pgaudit disponibles, vous devriez avoir :

pgaudit14_12.x86_64 : PostgreSQL Audit Extension

Alors, installons-le :

$ yum install pgaudit14_12

Maintenant, vous devrez l'ajouter dans le fichier de configuration postgresql.conf, situé par défaut dans /var/lib/pgsql/12/data/postgresql.conf, et redémarrer le service PostgreSQL pour appliquer le changement.

shared_preload_libraries = 'pgaudit, pg_stat_statements'

Après avoir redémarré votre service de base de données, vous devez créer l'extension :

postgres=# CREATE EXTENSION pgaudit;

CREATE EXTENSION

And now, you can run the following query to check the new extension created:

postgres=# SELECT * FROM pg_available_extensions WHERE name LIKE '%audit%';

  name   | default_version | installed_version |             comment

---------+-----------------+-------------------+---------------------------------

 pgaudit | 1.4.1           | 1.4.1             | provides auditing functionality

(1 row)

Configuration de pgAudit

Vous pouvez vérifier la configuration actuelle en exécutant la requête suivante :

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

            name            | setting

----------------------------+---------

 pgaudit.log                | none

 pgaudit.log_catalog        | on

 pgaudit.log_client         | off

 pgaudit.log_level          | log

 pgaudit.log_parameter      | off

 pgaudit.log_relation       | off

 pgaudit.log_statement_once | off

 pgaudit.role               |

(8 rows)

Voyons ces paramètres un par un.

pgaudit.log :spécifie les classes d'instructions qui seront consignées par la journalisation d'audit de session. La valeur par défaut est aucune. Les valeurs possibles sont :
- LIRE :SELECT et COPY lorsque la source est une relation ou une requête.
- WRITE :INSERT, UPDATE, DELETE, TRUNCATE et COPY lorsque la destination est une relation.
- FUNCTION :appels de fonction et blocs DO.
- ROLE :déclarations relatives aux rôles et privilèges :GRANT, REVOKE, CREATE/ALTER/DROP ROLE.
- DDL :tous les DDL qui ne sont pas inclus dans la classe ROLE.
- MISC :commandes diverses, par ex. JETER, RÉCUPÉRER, POINT DE CONTRÔLE, VIDE, DÉFINIR.
- MISC_SET :commandes SET diverses, par ex. DÉFINIR LE RÔLE.
- TOUS :inclure tous les éléments ci-dessus.
pgaudit.log_catalog :spécifie que la journalisation de session doit être activée dans le cas où toutes les relations d'une instruction se trouvent dans pg_catalog. La désactivation de ce paramètre réduira le bruit dans le journal des outils tels que psql et PgAdmin qui interrogent fortement le catalogue. La valeur par défaut est activée.
pgaudit.log_client :spécifie si les messages du journal seront visibles pour un processus client tel que psql. Ce paramètre doit généralement rester désactivé, mais peut être utile pour le débogage ou à d'autres fins. La valeur par défaut est désactivée.
pgaudit.log_level :spécifie le niveau de journalisation qui sera utilisé pour les entrées de journal. Ce paramètre est utilisé pour les tests de régression et peut également être utile aux utilisateurs finaux à des fins de test ou à d'autres fins. La valeur par défaut est log.
pgaudit.log_parameter :spécifie que la journalisation d'audit doit inclure les paramètres transmis avec l'instruction. Lorsque des paramètres sont présents, ils seront inclus au format CSV après le texte de l'instruction. La valeur par défaut est désactivée.
pgaudit.log_relation :spécifie si la journalisation d'audit de session doit créer une entrée de journal distincte pour chaque relation (TABLE, VIEW, etc.) référencée dans une instruction SELECT ou DML. Il s'agit d'un raccourci utile pour une journalisation exhaustive sans utiliser la journalisation d'audit d'objet. La valeur par défaut est désactivée.
pgaudit.log_statement_once :spécifie si la journalisation inclura le texte et les paramètres de l'instruction avec la première entrée de journal pour une combinaison instruction/sous-instruction ou avec chaque entrée. La désactivation de ce paramètre entraînera une journalisation moins détaillée mais peut rendre plus difficile la détermination de l'instruction qui a généré une entrée de journal, bien que la paire instruction/sous-instruction avec l'ID de processus devrait suffire à identifier le texte de l'instruction consigné avec une entrée précédente. La valeur par défaut est désactivée.
pgaudit.role :spécifie le rôle principal à utiliser pour la journalisation d'audit d'objet. Plusieurs rôles d'audit peuvent être définis en les attribuant au rôle principal. Cela permet à plusieurs groupes d'être en charge de différents aspects de la journalisation d'audit. Il n'y a pas de valeur par défaut.

Utilisation de pgAudit

Maintenant que nous avons passé en revue les paramètres de configuration, voyons un exemple d'utilisation dans le monde réel.

Pour auditer toutes les lectures, écritures et requêtes DDL, exécutez :

test1=# set pgaudit.log = 'read,write,ddl';

SET

Et ensuite, exécutez les phrases suivantes :

test1=# CREATE TABLE table1 (id int, name text);

CREATE TABLE

test1=# INSERT INTO table1 (id, name) values (1, 'name1');

INSERT 0 1

test1=# INSERT INTO table1 (id, name) values (2, 'name2');

INSERT 0 1

test1=# INSERT INTO table1 (id, name) values (3, 'name3');

INSERT 0 1

test1=# SELECT * FROM table1;

 id | name

----+-------

  1 | name1

  2 | name2

  3 | name3

(3 rows)

Si vous consultez le fichier journal de PostgreSQL, vous verrez ceci :

2020-11-20 19:17:13.848 UTC [25142] LOG:  AUDIT: SESSION,3,1,DDL,CREATE TABLE,,,"CREATE TABLE table1 (id int, name text);",<not logged>

2020-11-20 19:18:45.334 UTC [25142] LOG:  AUDIT: SESSION,4,1,WRITE,INSERT,,,"INSERT INTO table1 (id, name) values (1, 'name1');",<not logged>

2020-11-20 19:18:52.332 UTC [25142] LOG:  AUDIT: SESSION,5,1,WRITE,INSERT,,,"INSERT INTO table1 (id, name) values (2, 'name2');",<not logged>

2020-11-20 19:18:58.103 UTC [25142] LOG:  AUDIT: SESSION,6,1,WRITE,INSERT,,,"INSERT INTO table1 (id, name) values (3, 'name3');",<not logged>

2020-11-20 19:19:07.261 UTC [25142] LOG:  AUDIT: SESSION,7,1,READ,SELECT,,,SELECT * FROM table1;,<not logged>

Bien sûr, ceci est un exemple de base. Vous pouvez utiliser les paramètres de configuration décrits dans la section précédente en fonction de votre entreprise.

Activer pgAudit avec ClusterControl

Au lieu d'installer et d'activer manuellement pgAudit, une autre option consiste à utiliser la CLI ClusterControl pour faire le travail à votre place. Pour cela, vous pouvez lancer la commande suivante depuis votre serveur ClusterControl :

$ s9s cluster --setup-audit-logging --cluster-id=ID

Où ID est l'ID du cluster PostgreSQL.

Pendant son exécution, vous pouvez surveiller l'état en vérifiant la tâche ClusterControl. Tout d'abord, vous aurez besoin de l'identifiant de la tâche, que vous pouvez obtenir à partir de la liste des tâches :

$ s9s job --list

163  18 RUNNING  test_dba                     admins 19:41:45            90% Setup Audit Logging

Maintenant, vérifiez les détails de la tâche :

$ s9s job --log --job-id=163

Using SSH credentials from cluster.

Cluster ID is 18.

The username is 'root'.

10.10.10.129:5432: Configuring audit logging.

10.10.10.129:5432: Installing 'pgaudit14_12'.

10.10.10.129:5432: Setting pgaudit.log to ROLE,DDL,MISC.

Writing file '10.10.10.129:/var/lib/pgsql/12/data/postgresql.conf'.

10.10.10.129:5432: Restarting PostgreSQL node.

10.10.10.129: waiting for server to shut down.... done

server stopped

waiting for server to start....2020-11-20 19:41:52.069 UTC [25137] LOG:  pgaudit extension initialized

2020-11-20 19:41:52.069 UTC [25137] LOG:  starting PostgreSQL 12.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit

2020-11-20 19:41:52.069 UTC [25137] LOG:  listening on IPv4 address "0.0.0.0", port 5432

2020-11-20 19:41:52.069 UTC [25137] LOG:  listening on IPv6 address "::", port 5432

2020-11-20 19:41:52.080 UTC [25137] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"

2020-11-20 19:41:52.102 UTC [25137] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"

2020-11-20 19:41:52.130 UTC [25137] LOG:  redirecting log output to logging collector process

2020-11-20 19:41:52.130 UTC [25137] HINT:  Future log output will appear in directory "log".

 done

server started

10.10.10.129:5432: Waiting for node to be accessible.

10.10.10.129:5432: pgaudit 1.4.1 is enabled.

Cette action nécessitera un redémarrage du service de base de données qui sera effectué par ClusterControl dans la même tâche. Après l'avoir redémarré, l'extension pgAudit est activée et prête à être utilisée :

postgres=# SELECT * FROM pg_available_extensions WHERE name LIKE '%audit%';

  name   | default_version | installed_version |             comment

---------+-----------------+-------------------+---------------------------------

 pgaudit | 1.4.1           | 1.4.1             | provides auditing functionality

(1 row)

C'est tout ! Vous pouvez maintenant configurer et utiliser pgAudit de la même manière que nous l'avons montré précédemment.

Conclusion

L'audit est requis pour de nombreuses réglementations de sécurité et il est également utile si vous voulez savoir ce qui s'est passé dans votre base de données, et quand et qui en était responsable.

Dans ce blog, nous avons parlé de l'extension pgAudit PostgreSQL comme un bon moyen d'auditer vos bases de données PostgreSQL, et nous vous avons également montré comment l'implémenter à la fois manuellement et à l'aide de la CLI ClusterControl.

Gardez à l'esprit que, selon la configuration, il est possible que pgAudit génère un énorme volume de données. Vous devez donc faire attention à déterminer ce que vous devez auditer et pendant combien de temps.