Является ли использование интегрированной безопасности (SSPI) для доступа к SQL Server лучше для веб-приложений?

При развертывании веб-приложений (.net) в производственной среде лучше использовать встроенную защиту или это имеет значение?

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

Мысли?

Я бы сказал, что есть только две веские причины использовать аутентификацию SQL:

1. Вы подключаетесь из-за пределов домена, поэтому встроенная аутентификация.
2. Вы используете тест TPC-C, и каждый цикл считается. Аутентификация SQL немного быстрее.

Для сценария, который вы предлагаете (хост веб-сервера полностью скомпрометирован), ничто не может вас защитить. Хакер может сделать на сервере БД как минимум все, что может сделать веб-сервер . И я бы сказал, что глубокая защита может научить вас минимизировать потери в таком случае: уменьшить права на БД учетной записи, используемой веб-сервером, до абсолютно необходимого минимума и ничего более. Во-вторых, убедитесь, что если хост веб-сервера скомпрометирован, его нельзя использовать для повышения привилегий, превышающих учетную запись веб-сервера (т. Е. На хосте WWW нет другой службы, которая использует учетные данные с более высокими привилегиями в БД, чем учетная запись WWW). Это основные принципы безопасности, которые не имеют ничего общего с используемой схемой аутентификации.

Хотя аутентификация sql auth и windows auth не дает явного преимущества в вашем сценарии, есть и другие вопросы, которые следует учитывать:

1. Централизованное применение политик: у вас есть одно место для настройки политик паролей, включая срок действия и срок действия пароля, прекращение действия учетной записи и т. Д.
2. Контроль над олицетворением и делегирование доверия. После использования sql auth в цепочке доверительного делегирования все ставки отключаются, поскольку это не настоящее «делегирование» и, следовательно, больше не подпадает под ограничения, налагаемые вашей политикой
3. Аудит: sql auth даже не виден вашим LSA, поэтому вся ваша инфраструктура аудита просто обойдена. Вы должны явно добавить записи, которые SQL создает о событиях аутентификации sql, но смешивает яблоки и апельсины, так как эти события имеют различный источник, поставщика и схему в журнале событий.

И последнее замечание: протокол TDS раскрывает пароль аутентификации sql в виде открытого текста над трафиком, но это обычно смягчается запросом шифрования трафика SSL.

Так почему же вы видите все еще хосты sql auth WWW, которые хранят пароль в открытом виде в web.config? Это плохие разработчики / администраторы, не будьте одним из них.

msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx

technet.microsoft.com/en-us/library/ms189067.aspx

Если вы не используете SSPI, вы жестко запрограммировали имя пользователя и пароль в исходные файлы.

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

Это относительно небезопасно. Недовольный бывший сотрудник может использовать информацию злонамеренно. Посетитель может увидеть код где-то на экране. Или исходный код может случайно выйти в дикую природу.

Преимущество SSPI заключается в том, что пароль никогда не хранится в открытом виде.

Другие ответы до сих пор были хорошими, но я добавлю еще один: управление.

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

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

Кроме того, только то, что хакер может проникнуть на сервер, не означает, что игра окончена. Хакер может получить контроль над непривилегированным процессом, но ничего не делать на сервере. Вот почему важно не запускать все как администратор или систему, а вместо этого использовать учетные записи службы с минимальными привилегиями.

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

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

Давайте начнем с подражания машине. Если удостоверение пула приложений - «Сетевая служба» и в приложении .NET нет олицетворения, то да, веб-приложение будет подключаться к внутреннему SQL Server с использованием учетной записи компьютера компьютера. И это будет означать, что вы предоставили доступ к указанной учетной записи компьютера. Microsoft CRM работает таким образом.

Однако, если вы указали личность, этой учетной записи пользователя потребуется доступ к SQL Server. Хотя вы правы в том, что если злоумышленник скомпрометировал веб-сервер, он фактически имеет тот же доступ, что и учетная запись идентификатора, правда в том, что использование входа в SQL Server здесь ничего не меняет. Получив доступ, я могу изменить веб-приложение так, чтобы оно делало то, что я хочу, и оно будет таким, насколько это позволят ваши разрешения безопасности на внутреннем SQL Server.

Теперь о том, почему использовать SSPI. Прежде всего, вы не используете имя входа на основе SQL Server. Это означает, что Active Directory является единственным источником безопасности. Это означает, что у вас есть обычные средства аудита для определения недопустимого доступа. Во-вторых, это означает, что если другие приложения не требуют этого, вы можете оставить свой SQL Server в режиме проверки подлинности только Windows. Это означает, что вход в SQL Server не разрешен. Это означает, что любые атаки на sa прекращаются еще до их начала. И, наконец, это облегчает восстановление. Если вы используете учетную запись на основе SQL Server, вам нужно извлечь ее с помощью SID и зашифрованного пароля. Если вы используете учетную запись пользователя Windows в качестве «служебной учетной записи», когда вы переходите на новый SQL Server, создавая имя входа,

Вопрос в том, что "лучше"? На что сложно ответить, так как это зависит от контекста, ценностей и приоритетов спрашивающего.

Лично мне нравится аутентификация SQL.

• AD - это еще одна вещь для запуска, поддержки и управления учетными записями служб.
• AD должен быть доступен в вашей хостинговой среде.
• AD затруднит переход на облачное или гибридное облако.
• AD упрощает добавление учетных записей служб в группы, в которых не должны находиться администраторы в какой-либо другой части вашей организации.
• SSPI не обходит проблему шифрования строки подключения, поскольку вы должны зашифровать свое имя хоста SQL в config.
• SQL-аутентификация проста и просто текстовая конфигурация, легко развертываемая.
• Настройка идентификаторов пула приложений - это еще одна вещь для автоматизации, а затем скрытие имени пользователя и пароля в этих сценариях автоматизации для каждой среды.
• Использование двух строк подключения упрощает использование скользящих паролей, поэтому вы можете обновить пароль без простоев.

Последний пункт: вы кодируете свой класс диспетчера подключений, чтобы попробовать каждую строку подключения. Таким образом, вы можете изменить пароль для первого в конфигурации, отменить изменение, и оно переключится на второе подключение, затем вы обновите пароль на MSQL и первый будет использован снова. Окончательное изменение конфигурации необходимо для того, чтобы установить второй пароль, такой же, как первый, и готовый для следующего раза.

Если пользователи не будут манипулировать базой данных напрямую (с помощью других клиентских инструментов, таких как SQL Server Management Studio), я обычно просто создаю один логин SQL для приложения и предоставляю ему необходимый доступ. На этом этапе пользователь ограничен в том, что он может делать, что разрешено интерфейсом веб-приложения.