Bezpieczeństwo jest niezbędne dla wszystkich systemów, aby chronić Twoje dane tak bardzo, jak to możliwe. Nawet jeśli zawsze istnieje ryzyko włamania, przestrzeganie listy kontrolnej bezpieczeństwa znacznie zmniejszy to ryzyko. Podstawowa lista kontrolna bezpieczeństwa obejmuje konfigurację zapory sieciowej, szyfrowanie danych, politykę uwierzytelniania itp. Innym ważnym narzędziem do ochrony danych w systemach operacyjnych opartych na Debianie jest AppArmor. W tym blogu zobaczymy, co to jest i jak go skonfigurować dla baz danych PostgreSQL i TimescaleDB.
Co to jest AppArmor?
AppArmor, dołączony domyślnie w systemach operacyjnych Ubuntu i Debian (między innymi), to system obowiązkowej kontroli dostępu (MAC), który ogranicza programy do ograniczonego zestawu zasobów. Działa przy użyciu profili załadowanych do jądra. Profile te można skonfigurować w dwóch trybach:
-
Egzekwowanie:Profile załadowane w tym trybie będą egzekwować zasady zdefiniowane w profilu, a także zgłaszać naruszenie zasad próby.
-
Narzeka:Profile w tym trybie nie będą egzekwować zasad, ale zamiast tego zgłaszają próby naruszenia zasad.
Ponadto AppArmor umożliwia mieszanie profili trybu egzekwowania i skarg.
Jak skonfigurować AppArmor
Profile AppArmor znajdują się w /etc/apparmor.d/. Możesz stworzyć własne profile i przenieść je tam lub sprawdzić repozytorium AppArmor. Zobaczmy, jak stworzyć nowy profil AppArmor.
Najpierw zainstalujmy niezbędne pakiety do obsługi tego:
$ apt install apparmor-profiles apparmor-utils
I sprawdź, czy AppArmor jest włączony:
$ systemctl status apparmor.service
lub
$ 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
...
Jeśli sprawdzisz wspomnianą ścieżkę /etc/apparmor.d/, zobaczysz kilka podstawowych profili, takich jak usr.sbin.tcpdump lub usr.sbin.traceroute. Teraz stwórzmy nowy profil dla PostgreSQL lub TimescaleDB. W tym celu możesz użyć tego profilu jako przykładu. Bazując na tym profilu, zastąpimy wersję PostgreSQL, aby była bardziej szczegółowa. W tym przypadku użyjemy 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,
}
Przechowuj go w /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres. Następnie załaduj nowy profil za pomocą apparmor_parser -a:
$ cat /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres | sudo apparmor_parser -a
Jeśli chcesz coś zmienić w tym profilu, musisz go ponownie załadować:
$ apparmor_parser -r /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres
Możesz przypisać tryb skarg do profilu za pomocą następującego polecenia:
$ aa-complain /usr/lib/postgresql/13/bin/postgres
Następnie możesz sprawdzić plik syslog w /var/log, aby sprawdzić, czy konfiguracja AppArmor jest poprawna, czy też musisz coś zmodyfikować. Gdy jest to bezpieczne, możesz zmienić tryb na Wymuszaj, uruchamiając:
$ aa-enforce /usr/lib/postgresql/13/bin/postgres
Możesz filtrować dziennik pod kątem działań DOZWOLONE lub ODMOWA:
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
Możesz także wyłączyć profile w ten sposób:
$ aa-disable /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres
I trzeba będzie ponownie załadować usługę:
$ systemctl reload apparmor.service
Jeśli wolisz wyłączyć AppArmor, możesz uruchomić:
$ systemctl stop apparmor
$ systemctl disable apparmor
Oczywiście nie jest to zalecane w środowiskach produkcyjnych i należy je utrzymywać przynajmniej w trybie narzekania we wszystkich profilach, aby można było sprawdzić logi w poszukiwaniu nieoczekiwanych zachowań.
Jak używać PostgreSQL i TimescaleDB z ClusterControl i AppArmor
ClusterControl nie zarządza żadnymi modułami bezpieczeństwa jądra Linuksa, takimi jak AppArmor. Podczas wdrażania klastra PostgreSQL lub TimescaleDB za pomocą ClusterControl możesz określić, czy chcesz, aby ClusterControl wyłączał AppArmor podczas procesu wdrażania, aby zmniejszyć ryzyko błędów:
Jeśli nie chcesz go wyłączać, co jest zalecane w przypadku produkcji środowiskach, możesz użyć trybu Reklamacji i monitorować dziennik na swoich serwerach, aby upewnić się, że masz poprawną konfigurację AppArmor. Następnie możesz zmienić go na Wymuszanie, postępując zgodnie z instrukcjami wymienionymi powyżej.
Więcej informacji na temat konfiguracji AppArmor można znaleźć na oficjalnej stronie Ubuntu.