Entendiendo una DMZ con múltiples servidores

El propósito de la DMZ es no exponer su DB directamente a Internet. En su lugar, lo expone a su aplicación web, y su aplicación web a Internet. Pero debes cuidar la seguridad tanto de la aplicación web como de la base de datos.

Si su aplicación web se ve comprometida, no significa que la base de datos también lo sea. Hay varios vectores aquí, por ejemplo, podría tener una vulnerabilidad de inyección de SQL en su código, por lo que sería irrelevante si la base de datos está en una DMZ, subred privada o incluso el mismo host que la aplicación web, ya que un atacante podría recuperar información de todos modos.

Otro ejemplo, de alguna manera su aplicación podría llevar a acceder al sistema operativo. Pero si su sistema está cuidadosamente reforzado, el atacante solo podría acceder a los recursos a los que tiene acceso el usuario de la aplicación web. La base de datos no debe ser ninguno de esos recursos.

Otra forma es tener un proxy inverso también conocido como load Balancer para que actúe como punto de terminación de tráfico para el tráfico externo e interno. Cuando el tráfico finaliza en un proxy, puede inspeccionar los encabezados y el contenido del tráfico antes de permitir que se restablezca en los servidores que se ocultan detrás del proxy inverso.

Para combatir los ataques de las aplicaciones web, puede considerar un firewall de aplicación web en la parte superior de su red de firewall y sistemas de detección y prevención de intrusos.

Si su aplicación no requiere acceso de escritura a la base de datos, considere colocar una réplica de solo lectura de la base de datos en la DMZ, luego use un puerto oscuro para la replicación de la base de datos con la base de datos "real".