Это хорошая практика установить строки подключения в веб-конфигурации?

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

В этом нет существенной разницы, за исключением того, что вам придется создавать двоичный файл, если вы хотите внести изменения в конфигурацию, если вы поместите его в DLL, тогда как администратор может просто изменить конфигурацию с помощью хорошо понятных готовых инструментов. если это в конфиге. Уже есть механизм для шифрования строк конфигурации и дополнительные указания по MSDN . Текущие версии Asp.Net могут иметь альтернативные механизмы, поэтому проведите дополнительное исследование, прежде чем переходить к подходу.

То, что что-то находится в DLL, не делает его более безопасным. Текстовый редактор также может открывать двоичные файлы, такие инструменты, как Reflector, могут предоставить более удобный интерфейс для навигации по .Net DLL; DLL не обеспечит никакого «дополнительного» шифрования.

Не важно где хранятся зашифрованные данные, важно, как они зашифрованы.

Зашифрованные разделы в файле web.config обычно шифруются с помощью API защиты данных , который чрезвычайно трудно взломать без ущерба для всей машины. Вы также можете использовать контейнер с ключом RSA, который похож (сложно достать его из машины).

Если вы хотите сохранить зашифрованную строку в DLL, я думаю, это нормально, хотя она по своей природе не более безопасна, чем зашифрованная web.config (любой может заглянуть в эту DLL с Reflector ), и ее, очевидно, сложнее изменить (вы надо перекомпилировать). Но опять же, гораздо важнее то, как была сгенерирована эта зашифрованная строка; предположительно, вы не используете тех же провайдеров, что и для зашифрованного web.config, так что вы используете?

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

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

На самом деле я не могу вспомнить слишком много ситуаций, когда жесткое кодирование (зашифрованной) строки подключения в DLL более безопасно, чем шифрование соответствующего раздела web.config. В лучшем случае это просто добавляет неудобств, в худшем - полагается на какую-то неуклюжую пользовательскую защиту, пронизанную дырами. Сделайте себе одолжение и сделайте то, что рекомендует Microsoft - просто зашифруйте ваш web.config, если там есть конфиденциальные данные.

Лучшая практика для ASP.NET - поместить все конфигурации / настройки в файл web.config или файл app.config (для других типов проектов).

О шифровании и причинах его использования в строках соединения должен быть особый случай. Поскольку в большинстве случаев до 99% вам не нужно шифровать строки подключения. В корпоративных приложениях Microsoft строка подключения отображается в файле web.config / app.config. Я думаю, ты слишком усложняешь безопасность.

Еще одна вещь, жесткое программирование ваших строк подключения - плохая практика. Например, не помещайте какую-либо строку подключения (также называемую строкой подключения) в DLL или .aspx / .ascx / .cshtml или код-позади.