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

Question

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

Обычно я просто добавляю соответствующуюСтрока подключения к файлу Web.config:

<add name="MainDB" 
    connectionString="Server=localhost; Database=TopSecretData; User Id=Joe;
    password=password" providerName="System.Data.SqlClient" />

Но, очевидно, есть явный недостаток безопасности, если я оставлю свой идентификатор пользователя и пароль прямо в Web.config, особенно когда он находится под контролем источника.

Короче говоря: как я могу сохранить информацию о строке подключения, не открывая ее для общего доступа?

Answer 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();

Answer 2

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

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

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

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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