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

Question

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

Answer 1

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

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

Здесь должен использоваться принцип наименьших привилегий. Для 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 2

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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