Соответствующие разрешения для SQL Server для разработчиков

Question

После нескольких поисков Google и быстрого рассмотрения здесь вопросов я не могу найти то, что, как я думал, будет ответом кулинарной книги для разрешений SQL Server.

Как я часто вижу в небольших магазинах, большинство разработчиков здесь использовали учетную запись администратора для SQL Server при разработке. Я хочу настроить роли и разрешения, которые я могу назначить разработчикам, чтобы мы могли выполнить наши задания, но также делать это с минимальными разрешениями. Может ли кто-нибудь предложить советы о том, какие разрешения SQL Server назначить?

Компоненты:

• SQL Server 2008
• службы отчетов SQL Server (SSRS) 2008
• службы интеграции SQL Server (SSIS) 2008

Платформы:

• Производство
• Постановка/QA
• Разработка/интеграция

Мы бежим «Mixed Mode» безопасность из-за некоторых устаревших приложений и сетей, но переходят на Windows, Авт. Я не уверен, действительно ли это влияет на настройку роли.

Я планирую настроить доступ для разработчиков к базам данных Prod и Staging/QA как только для чтения. Тем не менее, я все еще хочу, чтобы разработчики сохраняли возможность запуска профилирования.

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

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

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

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

Может ли кто-нибудь указать мне или предоставить хороший пример для разрешений для этих ролей на этих платформах?

Answer 1

Это будет широко варьироваться от компании к компании. Ключевым компонентом является блокировка производства, чтобы разработчики не могли создавать или изменять объекты. Наши разработчики имеют только права доступа на prod, ничего другого. Они не могут даже выполнить хранимую процедуру, если не войти в приложение и не использовать разрешения приложения.

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

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

Далее нет людей, которые делают на лету неотложные, непроверенные изменения в prod, которые никогда не спускаются на dev и qa и, таким образом, теряются при следующей загрузке новой версии. В результате изменения, которые не работали на prod, тоже пошли вниз, потому что теперь все тестируется, прежде чем кто-то попытается поставить его на prod.

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

Answer 2

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