DMZ 的目的是将外部系统必须直接访问但还需要访问外部系统不能直接访问的后端系统的任何系统放置在那里。

面向公众的网站使用的后端数据库是这种后端系统的完美示例，它不应该放在 DMZ 中，而应该放在它后面。

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

当您还希望将数据库与本地 LAN 隔离（以防止内部攻击者）时，您可以设置一个两层 DMZ，其中一个额外的防火墙将后端系统与 LAN 隔离，这样只有授权的员工才能访问它们，并且可能仅访问您希望他们访问的机器上的那些服务。

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

但有时您不希望您的员工直接访问数据库服务器，即使他们有个性化的用户帐户。大多数数据库系统允许您设置对某些表具有读或写权限的用户帐户，但是当您希望对每个用户可以访问和不能访问的数据进行细粒度控制时，数据库的内置权限处理可能不够。在这种情况下，您将在 DBServer 和员工之间有一个单独的应用程序服务器，它作为员工客户端程序和数据库之间的抽象层，就像网络服务器为客户所做的那样。应用程序服务器实际上可能是一个 Web 服务器（一个内部 Web 界面）。

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

您甚至可以更进一步，引入第三个 DMZ 来放置内部应用程序服务器。这将保护 DBserver，以防员工完全破坏应用程序服务器并使用它对 DBserver 发起非基于 SQL 的攻击. 但这已经是一个非常偏执的安全级别。但是，可能存在高度安全的组织，这种偏执程度是合理的。

您选择哪个选项取决于您需要的安全级别。当你有一个小团队并且你可以相信他们不会在数据库服务器上尝试任何 l337 h4x0r 东西时，更简单的选项 1 就足够了。但是，当您拥有一个拥有成百上千个客户端的非常大的内部网络并且您不能保证每个人都值得信赖时，您必须考虑您的 LAN 与 Internet 一样危险，并且必须使用附加防火墙并选择选项 2 或 3。