При развертывании веб-приложений (.net) в производственной среде лучше использовать интегрированную безопасность, или это вообще не имеет значения?
Мне кажется, что, если хакер сломает веб-сервер, это не будет иметь значения, поскольку он может легко выдать себя за пользователя. Как вы думаете?
Ответ 1
Я бы сказал, что есть только две веские причины для использования SQL auth:
Вы подключаетесь из-за пределов домена, поэтому применяется интегрированный аутентификатор.
Вы выполняете бенчмарк TPC-C, и каждый цикл имеет значение. SQL-авторизация немного быстрее.
Для сценария, который вы предлагаете (хост веб-сервера полностью взломан), ничто не может защитить вас. Хакер может сделать на сервере БД как минимум все, что может сделать веб-сервер. И я бы сказал, что защита в глубину может научить вас минимизировать потери. В таком случае: уменьшите права на БД учетной записи, используемой веб-сервером ur, до абсолютно необходимого минимума и не более того. Во-вторых, убедитесь, что, если хост веб-сервера скомпрометирован, он не может быть использован для повышения привилегий выше, чем учетная запись веб-сервера (т. е. на WWW-хосте нет другой службы, которая использует учетные данные с более высокими привилегиями в БД, чем учетная запись WWW). Это основные принципы безопасности, не имеющие ничего общего с используемой схемой аутентификации.
Хотя в вашем сценарии sql auth против windows auth не дает ни тому ни другому явного преимущества, есть и другие вопросы, которые следует рассмотреть:
Централизованное применение политик: у вас есть одно место для настройки политик паролей, включая время жизни и истечения срока действия пароля, прекращение действия учетной записи и т. д.
Контроль над имперсонацией и делегированием доверия. Как только sql auth используется в цепочке делегирования доверия, все ставки сделаны, поскольку это не настоящее «делегирование» и, следовательно, больше не подпадает под ограничения, налагаемые вашими политиками.
Аудит: sql auth даже не виден вашим LSA, поэтому вся ваша инфраструктура аудита просто обходится стороной. Вам нужно явно добавить записи, которые производит SQL, о событиях sql auth, но это некорректно, поскольку данные события имеют разный источник, провайдера и схему в журнале событий.
И последнее замечание: протокол TDS раскрывает пароль sql auth открытым текстом по трафику, но это обычно смягчается запросом SSL шифрования трафика.
Так почему же вы все еще видите sql auth WWW хосты, которые хранят пароль в открытом виде в web.config?
Ответ 2
Я не уверен на 100%, но думаю, что суть в том, что SQL auth небезопасен, поэтому лучше использовать Windows auth. В зависимости от того, как настроено ваше приложение, вы также можете хранить соответствующие учетные данные в зашифрованном виде на машине, используя Windows auth. Я не думаю, что это действительно возможно с SQL auth. Вы можете замаскировать его, но в конечном итоге он должен быть в открытом виде. Кроме того, если хакер может проникнуть на сервер, это не значит, что игра окончена. Хакер может получить контроль над непривилегированным процессом, но не сделать ничего другого на сервере. Вот почему важно не запускать все от имени администратора или системы, а использовать служебные учетные записи с минимальными привилегиями.
Ответ 3
Прежде всего, я хочу сказать, что исхожу из предположения, что речь идет о внутреннем веб-сервере во внутренней частной сети.
Давайте начнем с имперсонификации машины. Если идентификатором пула приложений является Network Service, а в приложении .NET нет имперсонализации, то да, веб-приложение подключится к внутреннему SQL Server, используя учетную запись компьютера машины. И это означает, что вы предоставили доступ к этой учетной записи компьютера. CRM от Microsoft работает именно так.
Однако, если вы указали идентификатор, этой учетной записи пользователя потребуется доступ к SQL Server. Хотя вы правы в том, что, если злоумышленник скомпрометирует веб-сервер, он получит тот же доступ, что и учетная запись, правда в том, что использование входа в SQL Server ничего не меняет. Получив доступ, я могу модифицировать веб-приложение так, чтобы оно делало то, что я хочу, и оно будет делать это, насколько позволяет ваша безопасность на внутреннем SQL-сервере.
Теперь о том, зачем использовать SSPI. Прежде всего, вы не используете логин на базе SQL Server. Это означает, что Active Directory является единственным источником безопасности. Это означает, что у вас есть обычные средства аудита для определения недействительного доступа. Во-вторых, это означает, что, если нет других приложений, которые требуют этого, вы можете оставить SQL Server в режиме аутентификации только Windows. Это означает, что вход в SQL Server запрещен. Это означает, что любые атаки на sa будут остановлены еще до того, как они начнутся. И, наконец, это упрощает восстановление. Если вы используете логин на базе SQL Server, вам нужно будет извлечь логин с SID и зашифрованным паролем. Если вы используете учетную запись пользователя на базе Windows в качестве «служебной учетной записи», то при переходе на новый SQL Server, создав логин, все будет переподключено после восстановления базы данных, поскольку SID будут совпадать между логином и пользователем базы данных.
Ответ 4
Вопрос в том, что «лучше»? На этот вопрос трудно ответить, поскольку он зависит от контекста, ценностей и приоритетов вопрошающего. Лично мне нравится SQL auth.
AD – это еще одна вещь, которую нужно запускать, поддерживать и управлять учетными записями служб.
AD должен быть доступен в вашей среде хостинга.
AD затрудняет переход в облако или гибридное облако.
AD позволяет легко добавлять служебные учетные записи в группы, в которых они не должны находиться, администраторами из другой части вашей организации.
SSPI не обходит проблему шифрования строки подключения, поскольку вы должны шифровать имя хоста SQL в конфигурации.
SQL auth прост и представляет собой просто текстовую конфигурацию, которую легко развернуть.
Установка идентификаторов App Pool – это еще одна вещь, которую можно автоматизировать, а затем скрыть имя пользователя и пароль в этих сценариях автоматизации для каждой среды.
Использование двух строк подключения упрощает использование паролей, поэтому вы можете обновлять пароль без простоя.
Последний момент: вы кодируете класс менеджера соединений, чтобы попробовать каждую строку соединения, таким образом, вы можете изменить пароль на первом соединении в конфигурации, вытолкнуть изменение, и оно перейдет на второе соединение, затем вы обновите пароль на MySQL, и первое соединение будет использоваться снова. Последнее изменение конфигурации необходимо для того, чтобы установить второй пароль таким же, как и первый, готовый к следующему разу.
Ответ 5
Другие ответы были хороши, но я добавлю еще один: управление.
Рано или поздно вы, вероятно, столкнетесь с несколькими SQL-серверами. Управление аутентификацией SQL между вашим приложением и несколькими серверами SQL становится немного болезненным, особенно когда вы сталкиваетесь с проблемами безопасности. Если вы один раз измените пароль аутентификации Windows, он сразу же изменится на всех ваших серверах. Если вам нужно менять пароли аутентификации SQL, это еще более болезненно – до такой степени, что вы, вероятно, вообще не будете этого делать. Это риск для безопасности.
Security