Acceso a las cadenas de conexión a través de un servicio web

Question

La idea de almacenar cadenas de conexión en una base de datos es una idea perversa, pero por favor escúcheme primero. Todos sabemos que es una buena práctica cifrar las cadenas de conexión en el archivo web.config, pero ¿qué sucede si nos salteamos el archivo web.config por completo?

Hace un par de meses me pidieron que mover bases de datos de un servidor a otro. Esto significaba tener que actualizar las cadenas de conexión en cada programa que accedía a estas diversas bases de datos. Esta es la tercera vez en 2 años que tengo que mover las bases de datos de un servidor a otro. Así que pensé en almacenar cadenas de conexión en una base de datos y asignarle a cada una un GUID al que se debe acceder a través de un servicio web. En lugar de colocar cadenas de conexión en un web.config, solo necesitaría almacenar el GUID de la cadena de conexión en el archivo web.config, y hacer referencia al servicio web de la cadena de conexión para poder solicitar esa cadena de conexión. El cifrado se puede realizar en el nivel de la aplicación y las cadenas de conexión solo se almacenan cifradas en la base de datos.

He creado una prueba de concepto y funciona bien (es sólo en una intranet local y no expuesto a la Internet).

El beneficio es obvio para mí; como poder actualizar rápidamente las cadenas de conexión sin tener que tocar la aplicación web. Esto significa que puede crear una aplicación web solo para editar cadena de conexión en la base de datos, que un DBA podría usar allí mismo, para que nunca tenga que molestar a un programador cuando mueva bases de datos.

Pero el beneficio no es lo que me interesa. Estoy interesado en lo que todo el mundo aquí piensa en hacer algo como esto?

Answer 1

Tome sus cadenas de conexión fuera del web.config principal y los pusieron en un archivo de configuración distinto. Este archivo será el mismo para todas sus aplicaciones, de modo que si tienen que cambiar, solo tiene que copiar y pegar el mismo archivo en todas las carpetas de la aplicación en lugar de editar cada configuración por separado.

Answer 2

¿Qué sucede cuando su servicio web cambia de ubicación? Entonces, tendrías que actualizar todos los web.configs de todos modos.

¿Están sus aplicaciones en el mismo servidor o distribuidas en solo unos pocos servidores? Puede editar la máquina web.configs para incluir los strings de conexión DB para guardar una gran cantidad de repitition.

Answer 3

Tiendo a hacer una de dos cosas. Almacenaré las conexiones en Machine.Config, o crearé un nuevo nombre de host que solo se refiere al servidor de bases de datos. Luego puse un registro en el archivo de hosts.

El beneficio de esto es que nunca tenga que cambiar un archivo de configuración cuando muevo de mi local de la caja, a dev entornos de control de calidad o de producción.

Answer 4

Las principales desventajas que puedo ver son la penalización obvia de rendimiento (y si guarda en caché la cadena de conexión) y el único punto de falla que probablemente presente a todas sus aplicaciones (a menos que vaya a equilibrar la carga esto servicio, que parecería un exceso)

Answer 5

Pregunta muy interesante. Lo encontré porque tenía la misma idea.

Me parece muy similar a UDDI y le da otra capa de direccionamiento indirecto con posibles mejoras de seguridad & mantenimiento mejorado (excepto por el único punto de falla que puede resolver de todos modos).

Por supuesto que hay DNS que resolvería el problema de los nombres de host, pero con un servicio web que tiene posibilidades increíbles como volver a diferentes cadenas de conexión en función de quién lo pregunta (es decir, en función deCertificado SSL o usuario/pase o token, servicios de directorio como AD, LDAP, rol de usuario, etc. - el cielo es el límite :)

Además, todas las cadenas de conexión estarían debidamente protegidas y serían inaccesibles para miradas curiosas de usuarios curiosos.

Al principio, esta idea parece perversa, pero cuanto más pienso en ello, más estoy convencido de que una empresa de nivel empresarial podría beneficiarse mucho de la introducción de dicha solución.

Answer 6

Veo que no soy el único que ha tenido esta idea. Recientemente comencé a reflexionar sobre esto después de considerar el surtido de aplicaciones personalizadas y sitios de Intranet (sin importar las numerosas bases de datos y servidores). Me parece que el servicio WCF podría o debería escribirse de tal manera que devuelva la información de conexión de la base de datos de varias maneras: cadena de conexión, una conexión real o solo el servidor y el nombre de la base de datos. Además, es probable que el servicio mismo obtenga su información de una base de datos y una tabla auxiliares centrales que se pueden usar para administrar los diversos puntos de conexión. Por ejemplo: Dame la conexión, producción o desarrollo de la base de datos contables, etc.