• La mejor ubicación es colocar los servidores de bases de datos en una zona de confianza propia.
• Deben permitir conexiones entrantes solo desde los servidores web, y eso debe hacerse cumplir en un firewall y en las máquinas. La realidad suele dictar unas pocas máquinas más (db admin, etc). Obedezca la realidad según sea necesario, por supuesto.
• Solo deberían realizar conexiones salientes si está actualizando el software.

De acuerdo con Jeff Ferland, los servidores de bases de datos deben estar en su cuenta: debe tener una red limpia para la replicación & copia de seguridad.

Perdone mi arte ASCII, una visión general rápida de un ideal razonable:

      [internet]
          |
    outer-firewall--- [proxy-zone]
          |      
         ----- [app-zone]
          |
    inner-firewall 
[lan]--/         \-- [database-zone]

1. Ejecute un proxy inverso, Apache + mod_security / varnish / nginx / WAF / lo que sea, en la zona de proxy. Agregue balanceo de carga / failover aquí si es necesario también. También servidor proxy / de retransmisión para conexiones salientes (DNS, SMTP, proxy HTTP), si es necesario.
2. Cuando la lógica de la aplicación se ejecuta en un servidor web (Java / PHP / ASP), prefiero llamarlo servidor de aplicaciones.
3. Cuando necesita escalar, puede escalar horizontalmente, los balanceadores de carga lo hacen más fácil. También puede considerar la replicación de contenido estático no autenticado a los proxies front-end.
4. es posible que desee agregar una o más de las zonas: IDS, administración, copia de seguridad, acceso remoto, proxy de salida

Estás intentando mitigar, por lo que:

• la comunicación entre zonas debe limitarse al mínimo requerido para fines de servicio y monitoreo.
• reverse-proxy acepta conexiones no confiables de Internet, solo puede conectarse a servicios en servidores de aplicaciones. Si desea clasificar sus zonas por tráfico, debe considerar cuidadosamente la terminación de HTTPs, y si desea crear nuevas conexiones HTTP a los servidores de aplicaciones.
• la zona de la aplicación acepta conexiones de confianza parcial desde proxies, solo puede conectarse a bases de datos. Puedes confiar un poco más en tus servidores de aplicaciones cuando sabes que no están hablando directamente a Internet.
• los servidores de bases de datos solo aceptan conexiones desde los servidores de aplicaciones, la zona de la base de datos debe ser su red "más limpia"
• considere usar diferentes firewalls (proveedor / producto) para los firewalls externos e internos
• para los servicios de salida requeridos (DNS, SMTP o parches / actualizaciones), estos deben ir a través de un servidor distinto (por ejemplo, en la zona proxy o en la zona proxy saliente).
• lo mismo sucede con cualquier conexión HTTPS de validación de CC saliente. (Si tiene la mala suerte de tener una caja negra proporcionada por un proveedor para la validación, eso también debería ir en una zona dedicada, IMHO).
• use direcciones IP públicas solo en la zona proxy, direcciones privadas en otros lugares. Ningún servidor fuera de la zona proxy necesita tener una IP pública, NAT o una ruta predeterminada a Internet.

Las zonas separadas facilitan el trabajo de su IDS y hacen que el registro sea más efectivo. Si tiene los recursos, agregue una zona de administración, NIC de administración separadas para cada servidor (puertos protegidos, si puede).

En realidad, puede terminar compactando la "red ideal" a un único firewall y VLAN, pero si considera sus opciones ahora con lo anterior en mente, debería ser más fácil migrar en el futuro, es decir, poco después de la próxima visita de su amigable auditor PCI-DSS de barrio ;-)

La siguiente es una configuración bastante común para el architecutre de DMZ:

Internet

^

Firewall1

^

DMZ (aloje sus servidores dmz aquí solo permitiendo puertos específicos a través del firewall)

^

Firewall2

^

Red de base de datos (solo permite puertos y protocolos específicos desde firewall2 a esta red)

Como menciona, la base de datos contiene datos de tarjetas de crédito (confidenciales), incluso en el interior del firewall2, la red de la base de datos debe estar separada de las redes corporativas y de usuarios. Muchas veces veo las joyas de la corona de una compañía abierta en la red interna para que todos los usuarios puedan probar y acceder. Yendo un paso más allá, podría tener una base de datos. La VLAN de administración solo permite que los sistemas dentro de esta VLAN tengan permiso para acceder a las bases de datos (aparte de la aplicación que necesita acceder a la DMZ, por supuesto).

Espero que esto ayude.

3-Tier Architecture es la solución más segura y escalable. A medida que aumenta el tráfico de clientes, podemos sumar tantos niveles intermedios necesarios para garantizar el rendimiento. La arquitectura de tres niveles también es más segura porque la capa intermedia protege el nivel de la base de datos. Necesitamos proteger el nivel de la base de datos del acceso directo y debemos ubicarlo en una zona de confianza y solo debe aceptar conexiones de servidores de aplicaciones.

Como tendrá que cumplir con PCI-DSS, también deberá asegurarse de que tiene firewalls en cada conexión a Internet y entre DMZ y redes internas. Hay algunos buenos indicadores en los cuestionarios de autoevaluación.

Tampoco cree que el servidor de la base de datos si un cuadro de wintel sea miembro del dominio, etc.

Preferiría una arquitectura en la que el servidor DB esté protegido por algo más que un firewall. Es decir, asumiría que el servidor web se ve comprometido, pero en lugar de poder realizar operaciones de base de datos arbitrarias, solo puede obtener datos extremadamente limitados de un servidor intermediario. Un entusiasta de la base de datos afirmaría que cualquier base de datos tendrá incorporada la verificación de privilegios suficiente. Pero bueno, la defensa en profundidad.