Il punto di una DMZ è di posizionare qualsiasi sistema lì dentro che deve essere raggiunto direttamente dai sistemi esterni ma richiede anche l'accesso ai sistemi di back-end a cui non deve accedere direttamente da sistemi esterni.
Un database di back-end usato da un sito web pubblico è un perfetto esempio di un sistema di back-end che non dovrebbe essere collocato nella DMZ ma dietro di esso.
Customers Internet
|
====Firewall====
| DMZ
Webserver
|
====Firewall====
| Internal network
DBserver--Employees
Se si desidera isolare il database dalla LAN locale (per proteggersi dagli aggressori interni), è possibile impostare un DMZ a due livelli in cui un firewall aggiuntivo protegge i sistemi di back-end dalla LAN in modo che solo i dipendenti autorizzati possano accedere loro e possono accedere a tali servizi solo sulla macchina a cui si desidera che accedano.
Customers Internet
|
====Firewall====
| DMZ1
Webserver
|
====Firewall====
| DMZ2
DBserver
|
====Firewall====
| Internal network
Employees
Ma a volte non vuoi che i tuoi dipendenti abbiano accesso diretto al server del database, anche quando dispongono di account utente personalizzati. La maggior parte dei sistemi di database consente di impostare account utente con autorizzazioni di lettura o scrittura su determinate tabelle, ma quando si desidera avere un controllo preciso sui dati a cui ogni utente può e non può accedere, la gestione dei permessi incorporata del proprio database potrebbe essere insufficiente. In tal caso, si avrà un server applicazioni separato tra DBServer e dipendenti che funge da livello di astrazione tra il programma client dipendenti e il database proprio come fa il server web per i clienti. Il server delle applicazioni potrebbe infatti essere un server web (un'interfaccia web interna).
Customers Internet
|
========Firewall========
| DMZ1
Webserver
|
========Firewall========
| DMZ2
DBserver--AppServer
|
========Firewall========
| Internal network
Employees
Potresti anche andare oltre e introdurre un terzo DMZ per inserire il server delle applicazioni interno. Ciò proteggerebbe il server DB nel caso in cui un dipendente comprometta totalmente il server delle applicazioni e lo usi per lanciare un attacco che non è basato su SQL contro il server DB. Ma questo sarebbe già un livello di sicurezza molto paranoico. Tuttavia, potrebbero esserci organizzazioni ad alta sicurezza laddove tale livello di paranoia è giustificato.
Quale opzione scegli dipende dal livello di sicurezza di cui hai bisogno. Quando hai un piccolo team e ti puoi fidare che non provino alcuna roba l337 h4x0r sul server del database, l'opzione 1 più semplice è sufficiente. Ma quando hai una rete interna molto grande con centinaia di migliaia di clienti e non puoi fare in modo che tutti siano degni di fiducia, devi considerare la tua LAN altrettanto pericolosa di Internet e devi proteggere qualsiasi applicazione interna con un firewall aggiuntivo e scegliere l'opzione 2 o 3.