В предишната ни публикация в блога ви показахме как можете да защитите своите бази данни с отворен код с ClusterControl. Но какво да кажем за самия сървър ClusterControl? Как да го подсигурим? Това ще бъде темата за днешния блог. Предполагаме, че хостът е само за използване на ClusterControl, без да се изпълняват други приложения на него.
Група за защитна стена и сигурност
Първо и най-важно, трябва да затворим всички ненужни портове и да отворим само необходимите портове, използвани от ClusterControl. Вътрешно, между ClusterControl и сървърите на базата данни, има значение само портът netcat, където портът по подразбиране е 9999. Този порт трябва да бъде отворен само ако искате да съхраните архива на сървъра на ClusterControl. В противен случай можете да затворите това.
От външната мрежа се препоръчва да отваряте достъп само до HTTP (80) или HTTPS (443) за потребителския интерфейс на ClusterControl. Ако използвате ClusterControl CLI, наречен 's9s', крайната точка на CMON-TLS трябва да бъде отворена на порт 9501. Възможно е също така да инсталирате свързани с база данни приложения върху сървъра на ClusterControl, като HAProxy, Keepalived, ProxySQL и други. В този случай трябва да отворите и необходимите портове за тях. Моля, вижте страницата с документация за списък с портове за всяка услуга.
За да настроите правилата на защитната стена чрез iptables, на възел ClusterControl, направете:
$ 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Горните са най-простите команди. Можете да бъдете по-строги и да разширите командите, за да следвате вашата политика за сигурност – например, като добавите мрежов интерфейс, адрес на местоназначение, адрес на източник, състояние на връзката и какво ли още не.
Подобно на стартирането на настройката в облака, по-долу е даден пример за правила за входяща група за сигурност за сървъра ClusterControl на AWS:
Различните доставчици на облак предоставят различни реализации на групи за сигурност, но основните правила са сходни.
Шифроване
ClusterControl поддържа криптиране на комуникации на различни нива, за да гарантира, че задачите за автоматизация, наблюдение и управление се изпълняват възможно най-сигурно.
Изпълнява се на HTTPS
Скриптът на инсталатора (install-cc.sh) ще конфигурира по подразбиране самоподписан SSL сертификат за използване на HTTPS. Ако изберете този метод за достъп като основна крайна точка, можете да блокирате обикновената HTTP услуга, работеща на порт 80 от външната мрежа. Въпреки това, ClusterControl все още изисква достъп до CMONAPI (наследен Rest-API интерфейс), който работи по подразбиране на порт 80 на локалния хост. Ако искате да блокирате HTTP порта навсякъде, уверете се, че сте променили URL адреса на ClusterControl API под Регистрации на клъстер страница, за да използвате вместо това HTTPS:
Самоподписаният сертификат, конфигуриран от ClusterControl, има 10 години (3650 дни) на валидност. Можете да проверите валидността на сертификата, като използвате следната команда (на сървър на 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
...Обърнете внимание, че абсолютният път до файла на сертификата може да е различен в зависимост от операционната система.
Клиент-сървър криптиране на MySQL
ClusterControl съхранява данни за наблюдение и управление в MySQL бази данни на възела ClusterControl. Тъй като самият MySQL поддържа SSL криптиране клиент-сървър, ClusterControl е в състояние да използва тази функция за установяване на криптирана комуникация с MySQL сървъра, когато пише и извлича неговите данни.
За тази цел се поддържат следните опции за конфигурация:
- cmondb_ssl_key - път до SSL ключа, за SSL криптиране между CMON и CMON DB.
- cmondb_ssl_cert - път към SSL сертификат, за SSL криптиране между CMON и CMON DB
- cmondb_ssl_ca - път до SSL CA, за SSL криптиране между CMON и CMON DB
Преди известно време разгледахме стъпките за конфигуриране в тази публикация в блога.
Все пак има уловка. Към момента на писане, потребителският интерфейс на ClusterControl има ограничение за достъп до CMON DB чрез SSL с помощта на потребителя cmon. Като заобиколно решение ще създадем друг потребител на база данни за ClusterControl UI и ClusterControl CMONAPI, наречен cmonui. Този потребител няма да има активиран SSL в таблицата с привилегии.
mysql> GRANT ALL PRIVILEGES ON *.* TO 'cmonui'@'127.0.0.1' IDENTIFIED BY '<cmon password>';
mysql> FLUSH PRIVILEGES;Актуализирайте конфигурационните файлове на ClusterControl UI и CMONAPI, разположени съответно на clustercontrol/bootstrap.php и cmonapi/config/database.php с новосъздадения потребител на база данни, 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>');Тези файлове няма да бъдат заменени, когато извършите надстройка чрез мениджъра на пакети.
CLI криптиране
ClusterControl също идва с интерфейс на командния ред, наречен 's9s'. Този клиент анализира опциите на командния ред и изпраща специфично задание към услугата на контролера, която слуша на порт 9500 (CMON) или 9501 (CMON с TLS). Последният е препоръчителен. Скриптът на инсталатора по подразбиране ще конфигурира s9s CLI да използва 9501 като порт за крайна точка на сървъра ClusterControl.
Контрол на достъп, базиран на роли
ClusterControl използва контрол на достъпа, базиран на роли (RBAC), за да ограничи достъпа до клъстери и съответните им функции за разгръщане, управление и наблюдение. Това гарантира, че са разрешени само оторизирани потребителски заявки. Достъпът до функционалността е фино-зърнест, което позволява достъпът да бъде дефиниран от организация или потребител. ClusterControl използва рамка за разрешения, за да дефинира как потребителят може да взаимодейства с функцията за управление и наблюдение, след като е бил упълномощен за това.
Потребителският интерфейс RBAC може да бъде достъпен чрез ClusterControl -> User Management -> Access Control :
Всички функции се разбират сами, но ако искате допълнително описание, моля, вижте страницата с документация.
Ако имате множество потребители, участващи в операцията на клъстера на базата данни, силно се препоръчва да зададете съответно контроли за достъп за тях. Можете също да създадете множество екипи (организации) и да им присвоите нула или повече клъстери.
Изпълнява се на персонализирани портове
ClusterControl може да бъде конфигуриран да използва персонализирани портове за всички зависими услуги. ClusterControl използва SSH като основен комуникационен канал за управление и наблюдение на възли от разстояние, Apache за обслужване на потребителския интерфейс на ClusterControl, а също и MySQL за съхраняване на данни за наблюдение и управление. Можете да стартирате тези услуги на персонализирани портове, за да намалите атакуващия вектор. Следните портове са обичайните цели:
- SSH – по подразбиране е 22
- HTTP – по подразбиране е 80
- HTTPS – по подразбиране е 443
- MySQL – по подразбиране е 3306
Има няколко неща, които трябва да промените, за да стартирате горните услуги на персонализирани портове, за да работи ClusterControl правилно. Разгледахме това подробно в страницата с документация, Работи на персонализиран порт.
Разрешение и собственост
Конфигурационните файлове на ClusterControl съдържат чувствителна информация и трябва да се пазят дискретни и добре защитени. Файловете трябва да са разрешени само за потребител/група root, без разрешение за четене на други. В случай, че разрешението и собствеността са зададени погрешно, следната команда помага да ги възстановите обратно в правилното състояние:
$ chown root:root /etc/cmon.cnf /etc/cmon.d/*.cnf
$ chmod 700 /etc/cmon.cnf /etc/cmon.d/*.cnf
За услугата MySQL уверете се, че съдържанието на директорията с данни MySQL е разрешено за групата „mysql“ и потребителят може да бъде „mysql“ или „root“:
$ chown -Rf mysql:mysql /var/lib/mysqlЗа потребителския интерфейс на ClusterControl собствеността трябва да е разрешена за потребителя на Apache, или „apache“ за RHEL/CentOS, или „www-data“ за базирана на Debian ОС.
SSH ключът за свързване към хостовете на базата данни е друг много важен аспект, тъй като притежава самоличността и трябва да се съхранява с подходящо разрешение и собственост. Освен това SSH няма да позволи използването на незащитен ключов файл при иницииране на отдалеченото повикване. Проверете, че SSH ключовият файл, използван от клъстера, вътре в генерираните конфигурационни файлове в директорията /etc/cmon.d/, е настроен на допустимото за потребителя само опция. Например, помислете за osuser е "ubuntu", а ключовият файл е /home/ubuntu/.ssh/id_rsa:
$ chown ubuntu:ubuntu /home/ubuntu/.ssh/id_rsa
$ chmod 700 /home/ubuntu/.ssh/id_rsaИзползвайте силна парола
Ако използвате скрипта на инсталатора, за да инсталирате ClusterControl, препоръчваме ви да използвате силна парола, когато бъдете подканени от инсталатора. Има най-много два акаунта, които скриптът на инсталатора ще трябва да конфигурира (в зависимост от вашата настройка):
- MySQL cmon парола – Стойността по подразбиране е 'cmon'.
- Root парола за MySQL – Стойността по подразбиране е 'password'.
Отговорност на потребителя е да използва силни пароли в тези два акаунта. Скриптът за инсталиране поддържа куп специални символи за въвеждане на парола, както е споменато в съветника за инсталиране:
=> Set a password for ClusterControl's MySQL user (cmon) [cmon]
=> Supported special password characters: [email protected]#$%^&*()_+{}<>?Проверете съдържанието на /etc/cmon.cnf и /etc/cmon.d/cmon_*.cnf и се уверете, че използвате силна парола, когато е възможно.
Промяна на паролата 'cmon' на MySQL
Ако конфигурираната парола не отговаря на правилата ви за парола, за да промените паролата на MySQL cmon, има няколко стъпки, които трябва да изпълните:
-
Променете паролата в 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; -
Актуализирайте всички поява на опциите „mysql_password“ за услугата на контролера в /etc/cmon.cnf и /etc/cmon.d/*.cnf:
mysql_password=newPass -
Актуализирайте всички поява на константи 'DB_PASS' за потребителския интерфейс на ClusterControl в /var/www/html/clustercontrol/bootstrap.php и /var/www/html/cmonapi/config/database.php:
# <wwwroot>/clustercontrol/bootstrap.php define('DB_PASS', 'newPass');# <wwwroot>/cmonapi/config/database.php define('DB_PASS', 'newPass'); -
Променете паролата на всеки MySQL сървър, наблюдаван от ClusterControl:
$ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass'; $ FLUSH PRIVILEGES; -
Рестартирайте услугата CMON, за да приложите промените:
$ service cmon restart # systemctl restart cmon
Проверете дали процесът cmon е стартиран правилно, като погледнете /var/log/cmon.log. Уверете се, че имате нещо като по-долу:
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.Изпълнение офлайн
Свързани ресурси Обявяване на ClusterControl 1.5.1 – Включващо шифроване на архивиране за MySQL, MongoDB и PostgreSQL PCI съответствие за MySQL и MariaDB с ClusterControl Как да защитите MySQL/MariaDB сървъриClusterControl е в състояние да управлява вашата инфраструктура на база данни в среда без достъп до Интернет. Някои функции няма да работят в тази среда (архивиране в облак, внедряване чрез публични репозитории, надстройки), основните функции са налице и биха работили добре. Също така имате избор първоначално да внедрите всичко с интернет и след това да изключите интернет, след като настройката е тествана и готова да обслужва производствените данни.
Като сте изолирали ClusterControl и клъстера на базата данни от външния свят, вие сте премахнали един от важните атакуващи вектори.
Резюме
ClusterControl може да ви помогне да защитите клъстера на базата данни, но не се осигурява сам. Оперативните екипи трябва да се уверят, че сървърът ClusterControl също е закален от гледна точка на сигурността.
