Авторизация и разрешения MariaDB для пользователей SQL Server

Понимание учетных записей и пользователей

MariaDB авторизует доступ и проверяет разрешения на учетных записях, а не на пользователях. Даже если MariaDB поддерживает стандартные SQL-команды, такие как CREATE USER и DROP USER, важно помнить, что она фактически работает с учетными записями.

Учетная запись задаётся в формате 'user'@'host'. Кавычки необязательны и позволяют включить специальные символы, такие как точки. Часть хоста фактически может быть шаблоном, который следует той же синтаксической структуре, что и при LIKE сравнениях. Шаблоны часто удобны, поскольку они могут соответствовать нескольким именам хостов.

Вот несколько примеров.

Опускание части хоста указывает на учетную запись, которая может получить доступ с любого хоста. Таким образом, следующие операторы эквивалентны:

CREATE USER viviana;
CREATE USER viviana@'%';

Однако таким учетным записям может быть запрещено подключение с localhost, если присутствует анонимный пользователь ''@'%'. Подробности см. в разделе localhost и %.

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

Системная переменная sql_mode имеет флаг NO_AUTO_CREATE_USER. В последних версиях MariaDB он включён по умолчанию. Если он не включён, оператор GRANT, указывающий привилегии для несуществующей учетной записи, автоматически создаст эту учетную запись.

Для получения дополнительной информации: SQL-команды управления учетными записями.

Установка или изменение паролей

Учетные записи с одинаковым именем пользователя могут иметь разные пароли.

По умолчанию у учетной записи нет пароля. Пароль можно установить или изменить следующим образом:

• Указав его в CREATE USER.
• Пользователю с помощью SET PASSWORD.
• Суперпользователю с помощью SET PASSWORD или ALTER USER.

Во всех этих операторах (CREATE USER, ALTER USER, SET PASSWORD) можно указать пароль в виде текста или в виде хэша:

-- specifying plain passwords:
CREATE USER tom@'%.example.com' IDENTIFIED BY 'plain secret';
ALTER USER tom@'%.example.com' IDENTIFIED BY 'plain secret';
SET PASSWORD = 'plain secret';
-- specifying hashes:
CREATE USER tom@'%.example.com' IDENTIFIED BY PASSWORD 'secret hash';
ALTER USER tom@'%.example.com' IDENTIFIED BY PASSWORD 'secret hash';
SET PASSWORD = PASSWORD('secret hash');

Функция PASSWORD() использует тот же алгоритм, что и MariaDB для генерации хэшей. Поэтому её можно использовать для получения хэша из обычного пароля. Обратите внимание, что эту функцию не следует использовать приложениям, так как её результат может зависеть от версии и конфигурации MariaDB.

SET PASSWORD по умолчанию применяется к текущей учетной записи. Суперпользователи могут изменить пароли других учетных записей таким образом:

SET PASSWORD FOR tom@'%.example.com' = PASSWORD 'secret hash';

CREATE USER 'tom'@'%.example.com' PASSWORD EXPIRE INTERVAL 365 DAY;

CREATE USER 'tom'@'%.example.com' PASSWORD EXPIRE NEVER;

CREATE USER 'tom'@'%.example.com' ACCOUNT LOCK;

Плагины аутентификации

MariaDB поддерживает плагины аутентификации. Эти плагины реализуют вход и авторизацию пользователя перед использованием MariaDB.

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

Пользователи Windows могут быть заинтересованы в плагинах именованных каналах и GSSAPI. Плагин GSSAPI также требует использования плагина на стороне клиента.

Плагин можно назначить пользователю с помощью CREATE USER, ALTER USER или GRANT, используя синтаксис IDENTIFIED VIA. Например:

CREATE USER username@hostname IDENTIFIED VIA gssapi;
GRANT SELECT ON db.* TO username@hostname IDENTIFIED VIA named_pipe;

Подключения TLS

Для конкретного пользователя могут потребоваться подключения TLS. Могут быть установлены дополнительные требования:

• Наличие действительного сертификата X509.
• Сертификат может быть обязан быть выдан конкретным органом.
• Может потребоваться конкретный субъект сертификата.
• Может потребоваться конкретный набор шифров сертификата.

Эти требования можно установить с помощью CREATE USER, ALTER USER или GRANT. Синтаксис см. в CREATE USER.

MariaDB может быть скомпонована с несколькими библиотеками криптографии в зависимости от её версии. Для получения дополнительной информации о библиотеках см. TLS и библиотеки криптографии, используемые MariaDB.

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

Разрешения

Разрешения могут быть предоставлены учетным записям. Как упоминалось ранее, указанные учетные записи могут фактически быть шаблонами, и несколько учетных записей могут соответствовать шаблону. Например, в этом примере мы создаём три учетные записи и назначаем разрешения всем им:

CREATE USER 'tom'@'example.com';
CREATE USER 'tom'@'123.123.123.123;
CREATE USER 'tom'@'tomlaptop';
GRANT USAGE ON *.* TO tom@'%';

В MariaDB существуют следующие уровни разрешений:

• Глобальные привилегии;
• Разрешения на базе данных;
• Разрешения на таблицы;
• Разрешения на столбцы;
• Разрешения на функции и разрешения на процедуры.

Обратите внимание, что база данных и схема являются синонимами в MariaDB.

Разрешения могут быть предоставлены для несуществующих объектов, которые могут существовать в будущем.

Список поддерживаемых привилегий можно найти на странице GRANT. Некоторые моменты могут быть полезны для пользователей SQL Server:

• Привилегия USAGE не оказывает никакого эффекта. Команда GRANT завершается неудачей, если мы не предоставим хотя бы одну привилегию; но иногда мы хотим запустить её для других целей, например, чтобы потребовать от пользователя использования подключений TLS. В таких случаях полезно предоставить USAGE.
• Обычно мы можем получить список всех баз данных, для которых у нас есть хотя бы одно разрешение. Разрешение SHOW DATABASES позволяет получить список всех баз данных.
• В MariaDB нет привилегии SHOWPLAN. Вместо этого для EXPLAIN требуется привилегия SELECT для каждой из используемых таблиц и привилегия SHOW VIEW для каждой из используемых представлений.
• Те же разрешения нужны для просмотра структуры таблицы (SELECT) или определения представления (SHOW VIEW).
• REFERENCES не оказывает никакого эффекта.

MariaDB не поддерживает отрицательные разрешения (команда DENY).

Некоторые различия в отношении SQL-команд:

• В MariaDB операторы GRANT и REVOKE могут назначать/отзывать разрешения только для одного пользователя за раз.
• Хотя мы можем назначать/отзывать привилегии на уровне столбцов, нам нужно выполнить оператор GRANT или REVOKE для каждого столбца. Синтаксис table (column_list) не распознаётся MariaDB.
• В MariaDB нет необходимости (или возможности) указывать тип класса.

Роли

MariaDB поддерживает роли. Разрешения могут быть назначены ролям, и роли могут быть назначены учетным записям.

Учетная запись может иметь ноль или одну роль по умолчанию. Роль по умолчанию — это роль, которая автоматически активируется для пользователя при подключении. Для назначения или удаления роли по умолчанию можно использовать следующие SQL-операторы:

SET DEFAULT ROLE some_role FOR username@hostname;
SET DEFAULT ROLE NONE FOR username@hostname;

Обычно роль не является ролью по умолчанию. Если мы назначаем роль таким образом:

GRANT some_role TO username@hostname;

...пользователь не получит эту роль автоматически. Им придётся включить её явно:

SET ROLE some_role;

В MariaDB нет предопределённых ролей, таких как public.

Для ознакомления с ролями см. Обзор ролей.