17.5.11.2. MySQL Cluster и MySQL Privileges

В этом разделе мы обсуждаем, как система полномочия MySQL работает относительно MySQL Cluster и импликаций этого для того, чтобы сохранить MySQL Cluster безопасным.

Стандартные полномочия MySQL применяются к таблицам MySQL Cluster. Это включает все типы полномочия MySQL (SELECT полномочие, UPDATE полномочие, DELETE полномочие, и так далее) предоставленный на базе данных, таблице, и уровне столбца. Как с любым другим MySQL Server, пользователем и информацией о полномочии сохранен в mysql системная база данных. SQL-операторы, используемые, чтобы предоставить и отменить полномочия на NDB таблицы, базы данных, содержащие такие таблицы, и столбцы в пределах таких таблиц, идентичны во всех отношениях с GRANT и REVOKE операторы, используемые в соединении с объектами базы данных, включающими любой (другой) механизм хранения MySQL. Той же самой вещью является истина относительно CREATE USER и DROP USER операторы.

Важно иметь в виду, что по умолчанию таблицы предоставления MySQL используют MyISAM механизм хранения. Из-за этого те таблицы обычно не дублируются или совместно используются среди серверов MySQL, действующих как узлы SQL в MySQL Cluster. Другими словами изменения в пользователях и их полномочиях автоматически не распространяют между узлами SQL по умолчанию. Если Вы желаете, можно включить автоматическому распределению пользователей MySQL и полномочий через узлы SQL MySQL Cluster; см. Раздел 17.5.14, "Распределенный MySQL Privileges для MySQL Cluster", для деталей.

Наоборот, потому что нет никакого пути в MySQL, чтобы отрицать полномочия (полномочия могут или быть отменены или не предоставлены во-первых, но не отрицаться как таковые), нет никакой специальной защиты для NDB таблицы на одном узле SQL от пользователей, у которых есть полномочия на другом узле SQL; (Это - истина, даже если Вы не используете автоматическое распределение пользовательских полномочий. Категорическим примером этого является MySQL root учетная запись, которая может выполнить любое действие на любом объекте базы данных. В комбинации с пустым [mysqld] или [api] разделы config.ini файл, эта учетная запись может быть особенно опасной. Чтобы понять почему, рассмотрите следующий сценарий:

config.ini файл содержит по крайней мере один пустой [mysqld] или [api] раздел. Это означает, что сервер управления MySQL Cluster не выполняет проверки узла, от которого MySQL Server (или другой узел API) получает доступ к MySQL Cluster.
Нет никакого брандмауэра, или брандмауэр не в состоянии защитить от доступа к MySQL Cluster от узлов, внешних к сети.
Имя хоста или IP-адрес сервера управления Кластера MySQL известны или могут быть определены снаружи сети.

Если эти условия являются истиной, то любой, где угодно может запустить MySQL Server с --ndbcluster --ndb-connectstring=management_host и получить доступ к этому MySQL Cluster. Используя MySQL root учетная запись, этот человек может тогда выполнить следующие действия:

Выполните операторы метаданных такой как SHOW DATABASES оператор (чтобы получить список всех NDB базы данных на сервере) или SHOW TABLES FROM some_ndb_database оператор, чтобы получить список всех NDB таблицы в данной базе данных
Выполните любые юридические операторы MySQL на любой из обнаруженных таблиц, таких как:
- SELECT * FROM some_table считать все данные из любой таблицы
- DELETE FROM some_table удалить все данные из таблицы
- DESCRIBE some_table или SHOW CREATE TABLE some_table определить табличную схему
- UPDATE some_table SET column1 = some_value заполнить столбец таблицы данными "мусора"; это могло фактически нанести намного больший ущерб чем простое удаление всех данных
  
  Больше коварных изменений могло бы включать операторы как они:
```
UPDATE some_table SET an_int_column = an_int_column + 1
```
  или
```
UPDATE some_table SET a_varchar_column = REVERSE(a_varchar_column)
```
  Такие злонамеренные операторы ограничиваются только воображением атакующего.
Единственные таблицы, которые были бы безопасны от этого вида погрома, будут теми таблицами, которые были составлены, используя механизмы хранения кроме NDB, и так не видимый к узлу SQL "жулика".

Пользователь, который может войти в систему как root может также получить доступ INFORMATION_SCHEMA база данных и ее таблицы, и так получают информацию о базах данных, таблицах, сохраненных подпрограммах, запланированных событиях, и любых других объектах базы данных, для которых метаданные сохранены в INFORMATION_SCHEMA.

Это - также очень хорошая идея использовать различные пароли для root учетные записи на различных узлах SQL MySQL Cluster, если Вы не используете распределенные полномочия.

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

Важный

Никогда не оставляйте корневой пароль учетной записи MySQL пустым. Это так же, как истина, когда рабочий MySQL как узел SQL MySQL Cluster, как это, выполняя это как автономное (некластер) MySQL Server, и должен быть сделан как часть процесса установки MySQL прежде, чем сконфигурировать MySQL Server как узел SQL в MySQL Cluster.

Если Вы хотите использовать распределенные возможности полномочия Кластера MySQL, недопустимо просто преобразовать системные таблицы в mysql база данных, чтобы использовать NDB механизм хранения вручную. Используйте хранимую процедуру, обеспеченную с этой целью вместо этого; см. Раздел 17.5.14, "Распределенный MySQL Privileges для MySQL Cluster".

Иначе, если Вы должны синхронизироваться mysql системные таблицы между узлами SQL, можно использовать стандартную репликацию MySQL, чтобы сделать так, или использовать сценарий, чтобы скопировать записи таблицы между серверами MySQL.

Сводка. Наиболее важные моменты, чтобы помнить относительно системы полномочия MySQL относительно MySQL Cluster перечисляются здесь:

Пользователи и полномочия, установленные на одном узле SQL, автоматически не существуют или вступают в силу на других узлах SQL в кластере. Наоборот, удаление пользователя или полномочия на одном узле SQL в кластере не удаляет пользователя или полномочие от любых других узлов SQL.
Можно распределить пользователей MySQL и полномочия среди узлов SQL, используя сценарий SQL, и хранимые процедуры, которые он содержит, которые предоставляются с этой целью в распределении MySQL Cluster.
Как только пользователю MySQL предоставляют полномочия на NDB таблица от одного узла SQL в MySQL Cluster, тот пользователь может "видеть" любые данные в той таблице независимо от узла SQL, от которого порожденные данные, даже если Вы не используете распределение полномочия.