Анонимный доступ (IIS) и SQL Server

Question

Я только что дал интервью в Редмонде, где мне задавали тонну вопросов безопасности, связанных с asp.net. Один из вопросов, которые они задавали, касался настройки приложения защищенной интрасети для использования ограниченного делегирования для доступа к SQL Server. В этом случае учетной записи пользователя AD делегирован доступ к SQL Server. Цель, конечно же, состоит в том, чтобы: а) нигде не хранить имя пользователя / пароль на веб-сервере (web.config) и б) предоставить абстрактную модель безопасности, которой можно управлять в Active Directory.

Это заставило меня задуматься о том, как я все эти годы настраивал свои сайты для анонимного доступа. Обычно я запускаю свои веб-сайты IIS с использованием анонимной учетной записи по умолчанию и сохраняю строку подключения в файле web.config (в зашифрованном виде, а иногда и в виде открытого текста). Это, конечно, требует, чтобы ваш SQL Server работал в смешанном режиме. Итак, мой вопрос: что если мы вообще не сохранили строку подключения в web.config, а просто создали уникальную учетную запись анонимного домена для конкретного веб-сайта, который имел бы доступ db_datareader в SQL Server? Есть ли какая-то причина, почему это было бы плохой идеей?

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

Кто-нибудь знает лучшую практику здесь?

Answer 1

Возможно, вы могли бы использовать ODBC для создания DSN для соединения с SQL Server. Тогда ваш web.config должен знать только DSN. Это может потребовать от вас использовать System.Data.OleDb. Я никогда не видел DSN, используемый в ASP.NET, но он был довольно стандартным для Classic ASP. И я никогда не слышал об Active Directory, который используется для управления ODBC.

Answer 2

Где я работаю, у нас есть служба Windows, которая работает под определенной учетной записью домена. Эта учетная запись настроена в SQL Server как логин, и у нее есть соответствующий пользователь в базе данных, к которой ему необходим доступ. У нас никогда не было проблем с этим.

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

Я рассмотрел вопрос об использовании AD для управления доступом к SQL аналогичным образом, который вы описали в первом абзаце. (Группа AD -> Вход в SQL Server -> Пользователь БД -> Объекты БД) Единственный недостаток, который я вижу до сих пор, заключается в том, что если пользователь подключен напрямую к базе данных, он будет обходить любую логику, имеющуюся в вашем приложении. Одним из преимуществ является то, что вы знаете, какие пользователи домена обращаются к вашей базе данных.