При развертывании веб-приложений (.net) в производственной среде лучше использовать встроенную защиту или это имеет значение?
Мне кажется, что если хакер взломает веб-сервер, это не будет иметь большого значения, поскольку они могут легко выдать себя за компьютер.
Мысли?
Ответы:
Я бы сказал, что есть только две веские причины использовать аутентификацию SQL:
Для сценария, который вы предлагаете (хост веб-сервера полностью скомпрометирован), ничто не может вас защитить. Хакер может сделать на сервере БД как минимум все, что может сделать веб-сервер . И я бы сказал, что глубокая защита может научить вас минимизировать потери в таком случае: уменьшить права на БД учетной записи, используемой веб-сервером, до абсолютно необходимого минимума и ничего более. Во-вторых, убедитесь, что если хост веб-сервера скомпрометирован, его нельзя использовать для повышения привилегий, превышающих учетную запись веб-сервера (т. Е. На хосте WWW нет другой службы, которая использует учетные данные с более высокими привилегиями в БД, чем учетная запись WWW). Это основные принципы безопасности, которые не имеют ничего общего с используемой схемой аутентификации.
Хотя аутентификация sql auth и windows auth не дает явного преимущества в вашем сценарии, есть и другие вопросы, которые следует учитывать:
И последнее замечание: протокол 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.
Последний пункт: вы кодируете свой класс диспетчера подключений, чтобы попробовать каждую строку подключения. Таким образом, вы можете изменить пароль для первого в конфигурации, отменить изменение, и оно переключится на второе подключение, затем вы обновите пароль на MSQL и первый будет использован снова. Окончательное изменение конфигурации необходимо для того, чтобы установить второй пароль, такой же, как первый, и готовый для следующего раза.
Если пользователи не будут манипулировать базой данных напрямую (с помощью других клиентских инструментов, таких как SQL Server Management Studio), я обычно просто создаю один логин SQL для приложения и предоставляю ему необходимый доступ. На этом этапе пользователь ограничен в том, что он может делать, что разрешено интерфейсом веб-приложения.