¿Es suficiente tener una base de datos única dentro de la DMZ desde la cual los servidores web en la DMZ reciben sus datos?
¿O si la configuración con dos bases de datos es una solución mejor, sería tener una base de datos en la red interna que recibe la base de datos en la DMZ?
Su pregunta es un poco vaga, por lo que le aconsejo que considere los modelos de amenazas de los que está tratando de protegerse.
Lo primero que debe hacer es definir que un DMZ es una región en su red que se considera total o parcialmente sin confianza, porque está conectada a Internet (o alguna otra red hostil y no confiable). La DMZ define un límite de seguridad entre esa infraestructura y su entorno interno más confiable. Ese límite de seguridad generalmente es impuesto por un firewall o controles de red similares. Es posible que esté diciendo "sí, lo sé", pero he visto a personas que malinterpretan completamente el punto de una DMZ y quiero asegurarme de que estamos en terreno firme.
Según tengo entendido, le preocupa mantener su base de datos en la DMZ junto con el servidor web, porque tiene equipos internos de su red de confianza que se conectan a esa base de datos. Esta es una configuración común, y muchas personas se las arreglan bien permitiendo las conexiones desde la red de confianza a la base de datos en la DMZ.
Sin embargo, una cosa a considerar es el modelo de autenticación. Si se está autenticando en un servidor MSSQL en la DMZ a través de AD, y su controlador de dominio no está en su DMZ (¡espero que no!), Deberá permitir el tráfico de AD a través del firewall. Esto no es una buena idea, de verdad. Por lo tanto, utilizar la replicación de la base de datos para sincronizar los datos a través del límite de la DMZ, de modo que la base de datos interna se pueda autenticar a través de AD, mientras que la base de datos externa (es decir, basada en DMZ) No necesito hablar con el DC, es una solución bastante buena.
Es mejor NO usar una DMZ en absoluto.
pero si debe, suponga que todo en la DMZ está comprometido y debe desconfiarse y suponer que se filtró a otros. por lo tanto, la mejor solución sería mover su base de datos y servicio web fuera de la DMZ, y emplear un proxy inverso dentro de su dmz. (y asegúrese de que el servidor web solo pueda hablar con el proxy, y la base de datos solo con el servidor web) cuando haga esto. y todas las demás técnicas y salvaguardas estándar que podría evitar los atacantes. (aún debe realizar una verificación de seguridad como se indica en un comentario de @Polynomial)
- Información adicional sobre DMZ.
Los DMZ son sistemas que están fuera de su protección normal y guardas de seguridad (por ejemplo, sin todas las cosas que normalmente tiene para protegerse contra el uso indebido). en realidad, no hay ninguna razón válida para tener un sistema en una DMZ aparte de los honeypots (un honeypot es un sistema diseñado específicamente para atraer virus / atacantes y poder analizarlos). Para cualquier otro uso legítimo, debe usar las defensas de múltiples capas y solo tienen una ruta de acceso claramente definida A TRAVÉS de sus firewalls (como su firewall permite llamadas a su servidor web en el puerto 80 y 443, pero solo si existe para "su dominio" y solo para un punto final específico (como el solo servidor web o el equilibrador de carga principal).
En la práctica, a veces es necesario tener un sistema en su DMZ para utilizar algo debido a una política (en mi opinión, una política incorrecta). si estás atrapado con esa situación,
Yo usaría lo que se llama un proxy inverso para enviar todas las solicitudes válidas desde el interior de la DMZ al interior de su red segura donde se encuentra su servidor web. esto evita la mayoría de los ataques scipted y mantiene intacta su seguridad base. significa que tiene que proteger su servidor web a través de otros medios para limitar el efecto de un servidor web comprometido (simplemente porque ahora está dentro de su red)