Jak zabezpieczyć serwer ClusterControl

W naszym poprzednim poście na blogu pokazaliśmy, jak możesz zabezpieczyć swoje bazy danych typu open source za pomocą ClusterControl. Ale co z samym serwerem ClusterControl? Jak to zabezpieczamy? To będzie temat dzisiejszego bloga. Zakładamy, że host jest przeznaczony wyłącznie do użytku ClusterControl, bez uruchomionych na nim innych aplikacji.

Grupa zapory i zabezpieczeń

Przede wszystkim powinniśmy zamknąć wszystkie niepotrzebne porty i otwierać tylko niezbędne porty używane przez ClusterControl. Wewnętrznie, między ClusterControl a serwerami bazy danych, liczy się tylko port netcat, gdzie domyślny port to 9999. Ten port należy otworzyć tylko wtedy, gdy chcesz przechowywać kopię zapasową na serwerze ClusterControl. W przeciwnym razie możesz to zamknąć.

Z sieci zewnętrznej zaleca się otwieranie dostępu tylko do HTTP (80) lub HTTPS (443) dla interfejsu użytkownika ClusterControl. Jeśli używasz ClusterControl CLI o nazwie „s9s”, punkt końcowy CMON-TLS musi być otwarty na porcie 9501. Możliwe jest również zainstalowanie aplikacji związanych z bazą danych na serwerze ClusterControl, takich jak HAProxy, Keepalived, ProxySQL i tym podobne. W takim przypadku również musisz otworzyć niezbędne porty. Zapoznaj się ze stroną dokumentacji, aby uzyskać listę portów dla każdej usługi.

Aby skonfigurować reguły zapory sieciowej za pomocą iptables, w węźle ClusterControl wykonaj:

$ iptables -A INPUT -p tcp --dport 9999 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 80 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 443 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 9501 -j ACCEPT
$ iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT

Powyższe to najprostsze polecenia. 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.

Podobnie jak w przypadku uruchamiania konfiguracji w chmurze, poniżej znajduje się przykład przychodzących reguł grup zabezpieczeń dla serwera ClusterControl w AWS:

Różni dostawcy usług w chmurze zapewniają różne implementacje grup zabezpieczeń, ale podstawowe zasady są podobne.

Szyfrowanie

ClusterControl obsługuje szyfrowanie komunikacji na różnych poziomach, aby zapewnić jak najbezpieczniejsze wykonywanie zadań automatyzacji, monitorowania i zarządzania.

Działa na HTTPS

Skrypt instalatora (install-cc.sh) domyślnie skonfiguruje samopodpisany certyfikat SSL do użytku HTTPS. Jeśli wybierzesz tę metodę dostępu jako główny punkt końcowy, możesz zablokować zwykłą usługę HTTP działającą na porcie 80 z sieci zewnętrznej. Jednak ClusterControl nadal wymaga dostępu do CMONAPI (starszego interfejsu Rest-API), który domyślnie działa na porcie 80 na hoście lokalnym. Jeśli chcesz zablokować cały port HTTP, upewnij się, że zmieniłeś adres URL interfejsu ClusterControl API w sekcji Rejestracje klastra strona, aby zamiast tego używać HTTPS:

Certyfikat z podpisem własnym skonfigurowany przez ClusterControl ma 10 lat (3650 dni) ważności. Możesz zweryfikować ważność certyfikatu za pomocą następującego polecenia (na serwerze CentOS 7):

$  openssl x509 -in /etc/ssl/certs/s9server.crt -text -noout
...
        Validity
            Not Before: Apr  9 21:22:42 2014 GMT
            Not After : Mar 16 21:22:42 2114 GMT
...

Zwróć uwagę, że bezwzględna ścieżka do pliku certyfikatu może się różnić w zależności od systemu operacyjnego.

Szyfrowanie MySQL klient-serwer

ClusterControl przechowuje dane monitorowania i zarządzania w bazach danych MySQL w węźle ClusterControl. Ponieważ sam MySQL obsługuje szyfrowanie SSL klient-serwer, ClusterControl jest w stanie wykorzystać tę funkcję do ustanowienia zaszyfrowanej komunikacji z serwerem MySQL podczas zapisywania i pobierania danych.

W tym celu obsługiwane są następujące opcje konfiguracji:

• cmondb_ssl_key - ścieżka do klucza SSL, dla szyfrowania SSL między CMON a CMON DB.
• cmondb_ssl_cert - ścieżka do certyfikatu SSL, dla szyfrowania SSL między CMON a CMON DB
• cmondb_ssl_ca - ścieżka do SSL CA, do szyfrowania SSL między CMON a CMON DB

Czynności konfiguracyjne omówiliśmy w tym poście na blogu jakiś czas temu.

Jest jednak pewien haczyk. W chwili pisania tego tekstu interfejs użytkownika ClusterControl ma ograniczenia w dostępie do bazy danych CMON za pośrednictwem protokołu SSL przy użyciu użytkownika cmon. Jako obejście mamy zamiar utworzyć innego użytkownika bazy danych dla interfejsu użytkownika ClusterControl i ClusterControl CMONAPI o nazwie cmonui. Ten użytkownik nie będzie miał włączonej obsługi SSL w swojej tabeli uprawnień.

