¿Es arriesgado tener un servidor de base de datos y un servidor web en la misma máquina?

Parece que la vida sería simple para ejecutar el servidor de base de datos en la misma máquina que el servidor web, pero ¿estamos asumiendo un gran riesgo al hacer esto?

El entorno será el servidor Windows 2008, Postgresql (última versión, posiblemente 9.0 cuando salga) y Apache 2.

No necesariamente.

Suponiendo que su servidor web se vea comprometido, el atacante seguirá obteniendo la credencial para acceder a las mismas bases de datos, sin importar en qué servidor se ejecuten. Después de todo, el servidor de bases de datos aún deberá configurarse para permitir solicitudes legítimas del servidor web.

(Suponiendo medidas de seguridad razonables como mysqld que no acepta el inicio de sesión de root sin contraseña de localhost).

Dicho esto, es posible que aún desee ejecutar un servidor de base de datos separado. La razón de esto está relacionada con el rendimiento, la escalabilidad, etc.

No estoy de acuerdo con los carteles que afirman que esto no es un problema de seguridad, y he aquí por qué:

• Su servicio frontal debe tener la superficie de ataque más pequeña posible . Esta es la razón principal para usar proxies inversos y firewalls, y para mantener los servicios y programas innecesarios lejos de los servidores que no requieren su funcionamiento. Esta es la razón por la cual los servidores web son los objetivos más comunes para los pases de seguridad.
• Su servidor web no debe tener derechos de dios sobre su sistema de base de datos. Por lo tanto, comprometer el servidor web no compromete también el servidor de la base de datos. Para empezar, la cuenta que utiliza el servidor web para acceder a la base de datos no debe tener derechos administrativos locales para el cuadro SQL, sus derechos deben limitarse únicamente a los permisos de la base de datos. En segundo lugar, dentro de esos permisos de SQL, debería funcionar bajo el principio del mínimo privilegio . Su cuadro web no debería ser capaz de instanciar nuevas bases de datos dentro de la instancia, por ejemplo. Idealmente, su cuadro web no tendrá la capacidad de soltar tablas o eliminar filas de cualquier tabla que no sea absolutamente necesario. Por lo tanto, en caso de un compromiso en una configuración de 2 niveles configurada correctamente, el impacto de un atacante que usa las credenciales de SQL tiene un alcance limitado.

Realmente dependería del modelo de seguridad de sus servidores web y de base de datos (es decir, el software), así como del grado de firewall / control de acceso / IDP que aplicaría en los dos si estuvieran en servidores separados.

Si todo lo demás es igual, es probable que sea mejor separar los dos. Sin embargo, en la práctica, al menos en un entorno LAMP, siempre que esté utilizando Apache Privsep (si no está seguro, no se preocupe, lo está) y no está utilizando el inicio de sesión raíz en MySQL en su aplicación web, y no tiene tcp / 3306 expuesto al mundo exterior, realmente no está ganando mucha seguridad al mover uno u otro a una pieza diferente de silicio. Sin embargo, obtienes beneficios de rendimiento y capacidad de depuración.

Su pregunta tiene el estilo que parece requerir una respuesta absoluta, pero sin más información (como mínimo, de qué sabores de SO y servidor web / DB estamos hablando), es difícil incluso dar una informativa.

No veo mucho riesgo de seguridad adicional al poner la base de datos y los servidores web en el mismo hardware. Si se infringe el servidor web, se puede acceder a los datos de todos modos. La seguridad no es la razón típica para segregar niveles.

En cualquier caso, desea asegurarse de que el servidor de la base de datos está escuchando en puertos no estándar, solo responderá a las solicitudes del servidor web y que el firewall solo permite solicitudes http / s al servidor web y no a otros puertos o direcciones .

Sin embargo, separarlos es una buena práctica ... cada servidor es más fácil de administrar y configurar, y puede lidiar con fallas, problemas, reconstrucciones, problemas de rendimiento, etc. Por lo tanto, puede considerar dos servidores virtuales en el mismo hardware, que luego se pueden separar cuando el rendimiento o la capacidad lo requieran.

No lo haría, pero ese soy yo.

Depende de lo que esté delante de su caja (es decir, cortafuegos, equilibradores de carga, etc.) y cuán 'ajustados' sean, cuáles son los datos reales (es decir, los datos disponibles públicamente ahora impactan en un extremo, los secretos nacionales en el otro) , si hay algún impacto en el rendimiento al combinarlos, la fuerza de la red entre ambos (es decir, firewalls entre niveles) y la calidad del endurecimiento del sistema operativo / aplicación que se aplicará.

Si no espera que este sistema tenga que lidiar con demasiada carga, una cosa que podría considerar sería virtualizar el sistema en dos máquinas virtuales separadas; uno por función, posiblemente con una tercera máquina virtual de firewall solo de software entre ellos, incluso. Esto significaría que incluso si alguien descifrara su servidor web, tendría que descifrar el servidor de la base de datos y, si se incluye, una máquina virtual de firewall intermedia. Por supuesto, esto reduciría el rendimiento general del sistema, pero sería al menos hasta cierto punto más seguro y también podría ayudar si su carga llegara a requerir un diseño de dos servidores, ya que simplemente podría mover una VM a la segunda máquina. El producto ESXi gratuito de VMWare podría hacer todo esto con bastante facilidad y ya hay VM firewall gratuitas preempaquetadas listas para su implementación si así lo desea.