25.6.21.2 NDB Cluster and MySQL Privileges — MySQL 8.4

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

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

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

Важно помнить, что по умолчанию таблицы предоставления привилегий MySQL используют движок хранения InnoDB. В связи с этим эти таблицы обычно не дублируются и не разделяются между серверами MySQL, действующими в качестве SQL-узлов в кластере NDB. Другими словами, изменения в пользователях и их привилегиях по умолчанию не распространяются автоматически между SQL-узлами кластера NDB. При необходимости вы можете включить синхронизацию пользователей и привилегий MySQL по всем SQL-узлам кластера NDB; подробности см. в разделе 25.6.13 «Синхронизация привилегий и NDB_STORED_USER».

Наоборот, поскольку в 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 в заданной базе данных
Выполнять любые законные SQL-запросы на любых обнаруженных таблицах, таких как:
- SELECT * FROM some_table или TABLE some_table для чтения всех данных из любой таблицы
- DELETE FROM some_table или TRUNCATE 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.

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

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

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