¿Cómo explica a los expertos que un servidor de base de datos no debe residir en la DMZ?

"Haga que su red sea segura para las bases de datos" ( enlace ) se lee un poco anticuado en algunas secciones, pero proporciona un nivel decente de orientación "para tontos" en la dirección que está buscando.

También podría agotarse hurgando en el centro de recursos del NIST de EE. UU. ( enlace ). Creo que la ISO / IEC 27033-2: 2012 de ISO también estaría en el tema, pero no tengo una copia a mano para estar seguro.

Está intentando separar / aislar los servidores más sensibles (los servidores de base de datos) de los más expuestos (y, por lo tanto, vulnerables).

Estás proponiendo un enfoque de "defensa en profundidad", que busca a) prevenir ataques cuando sea posible, y b) retrasar su progreso (y el acceso a las cosas importantes) cuando no.

Idealmente, todo está siempre reforzado y parcheado, los servidores solo escuchan el tráfico en los puertos requeridos, y solo desde los dispositivos permitidos, todo el tráfico "en vuelo" es inaccesible para oyentes no autorizados (a través de cifrado y / o aislamiento), y todo está Monitoreado por intrusión e integridad.

Si todo eso está en su lugar con un 100% de certeza, entonces, su "oposición" ha abordado el punto a) anterior, tanto como sea posible . Gran comienzo, pero ¿qué pasa con el punto b)?

If un servidor web se ve comprometido, su arquitectura propuesta se encuentra en un lugar mucho mejor. Su potencial huella de ataque, y su vector, es mucho más grande de lo que debe ser.

La justificación para una base de datos separada de los servidores web no es diferente de la justificación que han aceptado para separar los servidores web de la LAN. Más claramente: si están tan convencidos de que un servidor web comprometido no representa ningún peligro para otros sistemas en la misma zona de seguridad, ¿por qué creen que se requiere una DMZ?

Es muy frustrante estar en tu situación. Por lo menos, en su posición, crearía una nota de riesgo que describa sus inquietudes y sugerencias, y me aseguraré de que lo reconozcan. CYA, de todos modos.

  

Es como, "¿Poner el joyero fuera de la casa para que los ladrones no se molesten en entrar al televisor?"

Sí, es exactamente así.

Si no te importa el valor de la base de datos, en términos relativos, entonces seguro que tiene sentido dejarlo afuera - si se asume que la aplicación es terriblemente insegura, pero debes publicarla de todas formas Razón, y no quiero asegurarla, entonces esto tiene sentido como una manera de aislar este horrible sistema inseguro de todos los otros sistemas internos.

Por otro lado, realmente no hay excusa para esperar tener TAL una aplicación insegura que permita la toma completa del servidor de la base de datos. Además, no hay una razón real para utilizar la "exposición" como alternativa al "aislamiento", también hay soluciones simples para hacerlo bien.

Cuando se trata de eso, parece que esta es una de las 2 situaciones posibles:

1. Estos llamados "expertos" son realmente despistados.
2. Hay otros requisitos comerciales que se están negociando aquí.

Creo que tu analogía funciona perfectamente. Si luego te dicen el equivalente a "En realidad, esas joyas son falsas, por cierto, el televisor es realmente un trabajo personalizado de 60" 5K con llantas de oro ", entonces eso podría ser una compensación razonable (aunque es mejor hacerlo bien, aunque ).
De lo contrario, es probable que no haya forma de explicarlo, ya que están trabajando por falta de conocimiento.

Si la base de datos contiene los detalles de la tarjeta, se puede argumentar muy fácilmente que no está cumpliendo con el requisito de PCI DSS sobre la protección adecuada.

También falla las comprobaciones de integridad en puntos únicos de falla y protege sus activos principales.

Si los datos valen miles de millones, ¿por qué no gastaría unos pocos miles más para agregar capas de protección? La buena práctica de la industria es tener zonas de seguridad en capas.

Puede apuntarlos a PCI, a la Guía de buenas prácticas de ISF y a muchas otras.

Si está sugiriendo que el servidor de la base de datos pase de estar en la misma zona de seguridad que el servidor web a estar en la misma zona de seguridad que algunos sistemas internos, uno podría concluir razonablemente que está reduciendo la seguridad.

