We are departing from our typical native application development and are developing some new web-based application services. We are using .Net and WCF and most likely hosting on IIS.
Our services will need to use a database to persist data. In all cases we intend to make the database server a different box than our host. Most of the resources we find seem to indicate storing the database connection string in the web.config (or app.config file for self-hosting). Our concern is that since the service is web-facing the box it is running on is a more likely to be hacked/compromised. If that happens, the attacker now had the DB connection string and will have full access to all of the data.
An initial thought was to make the WCF service simply proxy to a server application that lives on another machine that holds the connection information and does all the processing logic. That way, if the the web-host is compromised they would have to figure out how to communicate with our server application, or compromise that machine as well, to gain database access. Though we do have concerns of the performance costs of proxying and possibly having a bottle-neck at the server application.
The concern with that approach is that we are not finding much in the way of WCF/IIS literature that recommending on such an approach, but we might just not know what it is called in order to find such information. The question: is proxying like that a good practice and why/(why not) (or where might I find more information on this topic), or is there a better practice?
As with these things, it all depends on how secure you need things. You can encrypt your web.config:
http://msdn.microsoft.com/en-us/library/dtkwfdky.aspx
But you have to ask that if your attacker has the ability to compromise your web host machine, they will be able to find your other server, and may also then have the ability to compromise that – not 100% sure what the net gain here is (apart from making your life more difficult).