I have a classic DMZ architecture:

enter image description here

My webserver is placed in the DMZ. The webserver needs to communicate with a database server. This database server is the most critical component of my network as it contains confidential data.

Where should I place the DB server and why? Should I add a second firewall and create another DMZ?

  • 3
    Why does the database server need to communicate with the web server? I would think that it would be the other way around(the web server that needs to communicate with the db server, and the db server just needs to return the results). The db server should not be permitted to initiate communication with the web server; it has no need to.
    – Kevin M
    Commented Nov 14, 2011 at 15:28
  • Correct. I updated the question accordingly :)
    – lisa17
    Commented Nov 14, 2011 at 16:15
  • What assets does the database contain?
    – this.josh
    Commented Nov 15, 2011 at 9:11
  • @this.josh credit cards details
    – lisa17
    Commented Nov 15, 2011 at 11:00

6 Answers 6

  • The best placement is to put the database servers in a trusted zone of their own.
  • They should allow inbound connections from the web servers only, and that should be enforced at a firewall and on the machines. Reality usually dictates a few more machines (db admin, etc). Obey reality as needed, of course.
  • They should only be making outbound connections if you're updating software on them.
  • so I should add another leg to the firewall for a DB DMZ, correct?
    – lisa17
    Commented Nov 14, 2011 at 20:20
  • 2
    @lisa1987 Yes. You may be able to accomplish it via VLANs rather than hardware.
    – Jeff Ferland
    Commented Nov 14, 2011 at 20:27
  • putting a sensor on the segment will allow you to monitor it easily plus the log will be clearer. The syslog server could be on a different segment and valuable information could be associated with debugging.
    – happy
    Commented Jan 9, 2013 at 6:25
  • Be especially careful to mitigate VLAN Hopping en.wikipedia.org/wiki/VLAN_hopping when depending on VLANs for security.
    – mgjk
    Commented Jan 9, 2013 at 17:24
  • @JeffFerland Thanks. So would you suggest not to call any webservices (SOAP) from Database code instead call in the Java layer ?
    – Jay
    Commented Oct 9, 2015 at 12:50

Agree with Jeff Ferland, database servers should be on their own: you should have a clean network for replication & backup.

Pardon my ASCII art, a quick overview of a reasonable ideal:

    outer-firewall--- [proxy-zone]
          +---- [app-zone]
       |        |
[lan]--+        +-- [database-zone]
  1. Run a reverse-proxy, Apache+mod_security/varnish/nginx/WAF/whatever, in the proxy zone. Add load-balancing/failover here if needed too. Also add proxy/relay servers for outbound connections (DNS, SMTP, HTTP proxy), if required.
  2. When application logic runs on a web server (Java/PHP/ASP), I prefer to call it an application server.
  3. When you need to scale you can scale horizontally, load balancers make this easier. You may also consider replicating static and/or unauthenticated content to the front-end proxies (advance thinking about URL paths, hostnames and cookies pays off here)
  4. you might want to add one or more zones of type: IDS, management, backup, remote access, outbound proxy

You're trying to mitigate, so:

  • inter-zone communication must be limited to the minimum required for services, administration and monitoring purposes.
  • a reverse-proxy accepts untrusted connections from the internet, and can only initiate connections to services on application servers, no outbound internet connections. If you want to classify (color) your zones by nature/traffic you need to consider carefully termination of HTTPs, and if you want to create new HTTPs connections to the app servers (update: you probably do, but you can configure a small set of fast ciphers, and omit CA bundles to keep overheads low).
  • application zone accepts semi-trusted connections from proxies, and can initiate connections only to databases. You can trust your application servers a little bit more when you know they're not talking directly to the internet.
  • database servers accept connections only from application servers, the database zone should be your "cleanest" network
  • consider using different firewalls (vendor/product) for the outer- and inner-firewalls
  • for required outbound services (DNS, SMTP or patching/updates) these should go via a distinct server (e.g. on the proxy-zone, or seperate outbound-proxy-zone).
  • same goes any outbound CC validation HTTPS connections. (If you're unlucky enough to have some vendor or services black box for validation, these ought go on a dedicated zone too, IMHO.)
  • use public IP addressing only in the proxy zone, private addressing elsewhere. No server outside the proxy zone(s) need have a public IP, NAT, or even a default route to the internet.

Separate zones makes your IDS's job easier, and logging more effective. Zones should be layer 2 (switching) and layer 3 (IP) isolated. If you have the resources, add a management-zone, separate management NICs for each server (protected ports if you can). Service monitoring is best done over the operational network.

In reality you may end up compacting the "ideal" network to a single firewall and VLANs. Any dev/preprod environments should copy the operational network as closely as possible (especially if you don't want to chase your tail debugging issues introduced, like dropped idle connections). If you consider your options now with the above in mind it should be easier to migrate in future, i.e. shortly after the next visit from your friendly neighborhood PCI-DSS auditor ;-)


The following is quite a common setup for DMZ architecutre:





DMZ (Host your dmz servers here only allowing specific ports through the firewall)




Database Network (only allow specific ports and protocol from firewall2 to this network)

As you mention the database contains credit card (sensitive) data then even on the innerside of firewall2 the database network should be segregated from the corporate and user networks. So many times I see the crown jewels of a company wide open on the internal network for all users to probe and access. Going a step further you could have a database admin VLAN only only allow systems within this VLAN permission to access the databases (apart from the application that needs to access it from the DMZ of course).

Hope this helps.


3-Tier Architecture is the most secure and scalable solution. As client traffic is increased we can add up as many middle tiers needed to ensure performance. Three Tier architecture is also more secure because the middle layer is protecting the database tier. We need to protect database tier from direct access and need to be placed it in trusted zone and it should be only accept connections from application servers.

3 Tier Architecture


As you will need to comply with PCI-DSS you will also need to ensure that you have firewalls at each internet connection and between DMZ and internal networks. Theres some good pointers in the self asssessment questionnaires.

Also dont make the database server if a wintel box a member of the domain etc

  • Could you expand on not adding the database server to the domain? I disagree with you but keen to hear your view.
    – fixulate
    Commented Jan 9, 2013 at 12:38
  • well in my experience it adds a lot more risk to internal system compromise if the server is a domain member and therefore will be subjected to domain accounts for administration
    – Matthew
    Commented Jan 14, 2013 at 16:44
  • 1
    But with being part of the domain you get all the security benefits that you lose by being standlone? GPO, centralised management, password policy, account auditing, etc. Curious to know if anybody else thinks removing servers from the domain increases their security posture?
    – fixulate
    Commented Jan 23, 2013 at 13:10
  • @fixulate, are you asking because you're using SQL Server with Windows Authentication?
    – MGoBlue93
    Commented Feb 27, 2019 at 21:03

I would prefer an architecture where the DB server is protected by more than just a firewall. That is, I would assume the webserver gets compromised - but instead of being able to do arbitrary DB operations, it can only fetch extremely limited data from an intermediary server. A DB enthusiast would assert that any DB will have sufficient privilege-checking builtin. But well, defense in depth.

You must log in to answer this question.

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