Назад | Перейти на главную страницу

Разрешения для машины разработки MySQL

Я администрирую два сервера, которые следуют модели машин разработки и производства.

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

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

Есть ли способ создать для каждого разработчика на машине разработки пользователя с разрешением создавать (просто создавать, а не читать / изменять / стирать) пользователей шаблонов с фиксированным набором разрешений? Таким образом, они могли создать свой собственный новый безопасный набор имени пользователя / пароля / базы данных, не дожидаясь, пока я приму их запрос.

Наш сервер разработки доступен снаружи (поэтому разработчики могут использовать ssh и работать из дома), поэтому я не хочу давать одному пользователю много разрешений из-за экспериментального характера приложений, размещенных на сервере. (Если база данных скомпрометирована, лучшее, что он может сделать, это удалить базу данных приложения вместо всех баз данных, к которым пользователь имеет доступ).

MySQL не имеет понятия «шаблонные разрешения». Есть несколько полезных типов разрешений, но они недостаточно детализированы, чтобы создать что-то эквивалентное.

Пользователь, создающий базу данных, должен выполнить три шага:

  • Создание новой базы данных - разрешено предоставлением CREATE пользователю, создающему базу данных.
  • Создание нового пользователя - разрешено путем предоставления CREATE USER пользователю, создающему базу данных. К сожалению, разрешение CREATE USER также позволяет использовать DROP USER, RENAME USER и REVOKE ALL PRIVILEGES. К сожалению, это позволяет запускать DROP USER 'root' @ 'localhost'; и тому подобное.
  • Предоставление разрешений на чтение / запись. Разрешения передаются от пользователя, создающего базу данных, новому пользователю, поэтому пользователь, создающий базу данных, должен иметь существующие разрешения для вновь созданной базы данных. Это возможно, если предоставить ВСЕ ПРИВИЛЕГИИ для всех баз данных, начинающихся с префикса (например, dev1_), и требовать, чтобы новые базы данных начинались с этого префикса. Разрешение WITH GRANT OPTION позволяет пользователю передавать свои разрешения только что созданному пользователю.

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

grant all privileges on `dev1_%`.* to 'dev1'@'%' identified by 'password';
grant create on `dev1_%`.* to 'dev1'@'%' identified by 'password';

Это создаст пользователя «dev1», который сможет создавать и использовать базы данных только начиная с «dev1_».

Поскольку MySQL не может предоставить решение самостоятельно, я бы рекомендовал просто написать программу для выполнения шагов по созданию базы данных и имени пользователя. Разработчики могут вызвать такую ​​проблему:

create_dev_database --comment "xyz app test database" database_name username

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

  • Применяйте надежные пароли (без паролей, как указано выше :))
  • Применять ограничения доступа по имени хоста (ограничьте подключения к "% .example.com" вместо того, чтобы разрешить разработчикам выбирать "%")
  • Регистрируйте данные доступа и назначение новых баз данных (не нужны сотни активных / неактивных баз данных и отсутствие документации об их назначении)

Такая программа должна будет использовать и защищать ваш пароль root MySQL. Как это будет достигнуто, зависит от платформы.

Удачи!

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

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