May 15, 2009 at 2:34 pm
Our company is really trying to improve security within applications. Many of our applications are home grown, and we use SQL Server authentication accounts for generic access.
Within our applications (many technologies - java, .NET, classic asp, etc.), we need to have the connection information for the database(s) we use. We've made sure that the information, especially user names and passwords, are not stored in clear text.
However, I'm looking for better, more secure ways to get database connections within applications. What kinds of processes are other organizations using?
A simplified explanation of one suggestion we've had is to store connection information (encrypted) in a database and let a web service return the connection string based on a set of parameters passed. Of course the problem with that is verifying that the person/application calling the web service is valid, or determining parameters that would be difficult to obtain for those without a "need to know".
One great benefit I can see from this suggestion is that it would make some DBA tasks very easy. When passwords need to be changed or databases need to be moved to other servers, the info can be modified in the connection information DB, and applications using the web service would continue to work without the trouble of tracking down developers and scheduling when they can change their connection info.
So what are other developers out there doing about securing connection string information, and what are the pros/cons of doing it that way?
Thanks!
Desiree
May 15, 2009 at 2:42 pm
Hi
If possible I would suggest to use windows authentication.
An encrypted connection string seems to be a good approach. You should not store user/password on client side. Store only server/database information in your connection string and use a login dialog to authenticate.
Greets
Flo
May 15, 2009 at 2:54 pm
Thanks for your response. I forgot to mention a couple of details in my original post - our company has 5000+ employees, so maintaining lists for individual users to access specific databases could become a nightmare for databases that do not allow access to "Everyone".
Additionally, we have many users who are not in our company's "domain" (they are corporate management and will not allow us to give them domain accounts. Believe me, we've tried!). We're unable to authenticate them using windows authentication, because our network cannot recognize them...Thus the need for using SQL Server authentication in many cases.
May 15, 2009 at 3:14 pm
In this case you have to use SQL Server authentication.
To simplify the server-switch and database naming problems some possibilities:
To handle a possible switch of the database to another server we use NAT in your company. The databases have their own virtual IP. If we have to switch a database to another server we just have to switch the IP address
If your database might have another name on another server you can use one helper database which is available on each server and stores the database names depending on the application name. You can use a stored procedure in this database which will be called from your application to get the name of the database on the current server. Now the application can easily change the database and start working.
Greets
Flo
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply