Управление доступом к базам MySQL

Дневник админа
Управление доступом к базам MySQL

Управление доступом к базе данных MySQL

Система управления базами данных MySQL очень часто используется для хранения конфиденциальной информации на веб-сайтах. В случае обычного веб-сайта или форума он может хранить сообщения пользователей, данные динамических страниц и данные посетителей, а в случае онлайн-сервиса он хранит конфиденциальные данные и другие данные о пользователе и его действиях. Все эти факторы приводят к тому, что общая безопасность веб-сайта или, скорее, всей интернет-системы зависит от того, насколько безопасен сервер базы данных.

При обычном виртуальном хостинге каждый клиент получает свой собственный логин и пароль, и у них есть доступ только к одной базе данных, где они могут создавать столько таблиц, сколько захотят. Один и тот же физический сервер базы данных используется разными клиентами, каждый из которых имеет доступ только к одной конкретной базе данных. Ситуация, при которой у пользователя есть одна база данных, за владение которой движок борется. форум (который требует создания сотен или более таблиц) и скрипты для списков рассылки, новостей, скрипта поисковой системы, а если у вас установлена ​​система управления контентом (CMS) или электронный магазин — то база данных содержит огромное количество разные таблицы, иногда с очень странными и бессмысленными именами (хорошо, если в двух скриптах не используются таблицы с одинаковым именем, но разная структура). В таких случаях было бы очень желательно иметь возможность создать несколько отдельных баз данных и выделить их для разных приложений (например, одну для форума, другую для интернет-магазина).

Помимо хлопот по управлению несколькими сотни таблиц в одной базе данных, вы также столкнетесь с необходимостью ограничивать доступ к таблицам, базам данных и даже отдельным столбцам данной таблицы для разных пользователей. Уверяем вас, что разработчики MySQL уже позаботились об этой ситуации: MySQL имеет очень гибкий и эффективный механизм для управления и ограничения доступа пользователей к таблицам и базам данных.

Этот механизм работает, конечно же, через службу таблицы. В списке баз данных есть одна база данных обслуживания, называемая & # 171; mysql & # 187 ;, которая хранит в нескольких таблицах все служебные данные, необходимые для сервера. Пока нас интересует только управление правами доступа, которые поддерживаются следующими таблицами:

columns_priv — доступ к таблицам на уровне столбцов; db — доступ к отдельным базам данных; host — доступ к базам данных с отдельных хостов/IP. ; tables_priv — доступ к отдельным таблицам базы данных; user — глобальные настройки доступа для отдельных пользователей.

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

Разрешения, определенные в пользовательской таблице, являются глобальными, что означает что они применяются ко всем базам данных, к которым у пользователя есть доступ. В этой таблице также хранятся имена пользователей и пароли. Кроме того, имена пользователей хранятся в виде обычного текста, а пароли зашифровываются с помощью функции ПАРОЛЬ (). Сервер MySQL использует свой собственный метод шифрования вместо системного шифрования (если он предоставляется операционной системой, например Linux/UNIX).

Поскольку MySQL предназначен для работы в сети, он может подключаться к серверу с нескольких хостов. . Поэтому в таблице настроек есть столбец хоста, где вы можете указать конкретный компьютер, IP-адрес или диапазон адресов, с которых данный пользователь (или все, любые пользователи) может подключаться или не подключаться вообще. Например, если тестовый сервер находится в локальной сети, вы можете выборочно разрешить доступ с одних компьютеров и полностью запретить доступ с других.

Если одному и тому же пользователю необходимо разрешить доступ с нескольких компьютеров, таблица показывает В корневых настройках создайте две (три или более — в зависимости от ваших потребностей) записи, каждая с разными настройками доступа. Например,чтобы разрешить root-доступ с localhost и 192.168.1.138, вам нужно добавить две идентичные записи в таблицу user, единственная разница — в поле host. Хотя вы, конечно, не можете сделать их идентичными — тогда один и тот же пользователь будет иметь разные привилегии в зависимости от того, откуда он вошел в систему.

Столбец хоста может быть задан в разных форматах. Это может быть имя хоста localhost или IP-адрес 192.168.1.138. При необходимости можно использовать следующие символы изменения. Они похожи на такие же. Они используются в синтаксисе SQL-запросов. Символ & # 171; _ & # 187; соответствует любому символу и & # 171;% & # 187; любое количество символов. Например, чтобы разрешить доступ с любого хоста, содержащего hostinfo.ru, вы должны ввести% .hostinfo.ru в столбце host. Таким же образом можно определить диапазоны IP-адресов. Вы также можете использовать косую черту, чтобы указать сетевую маску 192.168.1/255. Для глобального доступа можно ввести & # 171;% & # 187; только в столбце хоста или оставьте его пустым, что идентично.

