Как да защитим клъстер Galera - 8 съвета

Като система за разпределена база данни, Galera Cluster изисква допълнителни мерки за сигурност в сравнение с централизирана база данни. Данните се разпределят между множество сървъри или дори центрове за данни. При значителна комуникация на данни между възли може да има значителна експозиция, ако не се вземат съответните мерки за сигурност.

В тази публикация в блога ще разгледаме някои съвети как да защитим нашия клъстер Galera. Имайте предвид, че този блог се основава на предишната ни публикация в блога – Как да защитите своите бази данни с отворен код с ClusterControl.

Група за защитна стена и сигурност

Следните портове са много важни за клъстер Galera:

• 3306 - MySQL
• 4567 – комуникация и репликация на Galera
• 4568 - Galera IST
• 4444 - Galera SST

От външната мрежа се препоръчва достъп само до MySQL порт 3306. Останалите три порта могат да бъдат затворени от външната мрежа и им позволява само вътрешен достъп между възлите на Galera. Ако използвате обратен прокси, стоящ пред възлите на Galera, например HAProxy, можете да заключите порта на MySQL от публичен достъп. Също така се уверете, че портът за наблюдение за скрипта за наблюдение на HAProxy е отворен. Портът по подразбиране е 9200 на възела Galera.

Следната диаграма илюстрира нашата примерна настройка на Galera Cluster с три възела, с HAProxy, обърнат към публичната мрежа със свързаните с нея портове:

Въз основа на горната диаграма командите iptables за възлите на базата данни са:

$ 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

Докато сте в балансира на натоварването:

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

Уверете се, че сте приключили правилата на защитната си стена с deny all, така че е разрешен само трафикът, както е дефиниран в правилата за изключения. Можете да бъдете по-строги и да разширите командите, за да следвате вашата политика за сигурност – например, като добавите мрежов интерфейс, адрес на местоназначение, адрес на източник, състояние на връзката и какво ли още не.

Клиент-сървър криптиране на MySQL

MySQL поддържа криптиране между клиента и сървъра. Първо трябва да генерираме сертификата. След като сте конфигурирани, можете да наложите потребителски акаунти, за да зададете определени опции за свързване с криптиране към MySQL сървър.

Стъпките изискват от вас:

1. Създайте ключ за сертифициращ орган (ca-key.pem)
2. Генерирайте самоподписан CA сертификат (ca-cert.pem)
3. Създайте ключ за сървърен сертификат (server-key.pem)
4. Генерирайте сертификат за сървър и го подпишете с ca-key.pem (server-cert.pem)
5. Създайте ключ за клиентски сертификат (client-key.pem)
6. Генерирайте сертификат за клиента и го подпишете с ca-key.pem (client-cert.pem)

Винаги внимавайте с частния ключ на CA (ca-key.pem) - всеки, който има достъп до него, може да го използва за генериране на допълнителни клиентски или сървърни сертификати, които ще бъдат приети като легитимни, когато проверката на CA е активирана. Изводът е, че всички ключове трябва да се пазят дискретни.

След това можете да добавите свързаните с SSL променливи под директива [mysqld], например:

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

Рестартирайте MySQL сървъра, за да заредите промените. След това създайте потребител с израза REQUIRE SSL, например:

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

Потребителят, създаден с REQUIRE SSL, ще бъде принуден да се свърже с правилните клиентски SSL файлове (client-cert.pem, client-key.pem и ca-cert.pem).

С ClusterControl SSL криптирането клиент-сървър може лесно да се активира от потребителския интерфейс, като се използва функцията „Създаване на SSL криптиране“.

Шифроване на Galera

Активирането на криптиране за Galera означава, че IST също ще бъде криптиран, тъй като комуникацията се осъществява през същия сокет. SST, от друга страна, трябва да се конфигурира отделно, както е показано в следващия раздел. Всички възли в клъстера трябва да бъдат активирани със SSL криптиране и не можете да имате комбинация от възли, където някои са активирали SSL криптиране, а други не. Най-доброто време да конфигурирате това е, когато настройвате нов клъстер. Ако обаче трябва да добавите това към работеща производствена система, за съжаление ще трябва да рестартирате клъстера и ще има престой.

Всички възли на Galera в клъстера трябва да използват един и същ ключ, сертификат и CA (по избор). Можете също да използвате същия ключ и сертификат, създадени за MySQL клиент-сървър криптиране, или да генерирате нов набор само за тази цел. За да активирате криптирането в Galera, трябва да добавите опцията и стойността под wsrep_provider_options в конфигурационния файл на MySQL на всеки възел на Galera. Например, помислете за следния съществуващ ред за нашия възел Galera:

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

