Jak zabezpieczyć klaster Galera — 8 wskazówek

Jako rozproszony system baz danych Galera Cluster wymaga dodatkowych środków bezpieczeństwa w porównaniu ze scentralizowaną bazą danych. Dane są rozprowadzane na wielu serwerach, a może nawet w centrach danych. Przy znacznej komunikacji danych między węzłami może wystąpić znaczne narażenie, jeśli nie zostaną podjęte odpowiednie środki bezpieczeństwa.

W tym poście na blogu przyjrzymy się kilku wskazówkom, jak zabezpieczyć nasz klaster Galera. Zwróć uwagę, że ten blog powstał na podstawie naszego poprzedniego wpisu na blogu – Jak zabezpieczyć swoje bazy danych typu open source za pomocą ClusterControl.

Grupa zapory i zabezpieczeń

Następujące porty są bardzo ważne dla klastra Galera:

• 3306 — MySQL
• 4567 — Komunikacja i replikacja Galera
• 4568 — Galera IST
• 4444 — Galera SST

Z sieci zewnętrznej zaleca się otwieranie dostępu tylko do portu MySQL 3306. Pozostałe trzy porty można zamknąć z sieci zewnętrznej i zezwalają one tylko na dostęp wewnętrzny pomiędzy węzłami Galera. Jeśli korzystasz z zwrotnego proxy przed węzłami Galera, na przykład HAProxy, możesz zablokować publiczny dostęp do portu MySQL. Upewnij się również, że port monitorowania dla skryptu monitorowania HAProxy jest otwarty. Domyślny port to 9200 w węźle Galera.

Poniższy diagram ilustruje naszą przykładową konfigurację w trójwęzłowym klastrze Galera, z HAProxy skierowanym do sieci publicznej z powiązanymi portami:

Na podstawie powyższego diagramu polecenia iptables dla węzłów bazy danych to:

$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 3306 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 4444 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dports 4567:4568 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 9200 -j ACCEPT

W systemie równoważenia obciążenia:

$ iptables -A INPUT -p tcp --dport 3307 -j ACCEPT

Pamiętaj, aby zakończyć reguły zapory z opcją odrzuć wszystko, aby dozwolony był tylko ruch określony w regułach wyjątków. Możesz być bardziej rygorystyczny i rozszerzyć polecenia, aby były zgodne z twoją polityką bezpieczeństwa - na przykład dodając interfejs sieciowy, adres docelowy, adres źródłowy, stan połączenia i co nie.

Szyfrowanie MySQL klient-serwer

MySQL obsługuje szyfrowanie między klientem a serwerem. Najpierw musimy wygenerować certyfikat. Po skonfigurowaniu możesz wymusić na kontach użytkowników określenie pewnych opcji połączenia z szyfrowaniem z serwerem MySQL.

Kroki wymagają:

1. Utwórz klucz dla urzędu certyfikacji (ca-key.pem)
2. Wygeneruj certyfikat CA z podpisem własnym (ca-cert.pem)
3. Utwórz klucz dla certyfikatu serwera (server-key.pem)
4. Wygeneruj certyfikat dla serwera i podpisz go za pomocą ca-key.pem (server-cert.pem)
5. Utwórz klucz dla certyfikatu klienta (client-key.pem)
6. Wygeneruj certyfikat dla klienta i podpisz go za pomocą ca-key.pem (client-cert.pem)

Zawsze uważaj na klucz prywatny CA (ca-key.pem) — każdy, kto ma do niego dostęp, może go użyć do wygenerowania dodatkowych certyfikatów klienta lub serwera, które zostaną zaakceptowane jako legalne po włączeniu weryfikacji CA. Najważniejsze jest to, że wszystkie klucze muszą być dyskretne.

Następnie możesz dodać zmienne związane z SSL zgodnie z dyrektywą [mysqld], na przykład:

ssl-ca=/etc/ssl/mysql/ca-cert.pem
ssl-cert=/etc/ssl/mysql/server-cert.pem
ssl-key=/etc/ssl/mysql/server-key.pem

Zrestartuj serwer MySQL, aby załadować zmiany. Następnie utwórz użytkownika z instrukcją REQUIRE SSL, na przykład:

mysql> GRANT ALL PRIVILEGES ON db1.* TO 'dbuser'@'192.168.1.100' IDENTIFIED BY 'mySecr3t' REQUIRE SSL;

