Práctica recomendada de implementación de cadenas de conexión ASP.NET

Question

He recopilado un resumen (afortunadamente útil) de las formas en que he investigado para lograr el objetivo de esta publicación, así como los problemas que tengo con ellos. Dígame si ha encontrado otras maneras que le gusten más, especialmente si resuelven los problemas que los métodos que menciono no lo hacen.

1. Dejar las cadenas de conexión en web.config y utilizan la transformación TXD/MSDeploy para reemplazarlos con los ajustes de acuerdo a mi configuración de generación activa (por ejemplo, un archivo web.PublicTest.config). Mi problema con esto es fusionar y enterrar algunas configuraciones específicas del servidor en un archivo por lo demás globalmente idéntico con muchos elementos de configuración. Además, no puedo compartir definiciones de cadenas de conexión entre varias aplicaciones de nivel de igual.

2. Especifique un valor de configSource = "DeveloperLocalConnectionStrings.config" para las cadenas de conexión en web.config, y XDT transformará este valor para apuntar a uno de los múltiples archivos específicos del entorno en mi base de código. Mi problema con esto es que envío contraseñas para todos mis entornos a todos los destinos (además de SVN, por supuesto) y tengo secciones de configuración no utilizadas ubicadas en servidores que esperan ser utilizados accidentalmente.

3. Cadenas de conexión específicas en el archivo machine.config en lugar de web.config. Problema: quién diablos espera encontrar las cadenas de conexión en machine.config, y la probabilidad de colisiones sorpresa de nombres como resultado es alta.

4. Especifique un configSource = "LocalConnectionStrings.config", no transforme el valor y edite el xml del proyecto para excluir el despliegue de la configuración de la cadena de conexión. http://msdn.microsoft.com/en-us/library/ee942158.aspx#can_i_exclude_specific_files_or_folders_from_deployment - Es la mejor solución que he encontrado para hacer frente a mis necesidades de una aplicación web patentada (no distribuida), pero estoy paranoico, otro miembro del equipo vendrá un día y copiará el sitio de producción para probar por alguna razón, y listo ! La base de datos de producción ahora se está modificando durante UAT. (Actualización: descubrí que no puedo usar la publicación con un clic en este escenario, solo la línea de comando msdeploy con el parámetro -skip. Excluir un archivo como el anterior es lo mismo que configurarlo en "No" compilar acción en lugar de " Contenido ", y da como resultado que el paquete lo elimine del destino de implementación.)

5. Cablee el paquete de implementación para solicitar una cadena de conexión si aún no está configurado (todavía no sé cómo hacerlo) pero entiendo que es posible). Esto tendrá resultados similares al # 4 anterior.

6. Especifique un configSource = ".. \ ConnectionStrings.config". Sería genial para mis necesidades, ya que podría compartir la configuración entre las aplicaciones que elija, y no habría nada específico de la máquina en mi directorio de aplicaciones. Desafortunadamente, las rutas padre no están permitidas en este atributo (como en el caso de 'appSettings file =' ''); tenga en cuenta también que puede usar spiffily file = dentro de un configSource = referencia).

p.s. Algunas de estas soluciones se discuten aquí: ASP.Net configuration file -> Connection strings for multiple developers and deployment servers

Answer 1

1. Utilice el nombre de host como clave para el connectionstring, de esa manera se puede elegir la fuente de datos automágicamente. Asegúrese de que la rutina de elección no tenga errores (cambie el nombre de host - ¡pruebe!) ...

2. No lo coloque en el archivo web.config, escriba un archivo ini, de esta forma no hay codificación XML.

3. Encripte la contraseña allí, con la clave privada/pública (RSA/PGP). Nunca use texto simple, o una clave simétrica, que es igual de mala.

Answer 2

comprobar mi siguiente entrada en el blog: Protecting asp.net machine keys and connection strings

Si utiliza la respuesta de dilema, utilizar una clave que no está en la carpeta del sitio, al igual que lo hace con asp.net secciones de configuración protegidos.

Aprobamos manualmente los cambios en el archivo web.config que va a la puesta en escena/producción. Usamos una base de datos integrada en vez de un nombre de usuario cuando es posible, pero una opción que hemos utilizado en el caso posterior es simplemente tener marcadores de posición para el nombre de usuario/contraseñas en SVN.

Hemos utilizado archivos de configuración por separado en el pasado, pero nos hemos encontrado con otro tipo de problemas con las modificaciones de web.config, por lo que hemos estado bloqueándolo en un solo archivo últimamente.

Answer 3

Al usar SQL Server, también puede usar Integrated Security/SSPI y agregar el inicio de sesión del equipo WebServer al servidor Sql.

De esta manera no tiene que exponer nada en la web.config y puede otorgarle roles a ese inicio de sesión como lo haría con cualquier otro usuario de la base de datos.

Aunque debe comprender las implicaciones y las consideraciones de seguridad que deben tomarse, ya que cualquier código malicioso ejecutado como esa máquina tendrá acceso al servidor Sql.

con respecto Ole