Добавете свързаните променливи вътре в кавичката, разделени с точка и запетая:

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

За повече информация относно параметрите, свързани със SSL на Galera, вижте тук. Извършете тази модификация на всички възли. След това спрете клъстера (един възел в даден момент) и стартирайте от последния възел, който е изключен. Можете да проверите дали SSL е зареден правилно, като погледнете в регистъра за грешки на 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:

С ClusterControl криптирането на Galera Replication може лесно да се активира с помощта на функцията „Създаване на SSL Galera Encryption“.

SST криптиране

Когато SST се случи без криптиране, комуникацията на данни се разкрива, докато SST процесът е в ход. SST е пълен процес на синхронизиране на данни от донор към възел за присъединяване. Ако нападателят е успял да „види“ пълното предаване на данни, лицето ще получи пълна моментна снимка на вашата база данни.

SST с криптиране се поддържа само за методи mysqldump и xtrabackup-v2. За mysqldump на потребителя трябва да бъде предоставено „ИЗИСКВА SSL“ на всички възли и конфигурацията е подобна на стандартното MySQL клиент-сървър SSL криптиране (както е описано в предишния раздел). След като криптирането клиент-сървър е активирано, създайте нов SST потребител с наложен SSL:

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

За rsync препоръчваме да използвате galera-secure-rsync, добавен SSL-защитен rsync SST скрипт за Galera Cluster. Работи почти точно като wsrep_sst_rsync с изключение на това, че осигурява действителните комуникации със SSL, използвайки socat. Генерирайте необходимия клиент/сървър ключ и файлове със сертификати, копирайте ги във всички възли и посочете „secure_rsync“ като SST метод в конфигурационния файл на MySQL, за да го активирате:

wsrep_sst_method=secure_rsync

