El objetivo de una DMZ es colocar cualquier sistema allí donde debe ser alcanzado por sistemas externos directamente, pero también requiere acceso a sistemas backend a los que no se debe acceder directamente por sistemas externos.
Una base de datos backend utilizada por un sitio web público es un ejemplo perfecto de un sistema backend de este tipo que no debe colocarse en la DMZ sino detrás de él.
Customers Internet
|
====Firewall====
| DMZ
Webserver
|
====Firewall====
| Internal network
DBserver--Employees
Cuando también desea aislar su base de datos de la LAN local (para protegerse contra los atacantes internos), puede configurar una DMZ de dos niveles en la que un firewall adicional proteja los sistemas backend de la LAN para que solo los empleados autorizados puedan acceder ellos y solo pueden acceder a los servicios en la máquina a la que desea que accedan.
Customers Internet
|
====Firewall====
| DMZ1
Webserver
|
====Firewall====
| DMZ2
DBserver
|
====Firewall====
| Internal network
Employees
Pero a veces no desea que sus empleados tengan acceso directo al servidor de la base de datos, incluso cuando tienen cuentas de usuario personalizadas en él. La mayoría de los sistemas de base de datos le permiten configurar cuentas de usuario con permisos de lectura o escritura para ciertas tablas, pero cuando desea tener un control preciso sobre los datos a los que cada usuario puede y no puede acceder, el manejo de permisos integrado de su base de datos podría ser insuficiente En ese caso, tendría un servidor de aplicaciones separado entre DBServer y los empleados que funciona como una capa de abstracción entre el programa cliente de los empleados y la base de datos, tal como lo hace el servidor web para los clientes. El servidor de aplicaciones podría, de hecho, ser un servidor web (una interfaz web interna).
Customers Internet
|
========Firewall========
| DMZ1
Webserver
|
========Firewall========
| DMZ2
DBserver--AppServer
|
========Firewall========
| Internal network
Employees
Incluso podría ir más lejos e introducir una 3ª DMZ para colocar el servidor de aplicaciones interno. Esto protegería el servidor de DB en el caso de que un empleado comprometa totalmente el servidor de aplicaciones y lo use para lanzar un ataque que no esté basado en SQL. contra el DBserver. Pero eso ya sería un nivel de seguridad muy paranoico. Sin embargo, puede haber organizaciones de alta seguridad en las que se justifique ese nivel de paranoia.
La opción que elija dependerá del nivel de seguridad que necesite. Cuando tienes un equipo pequeño y puedes confiar en que no intenten ninguna cosa l337 h4x0r en el servidor de la base de datos, la opción 1 más simple es suficiente. Pero cuando tiene una red interna muy grande con cientos o miles de clientes y no puede responder para que todos sean confiables, debe considerar su LAN tan peligrosa como Internet y proteger todas las aplicaciones internas con una firewall adicional y elija la opción 2 o 3.