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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лично мне нравится SQL auth.

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

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

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