Database – Debating our network structure (DMZ, database, service)

databasedmznetworkingservice

We're trying to decide where we should locate different servers. Should we put them in the DMZ? In our trusted network zone? And so on… Lots have been written on this topic, but there seems to be different opinions on whether or not to allow access from the DMZ to a database server on the internal network. I would like your opinion on our thoughts.

Basically, we have the following servers and services that are involved when servicing our customers:

Involved servers

The "Application service (WCF)" is basically our entry point to the database, holding all the business logic and verifying that everything is okay, before committing it to the database. There is a read-only service here aswell, optimized for querying the database.

Introducing a DMZ, where should we put the servers? The web-server and the external service obviously goes into the DMZ protected by a firewall, only allowing the necessary ports. But what about the Application service and the database server? We have considered the following scenarios:

  1. Application service and Database server in the internal network, protected by a firewall, only allowing the external web server and service to connect directly to the Application service, not the database.
  2. Application service in the DMZ, database server in the internal network protected by a firewall, allowing applications to connect to the database. Internal applications will connect to the application service in the DMZ.
  3. Everything in the DMZ.
  4. Fully separating the DMZ from the internal network, by placing a read-only database and a message queue in the DMZ. One-way access from the internal network to the DMZ, allowing the internal database to replicate transactions to the DMZ-database keeping it up to date. Instead of writing to the DMZ-database, commands are written to a message queue, and are picked up from a service from the inside, and handled by the Application service (we can live with the delay). This scenario also involves splitting up the Application service, so it only consists of a read-only querying service and a service placing commands on the queue in the DMZ. The original Application service will still be active on the internal network. There is some duplicated code here, but if this is the best scenario, we can live with that.

With my knowledge (no network expert), scenario 1 or 4 seems like the most suitable solutions. In solution 1, there's no direct connection to our database from the DMZ, but there's a port open from the DMZ to the inside. In solution 4, nothing is open from the DMZ to the inside, but we are exposing a read-only copy of the database in the DMZ. The database contains lots of sensitive customer information, so this might not be ideal.

What do you think? Any thoughts and opinions will be much appreciated.

Best Answer

I think the easiest way to tackle the answer to this question is to start from the other side: ask "what happens in the event of a compromise?". If the external web server is compromised, then what can the attacker jump to from there? Let's look at the options:

  1. (You didn't present this one, but I'm putting it here for completeness.) Everything in the internal network, with a hole poked through the firewall: you are screwed. If the web server is compromised, attackers have potential access to everything on the internal network (not just the database server).
  2. External Web Server in the DMZ, Application service in the DMZ, database server in the internal network: an extra hurdle for attackers: both the web server and application service need to be compromised before the attack can potentially jump to the database. A successful attack means attackers have potential access to everything on the internal network.
  3. Everything in the DMZ: a successful attack has no access to the internal network.
  4. Fully separating the DMZ from the internal network, by placing a read-only database and a message queue in the DMZ...: Minimizes the potential of jumping from the DMZ to the inside, but doesn't completely eliminate it. Requires additional complex configuration and work to make sure things are "just right".

My personal preference is to go for the next level: Everything in the DMZ, database server with all the important stuff behind a second level of protection, but still in the DMZ. Of course this adds complexity and may not be worth the effort. Really it depends on how important the stuff in the database server really is, and how big your company is. It might be good enough to simply lock down the database server so only the web server can access it, but that is a value judgement that no one but you can make.

Related Topic