Каковы разумные привилегии для предоставления типичным пользователям? [закрыто]

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

1. root
2. developer
3. application

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

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationимеет еще более ограниченный набор. Это должно быть ограничено манипулированием конкретной базой данных.

Я не уверен, какой разумный набор привилегий предоставить. Какой разумный набор привилегий предоставляет разработчик и приложение и почему?

Типичный пользователь должен иметь:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

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

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

EXECUTEзависит от вашего типа системы. Вы сохранили подпрограммы? Хотели бы вы, чтобы ваши пользователи имели к ним доступ? Убедитесь, что вы также знаете об SECURITY=DEFINER/INVOKERопределении хранимых процедур.

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

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

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

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

В любой реальной системе (т.е. не в личном проекте) эти типы пользователей будут различаться в зависимости от среды, поэтому все не так просто.

Во всех средах приложение должно иметь то, что ему нужно, и не более (обычно это «выбрать / вставить / обновить для всех таблиц» и «exec для всех процедур». Для более крупных систем, где у вас могут быть отдельные пользователи приложения для разных задач (для Например, одно приложение отвечает за ввод данных цензуры, а другое - за создание отчетов. Вам следует разделить их привилегии, чтобы они имели наименьшее количество необходимых им прав (вероятно, пользователю отчетов не нужны права на запись). Убедитесь, что вы повторили это в своем тесте. среды, если они у вас есть: я видел падение кода при переходе в Live, который работал в тесте, потому что все в тестовой среде обращались к БД как sa(MSSQL эквивалентно root).В идеале пользователь приложения, как правило, не должен иметь привилегий, позволяющих ему изменять вашу схему (CREATE, DROP...) - есть исключения из этого правила, но их мало и далеко друг от друга.

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

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

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