17.5.11.1. MySQL Cluster Security и Networking Issues

В этом разделе мы обсуждаем основные проблемы сетевой безопасности, поскольку они касаются MySQL Cluster. Чрезвычайно важно помнить, что MySQL Cluster "из поля" не безопасен; или Ваш администратор сети следует сделать надлежащие шаги, чтобы гарантировать, что Ваш кластер не может поставиться под угрозу по сети.

Протоколы связи кластера по сути небезопасны, и никакое шифрование, или подобные меры безопасности используются в связи между узлами в кластере. Поскольку у сетевой скорости и задержки есть прямое воздействие на эффективности кластера, также не желательно использовать SSL, или другое шифрование к сетевым соединениям между узлами, схемы как таковые эффективно замедлят связь.

Это - также истина, что никакая аутентификация не используется для того, чтобы управлять доступом узла API к MySQL Cluster. Как с шифрованием, издержки внушительных требований аутентификации оказали бы неблагоприятное влияние на производительность Кластера.

Кроме того, нет никакой проверки исходного IP-адреса ни для одного из следующих, получая доступ к кластеру:

SQL или узлы API, используя "свободные слоты", создаваемые пустым [mysqld] или [api] разделы в config.ini файл

Это означает это, если есть кто-либо пустой [mysqld] или [api] разделы в config.ini файл, тогда любые узлы API (включая узлы SQL), которые знают имя хоста сервера управления (или IP-адрес) и порт, может соединиться с кластером и получить доступ к своим данным без ограничения. (См. Раздел 17.5.11.2, "MySQL Cluster и MySQL Privileges", для получения дополнительной информации об этом и связал проблемы.)

Отметить

Можно осуществить некоторый контроль над SQL и доступом узла API к кластеру, определяя a HostName параметр для всех [mysqld] и [api] разделы в config.ini файл. Однако, это также означает, что, должен Вы хотеть соединить узел API с кластером от ранее неиспользованного узла, Вы должны добавить [api] раздел, содержащий его имя хоста к config.ini файл.

Больше информации доступно в другом месте в этой главе о HostName параметр. Также см. Раздел 17.3.1, "Быстрая Тестовая Установка MySQL Cluster", для использования конфигурации в качестве примера HostName с узлами API.
Любой ndb_mgm клиент

Это означает, что любой клиент управления кластером, которому дают имя хоста сервера управления (или IP-адрес) и порт (если не стандартный порт) может соединиться с кластером и выполнить какую-либо клиентскую команду управления. Это включает команды такой как ALL STOP и SHUTDOWN.

По этим причинам необходимо защитить кластер на сетевом уровне. Самая безопасная сетевая конфигурация для Кластера является той, которая изолирует соединения между узлами Кластера от любых других сетевых коммуникаций. Это может быть выполнено любым из следующих методов:

Хранение узлов Кластера на сети, которая является физически отдельной от любых общедоступных сетей. Эта опция является самой надежной; однако, является самым дорогим реализовать.

Мы показываем пример установки MySQL Cluster, используя такую физически отдельную сеть здесь:

У этой установки есть две сети, одна частная (твердое поле) для серверов управления Кластером и узлов данных, и одной общественности (отмеченное точкой поле), где узлы SQL находятся. (Мы показываем управление, и узлы данных соединили использование гигабитного переключателя, так как это обеспечивает лучшую производительность.) Обе сети защищаются от внешней стороны аппаратным брандмауэром, иногда также известным как основанный на сети брандмауэр.

Эта сетевая установка является самой безопасной, потому что никакие пакеты не могут достигнуть управления кластера или узлов данных снаружи сети — и ни одна из внутренней связи кластера не может достигнуть внешней стороны — не проходя через узлы SQL, пока узлы SQL не разрешают никаким пакетам быть переданными. Это означает, конечно, что все узлы SQL должны быть защищены от взламывания попыток.

Важный

Относительно потенциальных уязвимостей системы обеспечения безопасности узел SQL не отличается от любого другого сервера MySQL. См. Раздел 6.1.3, "MySQL Making, Безопасный Против Атакующих", для описания методов можно использовать, чтобы защитить серверы MySQL.

Используя один или более программных брандмауэров (также известный как основанные на узле брандмауэры), чтобы управлять, через который пакеты проходят к кластеру от частей сети, которые не требуют доступа к этому. В этом типе установки программный брандмауэр должен быть установлен на каждом узле в кластере, который мог бы иначе быть доступным снаружи локальной сети.

