PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Comment configurer AppArmor pour PostgreSQL et TimescaleDB

La sécurité est un must pour tous les systèmes afin de protéger au maximum vos données. Même lorsqu'il y a toujours un risque d'être piraté, suivre une liste de contrôle de sécurité réduira considérablement ce risque. Une liste de contrôle de sécurité de base comprend une configuration de pare-feu, le chiffrement des données, une politique d'authentification, etc. Un autre outil important pour protéger vos données sur les systèmes d'exploitation basés sur Debian est AppArmor. Dans ce blog, nous verrons ce que c'est et comment le configurer pour les bases de données PostgreSQL et TimescaleDB.

Qu'est-ce qu'AppArmor ?

AppArmor, inclus par défaut dans les systèmes d'exploitation Ubuntu et Debian (entre autres), est un système de contrôle d'accès obligatoire (MAC) pour confiner les programmes à un ensemble limité de ressources. Cela fonctionne en utilisant des profils chargés dans le noyau. Ces profils peuvent être configurés selon deux modes :

  • Application :les profils chargés dans ce mode appliqueront la politique définie dans le profil et signaleront la violation de la politique tentatives.

  • Réclamation :les profils de ce mode n'appliqueront pas la politique, mais signaleront plutôt les tentatives de violation de la politique.

En outre, AppArmor permet de mélanger les profils de mode d'application et de réclamation.

Comment configurer AppArmor

Les profils AppArmor se trouvent dans /etc/apparmor.d/. Vous pouvez créer vos propres profils et les y déplacer ou consulter le référentiel AppArmor. Voyons comment créer un nouveau profil AppArmor.

Tout d'abord, installons les packages nécessaires pour gérer cela :

$ apt install apparmor-profiles apparmor-utils

Et voyez si AppArmor est activé :

$ systemctl status apparmor.service

ou

Le module 
$ aa-status
apparmor module is loaded.
31 profiles are loaded.
29 profiles are in enforce mode.
   /snap/snapd/11588/usr/lib/snapd/snap-confine
   /snap/snapd/11588/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
  ...

Si vous vérifiez le chemin mentionné /etc/apparmor.d/, vous verrez quelques profils de base comme usr.sbin.tcpdump ou usr.sbin.traceroute. Maintenant, créons un nouveau profil pour PostgreSQL ou TimescaleDB. Pour cela, vous pouvez utiliser ce profil comme exemple. Sur la base de ce profil, nous remplacerons la version PostgreSQL pour être plus précis. Dans ce cas, nous utiliserons PostgreSQL 13.

# Author: Felix Geyer <[email protected]>
#include <tunables/global>
/usr/lib/postgresql/13/bin/postgres {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/ssl_keys>
  /etc/postgresql/** r,
  /usr/share/postgresql/** r,
  /var/lib/postgresql/** rwl,
  /{,var/}run/postgresql/** rw,
  owner @{PROC}/13/oom_adj rw,
}

Stockez-le dans /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres. Ensuite, chargez le nouveau profil en utilisant apparmor_parser -a :

$ cat /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres | sudo apparmor_parser -a

Si vous souhaitez modifier quelque chose sur ce profil, vous devrez le recharger :

$ apparmor_parser -r /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres

Vous pouvez affecter le mode Complain au profil en utilisant la commande suivante :

$ aa-complain /usr/lib/postgresql/13/bin/postgres

Ensuite, vous pouvez vérifier le fichier syslog dans /var/log pour voir si la configuration d'AppArmor est correcte ou si vous devez modifier quelque chose. Lorsqu'il est sûr, vous pouvez changer le mode en Appliquer en exécutant :

$ aa-enforce /usr/lib/postgresql/13/bin/postgres

Vous pouvez filtrer le journal en recherchant les actions AUTORISÉES ou REFUSÉES :

Jun 25 19:48:02 ip-172-31-18-94 kernel: [ 5160.111028] audit: type=1400 audit(1624650482.537:103): apparmor="ALLOWED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17405/oom_score_adj" pid=17405 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113

Jun 25 19:48:02 ip-172-31-18-94 kernel: [ 5160.112524] audit: type=1400 audit(1624650482.541:104): apparmor="ALLOWED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17404/oom_score_adj" pid=17404 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113

Jun 25 19:50:02 ip-172-31-18-94 kernel: [ 5280.141262] audit: type=1400 audit(1624650602.569:112): apparmor="DENIED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17518/oom_score_adj" pid=17518 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113

Vous pouvez également désactiver les profils de cette manière :

$ aa-disable /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres

Et vous devrez recharger le service :

$ systemctl reload apparmor.service

Si vous préférez désactiver AppArmor, vous pouvez exécuter :

$ systemctl stop apparmor
$ systemctl disable apparmor

Bien sûr, cela n'est pas recommandé pour les environnements de production, et vous devriez le faire fonctionner, au moins, en utilisant le mode Complain dans tous les profils, afin que vous puissiez vérifier les journaux à la recherche d'un comportement inattendu.

Comment utiliser PostgreSQL et TimescaleDB avec ClusterControl et AppArmor

ClusterControl ne gère aucun module de sécurité du noyau Linux comme AppArmor. Lors du déploiement d'un cluster PostgreSQL ou TimescaleDB à l'aide de ClusterControl, vous pouvez spécifier si vous souhaitez que ClusterControl désactive AppArmor pour vous pendant le processus de déploiement afin de réduire le risque d'erreurs :

Si vous ne souhaitez pas le désactiver, ce qui est recommandé pour la production environnements, vous pouvez utiliser le mode Réclamation et surveiller le journal de vos serveurs pour vous assurer que vous disposez de la configuration AppArmor correcte. Après cela, vous pouvez le changer en Appliquer en suivant les instructions mentionnées ci-dessus.

Vous pouvez trouver plus d'informations sur la configuration d'AppArmor sur le site officiel d'Ubuntu.