Управление доступом к базам MySQL
Система управления базами данных MySQL очень часто применяется для хранения важной информации на веб-сайтах. Если это обычный сайт или форум - в базе могут храниться сообщения пользователей, данные для динамических страниц, данные о посещениях, если это какой-либо интерактивный сервис, то кроме данных про доступ (конфиденциальных), там хранится и другая информация о пользователе и его действиях. Все это приводит к тому, что общая безопасность сайта, вернее всей веб-системы, зависит от того, насколько защищен именно сервер базы данных.
На обычных виртуальных хостингах каждый клиент получает свой логин и пароль, и ему доступна только одна база, в которой он может создавать произвольное количество таблиц. Один и тот же физический сервер БД используют разные клиенты, каждый из которых имеет доступ только до одной определенной базы данных. Ситуация, когда у пользователя одна база, за владение которой сражаются и "движок" форума (которому требуется создать сотню и больше таблиц), и скрипты списков рассылки, новостей, поисковый скрипт, а если еще установлена система управления контентом (CMS) или электронный магазин - тогда в этой базе возникает такое огромное количество различных таблиц, порой с очень странными и ничего не обозначающими названиями (хорошо, если два скрипта не используют таблицы с одинаковыми названиями, но разной структурой). В таких случаях очень желательно иметь возможность создать несколько отдельных баз данных, и выделить их для разных приложений (к примеру, одна база для форума, другая для электронного магазина).
Кроме сложностей с управлением несколькими сотнями таблиц в одной базе, вы столкнетесь с необходимостью ограничивать доступ разных пользователей к таблицам, базам и даже отдельным столбцам конкретной таблицы. Спешим вас успокоить - разработчики СУБД MySQL уже позаботились о подобной ситуации - в MySQL есть очень гибкий и мощный механизм управления и разграничения доступа пользователей к базам и таблицам.
Работает этот механизм, естественно, через служебные таблицы. В списке баз данных есть одна служебная база под названием "mysql", в которой хранятся в нескольких таблицах все служебные данные, необходимые для работы сервера. Пока нас интересует только управление правами доступа, за которые отвечают следующие таблицы:
 |
Давайте детально рассмотрим таблицу user и специфику работы с ней, работа же с остальными таблицами аналогична и не будет сложнее.
Права, определяемые в таблице user, являются глобальными, это значит, что они применяются ко всем базам данных, к которым имеет доступ конкретных пользователь. Также в этой таблице хранятся сами имена пользователей и их пароли. Причем имена пользователей хранятся в виде открытого текста, а пароли зашифрованы функцией PASSWORD(). Сервер MySQL применяет свой метод шифрования вместо системного (если такая функция предоставляется ОС, к примеру, Linux/UNIX).
Поскольку MySQL предназначена для работы через сеть, то к серверу могут подключаться клиенты с различных хостов. Поэтому в таблице привилегий есть столбец host, в котором можно задать конкретный компьютер, IP или диапазон адресов, с которых определенный пользователь (или все, любые пользователи) могут подключаться, или же им полностью запрещен доступ. К примеру, если ваш тестовый сервер находится в локальной сети, то можно выборочно разрешить доступ к нему с отдельных компьютеров, а для всех остальных полностью заблокировать доступ.
Если для одного и того же пользователя надо разрешить доступ с различных компьютеров, то в таблице привилегий надо создать две (три или больше - сколько понадобится) записей, определяя в каждой отдельный параметр доступа. К примеру, для доступа пользователя root с компьютеров localhost и 192.168.1.138 надо в таблицу user внести две одинаковые записи, которые различаются только полем host. Хотя можно, конечно, и не делать их одинаковыми - тогда тот же пользователь, но в зависимости от места, откуда он подключился, будет иметь разные привилегии.
Значение столбца host можно задавать в различных форматах. Это может быть как имя хоста - localhost, так и IP-адрес - 192.168.1.138. При необходимости, можно применять символы подстановки. Они аналогичны тем же. Что применяются в синтаксисе SQL-запросов. Символ "_" означает любой символ, а "%" - любое количество символов. К примеру, для разрешения доступа с любого компьютера, содержащего в имени hostinfo.ru надо прописать %.hostinfo.ru в столбце host. Таким же способом можно задавать и диапазоны IP-адресов. Для задания маски сети доступен также вариант написания через слеш - 192.168.1/255. Для глобального задания доступа можно в столбце host прописать только символ "%" или оставить его пустым, что равнозначно.
 |
