it-swarm-es.com

¿Cuál es la mejor práctica para colocar servidores de bases de datos en topologías de red seguras?

Tengo una arquitectura clásica DMZ:

enter image description here

Mi servidor web está ubicado en la DMZ. El servidor web necesita comunicarse con un servidor de base de datos. Este servidor de base de datos es el componente más crítico de mi red ya que contiene datos confidenciales.

¿Dónde debo colocar el servidor de base de datos y por qué? ¿Debo agregar un segundo firewall y crear otra DMZ?

20
lisa17
  • 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 generalmente dicta unas pocas máquinas más (db admin, etc.). Obedezca la realidad según sea necesario, por supuesto.
  • Solo deberían estar haciendo conexiones salientes si está actualizando el software en ellas.
26
Jeff Ferland

De acuerdo con Jeff Ferland, los servidores de bases de datos deben estar solos: debe tener una red limpia para replicación y respaldo.

Perdón my ASCII art, una descripción 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 equilibrio de carga/conmutación por error aquí si es necesario también. También servidor proxy/retransmisor 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 un servidor de aplicaciones.
  3. Cuando necesite escalar, puede hacerlo horizontalmente, los equilibradores de carga lo hacen más fácil. También puede considerar replicar contenido estático no autenticado en los servidores proxy de front-end.
  4. es posible que desee agregar una o más zonas: IDS, administración, respaldo, acceso remoto, proxy saliente

Estás intentando mitigar, así 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 la terminación cuidadosa de los HTTP, y si desea crear nuevas conexiones HTTP a los servidores de aplicaciones.
  • la zona de aplicación acepta conexiones semi-confiables de servidores proxy, puede conectarse solo a bases de datos. Puede confiar un poco más en sus servidores de aplicaciones cuando sabe que no están hablando directamente a Internet.
  • los servidores de bases de datos aceptan conexiones solo de servidores de aplicaciones, la zona de bases de datos debe ser su red "más limpia"
  • considere usar diferentes firewalls (proveedor/producto) para los firewalls externos e internos
  • para los servicios requeridos saliente (DNS, SMTP o parches/actualizaciones) estos deben ir a través de un servidor distinto (por ejemplo, en la zona de proxy o la zona de proxy de salida).
  • lo mismo ocurre con las conexiones HTTPS de validación CC salientes. (Si tiene la mala suerte de tener una caja negra proporcionada por el proveedor para la validación, eso también debería ir en una zona dedicada, en mi humilde opinión).
  • utilice el direccionamiento IP público solo en la zona de proxy, el direccionamiento privado en otro lugar. Ningún servidor fuera de la zona de proxy necesita tener una IP pública, NAT o una ruta predeterminada a Internet.

Las zonas separadas facilitan el trabajo de su IDS y el registro es 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 vecindario Auditor PCI-DSS ;-)

21
mr.spuratic

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

Internet

^

Cortafuegos1

^

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

^

Cortafuegos2

^

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

Como usted menciona que la base de datos contiene datos de tarjetas de crédito (confidenciales), incluso en el lado interno 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 empresa abierta de par en par en la red interna para que todos los usuarios la prueben y accedan. Yendo un paso más allá, podría tener una base de datos admin VLAN solo permite que los sistemas dentro de este permiso VLAN) accedan a las bases de datos (aparte de la aplicación que necesita acceder desde el DMZ por supuesto).

Espero que esto ayude.

1
fixulate

La arquitectura de 3 niveles 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 colocarlo en una zona de confianza y solo debe aceptar conexiones de servidores de aplicaciones.

3 Tier Architecture

1
Ali Ahmad

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

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

0
Matthew

Preferiría una arquitectura donde el servidor de base de datos esté protegido por algo más que un firewall. Es decir, supondrí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 DB afirmaría que cualquier DB tendrá suficiente verificación de privilegios incorporada. Pero bueno, defensa en profundidad.

0
markhahn