Следующие поля пользователя и пароля определяют имя пользователя и пароль. В этих полях уже учитывается регистр, в отличие от host, поэтому root и root — разные пользователи. Подстановочные знаки в этом поле больше не работают — имя пользователя% & # 187; не является & # 171; пользователем & # 187; но & # 171; пользователь с именем% & # 187;. Чтобы указать анонимного пользователя, оставьте это поле пустым, в противном случае каждый символ будет рассматриваться как имя пользователя. То же самое относится и к полю пароля — пароль хранится в зашифрованном виде, подстановочные знаки недействительны, а пустое поле означает, что пользователь вообще не должен вводить пароль, а не то, что пароль может быть любым. Напоминаем, что мы не можем просто ввести пароль (даже если он зашифрован) в поле пароля, мы должны сначала зашифровать его с помощью ПАРОЛЯ (& # 171; password_open_text & # 187;). Например:

 INSERT INTO user SET host = "192.168.1.138", user = "raiden", password = PASSWORD ("my_password"); 

Другое поле — это поле базы данных db. Это также происходит в других таблицах, поэтому правила для имен баз данных должны быть одинаковыми для всех таблиц. Разрешено использовать & # 171;% & # 187; и & # 171; _ & # 187; подстановочные знаки, пустое значение соответствует & # 171; всем базам данных & # 187;. В этом поле учитывается регистр!

Затем есть целый набор столбцов, которые позволяют пользователю выполнять то или иное действие. Например, Select_priv, Insert_priv, Update_priv, Delete_priv, Index_priv и Alter_priv должны быть установлены на & # 171; Y & # 187; (разрешено) для обычного пользователя, поскольку эти запросы наиболее распространены в обычных приложениях. Остальные функции должны быть отключены для всех пользователей (особенно если у вас есть анонимная учетная запись) для большей безопасности. Итак, в следующих столбцах Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv и References_priv должны быть установлены на & # 171; N & # 187; (запрещено) и, при необходимости, разрешать только действия администратора и ограничивать возможности подключения до максимума, указав конкретное IP-адрес или имя компьютера, выберите длинный пароль, который сложно угадать.

Как и в таблице user, в таблице db вы можете установить разные разрешения для разных баз данных. Таким образом, вы можете разрешить пользователям создавать новые таблицы только в их собственных базах данных и предотвратить даже простой просмотр сторонних баз данных. Синтаксис всех полей полностью аналогичен синтаксису пользовательской таблицы.

Когда пользователь подключается, сервер MySQL сначала обрабатывает пользовательскую таблицу (объявленные там правила доступа являются глобальными), а затем, если прав недостаточно или права не могут быть определены доступ к базе данных — продолжает поиск в таблице db. Если во второй таблице нет подходящегоразрешений, сервер пытается найти их в таблицах tables_priv и columns_priv. Только когда сервер определяет на основе информации из всех доступных таблиц, что клиент не разрешил запрошенное действие, он отклоняет запрос клиента.

Таблица хостов также аналогична приведенной выше, только вместо имен пользователей и паролей для определения разрешений используется имя хоста или IP-адрес. На первый взгляд видно, что информация во многом дублируется. В конце концов, таблицы db и host почти эквивалентны и содержат одни и те же данные. На самом деле это немного другая ситуация. Хост таблицы не может быть изменен с помощью операторов SQL GRANT и REVOKE, его можно редактировать только напрямую. Когда сервер решает разрешить клиенту доступ к базам данных, он сначала ищет имя хоста или IP-адрес в таблице хостов. Если есть соответствующая запись в таблице хостов, разрешения из таблицы хостов и базы данных объединяются, и клиенту предоставляются некоторые разрешения. Если в таблице хостов нет упоминания о хосте или IP-адресе, сервер даже не смотрит на таблицу db, поэтому

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

Управление доступом к базам MySQL

Наконец, отметим один нюанс при определении разрешений. Сервер MySQL не сравнивает напрямую предпочтения при их поиске и сравнении. Например, предпочтения символов имеют приоритет над использованием подстановочных знаков. Пример: если есть две записи % .hostinfo.ru и admin.hostinfo.ru, вторая запись имеет более высокий приоритет. Следовательно, если для одного и того же пользователя существуют разные разрешения, в зависимости от хоста или других параметров, сначала будет выбрана запись с более точным и однозначным параметром. То же самое касается IP-адресов.

.

Оцените статью