Как лучше всего хранить строку подключения в .NET DLL?

В приложении, которое сейчас разрабатывает моя команда, есть библиотека DLL, которая используется для выполнения всех операций доступа к базе данных. Приложение не может использовать доверенное соединение, потому что база данных находится за брандмауэром, а сервер домена - нет. Таким образом, похоже, что строка подключения должна иметь имя пользователя и пароль БД. В настоящее время в DLL жестко запрограммирована строка подключения к базе данных, но я не хочу этого делать, когда мы запускаем, поскольку сборку можно разобрать, а имя пользователя и пароль будут прямо там, в открытом виде.

Одно из требований состоит в том, что пароль нужно менять раз в несколько месяцев, поэтому нам нужно будет распространить это на нашу внутреннюю базу пользователей.

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

ОБНОВЛЕНИЕ: Спасибо всем, кто ответил. Я попытаюсь ответить мне на некоторые вопросы ... DLL данных используется как ASP.NET WebForms, так и VB.NET WinForms. Я понимаю, что у приложений могут быть свои собственные файлы конфигурации, но я ничего не видел в файлах конфигурации для библиотек DLL. К сожалению, я не могу добраться до поста Джона Гэллоуэя на работе, поэтому не могу судить, сработает ли это. С точки зрения разработки, мы не хотим использовать веб-сервисы внутри компании, но, возможно, в следующем году предоставим их третьим сторонам. Я не думаю, что олицетворение сработает, потому что мы не можем аутентифицировать пользователя через брандмауэр. Поскольку пользователь (или бывший пользователь) может быть злоумышленником, мы скрываем это от всех!

Ответов (8)

Решение

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

Обновление: см. Сообщение Джона Гэллоуэя здесь.

Просто предположите, что злоумышленники БУДУТ получить учетные данные из вашего файла конфигурации. Это означает, что они смогут войти в вашу базу данных и делать все, на что способен этот пользователь. Поэтому просто убедитесь, что пользователь не может сделать ничего плохого, например, напрямую получить доступ к таблицам. Сделайте этого пользователя способным выполнять только определенные хранимые процедуры, и вы будете в лучшей форме. Это то место, где сияют звезды.

Если приложение является приложением ASP.NET, просто зашифруйте раздел строк подключения вашего файла web.config .

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

Просто мысли.

Обновлено: @ lassevk

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

Безопасность веб-службы была неявной. В зависимости от типа развертывания существует множество вариантов ... например, сертификаты на стороне клиента.

Вы хотите иметь возможность распространять DLL со всей информацией о настройке, находящейся в настраиваемом месте, но факт в том, что у вас не может быть одного из удобных файлов конфигурации .NET для DLL, если вы не сделаете что-то особенное.

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

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

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

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

Позвольте задать вопрос. От кого вы скрываете строку подключения? Пользователь или злоумышленник? А если пользователь, то почему?

.NET поддерживает шифрование таких значений конфигурации. Вы можете оставить его в файле конфигурации, но в зашифрованном виде.

Есть и другие идеи. Вы всегда можете использовать олицетворение. Также вы можете использовать корпоративную библиотеку (Common Library).

<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<enterpriseLibrary.ConfigurationSource selectedSource="Common">
<sources>
  <add name="Common" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    filePath="Config\Exception.config" />
</sources>

Несколько вариантов:

  1. Сохраните в web.config и зашифруйте
  2. Хранить в dll и запутывать (dotfuscator)
  3. Сохраните один в web.config (зашифрованный, конечно) и оставьте в базе данных (если вам нужно использовать несколько, и шифрование / дешифрование становится болью)