I need to create a web application that accesses a SQL Database on our company LAN. Is this a good/safe approach?

  1. Create a DMZ, currently there isn't one.

  2. Place Web Server (running IIS) in DMZ, put it in it's own workgroup and not make it a member of the corporate domain. As far as I can tell we will only need one box so no need to create a seperate domain for the DMZ.

  3. Put a firewall in front of DMZ (inbetween router and webserver) that only allows access for HTTP and/or HTTPS to webserver.

  4. Put another firewall behind DMZ (inbetween webserver and LAN) that only allows SQL connections from the webserver to SQL server on the LAN and blocks everything else.

For this configuration mentioned above we would need to purchase 2 firewalls and a router as well as a server to run the IIS. The application is basically just a .Net Form that accesses a database and creates a saveable .pdf when done. I assume we should be looking into application layer firewalls to help protect agains SQL injection /Cross site scripting, etc.)?

Will that network design be effective? Any other layout options that are more cost effective and/or safer?

  • Network architecture proceeds from what you are trying to accomplish. Creating "a web application that accesses a SQL database on [your] company LAN" is a poor description of what you are trying to accomplish. (What's the app for? What kind of data will it access? Can you achieve the results with extracts rather than live data? etc.)
    – voretaq7
    Commented Jan 13, 2012 at 21:44

1 Answer 1


Your architecture is basically sound, though note that you probably only need one firewall device, with DMZ rules for isolating the App server.
Consider the following, which only shows the traffic in/out of your theoretical application server.

enter image description here

A few other stray thoughts:

  • Look at my comment on your question.
    Ask yourself: Do I *need* to access my main SQL server at all? -- If you can make due with extracted data pushed to the DMZ App rather than letting it come through the firewall and access your corporate network you'll be in a better place from a security standpoint.

  • If you MUST directly access your SQL server make sure to use an account with the least privileges possible.

    • Don't let it read from any tables it doesn't need to read from.
    • Don't let it write to any tables it doesn't need to write to
      (Ideally don't write to anything! Batch changes and have them loaded in by another program that sanity checks them first.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .