c# - studio - Encriptar Web.Config(Web.Release.config) Transformar archivos usando aspnet_regiis
web.config transform (7)
Tengo el requisito de no almacenar ninguna información sensible (por ejemplo, nombres de usuario y contraseñas) en el control de código fuente.
Sí, no debería hacerlo, y una forma de lograrlo es mediante el uso de Variables de entorno o opciones de configuración de nivel de usuario. De acuerdo con Microsoft
Durante el desarrollo
El elemento appSettings tiene un atributo de archivo que le permite especificar un archivo externo que contiene configuraciones confidenciales de configuración de la aplicación. Puede mover todos sus secretos a un archivo externo siempre que el archivo externo no esté registrado en su árbol fuente.
Entonces puedes hacer algo como:
</connectionStrings>
<appSettings file="relative/path/to/AppSettingsSecrets.config">
</appSettings>
<system.web>
En cuanto a connectionStrings
Puede usar el atributo configSource para reemplazar el marcado completo. A diferencia del atributo de archivo que combina el marcado, el atributo configSource reemplaza el marcado.
Durante la implementación
Puede ir al Portal de administración de Azure y configurarlo manualmente, en Aplicaciones web> su aplicación web> Todas las configuraciones> Configuración de la aplicación
revisa this enlace para mayor referencia
Tengo el requisito de no almacenar ninguna información sensible (por ejemplo, nombres de usuario y contraseñas) en el control de código fuente. Estamos haciendo una aplicación .NET 4.5 MVC, así que mi plan era encriptar el web.config usando aspnet_regiis.exe y la funcionalidad incorporada de ASP.NET. No tengo problemas para hacer que esto funcione aquí, pero el problema que estoy teniendo es que también me gustaría encriptar las transformaciones (Web.Release.config, etc.) porque eso también contiene la información confidencial. He mirado alrededor y no he visto ninguna manera de hacer esto. ¿Alguien sabe una manera de lograr esto?
Hay dos maneras diferentes de manejar esto dependiendo de sus necesidades y los diferentes tipos de acceso que usted y su equipo de desarrollo tienen para los servidores.
Opción 1. Verificar en archivos de transformaciones cifradas en el control de fuente.
Crea tu web.config y encripta los appsettings y connectionstrings usando aspnet_regiis.exe. Luego, en su transformación (por ejemplo, web.release.config) para cada entorno, use los siguientes valores:
<appSettings configProtectionProvider="ProviderName" xdt:Transform="Replace">
<EncryptedData>.....</EncryptedData
</appSettings>
Si está usando diferentes proveedores en cada entorno (debería estarlo), entonces tendrá que hacer el cifrado para cada entorno.
Problema: si tiene varios desarrolladores / proyectos en marcha, puede ser fácil pasar por alto un nuevo valor de aplicación y no lo sabrá hasta que se implemente
Opción 2. Usar Transformaciones + reemplazo de tokens y cifrar en el lugar en el servidor
Para esta opción, usaría sus transformaciones tradicionales, pero reemplazará todos los datos confidenciales con tokens, como {{WebServicePassword}}. El reemplazo de tokens es una funcionalidad común que existe en la mayoría de las herramientas de implementación. En este caso, crearía una variable en su herramienta de implementación (VSTS, UrbanCode, etc.) que tiene el valor real de {{WebServicePassword}}. Luego, necesitaría configurar su implementación para hacer un reemplazo simbólico y los detalles específicos de esto diferirían según la herramienta de implementación en cuestión. Una vez que se implementa el archivo, ejecute aspnet_regiis.exe de forma remota en el servidor para cifrar el archivo web.config en su lugar.
Problema: el archivo no cifrado permanecerá en el servidor durante un breve momento antes de cifrarse. Dependiendo de su situación, esto puede o no ser un problema.
Personalmente prefiero la opción n. ° 2, ya que le permite ver todas las teclas de aplicación y puede manejar fácilmente los cambios a las claves (no a los valores) a través de solicitudes de extracción / revisiones de código. Al tratar con los valores de appsettings / databaseconnections cifrados en el control de código fuente, no tiene idea si el valor cifrado realmente contiene las claves que necesita su aplicación.
Hay una forma de encriptar información confidencial mediante la configuración protegida, de lo contrario, debe mantener el archivo en cualquier carpeta dentro de la aplicación y encriptarlo mediante la aplicación.
Intenta seguir, acabo de dar el ejemplo de proteger la cadena de conexión. Reemplace la etiqueta que desea reemplazar utilizando 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();
}
La forma en que manejo esto en mis proyectos es que las transformaciones eliminan todas las cadenas de conexión de desarrollo y los valores de cualquier configuración de aplicación segura, etc ... para que se puedan gestionar individualmente en cada entorno.
Nuestra configuración es esta ...
El proyecto web.config tiene todos los elementos de desarrollo comunes. Incluyendo cualquier configuración de aplicación de desarrollo que en un entorno de producción se considere privada. En nuestro caso, no importa que estas configuraciones estén registradas ya que son solo para nuestro uso interno. Las transformaciones eliminan toda esa información al publicar.
Nuestros servidores de compilación administran "publicar" y transforma. Entonces, lo que ocurre es que cuando construimos para una Configuración específica, esa transformación se ejecuta y elimina toda la información confidencial.
El siguiente paso es que la construcción cambie el nombre de web.config a web.config.default . Esto nos permite proporcionar un archivo de configuración que tiene todas las configuraciones predeterminadas en él que son específicas de esa compilación pero sin los datos confidenciales.
En la primera implementación, depende de la persona que realiza la implementación cambiar el nombre de web.config.default a web.config y completar la información confidencial. Desde allí pueden elegir si cifrar o no la información.
Cada implementación posterior nunca sobrescribe el web.config actual - solo agrega los valores predeterminados - le corresponde a la persona que realiza la implementación agregar o quitar cualquier elemento de configuración nuevo / en desuso.
Además, los pasos manuales aquí también podrían automatizarse utilizando algún tipo de instalador ...
La forma en que pude hacer esto fue yendo a cada máquina y encriptando la web.config allí con la cadena de conexión correcta y luego copiando la sección de la nueva cadena de conexión encriptada en la transformación web.cong apropiada. Es un gran dolor, pero funciona.
Puede mantener su archivo de transformación de producción en un repositorio de secretos al que solo puede acceder su equipo de operaciones. Su sistema de CI haría referencia a ambos repositorios y copiará el archivo de transformación de su repositorio de secretos a su directorio de compilación y compilará como lo hace ahora.
Esto eliminaría cualquier valor de configuración sensible de su repositorio principal y aún le permitiría aprovechar las capacidades de transformación.