Следующие поля - user и password, определяют имя и пароль пользователя. Эти поля уже, в отличие от host, различают регистр введенных символов, поэтому пользователь Root и root - это два разных пользователя. Знаки подстановки в этом поле уже не работают - имя пользователя %" означает не "любой пользователь", а именно "пользователь с именем %". Для задания анонимного пользователя надо просто оставить поле пустым, иначе любой символ будет считаться именем пользователя. Так же и в поле password - пароль хранится в зашифрованном виде, знаки подстановки недействительны, а пустое поле означает, что пользователь вовсе не должен указывать пароль, а не то, что пароль может быть произвольным. Напомним, что просто пароль (пусть и зашифрованный) нельзя помещать в поле password, предварительно его надо шифровать функцией PASSWORD("пароль_открытым_текстом"). Например:
INSERT INTO user SET host="192.168.1.138", user="raiden", password=PASSWORD("my_password");
Следующим полем является поле базы данных - db. В других таблицах оно также присутствует, поэтому во всех таблицах правила написания имен баз данных должны быть одинаковыми. Разрешается использовать символы подстановки "%" и "_", пустое значение соответствует "все базы". Поле чувствительно к регистру!
Далее идет целый набор столбцов, разрешающие те или иные действия для пользователя. К примеру, Select_priv, Insert_priv, Update_priv, Delete_priv, Index_priv и Alter_priv стоит установить в "Y" (разрешено) для обычного пользователя, так как такие запросы чаще всего встречаются в обычных приложениях. Остальные возможности для большей безопасности надо отключить для всех пользователей (особенно, если есть учетная запись анонимного пользователя). Поэтому в следующих столбцах - Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv и References_priv надо выставить значение "N"(запрещено), а при необходимости разрешить действия только администратору и максимально ограничить возможности подключения такого пользователя - указать конкретный IP-адрес или имя компьютера, выбрать длинный и сложный для подбора пароль.
Аналогична таблице user и таблица db, в которой можно задавать отдельные привилегии для конкретных баз данных. Таким образом, можно разрешить пользователям создавать новые таблицы только в своих базах данных и запретить даже простой просмотр чужих баз. Синтаксис всех полей полностью аналогичный таблице user.
При подключении пользователя сервер MySQL сначала обрабатывает таблицу user (записанные там правила доступа глобальные), а потом, если прав недостаточно или нельзя определить права доступа к конкретной базе - тогда уже поиск продолжается в таблице db. Если же и во второй таблице нет соответствующих привилегий, сервер пробует найти их в таблицах tables_priv и columns_priv. И только когда на основании информации со всех доступных таблиц сервер определяет, что клиенту не разрешено запрошенное действие, он отвергает клиентский запрос.
Таблица host также аналогична описанным выше, только вместо имен и паролей пользователей для идентификации привилегий служит имя хоста или IP-адрес. На первый взгляд, есть существенное дублирование информации. Ведь таблицы db и host почти равнозначны и содержат одинаковые данные. На самом деле это немного не так. Таблица host недоступна для изменения через операторы SQL GRANT и REVOKE, ее можно только править непосредственно. Когда сервер принимает решение о допуске клиента к базам, он сначала ищет упоминание имени хоста или IP в таблице host. Если там присутствует соответствующая запись, то тогда права из таблиц host и db обьединяються и клиент получает некоторые привилегии. Если же в таблице host нет указаний на счет хоста или IP, то сервер даже не рассматривает дальше таблицу db, так как если клиенту не разрешено подключение с хоста, то тогда бессмысленно искать права на доступ к отдельным базам.
И, напоследок, давайте остановимся на одном нюансе при определении привилегий. Сервер MySQL, когда ищет и сравнивает привилегии, не сравнивает их напрямую. К примеру, символьное обозначение параметра имеет больший приоритет, чем использование символов подстановки. Пример: если есть две записи - %.hostinfo.ru и admin.hostinfo.ru, то вторая запись имеет больший приоритет. Поэтому если для одного пользователя существуют разные привилегии в зависимости от хоста или других параметров, то будет выбираться первой та запись, где более точно и однозначно указан параметр. Это же касается и IP-адресов