Как я могу безопасно хранить и получать сведения о строках подключения?

Ответ 1

Лучшей практикой является шифрование раздела строк подключения. Используйте aspnet_regiis.exe, который можно найти в разных местах:

• Начало - Visual Studio - Инструменты Visual Studio - Командная строка Visual Studio
• C:\Windows\Microsoft.NET\Framework\v4.0.30319 (убедитесь, что вы запустили его как администратора)

До:

<configuration>
<connectionStrings>
<add name="MainConnectionString" 
 connectionString="data source=Ratbert;database=Sales;username=ASPNET;password=$Double_Rainbow2011" 
 providerName="System.Data.SqlClient"/>
</connectionStrings>
</configuration>

Запустите эту команду:

aspnet_regiis –pef connectionStrings c:\PathToWebSite

Или, если приведенная выше команда не работает (и вы получите текст справки aspnet_regiis), попробуйте

aspnet_regiis -pe connectionStrings -app "/" -site 6

где "6" - это идентификатор сайта, как указано в IIS.

После:

<connectionStrings configProtectionProvider="RsaProtectedConfigurationProvider">
  <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
   xmlns="http://www.w3.org/2001/04/xmlenc#">
   <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
   <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
     <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
     <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      <KeyName>Rsa Key</KeyName>
     </KeyInfo>
     <CipherData>
      <CipherValue>Bf677iFrUFW ... +4n4ZZKXCTUAu2Y=</CipherValue>
     </CipherData>
    </EncryptedKey>
   </KeyInfo>
   <CipherData>
    <CipherValue>UDEZ ...QfXUmM5rQ==</CipherValue>
   </CipherData>
  </EncryptedData>
 </connectionStrings>

Теперь, когда он искажен, вы не можете его редактировать. Расшифруйте вот так:

aspnet_regiis –pdf connectionStrings c:\PathToWebSite

или

aspnet_regiis -pd connectionStrings -app "/" -site 6

И затем измените и заново зашифруйте.

Чтобы прочитать строку подключения, используйте статический класс ConfigurationManager.

string connStr = 
ConfigurationManager
.Connectionstrings["MainConnectionString"]
.ConnectionString.ToString();

var myConnection = new SqlConnection(connStr);

myConnection.Open();

Ответ 2

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

например. БД, такие как MySQL, позволяют указать, какие серверы имеют к нему доступ, ограничивать доступ из любого места - так что хакер не может попасть в вашу БД, кроме как с веб-сервера. Это значительно снижает уровень безопасности и позволяет хранить ваши строковые файлы в SCM.

Он по-прежнему не на 100% безопасен, так как хакер может (часто легко) взломать ваш веб-сервер и просмотреть его. Вы можете сохранить пароль в другом месте, но это просто затеняет проблему - если веб-сервер может получить доступ к паролю, ваш хакер тоже может. (обратите внимание, что в других местах для хранения пароля есть реестр, отдельный файл, такой как .udl файл или что-то в /etc ). Вы можете защитить этот файл, чтобы только пользователь веб-сервера мог его прочитать, но взломанный веб-сервер, очевидно, может его прочитать!

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

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

Это подход, который мы использовали для системы высокой безопасности (гораздо больше вы можете сделать, чтобы защитить каждый сегмент этой цепи, используя стандартные механизмы безопасности ОС). Причины для этого стали для нас очень ясными, как только наш глава безопасности продемонстрировал взлом IIS, который дал ему удалённую оболочку с привилегиями администратора. Что бы вы ни делали, чтобы защитить свои конфиги на веб-сервере, бессмысленно, если хакер получит это. (и это было тривиально легко сделать - поскольку исправлено, но есть 0-дневные эксплойты, которые все время обнаруживаются)

Ответ 3

Возможно, вы захотите зашифровать строку подключения: http://chiragrdarji.wordpress.com/2008/08/11/how-to-encrypt-connection-string-in-webconfig/ (статья немного устарела)

Ответ 4

Общие подходы включают шифрование web.config и сохранение строк подключения в реестре.

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

Ответ 5

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