Hi, Looks like your setup is how database servers are somehow 'protected' everywhere, 3-tier model. The key is to have the firewall control that any connection coming from the DMZ (or beyond) in to the SQL server is from the web server (IP address, MAC address, authentication mechanisms, or whatever), and not any machine out there. Packet analysis on the firewall will help too. However, since the DMZ may have other servers (mail, etc) too and since it is more exposed to intrusions, you should add encrypted connection beetween web server and SQL server: A sniffer on your DMZ would be a problem otherwise.
So, this is doable so far... but what if I take over your web server and send whatever query I want to your SQL server? How would the SQL server figure out that its trusted friend, the web server, is now acting under my command instead of a remote authorized user? Well... this simply isn't part of the webserver/firewall/SQLserver setup question. It goes into the internet/webserver security setup. In fact, I don't even need to take over your web server. I only have to sniff, hijack, forge, or whatever a connection or convince an authorized user to reveal me her account name and password to get queries into the SQL server. Then... do you do on-line banking?... I do _not_ Christian. Dan Williamson wrote: > >I currently am faced with a troublesome infrastructure >dilemma. > >We have some real-time data that resides on an SQL server >in our intranet. This data is queried and updated by users >via a web server that is in our DMZ. Queries are sent from >the web server in the DMZ to the SQL server and data is >provided from the SQL server back to the web server based >on the queries. This obviously requires a two way >connection through the firewall which negates the reason >for the firewall in the first place. The question I have is >what is the most secure network design for these systems? >How do you provide access to real-time sensitive data in a >secure environment? Financial, medical and other government >agencies provide this kind of real-time information on a >daily basis so I know there are ways to do what we need. >I'm just not sure how yet. > >Any suggestions would be greatly appreciated. > > >