Użytkownik utworzony za pomocą REQUIRE SSL zostanie zmuszony do połączenia się z poprawnymi plikami SSL klienta (client-cert.pem, client-key.pem i ca-cert.pem).

Dzięki ClusterControl szyfrowanie SSL klient-serwer można łatwo włączyć z poziomu interfejsu użytkownika, korzystając z funkcji „Utwórz szyfrowanie SSL”.

Szyfrowanie Galery

Włączenie szyfrowania dla Galera oznacza, że ​​IST będzie również szyfrowany, ponieważ komunikacja odbywa się za pośrednictwem tego samego gniazda. Z drugiej strony SST należy skonfigurować osobno, jak pokazano w następnej sekcji. Wszystkie węzły w klastrze muszą mieć włączone szyfrowanie SSL i nie można mieć kombinacji węzłów, w których niektóre mają włączone szyfrowanie SSL, a inne nie. Najlepszy czas na skonfigurowanie to konfiguracja nowego klastra. Jeśli jednak musisz dodać to do działającego systemu produkcyjnego, niestety będziesz musiał ponownie uruchomić klaster i nastąpi przestój.

Wszystkie węzły Galera w klastrze muszą używać tego samego klucza, certyfikatu i urzędu certyfikacji (opcjonalnie). Możesz również użyć tego samego klucza i certyfikatu utworzonego do szyfrowania klient-serwer MySQL lub wygenerować nowy zestaw tylko do tego celu. Aby aktywować szyfrowanie w Galera, należy dołączyć opcję i wartość pod wsrep_provider_options w pliku konfiguracyjnym MySQL na każdym węźle Galera. Rozważmy na przykład następującą istniejącą linię dla naszego węzła Galera:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0;"

Dołącz powiązane zmienne wewnątrz cytatu, oddzielone średnikiem:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0; socket.ssl_cert=/etc/mysql/cert.pem; socket.ssl_key=/etc/mysql/key.pem;"

Więcej informacji o parametrach Galera związanych z SSL można znaleźć tutaj. Wykonaj tę modyfikację na wszystkich węzłach. Następnie zatrzymaj klaster (jeden węzeł na raz) i wykonaj rozruch z ostatniego zamkniętego węzła. Możesz sprawdzić, czy SSL jest poprawnie załadowany, zaglądając do dziennika błędów MySQL:

2018-01-19T01:15:30.155211Z 0 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '192.168.10.61:,192.168.10.62:,192.168.10.63:'
2018-01-19T01:15:30.159654Z 0 [Note] WSREP: SSL handshake successful, remote endpoint ssl://192.168.10.62:53024 local endpoint ssl://192.168.10.62:4567 cipher: AES128-SHA compression:

Dzięki ClusterControl szyfrowanie Galera Replication można łatwo włączyć za pomocą funkcji „Utwórz szyfrowanie SSL Galera”.

Szyfrowanie SST

Gdy SST odbywa się bez szyfrowania, komunikacja danych jest ujawniana podczas trwania procesu SST. SST to pełny proces synchronizacji danych od dawcy do węzła łączącego. Gdyby atakujący był w stanie „zobaczyć” pełną transmisję danych, osoba ta otrzymałaby pełną migawkę Twojej bazy danych.

SST z szyfrowaniem jest obsługiwane tylko dla metod mysqldump i xtrabackup-v2. W przypadku mysqldump użytkownik musi mieć przyznane "WYMAGAJ SSL" na wszystkich węzłach, a konfiguracja jest podobna do standardowego szyfrowania SSL klient-serwer MySQL (jak opisano w poprzedniej sekcji). Po aktywowaniu szyfrowania klient-serwer utwórz nowego użytkownika SST z wymuszonym protokołem SSL:

mysql> GRANT ALL ON *.* TO 'sst_user'@'%' IDENTIFIED BY 'mypassword' REQUIRE SSL;

W przypadku rsync zalecamy użycie galera-secure-rsync, skryptu SST rsync zabezpieczonego SSL dla Galera Cluster. Działa prawie dokładnie tak, jak wsrep_sst_rsync poza tym, że zabezpiecza faktyczną komunikację za pomocą protokołu SSL przy użyciu socat. Wygeneruj wymagane pliki kluczy i certyfikatów klienta/serwera, skopiuj je do wszystkich węzłów i określ „secure_rsync” jako metodę SST w pliku konfiguracyjnym MySQL, aby ją aktywować:

wsrep_sst_method=secure_rsync

W przypadku xtrabackup następujące opcje konfiguracyjne muszą być włączone w pliku konfiguracyjnym MySQL pod dyrektywą [sst]:

[sst]
encrypt=4
ssl-ca=/path/to/ca-cert.pem
ssl-cert=/path/to/server-cert.pem
ssl-key=/path/to/server-key.pem

Ponowne uruchomienie bazy danych nie jest konieczne. Jeśli ten węzeł zostanie wybrany przez Galera jako dawca, te opcje konfiguracji zostaną wybrane automatycznie, gdy Galera zainicjuje SST.

SELinux

Security-Enhanced Linux (SELinux) to mechanizm kontroli dostępu zaimplementowany w jądrze. Bez SELinux do kontroli dostępu użytkowników do plików używane są tylko tradycyjne metody kontroli dostępu, takie jak uprawnienia do plików lub listy ACL.

Domyślnie, przy włączonym trybie ścisłego wymuszania, wszystko jest odrzucane, a administrator musi utworzyć serię polityk wyjątków dla elementów systemu wymaganych do działania. Całkowite wyłączenie SELinux stało się obecnie powszechną złą praktyką w wielu instalacjach opartych na RedHat.

W zależności od obciążeń, wzorców użytkowania i procesów, najlepszym sposobem jest stworzenie własnego modułu polityki SELinux dostosowanego do Twojego środowiska. To, co naprawdę musisz zrobić, to ustawić SELinux w trybie zezwalającym (rejestrowanie tylko bez wymuszania) i wyzwalać zdarzenia, które mogą się zdarzyć w węźle Galera, aby SELinux mógł je rejestrować. Im bardziej rozbudowany, tym lepiej. Przykładowe wydarzenia, takie jak:

• Węzeł początkowy jako dawca lub dołączający
• Uruchom ponownie węzeł, aby wyzwolić IST
• Użyj różnych metod SST
• Tworzenie kopii zapasowych i przywracanie baz danych MySQL za pomocą mysqldump lub xtrabackup
• Włącz i wyłącz logi binarne

Jednym z przykładów jest to, że jeśli węzeł Galera jest monitorowany przez ClusterControl, a funkcja monitora zapytań jest włączona, ClusterControl włączy/wyłączy zmienną dziennika powolnych zapytań, aby przechwycić wolno działające zapytania. W ten sposób w pliku audit.log zobaczysz następującą odmowę:

$ grep -e denied audit/audit.log | grep -i mysql
type=AVC msg=audit(1516835039.802:37680): avc:  denied  { open } for  pid=71222 comm="mysqld" path="/var/log/mysql/mysql-slow.log" dev="dm-0" ino=35479360 scontext=system_u:system_r:mysqld_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

Chodzi o to, aby wszystkie możliwe odmowy były rejestrowane w dzienniku kontroli, który później może zostać użyty do wygenerowania modułu zasad za pomocą audit2allow przed załadowaniem go do SELinux. Koderstwo omówiło to szczegółowo na stronie dokumentacji, Konfiguracja SELinux.

Konto i uprawnienia SST

SST to wstępny proces synchronizacji wykonywany przez Galera. Aktualizuje węzeł przyłączający się z pozostałymi członkami w klastrze. Proces zasadniczo eksportuje dane z węzła dawcy i przywraca je w węźle dołączającym, zanim dołączający będzie mógł dogonić pozostałe transakcje z kolejki (tj. te, które miały miejsce podczas procesu synchronizacji). Obsługiwane są trzy metody KST:

• mysqldump
• rsync
• xtrabackup (lub xtrabackup-v2)

Do korzystania z mysqldump SST wymagane są następujące uprawnienia:

• WYBIERZ, POKAŻ WIDOK, WYZWALAJ, ZABLOKUJ TABELĘ, ZAŁADUJ PONOWNIE, PLIK

Z mysqldump nie będziemy iść dalej, ponieważ prawdopodobnie nie jest on często używany w produkcji jako metoda SST. Poza tym jest to procedura blokująca na dawcy. Rsync jest zwykle preferowanym drugim wyborem po xtrabackup ze względu na szybszy czas synchronizacji i mniejszą podatność na błędy w porównaniu z mysqldump. Uwierzytelnianie SST jest ignorowane w przypadku rsync, dlatego możesz pominąć konfigurację uprawnień konta SST, jeśli wybraną metodą SST jest rsync.

Przechodząc wraz z xtrabackup, zalecane są następujące uprawnienia dla standardowych procedur tworzenia kopii zapasowych i przywracania w oparciu o stronę dokumentacji Xtrabackup:

