Sicherheit ist ein Muss für alle Systeme, um Ihre Daten so gut wie möglich zu schützen. Auch wenn immer das Risiko besteht, gehackt zu werden, wird dieses Risiko durch das Befolgen einer Sicherheits-Checkliste erheblich reduziert. Eine grundlegende Sicherheits-Checkliste umfasst eine Firewall-Konfiguration, Datenverschlüsselung, Authentifizierungsrichtlinie usw. Ein weiteres wichtiges Tool zum Schutz Ihrer Daten auf Debian-basierten Betriebssystemen ist AppArmor. In diesem Blog werden wir sehen, was das ist und wie man es für PostgreSQL- und TimescaleDB-Datenbanken konfiguriert.
Was ist AppArmor?
AppArmor, standardmäßig in den Betriebssystemen Ubuntu und Debian (unter anderem) enthalten, ist ein MAC-System (Mandatory Access Control), um Programme auf eine begrenzte Anzahl von Ressourcen zu beschränken. Es funktioniert mit in den Kernel geladenen Profilen. Diese Profile können in zwei Modi konfiguriert werden:
-
Durchsetzung:Die in diesem Modus geladenen Profile setzen die im Profil definierte Richtlinie durch und melden Richtlinienverstöße Versuche.
-
Beschweren:Die Profile in diesem Modus erzwingen keine Richtlinien, sondern melden stattdessen Versuche einer Richtlinienverletzung.
Außerdem ermöglicht AppArmor das Mischen von Erzwingungs- und Beschwerdemodusprofilen.
So konfigurieren Sie AppArmor
Die AppArmor-Profile befinden sich in /etc/apparmor.d/. Sie können Ihre eigenen Profile erstellen und sie dorthin verschieben oder das AppArmor-Repository überprüfen. Sehen wir uns an, wie Sie ein neues AppArmor-Profil erstellen.
Lassen Sie uns zuerst die notwendigen Pakete installieren, um dies zu handhaben:
$ apt install apparmor-profiles apparmor-utils
Und prüfen Sie, ob AppArmor aktiviert ist:
$ systemctl status apparmor.service
oder
$ 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
...
Wenn Sie den erwähnten Pfad /etc/apparmor.d/ überprüfen, sehen Sie einige grundlegende Profile wie usr.sbin.tcpdump oder usr.sbin.traceroute. Lassen Sie uns nun ein neues Profil für PostgreSQL oder TimescaleDB erstellen. Dazu können Sie dieses Profil als Beispiel verwenden. Basierend auf diesem Profil werden wir die PostgreSQL-Version ersetzen, um genauer zu sein. In diesem Fall verwenden wir 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,
}
Speichern Sie es in /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres. Laden Sie dann das neue Profil mit apparmor_parser -a:
$ cat /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres | sudo apparmor_parser -a
Wenn Sie etwas an diesem Profil ändern möchten, müssen Sie es neu laden:
$ apparmor_parser -r /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres
Sie können dem Profil den Beschwerdemodus zuweisen, indem Sie den folgenden Befehl verwenden:
$ aa-complain /usr/lib/postgresql/13/bin/postgres
Dann können Sie die Syslog-Datei in /var/log überprüfen, um festzustellen, ob die AppArmor-Konfiguration korrekt ist oder ob Sie etwas ändern müssen. Wenn es sicher ist, können Sie den Modus auf Erzwingen ändern, indem Sie Folgendes ausführen:
$ aa-enforce /usr/lib/postgresql/13/bin/postgres
Sie können das Protokoll filtern, indem Sie nach ZULÄSSIGEN oder VERBOTENEN Aktionen suchen:
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
Sie können Profile auch folgendermaßen deaktivieren:
$ aa-disable /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres
Und Sie müssen den Dienst neu laden:
$ systemctl reload apparmor.service
Falls Sie AppArmor lieber deaktivieren möchten, können Sie Folgendes ausführen:
$ systemctl stop apparmor
$ systemctl disable apparmor
Natürlich wird dies für Produktionsumgebungen nicht empfohlen, und Sie sollten es zumindest am Laufen halten, indem Sie den Beschwerdemodus in allen Profilen verwenden, damit Sie die Protokolle auf unerwartetes Verhalten überprüfen können.
Verwendung von PostgreSQL und TimescaleDB mit ClusterControl und AppArmor
ClusterControl verwaltet keine Linux-Kernel-Sicherheitsmodule wie AppArmor. Wenn Sie einen PostgreSQL- oder TimescaleDB-Cluster mithilfe von ClusterControl bereitstellen, können Sie angeben, ob ClusterControl AppArmor während des Bereitstellungsprozesses für Sie deaktivieren soll, um das Fehlerrisiko zu verringern:
Wenn Sie es nicht deaktivieren möchten, was für die Produktion empfohlen wird Umgebungen können Sie den Beschwerdemodus verwenden und das Protokoll auf Ihren Servern überwachen, um sicherzustellen, dass Sie die richtige AppArmor-Konfiguration haben. Danach können Sie es gemäß den oben genannten Anweisungen in Enforce ändern.
Weitere Informationen zur AppArmor-Konfiguration finden Sie auf der offiziellen Ubuntu-Website.