Шифрование Web.Config (Web.Release.config) Преобразование файлов с помощью aspnet_regiis

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

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

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

Попробуйте следующее, я только что привел пример защиты строки подключения. Замените тег, который вы хотите заменить, используя System.Configuration;

 ExeConfigurationFileMap configMap = new ExeConfigurationFileMap();
                configMap.ExeConfigFilename = modulePath + "Web.Release.config";
                System.Configuration.Configuration config = ConfigurationManager.OpenMappedExeConfiguration(configMap, ConfigurationUserLevel.None);
                System.Configuration.ConfigurationSection section = config.GetSection("connectionStrings");
                if (!section.SectionInformation.IsProtected)
                {
                                   section.SectionInformation.ProtectSection("RsaProtectedConfigurationProvider");
                    config.Save();
                }

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

Вариант 1. Вернуть зашифрованные файлы преобразований в систему управления версиями.

Создайте файл web.config и зашифруйте параметры приложения и строки подключения с помощью aspnet_regiis.exe. Затем в вашем преобразовании (например, web.release.config) для каждой среды используйте следующие значения:

<appSettings configProtectionProvider="ProviderName" xdt:Transform="Replace">
<EncryptedData>.....</EncryptedData
</appSettings>

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

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

Вариант 2. Используйте Transforms + Token Replace и Encrypt на месте на сервере

Для этого варианта вы должны использовать свои традиционные преобразования, но заменить все конфиденциальные данные токенами, такими как {{WebServicePassword}}. Замена токена — это обычная функциональность, существующая в большинстве средств развертывания. В этом случае вы должны создать переменную в своем инструменте развертывания (VSTS, UrbanCode и т. д.), которая имеет истинное значение {{WebServicePassword}}. Затем вам нужно будет настроить свое развертывание для замены токенов, и конкретные детали этого будут отличаться в зависимости от рассматриваемого инструмента развертывания. После развертывания файла запустите aspnet_regiis.exe удаленно на сервере, чтобы зашифровать файл web.config на месте.

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

Лично я предпочитаю вариант № 2, так как он позволяет вам видеть все ключи настроек приложения, и вы можете легко обрабатывать изменения ключей (не значений) с помощью запросов на включение/проверки кода. Имея дело с зашифрованными значениями appsettings/databaseconnections в системе управления версиями, вы понятия не имеете, действительно ли зашифрованное значение содержит ключи, необходимые вашему приложению.

Существует один способ шифрования конфиденциальной информации с помощью Protected Конфигурация, иначе вам нужно сохранить файл в любой папке внутри appdata и зашифровать его с помощью приложения

У меня есть требование не хранить конфиденциальную информацию (например, имена пользователей и пароли) в системе управления версиями.

Да, вы не должны, и один из способов добиться этого — использовать либо переменные среды, либо параметры конфигурации на уровне пользователя. По словам Майкрософт

В процессе разработки

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

Then you can do something like:

</connectionStrings>
   <appSettings file="relative\path\to\AppSettingsSecrets.config">          
   </appSettings>
  <system.web>

Что касается строк подключения

Вы можете использовать атрибут configSource, чтобы заменить всю разметку. В отличие от атрибута файла, который объединяет разметку, атрибут configSource заменяет разметку.

Во время развертывания

Вы можете перейти на портал управления Azure и установить их вручную в разделе Веб-приложения > ваше веб-приложение > Все настройки > Настройки приложения.

проверьте эта ссылка для дальнейшего ознакомления

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

Наша установка такая...

В проекте web.config есть все стандартные вещи для разработчиков. Включая любые настройки приложения для разработки, которые в производственной среде будут считаться частными. В нашем случае не имеет значения, что эти настройки зарегистрированы, поскольку они предназначены только для нашего внутреннего использования. Преобразования удаляют всю эту информацию при публикации.

Наши серверы сборки управляют «публикацией» и преобразованиями. Итак, что происходит: когда мы создаем для определенной конфигурации, это преобразование запускается и удаляет всю конфиденциальную информацию.

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

При первом развертывании человек, выполняющий развертывание, должен переименовать web.config.default в web.config и заполнить конфиденциальную информацию. Оттуда они могут выбрать, следует ли шифровать информацию.

Каждое последующее развертывание никогда не перезаписывает текущий web.config — оно только добавляет значения по умолчанию — человек, выполняющий развертывание, может добавлять или удалять любые новые/устаревшие элементы конфигурации.

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