6

In a study project i have to plan a network for a small company (around 50 employees) and i am currently at the point, where i want to design the database architecture.

I read that its common to have a web server in the DMZ. The company has got an online shop. So it is necessary to access a database. Customers can create accounts and so on via the online shop. Where to put this database? Also inside the DMZ or inside the company's intranet?

Does it make sense to build up multiple DMZs, for preventing attacks on neighbor components in the DMZ? How to mirror customer data into the companys intranet?

Thanks for explanation!

tellob
  • 161
  • 1
  • 1
  • 3
  • The web server which runs the online shop application should have access to the DB server, but the actual DB server shouldn't be open to the entire internet, that would be a huge and unnecessary risk. –  May 17 '14 at 16:54

1 Answers1

6

The point of a DMZ is to place any systems in there which must be reached by external systems directly but also require access to backend systems which must not be accessed directly by external systems.

A backend database used by a public-facing website is a perfect example of such a backend system which should not be placed in the DMZ but behind it.

     Customers          Internet
         |        
  ====Firewall====
         |              DMZ
     Webserver  
         |          
  ====Firewall====
         |              Internal network
     DBserver--Employees

When you also want to isolate your database from the local LAN (to protect against internal attackers), you could set up a two-tier DMZ where an additional firewall shields backend-systems from the LAN so that only authorized employees may access them and may only access those services on the machine you want them to access.

     Customers          Internet
         |        
  ====Firewall====
         |              DMZ1
     Webserver  
         |          
  ====Firewall====
         |              DMZ2
      DBserver    
         |
  ====Firewall====
         |              Internal network
      Employees

But sometimes you don't want your employees to have any direct access the database server, even when they have personalized user accounts on it. Most database systems allow you to set user accounts with read- or write permissions to certain tables, but when you want to have fine-grained control over what data each user can and can't access, the build-in permission handling of your database might be insufficient. In that case you would have a separate application server between DBServer and employees which works as an abstraction layer between the employees client program and the database just like the webserver does for the customers. The application server might in fact be a webserver (an internal web interface).

     Customers              Internet
         |        
  ========Firewall========
         |                  DMZ1
     Webserver  
         |          
  ========Firewall========
         |                  DMZ2
      DBserver--AppServer   
                   |
  ========Firewall========
                   |        Internal network
               Employees

You might even go further and introduce a 3rd DMZ to place the internal application server in. This would protect the DBserver in the case that an employee totally compromises the application server and uses it to launch an attack which is not SQL-based against the DBserver. But that would already be a very paranoid level of security. However, there might be high-security organizations where such a level of paranoia is justified.

Which option you choose depends on the level of security you need. When you have a small team and you can trust them to not attempt any l337 h4x0r stuff on the database server, the simpler option 1 is sufficient. But when you have a very large internal network with hundreds to thousands of clients and you can not vouche for everyone to be trustworthy, you have to consider your LAN as just as dangerous as the internet and have to shield any internal-facing applications with an additional firewall and choose option 2 or 3.

Philipp
  • 48,867
  • 8
  • 127
  • 157
  • Well I think, that the second option, having two DMZs to protect the WebServer from external attacks and the database from internal attacks, is the best one for me. How would you manage the database replication? Of course it is not possible to store the data on only one machine - i need a backup. I read that most database systems consist out of a master-slave-combination. where to put master and slave in this situation and on which of both will be written by applications? Thanks! – tellob May 18 '14 at 08:57
  • @tellob Master/slave replication is for redundancy, not for security against unauthorized access. Applications write to the master which forwards all changes to the slave. When the master crashes, the slave can immediately take its place and become the new master. That means master and slave should be in the same DMZ zone. – Philipp May 18 '14 at 10:18
  • But with both DBs in the same DMZ, an attacker could maybe also attack the slave, or? I want to make sure, that if the master crashes by an attack or whatever, a slave can take its position, but the slave shall be in a secure environment, so that it cannot be attacked the same way, the master was. – tellob May 18 '14 at 11:41
  • @tellob by that logic you would have to place every single server in the whole datacenter into an own DMZ. Also, when an attacker compromised the master, why would they need to compromise the slave too? The master has all the data and any changes done to the data on the master will be replicated on the slave automatically. – Philipp May 18 '14 at 17:51