Подтвердить что ты не робот

Какую учетную запись вы рекомендовали бы использовать службы SQL Server Express 2008 в среде разработки?

Настройка SQL Server Express 2008 позволяет вам назначать разные учетные записи пользователей для каждой службы.

В среде разработки вы бы использовали пользователя домена, локального пользователя, NT Authority\NETWORK SERCVICE, NT Authority\Local System или какую-то другую учетную запись и почему?

4b9b3361

Ответ 1

Локальная система не рекомендуется, это эквивалентная учетная запись администратора и, следовательно, может привести к сомнительному кодированию, которое использует привилегии администратора, которые не будут разрешены в производственной системе, так как администраторы Admins/DBA безопасности действительно не нравится запускать службы как admin.

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

Если ему не нужно получать доступ к каким-либо (не анонимным) ресурсам домена, чем я обычно создаю уникальную локальную учетную запись с низким уровнем привилегий для ее запуска, чтобы получить дополнительное преимущество в безопасности, не имея нескольких служб, работающих в такой же контекст идентичности. Помните, что учетная запись Local Service не поддерживается службами SQL Server или SQL Server.

Если вам нужно получить доступ к неанонимным ресурсам домена, у вас есть три варианта:

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

Большая часть того, что я обычно делаю, не требует от службы доступа к ресурсам домена, поэтому я склонен использовать уникальные локальные учетные записи с низким уровнем привилегий, которыми я управляю. Я также работаю исключительно как пользователь, не являющийся администратором (и сделал это в XP SP2, Server 2003, Vista и Server 2008 без каких-либо серьезных проблем), поэтому, когда у меня есть случаи, когда мне нужна служба для доступа к ресурсам домена, тогда я не беспокоюсь об использовании моих собственных учетных данных домена (плюс, таким образом, мне не нужно беспокоиться о том, что сетевые администраторы создают/поддерживают кучу непродуктивных идентификаторов доменов).

Ответ 2

Это зависит.

  • Локальная система - Никогда, она слишком высокая привилегия.
  • Сетевая служба - Возможно, если вам нужно подключиться к сетевых ресурсов, но это Сомнительно.
  • Локальное обслуживание - возможно лучший выбор, ограниченные привилегии, не разблокировать сетевые подключения
  • Локальный интерактивный пользователь? Имеет ли это действительно необходимо иметь права входа или действовать как пользователь?
  • Пользователь домена? великодушие нет, если вы не получаете доступ сетевые диски изнутри; если SQL работает amok, тогда злоумышленник аутентифицирован в домене.

Ответ 3

У MS теперь есть хорошая статья об этом: http://msdn.microsoft.com/en-us/library/ms143504(v=sql.105).aspx

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

Ответ 4

Независимо от того, что он хочет использовать по умолчанию. Изменив это, вы просто попросите проблему позже.