¿Cuál es la mejor manera de centralizar y asegurar las cadenas de conexión?

Question

¿Cuál es la mejor manera de centralizar y asegurar las cadenas de conexión utilizadas por las aplicaciones? En mi entorno tenemos muchas aplicaciones internas. Cada aplicación requiere una o más cadenas de conexión para acceder a la base de datos. Tenemos el objetivo de centralizar todas estas cadenas de conexión (particularmente los inicios de sesión y contraseñas de SQL) para que podamos cambiar las contraseñas en un lugar en lugar de en 35 archivos .config, entradas de registro, etc. diferentes

Actualmente estamos utilizando un componente de producción propia que extrae la información de la cadena de conexión de una base de datos de acceso, esto cubre el requisito de centralización pero no es particularmente seguro. Además, tenemos aplicaciones escritas en lenguajes de asp clásico, vb6, delphi, c ++, .net, por lo que la solución debería ser utilizable por todas esas aplicaciones.

¿Alguien tiene una idea de cómo hacer esto mejor, o necesitamos reelaborar todo nuestro enfoque sobre la forma en que nuestras aplicaciones acceden a la base de datos?

Answer 1

Puede usar el servidor de Windows para crear usuarios que tengan acceso a su base de datos de SQL Server. Luego puede usar el inicio de sesión integrado de Windows en las cadenas de conexión.

Por cierto, almacenar contraseñas en MDB público las vuelve irrelevantes. Igual que no existen.

Answer 2

La compañía para la que trabajo ha utilizado una situación similar a través de una base de datos de SQL Server. Terminamos creando un .net dll compatible con COM para simplificar y asegurar la API en la base de datos y garantizar que se use la misma lógica entre los paquetes clásicos asp, .Net y DTS. Ha funcionado muy bien para nosotros durante un año y, aunque hay algunos elementos de refactorización que a muchos de nosotros nos gustaría hacer con él, ha sido excelente abordar problemas como migraciones de servidor o cambios de nombre.

Creo que estás en el camino correcto; sin embargo, recomendaría los siguientes cambios:

• Intente pasar a un verdadero servidor de base de datos. El acceso es excelente para MS Office pero no para algo de esta escala.
• Cree una consola administrativa que permita auditar quién está agregando y editando información (asegure quién tiene acceso a qué configuración también).
• Cree una DLL compatible con COM para que otros sistemas puedan consumirla de manera segura y coherente.

EDITAR:

Algo que he notado después de años de trabajo en un sistema como este es que ata sus manos ligeramente en algunas soluciones. Muchas herramientas (por ejemplo, nHibernate, Elmah, etc. en el mundo .Net) realmente están limitadas cuando la cadena de conexión ya no está en los archivos de configuración. Muchos pueden modificarse fácilmente para usar su API; sin embargo, es algo que lleva más tiempo investigar si quieres usarlo. Solo un FYI sobre eso.

Answer 3

¿No es posible pasar a Window Integrated Security en las cadenas de conexión, entonces no tiene que preocuparse tanto por el aspecto de seguridad (a menos que necesite asegurar la ubicación real de la conexión, supongo).