Предоставление пользователям MySQL минимальных привилегий

Ответ 1

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

• СОЗДАТЬ ВРЕМЕННЫЙ ТАБЛИЦУ
• EXECUTE (хранимые процедуры)
• FILE (для SELECT INTO и LOAD DATA)
• LOCK TABLES

Также существует вероятность того, что минимальные привилегии могут означать только SELECT для определенных таблиц и только SELECT и UPDATE для других таблиц и т.д. Это может быть изменено в любое время, когда улучшена функциональность приложения. И есть странные случаи, такие как необходимость иметь привилегию SELECT в таблице, которую вы никогда не запрашиваете, потому что на нее ссылаются внешние ключи в таблице, которую вы ОБНОВЛЯЕТ. Поэтому отслеживание минимальных привилегий - это боль в королевстве.

Что вы пытаетесь ограничить, используя привилегии SQL? Вы тот, кто написал весь код, поэтому управление привилегиями SQL при тонкой детализации не должно быть необходимым. Честно говоря, если ваши пользователи могут загружать и запускать SQL-запросы, которые вы не проверяли, у вас больше проблем:

SELECT * FROM mytable, mytable, mytable, mytable, mytable ORDER BY 1;

Реальные задачи, которые вы хотите управлять, не находятся на уровне базы данных, они находятся на уровне бизнес-приложений. Например, CMS имеет такие операции, как создание страницы, редактирование страницы, администрирование комментариев и т.д. Эти задачи являются более высокоуровневыми, чем привилегии SQL. Вы можете имитировать их с помощью ролей SQL (которые представляют собой группы привилегий), но роли SQL не поддерживаются широко.

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

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

Ответ 2

Я не согласен с Биллом здесь, и подход мышления Atomix более подходит. Если это не может быть продемонстрировано иначе, ответ Билла сильно увеличивает риск срыва базы данных.

Возможно, для опытных разработчиков существует и другая безопасность, но для других разработчиков, предоставляющих полный, неограниченный доступ к script для ~ чего-либо ~ в базу данных, возникает проблема, когда нет необходимости.

Здесь должен использоваться принцип наименьших привилегий. Для MySQL есть суперпользователь со всеми привилегиями, который используется для создания таблиц, удаления базы данных и т.д. В идеале это имя пользователя и пароль никогда не встречаются ни в одном файле PHP или любом файле на веб-сервере. (Я использую PHP в качестве примера, но применим к другим веб-приложениям). Вы использовали бы это имя пользователя и пароль с помощью чего-то вроде PHPMyAdmin или MySQL Workbench.

Затем для PHP-скриптов нужно иметь минимальный размер, например, только INSERT, SELECT, UPDATE, возможно, даже не DELETE, в зависимости от вашего PHP script. Это было бы в файлах PHP, то есть на самом деле только один файл OUTSIDE из корня документа, как это рекомендуется большинству.

Причина такова: да, для каждого пользователя веб-приложения вам не нужен пользователь MySQL. Но должен применяться принцип наименьших привилегий (http://en.wikipedia.org/wiki/Principle_of_least_privilege). Если каким-то образом ваш суперпользователь MySQL скомпрометирован, потому что вы случайно назвали ваш MySQL подключаться script как .txt вместо .php, или кто-то получил доступ к файлам веб-сервера, по крайней мере, "худшие", которые они могут делать, это SELECT, UPDATE и INSERT... В любом случае, это может вызвать большие проблемы, не так плохо, как давать им DROP DATABASE, DROP TABLES и многое другое.

Кроме того, в моем текущем проекте из-за гибких методов разработки (я не работаю, но рекомендую http://www.agilealliance.org/), один или два "нетехнические" члены команды напрямую используют PHPMyAdmin для непосредственных изменений в базе данных MySQL. Это связано с тем, что создание CMS для простого прямого ввода данных не требуется. В этом случае для них подходит третий пользователь MySQL с разумными, но опять же "достаточно" привилегиями. Мы не хотим наносить ущерб члену команды слишком маленькими привилегиями, но, конечно, они не могут случайно удалять или изменять вещи.

Так как у MySQL нет ROLES (с момента запроса исходного вопроса и по биллу), то разрешить любому веб-сайту script просто обращаться к MySQL, поскольку только один суперпользователь очень рискован.

Ответ 3

Веб-приложение обычно использует только одного пользователя для доступа к БД, а не пользователя на фактическую учетную запись пользователя. Применение минимальных привилегий - хорошая практика. Имя пользователя и пароль будут закодированы в ваш script (кто-нибудь обфускает это?), Поэтому есть место для компрометации, если ваши сценарии не управляются должным образом.

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

Поэтому я бы предложил разрешить только INSERT, UPDATE и SELECT - это быстро станет очевидным, если части вашего приложения нужно немного расслабить!

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