.NET How would I build a DAL to meet my requirments?

Question

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.

Answer 1

You can do this exposing your DAL via web services.

So on your 'middle' server have all the web services exposed that replicate your DAL which hopefully just calls stored procs and has no other access to the DB. Secure the middle server to only have access to only expose the web services to the public web server and no other entry point. You can use SSL if neeeded.

Secure the DB to only accept connections from the 'middle' server and ONLY have access to the stored procs your DAL needs to call.

If someone does compromise the public server they should only have port 80 or 443. You should only have some web service there so your exposure should be limitted if it is compromised. I had to setup a web app with a similar setup and had the same rules that the external web server could only communicate via port 80 or 443 to a 'middle' server in the DMZ and the 'middle' server had only a connection to the database. At each step, each machine was locked down to only the machines that could comminicate to it.

Keep in mind you web service design as well to have some type of authentication or make sure that all calls have checks on them to verify their legitimacy as well.

Answer 2

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.