Assuming that I must deploy an asp.net app over the following 3 servers:
1) DB – not public
2) ‘middle’ – not public
3) Web server – public
I am not allowed to connect from the web server to the DB directly. I must pass through ‘middle’ – this is purely to slow down an attacker if they breached the web server.
All db access is via stored procedures. No table access.
I simply want to provide the web server with a ado dataset (I know many will dislike this, but this is the requirement).
Using asmx web services – it works, but XML serialisation is slow and it’s an extra set of code to maintain and deploy.
Using a ssh/vpn tunnel so that the one connects to the db ‘via’ the middle server, seems to remove any possible benefit of maintaining ‘middle’.
Using WCF binary/tcp removes the XML problem, but still there is extra code.
Is there an approach that provides the ease of ssh/vpn, but the potential benefit of having the dal on the middle server?
Many thanks.
Personally, I would skip the “middle”. If the database is not exposed and the web server is, the “middle” buys you nothing. If they can get to one unexposed server, the battle is already lost. Secure the web server, secure the database server, and trust that software will do its job when configured as it is supposed to.
You could always put the database server on a different subnet. This sort of requirement usually is a sign of larger issues – DBA incompetencies, architectural incompetencies, etc. I have worked for major financial companies, and just making sure that the database server was not exposed was more than adequate – mostly due to having a properly secured and non-exposed database server makes it a moot point.
Not trying to come down on you, or question the requirements for the sake of doing so – but I would hope that a more reasonable and maintainable approach could be taken for the sake of your own sanity.
Edit – For the sake of clarification, I am not against using an actual application server. The context of my answer is based on the OP’s requirement that it be used as a database proxy layer.