Назад | Перейти на главную страницу

Встроенная безопасность SQL Server без домена

Этот вопрос потенциально находится где-то между ServerFault и администраторами DBA, но элемент Domain в этом, как и побудил меня поставить его здесь.

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

Имена входа SQL не будут работать с контейнерами FILESTREAM. С контейнерами FILESTREAM будет работать только аутентификация NTFS. FILESTREAM MSDN

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

Я осмотрелся, и есть несколько вопросов, предполагающих, что вы можете использовать РАБОЧИЕ ГРУППЫ с интегрированной безопасностью.

Интегрированная безопасность (SSID?) Без домена ...

Мой вопрос: есть ли рекомендуемая практика для описанного выше сценария? Должны ли мы попробовать безопасность WORKGROUP и посмотреть, как у нас обстоят дела, или есть причина, по которой мы не можем использовать домен или не использовать FILESTREAM?

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

Для использования встроенной безопасности домен не требуется. Если вы управляете множеством машин, предпочтительнее использовать домен, но с небольшим количеством серверов вы можете просто использовать локальных пользователей на каждом сервере. Хитрость в том, что у всех совместно используемых пользователей должны быть одинаковые имя пользователя и пароль на каждом сервере, который обращается к данным SQL. Например, предположим, что у вас есть веб-сервер IIS на одном компьютере и SQL Server на другом. Вы должны создать пользователя с одним и тем же именем пользователя и паролем как на компьютере с веб-сервером, так и на компьютере с SQL Server, возможно, с именем «IISUser». Затем в SQL Server вы должны назначить соответствующие разрешения этому пользователю, а на веб-сервере вы должны настроить пул приложений IIS для работы с тем же пользователем. Поскольку здесь используется встроенная безопасность, имя пользователя и пароль не нужно записывать или хранить в каком-либо файле конфигурации, а соединение является безопасным.

К сожалению, я не могу ответить на ваш вопрос «есть ли рекомендуемая практика» в отношении FILESTREAM, однако я бы посоветовал вам не избегать того, что вы хотите делать, просто потому, что вы также хотите избежать интегрированной безопасности. ИМО, вы должны использовать интегрированную безопасность в любом случае. Я бы посоветовал вам попробовать местных пользователей в вашей ситуации. В конечном итоге домен будет лучше, чем локальные пользователи (он будет еще более безопасным и простым в управлении), но я бы посчитал, что интегрированная безопасность с локальными пользователями все же лучше, чем логины SQL Server.