Просмотров: 3801

MySQL: Безопасность и аудит. Часть 1


Продолжаем начатый ранее разговор.

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

MySQL ЬнЫЙД ,tpjgfcyjcnm Безопасность security защита рецепты решения укрепление Securich Openark Kit хакеры взлом роли SQL база данных СУБД мускул запрос инекция sql injection блокировка пользователи

Такой загадочный GRANT

Для иллюстрирования сказанного выберем важную тему — присвоение и делегирования прав с помощью GRANT . Эта команда позволяет назначать как отдельные привилегии, так и выдавать весь спектр возможностей для администраторов БД (в таком случае можно воспользоваться мета-подстановкой ALL PRIVILEGES ).

После очень краткой теории, давайте посмотрим, как это работает:

root@mysql-5.5.17> GRANT ALL PRIVILEGES ON consumer.* TO 'super_usr'@'localhost';
root@mysql-5.5.17> SHOW GRANTS FOR 'super_usr'@'localhost';
+-----------------------------------------------------------------+
| Grants for super_usr@localhost                                  |
+-----------------------------------------------------------------+
| GRANT USAGE ON *.* TO super_usr'@'localhost'                    |
| GRANT ALL PRIVILEGES ON `consumer`.* TO 'super_usr'@'localhost' |
+-----------------------------------------------------------------+

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

Продолжим демонстрацию ещё одним примером присвоения прав, который вскрывает коварность этой команды:

root@mysql-5.5.17> GRANT EXECUTE, INSERT, SELECT, UPDATE ON `consumer`.* TO 'usual_usr'@'localhost';
root@mysql-5.5.17> SHOW GRANTS FOR 'usual_usr'@'localhost';
+----------------------------------------------------------------+
| Grants for usual_usr@localhost                                 |
+----------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'usual_usr'@'localhost'                  |
| GRANT ALL PRIVILEGES ON `consumer`.* TO 'usual_usr'@'localhost'|
+----------------------------------------------------------------+

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

Удивлены? Если кто-то в Oracle считает это логичным, когда мы явно присваиваем одно, а неявно получаем совсем другое — я так не считаю. Перейдем к следующему примеру, связанному с перетеканием привилегий уже через оператор «WITH GRANT OPTION »:

root@mysql-5.5.17> GRANT INSERT, UPDATE ON consumer.City TO 'alaura'@'localhost';
root@mysql-5.5.17> GRANT SELECT ON consumer.City TO 
'alaura'@'localhost' WITH GRANT OPTION;
root@mysql-5.5.17> SHOW GRANTS FOR 'alaura'@'localhost';
+---------------------------------------------------------+
| Grants for alaura@localhost                             |
+---------------------------------------------------------+
| GRANT USAGE ON *.* TO 'alaura'@'localhost'              |
| GRANT SELECT,INSERT,UPDATE ON `consumer`.`City`         |
| TO 'alaura'@'localhost' WITH GRANT OPTION               |
+---------------------------------------------------------+

Синтаксис второй команды недвусмысленно говорит, что мы передаем «WITH GRANT OPTION » для привилегии SELECT , но вывод результата утверждает обратное. Думаю, администраторы MySQL вряд ли будут хоть сколько-то удивлены подобной логикой, но как я неоднократно имел возможность наблюдать, операторы других известных СУБД были явно озадачены подобным развитием событий.

В этом плане синтаксис MySQL вводит в заблуждение, хотя бы тем, что позволяет без ошибки исполнять подобные действия

Я привел лишь один вариант неоднозначности, хотя в MySQL таковых имеется множество. И если администратор в этой ситуации может просто быть внимательным, то многие веб-приложения для управления этой СУБД, (например популярный phpMyAdmin), не всегда учитывают такие мелочи.

Положение отчасти усугубляется и тем, что в последнее время на многих западных хостинговых площадках получили широкое распространение известные «легковесные заменители» phpMyAdmin, такие как Adminer и phpMiniAdmin (которые часто используются параллельно с phpMyAdmin), логика передачи прав у них в отдельных случаях отличается от принятой в phpMyAdmin, но также не всегда идеальна и безупречна. С учетом всего выше сказанного — не всегда можно гарантировать однотипность или консистентность подходов при администрировании политик доступа в MySQL.

Но цель сегодняшнего обзора не в обсуждении подобных «слабых мест» и нелогичностей в MySQL — наш подход более конструктивен:

далее мы обсудим инструменты, позволяющие оперативно отслеживать и активно выявлять подобные аномалии (и их последствия), которые неизбежны в любой большой и сложной MySQL-системе

~

Читать этот материал дальше. Оглавление и начало этой серии статей — здесь.

Игорь Савчук ©  Системный Администратор, 2012
twitter.com facebook.com vkontakte.ru odnoklassniki.ru mail.ru ya.ru pikabu.ru blogger.com liveinternet.ru livejournal.ru google.com bobrdobr.ru yandex.ru del.icio.us

Подписка на обновления блога → через RSS, на e-mail, через Twitter
Теги: , , , ,
Эта запись опубликована: Понедельник, 28 мая 2012 в рубрике Unix'овое.

1 комментарий

Следите за комментариями по RSS
  1. Not so far I have found new cool tool to work with mySQL - Valentina Studio. Its free edition can do things more than many commercial tools!!

    I very recommend check it. http://www.valentina-db.com/en/valentina-studio-overview

Оставьте комментарий!

Не регистрировать/аноним

Используйте нормальные имена. Ваш комментарий будет опубликован после проверки.

Зарегистрировать/комментатор

Для регистрации укажите свой действующий email и пароль. Связка email-пароль позволяет вам комментировать и редактировать данные в вашем персональном аккаунте, такие как адрес сайта, ник и т.п. (Письмо с активацией придет в ящик, указанный при регистрации)

(обязательно)


⇑ Наверх
⇓ Вниз