Основанная на узле опция является наименее дорогой, чтобы реализовать, но полагается просто на программное обеспечение, чтобы обеспечить защиту и так является самой трудной сохранить безопасным.

Этот тип сетевой установки для MySQL Cluster иллюстрируется здесь:

MySQL Cluster, развернутый на сети, используя программные брандмауэры, чтобы создать общедоступные и частные зоны

Используя этот тип сетевых средств установки, что есть две зоны узлов MySQL Cluster. Каждый узел кластера должен быть в состоянии связаться со всеми другими машинами в кластере, но только тем, которые размещают узлы SQL (отмеченное точкой поле), можно разрешить иметь любой контакт с внешней стороной, в то время как те в зоне, содержащей узлы данных и узлы управления (твердое поле), должны быть изолированы от любых машин, которые не являются частью кластера. Приложениям используя кластер и пользователя тех приложений нельзя разрешить иметь прямой доступ к узлам узла данных и управлению.

Чтобы выполнить это, следует установить программные брандмауэры, которые ограничивают трафик типом или типами, показанными в следующей таблице согласно типу узла, который работает на каждом главном компьютере кластера:

Тип Узла, который будет Получен доступ	Трафик, чтобы Разрешить
SQL или узел API	Это происходит из IP-адреса управления или узла данных (использующий любой TCP или порт UDP). Это происходит изнутри сети, в которой кластер находится и находится на порту, который использует Ваше приложение.
Узел данных или узел управления	Это происходит из IP-адреса управления или узла данных (использующий любой TCP или порт UDP). Это происходит из IP-адреса узла API или SQL.

Любой трафик кроме того показанного в таблице для данного типа узла должен отрицаться.

Специфические особенности конфигурирования брандмауэра изменяются от приложения брандмауэра до приложения брандмауэра, и выходят за рамки этого Руководства. iptables является очень общим и надежным приложением брандмауэра, которое часто используется с APF в качестве фронтэнда, чтобы сделать конфигурацию легче. Вы можете (и если) консультируются с документацией для программного брандмауэра, который Вы используете, должны Вы хотеть реализовывать установку сети MySQL Cluster этого типа, или "смешанного" типа как обсуждено под следующим элементом.

Также возможно использовать комбинацию первых двух методов, используя оба аппаратных и программных обеспечения, чтобы защитить кластер — то есть, используя и основанные на сети и основанные на узле брандмауэры. Это между первыми двумя схемами и с точки зрения уровня безопасности и с точки зрения стоимости. Этот тип сетевой установки сохраняет кластер позади аппаратного брандмауэра, но разрешает входящим пакетам перемещаться вне маршрутизатора, соединяющего все узлы кластера, чтобы достигнуть узлов SQL.

Одно возможное сетевое развертывание MySQL Cluster, используя аппаратные и программные брандмауэры в комбинации показывают здесь:

В этом случае можно установить правила в аппаратном брандмауэре, чтобы отрицать любой внешний трафик кроме к узлам SQL и узлам API, и затем разрешить трафик им только на портах, требуемых Вашим приложением.

Безотносительно сетевой конфигурации, которую Вы используете, помнят, что Ваша цель с точки зрения хранения безопасного кластера остается тем же самым — чтобы препятствовать тому, чтобы любой несущественный трафик достиг кластера, гарантируя самую эффективную передачу между узлами в кластере.

Поскольку MySQL Cluster требует, чтобы большие количества портов, чтобы быть открытой для связи между узлами, рекомендуемая опция использовала отдельную сеть. Это представляет самый простой способ препятствовать тому, чтобы нежелательный трафик достиг кластера.

Отметить

Если Вы хотите администрировать MySQL Cluster удаленно (то есть, снаружи локальной сети), рекомендуемый способ сделать, это должно использовать ssh или другую безопасную оболочку входа в систему, чтобы получить доступ к узлу узла SQL. От этого узла можно тогда выполнить клиент управления, чтобы получить доступ к серверу управления безопасно изнутри собственной локальной сети Кластера.

Даже при том, что возможно сделать так в теории, не рекомендуется использовать ndb_mgm, чтобы управлять Кластером непосредственно снаружи локальной сети, на которой работает Кластер. Ни начиная с аутентификация, ни начиная с шифрование имеют место между клиентом управления и сервером управления, это представляет чрезвычайно небезопасное средство управления кластером, и почти наверняка должно поставиться под угрозу рано или поздно.