• UTWÓRZ, UTWÓRZ PRZESTRZEŃ TABEL, ZDARZENIE, WSTAW, ZABLOKUJ TABELĘ, PRZETWARZAJ, PONOWNIE ZAŁADUJ, KLIENT REPLIKACJI, WYBIERZ, POKAŻ WIDOK, SUPER

Jednak w przypadku użycia SST przez xtrabackup liczą się tylko następujące uprawnienia:

• PROCES, PRZEŁADOWANIE, KLIENT REPLIKACJI

W ten sposób oświadczenie GRANT dla SST można zminimalizować jako:

mysql> GRANT PROCESS,RELOAD,REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost' IDENTIFIED BY '[email protected]@sTr0nG%%P4ssW0rD';

Następnie skonfiguruj odpowiednio wsrep_sst_auth w pliku konfiguracyjnym MySQL:

wsrep_sst_auth = sstuser:[email protected]@sTr0nG%%P4ssW0rD

Przyznaj użytkownikowi SST tylko dla hosta lokalnego i używaj silnego hasła. Unikaj używania użytkownika root jako konta SST, ponieważ ujawniłoby to hasło roota w pliku konfiguracyjnym pod tą zmienną. Ponadto zmiana lub zresetowanie hasła root MySQL spowodowałoby w przyszłości uszkodzenie SST.

Wzmocnienie zabezpieczeń MySQL

Galera Cluster to wtyczka do replikacji z wieloma wzorcami dla silnika pamięci masowej InnoDB, która działa na forkach MySQL i MariaDB. Dlatego standardowe zalecenia dotyczące zwiększania bezpieczeństwa MySQL/MariaDB/InnoDB dotyczą również Galera Cluster.

Ten temat został omówiony w wielu postach na blogu. Omówiliśmy ten temat również w następujących postach na blogu:

• Dziesięć wskazówek, jak osiągnąć bezpieczeństwo MySQL i MariaDB
• Wskazówki i wskazówki dotyczące ClusterControl:zabezpieczanie instalacji MySQL
• Jak zabezpieczyć swoje bazy danych Open Source za pomocą ClusterControl

Powyższe wpisy na blogu podsumowują konieczność szyfrowania danych w spoczynku i przesyłanych danych, posiadania wtyczek audytu, ogólnych wytycznych dotyczących bezpieczeństwa, najlepszych praktyk w zakresie bezpieczeństwa sieci i tak dalej.

Użyj systemu równoważenia obciążenia

Istnieje wiele równoważników obciążenia bazy danych (reverse proxy), których można używać razem z Galerą - HAProxy, ProxySQL i MariaDB MaxScale, aby wymienić niektóre z nich. Możesz skonfigurować system równoważenia obciążenia, aby kontrolować dostęp do węzłów Galera. Jest to świetny sposób na rozłożenie obciążenia bazy danych między instancjami bazy danych, a także ograniczenie dostępu, np. jeśli chcesz przełączyć węzeł w tryb offline w celu konserwacji lub jeśli chcesz ograniczyć liczbę połączeń otwieranych na węzłach Galera. System równoważenia obciążenia powinien być w stanie kolejkować połączenia, a zatem zapewniać pewną ochronę przed przeciążeniem serwerów baz danych.

ProxySQL, potężny odwrotny serwer proxy bazy danych, który rozumie MySQL i MariaDB, może zostać rozszerzony o wiele przydatnych funkcji bezpieczeństwa, takich jak zapora zapytań, w celu blokowania obraźliwych zapytań z serwera bazy danych. Silnik reguł zapytań może być również użyty do przepisania złych zapytań w coś lepszego/bezpieczniejszego lub przekierowania ich na inny serwer, który może zaabsorbować obciążenie bez wpływu na którykolwiek z węzłów Galera. MariaDB MaxScale może również blokować zapytania na podstawie wyrażeń regularnych za pomocą filtra zapory bazy danych.

Kolejną zaletą posiadania systemu równoważenia obciążenia dla klastra Galera jest możliwość hostowania usługi danych bez narażania warstwy bazy danych na sieć publiczną. Serwer proxy może być używany jako host bastionu w celu uzyskania dostępu do węzłów bazy danych w sieci prywatnej. Izolując klaster bazy danych od świata zewnętrznego, usunąłeś jeden z ważnych wektorów ataku.

Otóż ​​to. Zawsze bądź bezpieczny i chroniony.