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

Ответ 1

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

Ответ 2

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

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

Ответ 3

Попробуйте следовать, я только что привел пример защиты строки подключения. Замените тег, который вы хотите заменить  используя 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();
                }

Ответ 4

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

Ответ 5

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

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

Во время разработки

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

Затем вы можете сделать что-то вроде:

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

Ответ 6

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

Наша настройка - это...

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

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

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

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

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

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

Ответ 7

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

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

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

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

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

Проблема: Если у вас несколько проектов/проектов, можно легко пропустить новое значение appsetting, и вы не узнаете, пока его развернутый

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

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

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

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