Интегрированная защита SQL Server без домена
Этот вопрос потенциально находится где-нибудь между ServerFault и Администраторами DBA, но Доменным элементом этого, как ведется меня поместить его здесь.
Мы разрабатывали продукт SOA и думаем о различных сценариях развертывания для наших серверов, которыми управляют, в офисе клиента. Триггер для этого вопроса был дискуссией об использовании SQL Server FILESTREAM, который требует интегрированной защиты
Логины SQL не будут работать с контейнерами FILESTREAM. Только аутентификация NTFS будет работать с контейнерами FILESTREAM. FILESTREAM MSDN
В данный момент FILESTREAM является единственной причиной, которую мы имеем для использования Интегрированной защиты, которая делает потенциальное требование для развертывания Контроллеров домена (и их требования дублирования) к непривлекательным серверам менеджера.
Я взглянул вокруг и существует несколько вопросов, предполагающих, что можно использовать РАБОЧИЕ ГРУППЫ с Интегрированной защитой.
Интегрированная защита (SSID?) в без доменов...
Мой вопрос, там методические рекомендации для сценария, описанного выше? Мы должны дать безопасности РАБОЧЕЙ ГРУППЫ движение и видеть, как мы преуспеваем или есть ли причина, это - большое нет не, и мы должны или использовать домен или не использовать FILESTREAM?
В общем, встроенная безопасность (также известная как надежное соединение)более безопасен, чем логины SQL, и предпочтительнее. Причина в том, что службы, которые должны подключаться к SQL Server, не нуждаются в жестко закодированных именах пользователей и паролях; они могут просто работать с пользователем, имеющим разрешения на доступ к SQL Server.
Для использования интегрированной безопасности домен не требуется. Если вы управляете множеством машин, предпочтительнее использовать домен, но с небольшим количеством серверов вы можете просто использовать локальных пользователей на каждом сервере. Уловка заключается в том, что у всех совместно используемых пользователей должны быть одинаковые имя пользователя и пароль на каждом сервере, который обращается к данным SQL. Например, предположим, что у вас есть веб-сервер IIS на одном компьютере и SQL Server на другом. Вы должны создать пользователя с одним и тем же именем пользователя и паролем как на компьютере с веб-сервером, так и на компьютере с SQL Server, возможно, с именем «IISUser». Затем в SQL Server вы должны назначить соответствующие разрешения этому пользователю, а на веб-сервере вы должны настроить пул приложений IIS для работы с тем же пользователем. Поскольку здесь используется интегрированная безопасность, имя пользователя и пароль не нужно записывать или хранить в каком-либо файле конфигурации, а соединение является безопасным.
К сожалению, я не могу ответить на ваш вопрос о «есть ли рекомендуемые методы» в отношении FILESTREAM, однако я предложит вам не избегать того, что вы хотите делать, просто потому, что вы также хотите избежать интегрированной безопасности. ИМО, вы должны использовать интегрированную безопасность в любом случае. Я бы посоветовал вам попробовать местных пользователей в вашей ситуации. В конечном счете, домен будет лучше, чем локальные пользователи (он будет еще более безопасным и простым в управлении), но я считаю, что интегрированная безопасность с локальными пользователями все же лучше, чем вход в SQL Server.