mysql> GRANT ALL PRIVILEGES ON *.* TO 'cmonui'@'127.0.0.1' IDENTIFIED BY '<cmon password>';
mysql> FLUSH PRIVILEGES;

Zaktualizuj pliki konfiguracyjne ClusterControl UI i CMONAPI znajdujące się odpowiednio w clustercontrol/bootstrap.php i cmonapi/config/database.php przy użyciu nowo utworzonego użytkownika bazy danych cmonui :

# <wwwroot>/clustercontrol/bootstrap.php
define('DB_LOGIN', 'cmonui');
define('DB_PASS', '<cmon password>');

# <wwwroot>/cmonapi/config/database.php
define('DB_USER', 'cmonui');
define('DB_PASS', '<cmon password>');

Te pliki nie zostaną zastąpione podczas aktualizacji za pomocą menedżera pakietów.

Szyfrowanie CLI

ClusterControl jest również wyposażony w interfejs wiersza poleceń o nazwie „s9s”. Ten klient analizuje opcje wiersza poleceń i wysyła określone zadanie do usługi kontrolera nasłuchującej na porcie 9500 (CMON) lub 9501 (CMON z TLS). Ten ostatni jest zalecany. Skrypt instalatora domyślnie skonfiguruje interfejs CLI s9s tak, aby używał 9501 jako portu końcowego serwera ClusterControl.

Kontrola dostępu oparta na rolach

ClusterControl używa kontroli dostępu opartej na rolach (RBAC) w celu ograniczenia dostępu do klastrów i ich odpowiednich funkcji wdrażania, zarządzania i monitorowania. Gwarantuje to, że dozwolone są tylko żądania autoryzowanych użytkowników. Dostęp do funkcjonalności jest szczegółowy, co pozwala na zdefiniowanie dostępu przez organizację lub użytkownika. ClusterControl używa struktury uprawnień, aby zdefiniować, w jaki sposób użytkownik może komunikować się z funkcjami zarządzania i monitorowania, po uzyskaniu do tego upoważnienia.

Dostęp do interfejsu użytkownika RBAC można uzyskać przez ClusterControl -> Zarządzanie użytkownikami -> Kontrola dostępu :

Wszystkie funkcje są oczywiste, ale jeśli potrzebujesz dodatkowego opisu, sprawdź stronę dokumentacji.

Jeśli masz wielu użytkowników zaangażowanych w działanie klastra bazy danych, zdecydowanie zaleca się odpowiednie ustawienie dla nich kontroli dostępu. Możesz także utworzyć wiele zespołów (organizacji) i przypisać je do zera lub większej liczby klastrów.

Działa na portach niestandardowych

ClusterControl można skonfigurować tak, aby używał portów niestandardowych dla wszystkich usług zależnych. ClusterControl wykorzystuje SSH jako główny kanał komunikacji do zdalnego zarządzania i monitorowania węzłów, Apache do obsługi interfejsu użytkownika ClusterControl, a także MySQL do przechowywania danych monitorowania i zarządzania. Usługi te można uruchomić na portach niestandardowych, aby ograniczyć wektor ataku. Następujące porty są zwykłymi celami:

• SSH - domyślnie 22
• HTTP – domyślnie 80
• HTTPS - domyślnie 443
• MySQL - domyślnie 3306

Jest kilka rzeczy, które musisz zmienić, aby uruchomić powyższe usługi na portach niestandardowych, aby ClusterControl działał poprawnie. Omówiliśmy to szczegółowo na stronie dokumentacji, Uruchamianie na porcie niestandardowym.

Uprawnienia i własność

Pliki konfiguracyjne ClusterControl zawierają poufne informacje i powinny być dyskretne i dobrze chronione. Pliki muszą być dozwolone tylko dla użytkownika/grupy root, bez uprawnień do odczytu dla innych. W przypadku nieprawidłowego ustawienia uprawnień i własności następujące polecenie pomoże przywrócić je do prawidłowego stanu:

