What is the best way to centralize and secure connection strings?

Question

What is the best way to centralize and secure the connections strings used by applications? In my environment we have many internal applications. Each application requires one or more connection strings in order to access the database. We have a goal of centralizing all these connection strings (particularly SQL logins and passwords) so we could change passwords in one place instead of in 35 different .config files, registry entries etc.

Currently we are using a home grown component which pulls the connection string information from an access database, this covers the centralization requirement but isn't particularly secure. In addition we have applications written in languages from classic asp, vb6, delphi, c++, .net so the solution would need to be usable by all those applications.

Does anyone have an idea of how to do this better, or do we need to rework our whole approach to the way our applications access the database.

Answer 1

The company I work for has used a similar situation through a SQL Server database instead. We ended up creating a COM-compliant .net dll to simplify and secure the API into the database and to ensure that the same logic is used between classic asp, .Net, and DTS packages. It has worked out great for us for year and while there are some refactoring items a lot of us would like to do with it, it's been great to address issues like server migrations or renamings.

I think you are on the right path; however, I would recommend the following changes:

• Try to move to a true database server. Access is great for MS Office but not for something of this scale.
• Build an administrative console that allows for auditing of who is adding and editing information (secure who has access to what settings too).
• Build a COM-compliant DLL so that it can be consumed by other systems in a secure and consistent manner.

EDIT:

Something that I have noticed after working years in a system like this is that it ties your hands slightly on some solutions. Many tools out there (i.e. nHibernate, Elmah, etc. in the .Net world) really are limited when the connection string is no longer in the config files. Many can be easily modified to use your API; however, it is something that takes more time to investigate if you want to use it. Just a FYI on that.

Answer 2

Is it not possible to move to Window Integrated Security in the connection strings, then you do not have to worry about the security aspect as much (unless you need to secure the actual location of the connection I guess).

Answer 3

You can use Windows server to create users that are allowed to access your SQL Server database. Then you can use integrated windows login in connection strings.

BTW Storing passwords in public MDB renders them irelevant. Same as they don't exist.