Encrypt Web.Config (Web.Release.config) Преобразование файлов с использованием aspnet_regiis
У меня есть требование не хранить конфиденциальную информацию (например, имена пользователей и пароли) в системе контроля версий. Мы создаем приложение.NET 4.5 MVC, поэтому я планировал зашифровать файл web.config с помощью aspnet_regiis.exe и встроенной функциональности ASP.NET. У меня нет проблем, чтобы заставить это работать здесь, но проблема, которую я имею, состоит в том, что я также хотел бы зашифровать преобразования (Web.Release.config и т. Д.), Потому что это также содержит конфиденциальную информацию. Я посмотрел вокруг и не видел никакого способа сделать это. Кто-нибудь знает способ сделать это?
7 ответов
Я смог выполнить эту работу, перейдя на каждую машину и зашифровав там файл web.config с правильной строкой подключения, а затем скопировав раздел только что зашифрованной строки подключения в соответствующее преобразование web.cong. Это огромная боль, но это работает.
Есть несколько способов справиться с этим в зависимости от ваших потребностей и разных типов доступа, который вы и ваша команда разработчиков имеете к серверам.
Вариант 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, и вы можете легко обрабатывать изменения ключей (не значений) с помощью запросов на просмотр / проверки кода. Имея дело с зашифрованными значениями appsettings / databaseconnections в управлении исходным кодом, вы не представляете, содержит ли зашифрованное значение ключи, необходимые вашему приложению.
Вы можете хранить ваш файл производственного преобразования в хранилище секретов, к которому имеет доступ только ваша ops-команда. Ваша система 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();
}
У меня есть требование не хранить конфиденциальную информацию (например, имена пользователей и пароли) в системе контроля версий.
Да, не следует, и один из способов сделать это - использовать переменные среды или параметры конфигурации на уровне пользователя. По данным Microsoft
Во время разработки
Элемент appSettings имеет атрибут file, который позволяет вам указать внешний файл, который содержит важные настройки приложения. Вы можете переместить все свои секреты во внешний файл, если внешний файл не включен в дерево исходных текстов.
Тогда вы можете сделать что-то вроде:
</connectionStrings>
<appSettings file="relative\path\to\AppSettingsSecrets.config">
</appSettings>
<system.web>Что касается connectionStrings
Вы можете использовать атрибут configSource для замены всей разметки. В отличие от атрибута файла, который объединяет разметку, атрибут configSource заменяет разметку.
Во время развертывания
Вы можете перейти на портал управления Azure и установить их вручную, в WebApps > в своем веб-приложении> Все настройки> Настройки приложения.
проверьте эту ссылку для дальнейшего использования
Существует один способ шифрования конфиденциальной информации с помощью защищенной конфигурации, в противном случае вам нужно сохранить файл в любой папке внутри appdata и зашифровать его с помощью приложения.
То, как я справляюсь с этим в моих проектах, заключается в том, что преобразования удаляют все строки подключения dev и значения любых безопасных настроек приложения и т. Д., Чтобы ими можно было управлять индивидуально в каждой среде.
Наша установка это...
В проекте web.config есть все, что нужно для разработки. Включая любые настройки приложения dev, которые в производственной среде будут считаться закрытыми. В нашем случае не имеет значения, что эти настройки зарегистрированы, поскольку они предназначены только для внутреннего использования. Преобразования удаляют всю эту информацию после публикации.
Наши сборочные серверы управляют "публикацией" и трансформациями. Итак, что происходит: когда мы строим для определенной Конфигурации, выполняется это преобразование, и оно удаляет всю конфиденциальную информацию.
Следующий шаг - сборка переименовывает web.config в web.config.default, Это позволяет нам предоставить файл конфигурации со всеми настройками по умолчанию, относящимися к этой сборке, но без конфиденциальных данных.
При первом развертывании это зависит от человека, который развертывает, чтобы переименовать web.config.default в web.config и заполните конфиденциальную информацию. Оттуда они могут выбрать, шифровать информацию или нет.
Каждое последующее развертывание никогда не перезаписывает текущее web.config - он только добавляет значения по умолчанию - только тот, кто выполняет развертывание, может добавить или удалить любые новые / устаревшие элементы конфигурации.
Кроме того, ручные шаги здесь также могут быть автоматизированы с помощью своего рода установщика...