За xtrabackup следните опции за конфигурация трябва да бъдат активирани в конфигурационния файл на MySQL под [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

Рестартирането на базата данни не е необходимо. Ако този възел е избран от Galera като донор, тези опции за конфигурация ще бъдат избрани автоматично, когато Galera инициира SST.

SELinux

Linux с подобрена сигурност (SELinux) е механизъм за контрол на достъпа, внедрен в ядрото. Без SELinux се използват само традиционни методи за контрол на достъпа като разрешения за файлове или ACL за контрол на достъпа до файлове на потребителите.

По подразбиране, с активиран режим на стриктно прилагане, всичко е отказано и администраторът трябва да направи серия от политики за изключения към елементите на системата, изисквани, за да функционират. Изцяло деактивирането на SELinux се превърна в обичайна лоша практика за много инсталации, базирани на RedHat в днешно време.

В зависимост от натоварванията, моделите на използване и процесите, най-добрият начин е да създадете свой собствен модул за политика SELinux, съобразен с вашата среда. Това, което наистина трябва да направите, е да настроите SELinux на разрешителен режим (само регистриране без прилагане) и да задействате събития, които могат да се случат на възел на Galera, за да може SELinux да регистрира. Колкото по-обширен, толкова по-добре. Примерни събития като:

• Начален възел като донор или съединител
• Рестартирайте възела, за да задействате IST
• Използвайте различни SST методи
• Архивирайте и възстановете MySQL бази данни с помощта на mysqldump или xtrabackup
• Активиране и деактивиране на двоични регистрационни файлове

Един пример е, ако възелът Galera се наблюдава от ClusterControl и функцията за наблюдение на заявки е активирана, ClusterControl ще активира/деактивира променливата на бавния регистър на заявките, за да улови бавно изпълняваните заявки. По този начин ще видите следния отказ в audit.log:

$ 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

Идеята е всички възможни откази да бъдат записани в регистъра на одита, който по-късно може да се използва за генериране на модула за политика с помощта на audit2allow преди да го заредите в SELinux. Codership е покрил това подробно в страницата с документация, SELinux Configuration.

SST акаунт и привилегии

SST е първоначален процес на синхронизиране, извършван от Galera. Той предоставя актуален възел за присъединяване с останалите членове в клъстера. Процесът основно експортира данните от донорния възел и ги възстановява на съединяващия възел, преди на съединителя да бъде позволено да навакса останалите транзакции от опашката (т.е. тези, които са се случили по време на процеса на синхронизиране). Поддържат се три SST метода:

• mysqldump
• rsync
• xtrabackup (или xtrabackup-v2)

За използване на mysqldump SST са необходими следните привилегии:

• ИЗБЕРЕТЕ, ПОКАЖЕТЕ ИЗГЛЕД, ЗАПУСКАНЕ, ЗАКЛЮЧВАНЕ НА ТАБЛИЦИТЕ, ПРЕЗАРЕЖДАНЕ, ФАЙЛ

Няма да продължаваме по-далеч с mysqldump, защото вероятно не се използва често в производството като SST метод. Освен това това е блокираща процедура на донора. Rsync обикновено е предпочитан втори избор след xtrabackup поради по-бързото време за синхронизиране и по-малко податлив на грешки в сравнение с mysqldump. SST удостоверяването се игнорира с rsync, поради което можете да пропуснете конфигурирането на привилегии на SST акаунт, ако rsync е избраният SST метод.

Придвижвайки се заедно с xtrabackup, се препоръчват следните привилегии за стандартни процедури за архивиране и възстановяване въз основа на страницата с документация на Xtrabackup:

• СЪЗДАВАНЕ, СЪЗДАВАНЕ НА ПРОСТРАНСТВО ЗА ТАБЛИЦА, СЪБИТИЕ, ВМЪКВАНЕ, ЗАКЛЮЧВАНЕ НА ТАБЛИЦА, ОБРАЩАНЕ, ПРЕЗАРЕЖДАНЕ, КЛИЕНТ НА ​​РЕПЛИКАЦИЯ, ИЗБИРАНЕ, ПОКАЗВАНЕ НА ИЗГЛЕД, СУПЕР

За използването на SST от xtrabackup обаче са важни само следните привилегии:

• КЛИЕНТ ЗА ПРОЦЕС, ПРЕЗАРЕЖДАНЕ, РЕПЛИКАЦИЯ

По този начин изразът GRANT за SST може да бъде сведен до минимум като:

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

След това конфигурирайте wsrep_sst_auth съответно в конфигурационния файл на MySQL:

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

Предоставете на потребителя на SST само локален хост и използвайте силна парола. Избягвайте да използвате root потребител като SST акаунт, защото това ще разкрие root паролата в конфигурационния файл под тази променлива. Освен това промяната или нулирането на MySQL root паролата ще наруши SST в бъдеще.

Укрепване на сигурността на MySQL

Galera Cluster е мулти-главен плъгин за репликация за машината за съхранение на InnoDB, която работи на MySQL и MariaDB разклонения. Следователно стандартните препоръки за укрепване на сигурността на MySQL/MariaDB/InnoDB важат и за Galera Cluster.

Тази тема е разгледана в множество публикации в блога. Ние също покрихме тази тема в следните публикации в блога:

• Десет съвета как да постигнете сигурност на MySQL и MariaDB
• Съвети и трикове за ClusterControl:Защита на вашата инсталация на MySQL
• Как да защитите своите бази данни с отворен код с ClusterControl

Горните публикации в блога обобщават необходимостта от криптиране на данни в състояние на покой и данни в пренос, наличието на плъгини за одит, общи указания за сигурност, най-добри практики за мрежова сигурност и така нататък.

Използвайте Load Balancer

Има редица балансиращи натоварвания на база данни (обратен прокси), които могат да се използват заедно с Galera - HAProxy, ProxySQL и MariaDB MaxScale, за да назовем някои от тях. Можете да настроите балансьор на натоварване, за да контролирате достъпа до вашите възли на Galera. Това е чудесен начин за разпределяне на натоварването на базата данни между екземплярите на базата данни, както и за ограничаване на достъпа, например, ако искате да вземете възел офлайн за поддръжка, или ако искате да ограничите броя на връзките, отворени на възлите на Galera. Балансьорът на натоварване трябва да може да поставя връзки в опашка и следователно да осигурява известна защита от претоварване на сървърите на вашите бази данни.

ProxySQL, мощен обратен прокси на базата данни, който разбира MySQL и MariaDB, може да бъде разширен с много полезни функции за сигурност като защитна стена на заявки, за да блокира нарушителните заявки от сървъра на базата данни. Двигателят за правила за заявка може също да се използва за пренаписване на лоши заявки в нещо по-добро/по-безопасно или за пренасочване към друг сървър, който може да поеме натоварването, без да засяга нито един от възлите на Galera. MariaDB MaxScale също така може да блокира заявки въз основа на регулярни изрази със своя филтър на защитната стена на базата данни.

Друго предимство на балансирането на натоварването за вашия Galera Cluster е възможността да хоствате услуга за данни, без да излагате нивото на базата данни на публичната мрежа. Прокси сървърът може да се използва като bastion хост за получаване на достъп до възлите на базата данни в частна мрежа. Като сте изолирали клъстера на базата данни от външния свят, вие премахнахте един от важните атакуващи вектори.

Това е. Винаги бъдете сигурни и защитени.