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

Question

Для веб-приложения, при создании пользователя, который будет подключаться к базе данных MySQL, у вас есть выбор привилегий.Предполагая, что единственными действиями, которые должен выполнять этот пользователь, являются SELECT / INSERT / UPDATE / DELETE, кажется, имеет смысл предоставлять только эти привилегии, однако я никогда не видел, чтобы это где-либо рекомендовалось - каковы причины для и против этого метода?

Answer 1

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

• СОЗДАТЬ ВРЕМЕННУЮ ТАБЛИЦУ
• ВЫПОЛНИТЬ (хранимые процедуры)
• ФАЙЛ (для ВЫБОРА и ЗАГРУЗКИ ДАННЫХ)
• БЛОКИРОВКА ТАБЛИЦ

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

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

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

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

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

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

Answer 2

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

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

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

Затем для сценариев PHP выберите один с необходимым минимумом, например, просто INSERT, SELECT, UPDATE, возможно, даже не DELETE, в зависимости от сценария PHP. Это будет в файлах PHP, то есть, фактически, ОДИН файл вне корня документа, как рекомендуется большинством.

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

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

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

Answer 3

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

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

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

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