Si el status quo es que el servidor web y el servidor de base de datos están ambos en la DMZ, y no se permiten conexiones de DMZ a la red interna, entonces mover el servidor de la base de datos de DMZ a la red interna requeriría permitir las conexiones de DMZ a la red interna. Eso significaría que está reduciendo la seguridad de la red interna sin obtener una protección significativamente mejor para la base de datos.

Si realmente cree que la base de datos es más sensible que la red interna (lo que podría ser cierto), no querría que la red interna se vea comprometida para obtener acceso directo a la base de datos.

Por lo tanto, lo que debe señalar es que no desea mover el servidor de la base de datos de una zona de seguridad a otra, en lugar de lo que desea hacer es crear una zona de seguridad completamente nueva. Para cumplir realmente con eso, realmente tendría que comprar un cortafuegos adicional y colocarlo entre la DMZ y la red extra segura.

Luego se reduce a evaluar el costo de comprar y mantener este firewall adicional contra la seguridad adicional que proporciona.

AvID ya ha cubierto la pregunta principal, pero debido a un ángulo ligeramente diferente, la mayoría de los firewalls soportarán múltiples interfaces y pueden proporcionar control del tráfico entre las interfaces.

La configuración de las múltiples interfaces para alojar cada uno de los aspectos de la solución (frontend, middleware, backend) reduciría el riesgo de un futuro compromiso de la base de datos desde el servidor web sin necesidad de múltiples firewalls físicos (si es lo que hacen los otros equipos). están preocupados por ... ¿es un problema de costo?) y sin introducir una ruta a la red interna.

Solo me pregunto si esto le daría una 'palanca' práctica para apoyar el argumento para implementar alguna separación, es decir, aporta algo diferente a la discusión que deben contrarrestar.

En su defecto, ¿qué pasa con una situación hipotética basada en una vulnerabilidad histórica del servidor web, que habría resultado en un compromiso posterior de cualquier otro servidor en el mismo segmento de red (incluida la base de datos) y cómo una DMZ en capas evitaría el avance? compromiso, presumiblemente habría un costo monetario por lo que sería "fácil" ilustrar el costo / esfuerzo beneficio?

Suponiendo que está intentando persuadirlos para que lo hagan en lugar de (necesariamente) convencerlos de que es correcto:

Explique que cuando sus grandes clientes y prospectos hagan una auditoría de seguridad, fallarán.

Si el obstáculo es el negocio, esa será la única razón suficiente y solo necesaria.

@Craig ... buena respuesta sensata práctica. Dado que bruce_bana dijo que el costo no debería ser un problema, esto debería ser realista para implementar después de usar la respuesta de @DerekM (que también es buena) para convencer a los supuestos expertos en seguridad. @DTK ... buen negocio CYA responde. Este definitivamente lo implementaría si fuera bruce_bana. @bruce bana ... intente este enlace desde este sitio para una solución / problema comparable / relacionado ... ¿Cuál es la mejor práctica para colocar servidores de bases de datos en topologías de red seguras?

Un buen argumento es que la barra realmente no es tan alta para separar los servidores web y los servidores de bases de datos en DMZ independientes.

Use un enrutador / cortafuegos real, y coloque los servidores web y los servidores de bases de datos en VLAN separadas, ambas fuera de la LAN interna segura, con reglas de cortafuegos que controlan el acceso a los puertos mínimos necesarios desde Internet a los servidores web. desde los servidores web a los servidores de bases de datos, y ningún acceso originado desde los servidores web a la LAN segura.

El servidor de seguridad también evitaría cualquier acceso directo desde Internet a los servidores de la base de datos, y controlaría estrechamente cualquier acceso desde los servidores de la base de datos hacia la LAN segura (con fines de autenticación o lo que sea).

De esa manera, el atacante ni siquiera puede acceder directamente a la red que contiene los servidores de la base de datos.

Si obtienen una cabeza de playa en uno de sus servidores web, todavía no están en la misma red con acceso sin restricciones para atacar su (s) servidor (es) de base de datos, y si tiene algún tipo de monitoreo de registros, debería recibir notificaciones sobre la violación de los servidores web antes de que los atacantes hayan tenido mucho tiempo para atacar a cualquier otra cosa.

Incluso si luego logran violar sus servidores de base de datos después de un período de tiempo a través del único puerto abierto que el servidor web utiliza para comunicarse con la base de datos, han perdido todo ese tiempo realizando relativamente poco, durante ese tiempo ha sido consciente de su ataque, en lugar de pasar todo ese tiempo entrando en su LAN segura.

