Интегрированная безопасность SQL Server без домена
Этот вопрос потенциально находится где-то между Администраторами ServerFault и Администраторами БД, но этот элемент Домена привел меня к этому.
Мы разрабатываем продукт SOA и думаем о различных сценариях развертывания наших управляемых серверов в офисе клиента. Триггером для этого вопроса стало обсуждение использования SQL Server FILESTREAM, который требует интегрированной безопасности.
Логины SQL не будут работать с контейнерами FILESTREAM. Только NTFS-аутентификация будет работать с контейнерами FILESTREAM. FILESTREAM MSDN
На данный момент FILESTREAM является единственной причиной, по которой мы используем Integrated Security, что делает потенциальное требование к развертыванию контроллеров домена (и их требования к избыточности) на серверах менеджера непривлекательным.
Я осмотрелся вокруг, и есть несколько вопросов, предполагающих, что вы можете использовать рабочие группы с интегрированной безопасностью.
Интегрированная безопасность (SSID?) В домене без...
Мой вопрос: есть ли рекомендуемая практика для сценария, описанного выше? Должны ли мы попробовать безопасность WORKGROUP и посмотреть, как мы продвигаемся, или есть причина, по которой нет, и нет, и мы должны либо использовать домен, либо не использовать FILESTREAM?
1 ответ
В целом, Integrated Security (также известная как Trusted Connection) более безопасна, чем логины SQL, и является предпочтительной. Причина в том, что сервисам, которые должны подключаться к SQL Server, не нужно нигде жестко прописывать имя пользователя и пароли; они могут просто работать с пользователем, у которого есть разрешения на доступ к SQL Server.
Для использования встроенной безопасности домен не требуется. Если вы управляете многими машинами, то предпочтительным является домен, но с небольшим количеством серверов вы можете просто использовать локальных пользователей на каждом сервере. Хитрость заключается в том, что все пользователи с общим доступом должны иметь одинаковые имя пользователя и пароль на каждом сервере, который обращается к данным SQL. Например, предположим, у вас есть веб-сервер IIS на одном компьютере и SQL-сервер на другом. Вы должны создать пользователя с одинаковыми именем пользователя и паролем на компьютерах с веб-интерфейсом и сервером SQL Server, возможно, с именем "IISUser". Затем в SQL Server вы назначаете соответствующие разрешения этому пользователю, а на веб-сервере вы устанавливаете пул приложений IIS для работы с этим же пользователем. Поскольку при этом используется встроенная безопасность, имя пользователя / пароль не нужно записывать или сохранять в каком-либо файле конфигурации, а соединение защищено.
К сожалению, я не могу ответить на ваш вопрос о том, "есть ли рекомендуемая практика" в отношении FILESTREAM, однако я хотел бы предложить вам не избегать того, что вы хотите делать, просто потому, что вы также хотите избежать встроенной безопасности. ИМО вы должны использовать интегрированную безопасность независимо. Я бы посоветовал вам попробовать локальные пользователи в вашей ситуации. В конечном итоге домен будет лучше, чем локальные пользователи (он будет еще более безопасным и более простым в управлении), но я бы посоветовал интегрированную безопасность с локальными пользователями по-прежнему лучше, чем имена входа SQL Server.