21.6.18.2 NDB Cluster and MySQL Privileges — MySQL 5.7

21.6.18.2 NDB Кластер и привилегии MySQL

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

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

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

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

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

Если эти условия выполняются, любой человек, где угодно, может запустить сервер MySQL с --ndbcluster --ndb-connectstring=management_host и получить доступ к этому NDB Кластеру. Используя учетную запись 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 NDB Кластера, если вы не используете распределенные привилегии.

В общем, у вас не будет безопасного NDB Кластера, если к нему есть прямой доступ извне вашей локальной сети.

Важно

Никогда не оставляйте пароль учетной записи MySQL root пустым. Это так же верно при запуске MySQL как узла SQL NDB Кластера, как и при запуске его как автономного (не кластерного) сервера MySQL и должно выполняться в рамках процесса установки MySQL перед настройкой сервера MySQL как узла SQL в NDB Кластере.

Если вы хотите использовать возможности распределенных привилегий NDB Кластера, вы не должны просто вручную преобразовать системные таблицы в базе данных mysql в использование движка хранения NDB. Используйте вместо этого хранимую процедуру, предназначенную для этой цели; см. Раздел 21.6.13, «Распределенные привилегии с использованием общих таблиц предоставления».

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

Резюме. Важнейшие моменты, которые следует помнить о системе привилегий MySQL в отношении NDB Кластера, перечислены здесь:

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