$ chown root:root /etc/cmon.cnf /etc/cmon.d/*.cnf
$ chmod 700 /etc/cmon.cnf /etc/cmon.d/*.cnf

W przypadku usługi MySQL upewnij się, że zawartość katalogu danych MySQL jest dozwolona dla grupy „mysql”, a użytkownikiem może być „mysql” lub „root”:

$ chown -Rf mysql:mysql /var/lib/mysql

W przypadku interfejsu użytkownika ClusterControl własność musi być dopuszczalna dla użytkownika Apache, albo „apache” dla RHEL/CentOS lub „www-data” dla systemu operacyjnego opartego na Debianie.

Klucz SSH do łączenia się z hostami bazy danych jest kolejnym bardzo ważnym aspektem, ponieważ przechowuje tożsamość i musi być przechowywany z odpowiednimi uprawnieniami i własnością. Ponadto SSH nie pozwoli na użycie niezabezpieczonego pliku klucza podczas inicjowania połączenia zdalnego. Sprawdź, czy plik klucza SSH używany przez klaster, wewnątrz wygenerowanych plików konfiguracyjnych w katalogu /etc/cmon.d/, jest ustawiony na dozwolony dla osuser tylko opcja. Rozważmy na przykład osuser to „ubuntu”, a plik klucza to /home/ubuntu/.ssh/id_rsa:

$ chown ubuntu:ubuntu /home/ubuntu/.ssh/id_rsa
$ chmod 700 /home/ubuntu/.ssh/id_rsa

Użyj silnego hasła

Jeśli używasz skryptu instalatora do zainstalowania ClusterControl, zachęcamy do użycia silnego hasła po wyświetleniu monitu przez instalatora. Istnieją co najwyżej dwa konta, które skrypt instalatora będzie musiał skonfigurować (w zależności od konfiguracji):

• Hasło cmon MySQL - Domyślna wartość to „cmon”.
• Hasło roota MySQL - Domyślna wartość to „hasło”.

Za używanie silnych haseł na tych dwóch kontach odpowiada użytkownik. Skrypt instalacyjny obsługuje kilka znaków specjalnych do wprowadzania hasła, jak wspomniano w kreatorze instalacji:

=> Set a password for ClusterControl's MySQL user (cmon) [cmon]
=> Supported special password characters: [email protected]#$%^&*()_+{}<>?

Sprawdź zawartość /etc/cmon.cnf i /etc/cmon.d/cmon_*.cnf i upewnij się, że używasz silnego hasła, gdy tylko jest to możliwe.

Zmiana hasła „cmon” MySQL

Jeśli skonfigurowane hasło nie spełnia Twoich zasad dotyczących haseł, aby zmienić hasło cmon MySQL, musisz wykonać kilka kroków:

1. Zmień hasło na serwerze MySQL ClusterControl:

   $ ALTER USER 'cmon'@'127.0.0.1' IDENTIFIED BY 'newPass';
   $ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
   $ FLUSH PRIVILEGES;

2. Zaktualizuj wszystkie wystąpienia opcji „mysql_password” dla usługi kontrolera w /etc/cmon.cnf i /etc/cmon.d/*.cnf:

   mysql_password=newPass

3. Zaktualizuj wszystkie wystąpienia stałych 'DB_PASS' dla ClusterControl UI wewnątrz /var/www/html/clustercontrol/bootstrap.php i /var/www/html/cmonapi/config/database.php:

   # <wwwroot>/clustercontrol/bootstrap.php
   define('DB_PASS', 'newPass');

   # <wwwroot>/cmonapi/config/database.php
   define('DB_PASS', 'newPass');

4. Zmień hasło na każdym serwerze MySQL monitorowanym przez ClusterControl:

   $ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
   $ FLUSH PRIVILEGES;

5. Uruchom ponownie usługę CMON, aby zastosować zmiany:

   $ service cmon restart # systemctl restart cmon

Sprawdź, czy proces cmon został uruchomiony poprawnie, przeglądając plik /var/log/cmon.log. Upewnij się, że masz coś takiego jak poniżej:

2018-01-11 08:33:09 : (INFO) Additional RPC URL for events: 'http://127.0.0.1:9510'
2018-01-11 08:33:09 : (INFO) Configuration loaded.
2018-01-11 08:33:09 : (INFO) cmon 1.5.1.2299
2018-01-11 08:33:09 : (INFO) Server started at tcp://127.0.0.1:9500
2018-01-11 08:33:09 : (INFO) Server started at tls://127.0.0.1:9501
2018-01-11 08:33:09 : (INFO) Found 'cmon' schema version 105010.
2018-01-11 08:33:09 : (INFO) Running cmon schema hot-fixes.
2018-01-11 08:33:09 : (INFO) Schema auto-upgrade succeed (version 105010).
2018-01-11 08:33:09 : (INFO) Checked tables - seems ok
2018-01-11 08:33:09 : (INFO) Community version
2018-01-11 08:33:09 : (INFO) CmonCommandHandler: started, polling for commands.

Uruchamianie offline

ClusterControl jest w stanie zarządzać infrastrukturą bazy danych w środowisku bez dostępu do Internetu. Niektóre funkcje nie działałyby w tym środowisku (kopia zapasowa w chmurze, wdrażanie przy użyciu publicznych repozytoriów, aktualizacje), główne funkcje są dostępne i będą działać dobrze. Masz również możliwość wstępnego wdrożenia wszystkiego za pomocą Internetu, a następnie odcięcia Internetu, gdy konfiguracja zostanie przetestowana i będzie gotowa do obsługi danych produkcyjnych.

Dzięki odizolowaniu ClusterControl i klastra bazy danych od świata zewnętrznego wyeliminowałeś jeden z ważnych wektorów ataku.

Podsumowanie

ClusterControl może pomóc zabezpieczyć klaster bazy danych, ale sam się nie zabezpiecza. Zespoły operacyjne muszą upewnić się, że serwer ClusterControl jest również wzmocniony z punktu widzenia bezpieczeństwa.