Типичный подход к аутентификации SQL Server для сервера приложений с выходом в Интернет

Question

Я работаю над выходящим в Интернет продуктом на базе ASP.NET, который использует SQL Server 2005. Большинство клиентов развертывают наше программное обеспечение, используя традиционный подход с сервером приложений (IIS), расположенным в DMZ, и SQL Server за вторичным брандмауэр.

Мы хотели бы выбрать один тип аутентификации SQL Server. Что с точки зрения безопасности и / или с точки зрения клиента, что предпочтительнее для интегрированной или SQL Server аутентификации?

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

Спасибо, Скотт

Answer 1

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

Если вы собираетесь передать это клиентам для установки, я бы, вероятно, пошел с аутентификацией sql, поскольку для этого не потребуется другая система для аутентификации пользователя (например, активный каталог).

Митчел замечательно говорит о том, что позволяет клиентам настраивать его. Я видел места, где проверка подлинности SQL прямо запрещена, и другие (например, где я сейчас работаю), где использование учетных записей Active Directory невозможно.

Answer 2

Проверка подлинности Windows более безопасна, чем проверка подлинности SQL, однако, если веб-сервер находится в демилитаризованной зоне, он, вероятно, не является частью домена Windows, и потребуется проверка подлинности SQL.

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

Answer 3

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

Answer 4

Работая в среде, где вы предоставляете продукт пользователям, я бы оставил это на их усмотрение в отношении того, как они конфигурируют соединение. Интегрированная безопасность и предоставление рабочего процесса ASP.NET обычно называют более безопасным маршрутом, однако в некоторых средах есть ограничения на делегирование, которые не позволяют его.

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

Answer 5

Возможно, вы захотите создать пользователя / имя входа в серверной части сервера sql с ограниченным набором прав, скажем «WebUser», для строки подключения в веб-конфигурации. Убедитесь, что вы не предоставляете право DDL этому пользователю (если этого не требует ваше приложение).

Но если вы на 100% уверены, что все пользователи будут пользователями Windows (частью домена Windows), то для вашей аутентификации SQL Server на «Аутентификация Windows» это самый безопасный способ сделать это, поскольку этот режим аутентификации унаследует политики домена и его пользователей (привилегии, роли и т. д.).