Предоставление привилегий SA для разработчиков в окне разработки

Несмотря на наши яростные протесты, наше руководство решило, что команде разработчиков должны быть предоставлены права 's' на сервере разработки. Подвох в том, что мы, группа поддержки БД, по-прежнему несем ответственность за поддержание этого ящика.

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

Пожалуйста, добавьте в этот список:

DO - ограничить деятельность разработанной БД

НЕ ДЕЛАЙТЕ --

• изменить любые настройки экземпляра SQL
• sp_configure (включая cmdshell)
• добавить / изменить / удалить любые настройки безопасности
• добавить / изменить / удалить объекты базы данных
• добавить / изменить / удалить объекты сервера, такие как устройства резервного копирования и связанные серверы
• добавить / изменить / удалить репликацию
• добавить / изменить / удалить планы обслуживания
• коснитесь любой базы данных, которая не принадлежит вашей команде

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

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

Поэтому обычно они работают под отдельными «ограниченными» учетными записями (которые я использую свободно, потому что этим ограниченным учетным записям по-прежнему требуются значительные разрешения - т.е. создавать, удалять, изменять для таблиц). Но для того редкого случая, когда они думают, что им нужно sa, они могут войти в систему, используя эту учетную запись. Затем вы можете пометить учетную запись в своих журналах и сделать дополнительный мониторинг. Вы дали разработчикам доступ, о котором они просили, но в некотором смысле это более управляемо.

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

Здесь говорится (MSDN), что вам нужен sysadmin (sa) для отладки на SQL Server 2005.

Тем не менее, этот вопрос SO показывает другой путь без sa, о чем я думал изначально. Просто позвольте им бежатьsp_sidedebug

Я также предложил бы дать им локальный SQL Express, который также решает другие проблемы ...

(отредактировано с дополнительной информацией)

Изменить, после ответа У. Крейга Трейдера

Другие проблемы с правами "sa" в худшем случае:

• разработчики будут создавать ненадежные сборки CLR
• они будут использовать xp_cmdshell
• все действия в контексте учетной записи службы сервера sql
• они примут права на подключение клиента
• и т. д.

например xp_cmdshell 'scm -Action 6 -Server PRODSERVER'

У меня есть предложение настроить управление на основе политик и применить все свои «делать» и «не делать» как правила политики. Это будет иметь большое значение для защиты экземпляра.

Я хотел бы также развернуть аудит изменений DDL см аудита в SQL Server 2008 , не столько в качестве сдерживающего фактора, но в основном как система отслеживания изменений , так когда - то будет ввинчивается, по крайней мере , вы будете знать , что изменилось.

Если это сервер DEVELOPMENT, в чем проблема с тем, что разработчики могут иметь полный доступ? Сказать разработчикам, что вы не можете добавлять / удалять / изменять объекты базы данных (например, таблицы, столбцы, индексы), все равно что говорить им: «Вы можете иметь компилятор, но вы не можете его запускать». Мне кажется, что разработчики хотят / нуждаются в доступе к своему собственному экземпляру базы данных, чтобы позволить им тестировать различные методы решения проблем, БЕЗ взлома с базами данных PRODUCTION или TEST. Вы должны поощрять такое поведение, а не препятствовать ему.

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

То, что вы ДОЛЖНЫ сделать, это установить регулярное расписание резервного копирования (по крайней мере, на ночь) и работать с разработчиками, чтобы убедиться, что они знают, как запускать незапланированные резервные копии и восстанавливать из резервных копий, чтобы минимизировать время простоя в случае возникновения проблем.

Это сервер разработки , а не сервер группы поддержки БД или производственный сервер. Держите хорошую резервную копию / образ и дайте разработчикам взломать. Предоставить DBA контроль над devbox - все равно что позволить хвосту вилять собакой. Это для разработчиков, чтобы сделать работу над разработчиком. Это включает в себя иногда что-то ломать и сбрасывать таблицы, а затем возвращать их с другими настройками. Ящики для разработчиков всегда будут в плохом состоянии через некоторое время, вот что мы делаем. Если мы не знаем, где возникает проблема, мы пробуем разные вещи. Некоторые из них легко отменить, некоторые не так уж и много.

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

Я думаю, что хороший вариант - установить локальную версию dev.

вопрос:

Вы не хотите, чтобы разработчики добавляли / меняли / удаляли объекты базы данных? !! Как они собираются развиваться?

Мы требуем, чтобы все изменения структуры базы данных делались с помощью скриптов (даже в dev) и сохранялись в subversion. Затем по установленному расписанию мы обновляем dev от prod, и им приходится повторно запускать свои сценарии, чтобы вернуться туда, где они были в цикле разработки. Это помогает гарантировать, что все выполняется с помощью сценариев, и что у них есть готовые сценарии, когда пришло время для развертывания.

Я знаю, что в 2008 году вы можете настроить триггеры DDL для отслеживания структурных изменений базы данных, можете ли вы сделать это в 2005 году? Таким образом, по крайней мере, вы можете узнать, когда кто-то меняет настройки, кто это сделал, и выяснить, почему.

Аудит SQL Server - это то, что вам нужно, но, если вы сделаете все объекты базы данных для них, зачем разработчикам нужен sa?

http://msdn.microsoft.com/en-us/library/cc280526.aspx