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

Question

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

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

Компоненты:

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

Платформа:

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

Мы используем систему безопасности "Смешанный режим" из-за некоторых устаревших приложений и сетей, но переходим к Windows Auth. Я не уверен, действительно ли это влияет на установленную роль.

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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