Ni siquiera pueden llegar a la LAN desde la DMZ donde viven los servidores web, por lo que su única ruta a la LAN en cualquier forma es saltar a los servidores de la base de datos, protegidos en la otra DMZ. Es probable que los servidores de su base de datos estén o estén vinculados a algún tipo de sistema de autenticación empresarial (Active Directory o lo que sea). ¿Desea esa capacidad en la misma DMZ con sus servidores web públicos?

Si puedo preocuparme lo suficiente por los problemas de seguridad para crear subredes de invitado y DMZ en mi página principal , para tener un lugar donde colocar "cosas" ("Internet de las cosas") sin tenerlas directamente en Mi LAN, una preocupación que vale miles de millones de dólares puede permitirse el lujo de compartir la mente y el tiempo para hacer lo mismo con servidores web importantes y servidores de bases de datos. Lo hago en la oficina con una combinación de una pila de conmutadores L2 / L3 administrados por Procurve de varios miles de dólares, un SonicWall UTM y un enrutador Ubiquiti EdgeMax. En home , tengo un Ubiquiti EdgeRouter Lite de $ 100, un switch HP de 8 puertos administrado por $ 100 y un Ubiquiti Unifi AP que admite múltiples VLAN, y mi configuración es totalmente capaz de hacer lo que estamos hablando. .

Y tengo la tranquilidad de no preocuparme de que mi DVR, impresora, reproductor de BluRay, termostato y cualquier otra cosa conectados a la red ejecuten el firmware obsoleto de BOBY BODY CON QUIÉN LO SABE, lo que no se ha descubierto exploits, pueden ser pirateados y llegar a mi computadora y archivos personales a través de la red.

No es muy difícil para los expertos en seguridad configurar este tipo de cosas, y ciertamente no tiene que involucrar hardware físico separado para cada firewall. SDN (redes definidas por software) está de moda en estos días, ¿verdad?

Incluso el EdgeRouter Lite de $ 100 puede enviar casi 1 Gbps a través del enrutador, con soporte para múltiples interfaces virtuales y reglas de firewall entre todas esas interfaces.

Una pequeña caja es realmente una cesta llena de cortafuegos.

Entonces, si gasta dinero real en un enrutador de nivel superior, obtendrá todas esas características y algunas más con un rendimiento de enrutamiento más sólido.

Incluso algo como Ubiquiti EdgeRouter Pro 8 le brinda 2 millones de paquetes por segundo por solo $ 375, con 8 interfaces físicas y subinterfaces VLAN en cada una de ellas, si las necesita. Si necesita un mayor rendimiento que eso, busque Brocade (Vyatta), Cisco, Juniper, etc. para hardware más grande. O algo así como la serie SuperMassive de Dell / Sonicwall. O ejecute el enrutador virtual Vyatta en un servidor Xeon de múltiples núcleos robusto.

No estoy tratando de vender enrutadores, solo estoy enfatizando que la barra no es tan alta para obtener el tipo de separación de seguridad que probablemente deberías tener y, obviamente, quieres aquí.

Dígale a su gerente directo que no está autorizado a aceptar ese riesgo en nombre de la compañía. Señale que el valor de los datos en la base de datos es $ xxx y que el nivel de aceptación del riesgo debe provenir de alguien autorizado para hacerlo, y pídale que defienda que un miembro de la gerencia ejecutiva apruebe la aceptación del riesgo.

Para estimar el valor de los datos, determine si se trata de datos vinculados a PCI DSS (si es así, observe el costo por cliente en el que Target / Home Depot ha incurrido en ventas perdidas, monitoreo de crédito, fraude), o si es PII (si es así, observe el daño financiero por paciente en el que los sistemas médicos han incurrido en pérdida de confianza, monitoreo de robo de identidad, pérdida de reputación) o si es la ventaja competitiva de su compañía (secretos comerciales, aún no datos financieros liberados, propiedad intelectual), entonces el valor de los datos podría ser la valoración actual de la empresa.

Si se le da una orden directa para aceptar el riesgo en nombre de la compañía, se le puede pedir que comience a actuar en calidad de funcionario de la compañía, y como tal, tiene una obligación (posiblemente una obligación legal) de señale que usted es una persona no designada a la que se le pide que se desempeñe como tal, y debe informar a la junta directiva de la cadena de administración. Esté preparado para una significativa explosión y para gastar un importante capital político para dar a conocer esto.

¡Buena suerte!