Настройка входа в SQL Server и автоматизация - PullRequest
Новая
       16

Настройка входа в SQL Server и автоматизация

1 голос
/ 30 июня 2009

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

Некоторая информация о моей ситуации:

  • SQL Server 2005
  • У нас есть N "клиентских" баз данных с одинаковыми схемами (теоретически, по крайней мере)
  • У нас есть центральная база данных "admin", которая ссылается на каждую клиентскую базу данных и может содержать значения конфигурации
  • Этот шаблон "admin / client" дублируется в нескольких средах (dev / qa / stage / prod)
  • Некоторым пользователям, например тестерам, необходимы разные права в зависимости от среды
  • Нам часто приходится извлекать резервные копии клиентских БД из одной среды, чтобы восстановить в другой для целей разработки или тестирования.
  • Мы храним наши хранимые процедуры и скрипты в системе контроля версий и разворачиваем в цикле сборки

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

Ответы [ 3 ]

2 голосов
/ 30 июня 2009

Чтобы упростить права, можно создать списки в базе данных Dev, QA, Test, Prod и предоставить правильные права на эти роли. Затем, когда вы восстанавливаете базы данных в каждой среде, просто оставьте разработчиков в правильной роли.

2 голосов
/ 30 июня 2009

Во-первых, чтобы упростить восстановление базы данных на другом сервере, убедитесь, что все ваши логины имеют одинаковый SID на всех ваших серверах, используя хранимую процедуру sp_help_revlogin от Microsoft для сценария входа в систему. первый сервер, на котором вы его создали, а затем используйте скрипт для создания логина на других ваших серверах. Это позволяет правильно сопоставить пользователя базы данных с именем входа при восстановлении базы данных.

Наличие разных разрешений на уровне базы данных в зависимости от среды будет проблемой в любой момент, независимо от того, как вы это разыгрываете. У меня есть хранимая процедура в master, которая вызывается на моем Dev-сервере как часть моего процесса восстановления, который выполняет дополнительные GRANT для базы данных, чтобы предоставить разработчикам доступ для внесения изменений. Это лучшее, что я смог придумать для решения подобных проблем.

1 голос
/ 21 июля 2009

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

Распространение доступа к базам данных - это либо ручная операция, либо короткий сценарий SQL, чтобы гарантировать, что имена входа в базе данных указывают на действительный логин SQL Server (который, в свою очередь, является группой AD).

Обычно это хорошо работает для общего случая. Затем мы можем использовать роли БД для назначения встроенных ролей (например, db_datareader) каждой группе AD

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

...