25.6.21.2 NDB Cluster and MySQL Privileges — MySQL 9.2

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

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

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

Важно помнить, что по умолчанию таблицы разрешений MySQL используют хранилище InnoDB. Из-за этого эти таблицы обычно не дублируются и не совместно используются между серверами MySQL, выполняющими роль SQL-узлов в кластере NDB. Другими словами, изменения в пользователях и их привилегиях по умолчанию не распространяются автоматически между SQL-узлами. Если вы хотите, вы можете включить синхронизацию пользователей и привилегий 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-запросы MySQL на любых обнаруженных таблицах, такие как:
- 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 Cluster, перечислены здесь:

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