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

8

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

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

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

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

НЕ ДЕЛАЙТЕ --

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

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

sql-server sql-server-2005 permissions Радж
источник
1
Какие задачи им нужно выполнить, что требует привилегий SA более высокого уровня?
Я думаю, что db_owner - это все, что им нужно ...
5
Хорошо, если им советуют НЕ «добавлять / изменять / удалять объекты базы данных», что они должны делать? Разве весь смысл в том, чтобы иметь ящик для разработки, заключается в том, что они могут его сломать?
Стюарт Эйнсворт
Это разработчики приложений. Им нужны привилегии 'sa', чтобы иметь возможность отлаживать хранимые процедуры в Dev Studio. Решение уже принято руководством, и они не хотят планировать. Мы стараемся свести к минимуму потенциальную головную боль
2
+1 за вопрос, так как я затронул этот вопрос пару раз. Другое решение: предоставьте разработчикам изолированную виртуальную машину с SQL на которой они на 100% босс. Они также на 100% ответственны за поддержание его жизнеспособности :) -> Удивительно, как быстро разработчики учатся не ломать свою собственную систему :)
Martin S. Stoller

Ответы:

8

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

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

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

Джоэл Коухорн
источник
6

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

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

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

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

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

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

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

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

ГБН
источник
1
Ответ разработчикам, которые пишут за пределами строк, заключается в том, чтобы выполнять непрерывную интеграцию с заблокированными «как это будет выполняться разрешениями пользователей» и соответственно отказывать в сборке. Пусть сервер сборки заново создаст базу данных и заполнит ее тестовыми данными (конечно, из SCM). (В моем случае я использовал точно такой же код, который установщик приложения использовал бы для создания новой базы данных, таким образом проверяя как установщик, так и приложение.)
1
@Craig trader: не будет работать. Перефразируя мой старый ответ, разработчикам нельзя доверять, и интеграция не обнаружит все случаи. Я разработчик dba: обезьяна клиентского кода - мой враг. В моей компании я выигрываю .... это мой набор поездов, и я имею дело с наименьшим общим знаменателем ...
gbn 22.12.10
Видимо, ваш пробег может меняться. По моему опыту, мне обычно приходилось немного тренироваться / ориентироваться, чтобы объяснить, как и почему все делается, но после этого дела обычно идут довольно хорошо. Конечно, я всегда настаиваю на том, что единственные сборки, которые выходят за рамки разработки, это те, которые приходят с строго контролируемого сервера сборки - если код не собирается там, это проблема с вашим кодом (или вашими тестами), а не с конфигурации. Я делал это с небольшими командами и большими проектами, во многих компаниях, и всегда успешно.
4

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

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

Ремус Русану
источник
3

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

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

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

Крейг Трейдер
источник
Ваша аналогия совершенно неверна. То, что происходит, это то, что они бродят вокруг, а затем рыдают, когда они не могут перенести свои гадости на заблокированные серверы. Я, конечно, разработчик DBA :-)
gbn
Тогда небольшое образование в порядке. Я разработчик, который слишком часто был администратором. Ноги в обоих мирах, как правило, были моей задачей - научить обе стороны сосуществовать. В конце концов, враги - это ПОЛЬЗОВАТЕЛИ, а не администраторы или разработчики ...
Есть также такие вещи, как планы обслуживания, к которым у них не должно быть доступа.
Джоэл Коухорн
1
Проблема в том, что у нас есть несколько групп разработчиков, и на этом сервере размещены все их базы данных. Эта группа, требующая прав 'sa', владеет только 33% Dbs. Проблема заключается в том, что они могут обойти сервер и сломать его, что также повлияет на другие группы. Компания не хочет приобретать для них отдельное оборудование, если только мы не сможем доказать, что они облажались.
2
Это нелепо. Каждая группа разработчиков должна иметь свой собственный сервер, чтобы никто не наступал ни на кого. Оборудование в наши дни практически бесплатное, а программное обеспечение почти такое же дешевое, как и оборудование. И если ваша организация достаточно велика, чтобы иметь несколько групп разработки, она должна использовать виртуализацию серверов, что сделает все это еще проще.
3

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


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

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

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

вопрос:

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

Радж Море
источник
Извините за путаницу. Под этим пунктом я имел в виду то, что разработчики не должны изменять настройки базы данных или удалять базы данных.
1

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

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

HLGEM
источник