database - ¿Por qué no es aconsejable tener la base de datos y el servidor web en la misma máquina?

security networking (18)

Al escuchar la entrevista de Scott Hanselman con el equipo Stack Overflow ( parte 1 y 2 ), insistió en que el servidor SQL y el servidor de aplicaciones deberían estar en máquinas separadas. ¿Esto solo es para asegurarse de que si un servidor está en peligro, no se puede acceder a ambos sistemas? ¿Las preocupaciones de seguridad superan la complejidad de dos servidores (costo adicional, conexión de red dedicada entre los dos, más mantenimiento, etc.), especialmente para una aplicación pequeña, donde ninguna de las piezas usa demasiada CPU o memoria? Incluso con dos servidores, con un servidor comprometido, un atacante podría causar daños graves, ya sea borrando la base de datos o jugando con el código de la aplicación.

¿Por qué sería esto tan importante si el rendimiento no es un problema?

Seguridad. Su servidor web vive en una zona desmilitarizada (DMZ), tiene acceso a internet público y recibe información no confiable de usuarios anónimos. Si su servidor web se ve comprometido y usted ha seguido las reglas de privilegio mínimo para conectarse a su base de datos, la exposición máxima es lo que su aplicación puede hacer a través de la API de la base de datos. Si tiene un nivel de negocios intermedio, tiene un paso más entre su atacante y sus datos. Si, por otro lado, su base de datos está en el mismo servidor, el atacante ahora tiene acceso raíz a sus datos y servidor.
Escalabilidad Mantener su servidor web sin estado le permite escalar sus servidores web horizontalmente sin esfuerzo. Es muy difícil escalar horizontalmente un servidor de base de datos.
Actuación. 2 cajas = 2 veces la CPU, 2 veces la RAM y 2 veces los ejes para acceder al disco.

Dicho todo esto, ciertamente puedo ver casos razonables de que ninguno de esos puntos realmente importa.

¡De acuerdo! Aquí está la cosa, es más seguro tener su Servidor DB instalado en otra Máquina y su Aplicación en el Servidor Web. A continuación, conecta su aplicación a la base de datos con un enlace web. Gracias.

Argumentar que hay una ganancia de rendimiento real al ejecutar un servidor de base de datos en un servidor web es un argumento defectuoso.

Dado que los servidores de bases de datos toman cadenas de consulta y devuelven conjuntos de resultados, los datos que realmente fluyen del servidor de datos al servidor web son relativamente pequeños, pero la potencia requerida para procesar la consulta y generar el conjunto de resultados es relativamente grande. Por lo tanto, optimizar el rendimiento en torno al tiempo de transferencia de datos se está optimizando en torno a lo incorrecto.

Con respecto a la seguridad, hay ventajas de tener el servidor de datos en una caja diferente a la del servidor web. Tener una configuración de este tipo no es la seguridad total, pero es un paso en la dirección correcta.

Con respecto a la escalabilidad, es fácil y relativamente económico agregar servidores web y ponerlos en clúster para manejar un mayor tráfico. No es tan fácil y barato agregar servidores de datos y agruparlos. Además, los servidores web y los servidores de datos tienen diferentes necesidades de hardware, por lo que múltiples cuadros ayudan con la escalabilidad.

Si está empezando de a poco y tiene solo una casilla, entonces una buena manera sería usar máquinas virtuales. Ejecutar el servidor web y el servidor de datos en diferentes máquinas virtuales en un servidor le ofrece todas las ventajas de los cuadros separados a costa de un precio de caja grande.

Creo que el gran factor sería el rendimiento. Tanto el servidor web / código de la aplicación como el servidor SQL almacenarían en caché los datos comúnmente solicitados en la memoria y usted está eliminando el rendimiento de la memoria caché ejecutándolos en el mismo espacio de memoria.

Creo que es porque las dos máquinas normalmente deberían optimizarse de diferentes maneras. Aparte de eso, no tengo ni idea, ejecutamos todas nuestras aplicaciones con la base de datos del servidor en la misma máquina, con la condición de que no nos enfrentemos al público, pero no hemos tenido problemas.

No puedo imaginar que a muchas personas les importe que una máquina se vea comprometida debido a que la aplicación web generalmente tendrá acceso casi ilimitado al menos a los datos, sino al esquema dentro de la base de datos.

Interesado en lo que otros podrían decir.

Depende de la aplicación y el propósito. Cuando la alta disponibilidad y el rendimiento no son críticos, no está mal no separar el DB y el servidor web. Especialmente considerando las ganancias de rendimiento: si la aplicación realiza una gran cantidad de consultas a la base de datos, se puede eliminar una cantidad considerable de carga de red manteniéndola todo en el mismo sistema, manteniendo los tiempos de respuesta bajos.

El sistema operativo es otra consideración. Si bien su base de datos puede requerir espacios de memoria más grandes y, por lo tanto, UNIX, su servidor web, o más específicamente su servidor de aplicaciones, ya que menciona solo dos niveles, puede estar basado en .Net y, por lo tanto, requiere Windows.

En realidad no importa (puede ejecutar su sitio con web / base de datos en la misma máquina), es simplemente el paso más fácil de escalar.

Es exactamente lo que hizo , comenzando con una sola máquina que ejecutaba IIS / SQL Server, luego cuando comenzó a cargarse mucho, se compró un segundo servidor y el servidor SQL se movió hacia eso.

Si el rendimiento no es un problema, no desperdicie dinero comprando / manteniendo dos servidores.

Escuché ese podcast, y fue divertido, pero el argumento de seguridad no tenía sentido para mí. Si ha comprometido el servidor A, y ese servidor puede acceder a los datos en el servidor B, entonces tendrá acceso instantáneamente a los datos en el servidor B.

Estoy de acuerdo con Daniel Earwicker: la pregunta de seguridad es bastante defectuosa.

Si tiene una configuración de cuadro único con un servidor web y solo la base de datos para ese servidor web, si dicho servidor está en peligro, perderá el servidor web y solo la base de datos para esa aplicación específica.

Esto es exactamente lo mismo que sucede si pierde el servidor web en una configuración de 2 servidores. Pierdes el servidor web y solo la base de datos para esa aplicación específica.

El argumento de que "el resto de la integridad del servidor DB se mantiene" donde tiene una configuración de 2 servidores es irrelevante, porque en el primer escenario, todos los demás servidores de bases de datos relacionados con cada otra aplicación (si los hay) tampoco se ven afectados. - ser, como están, alojados en otro lugar.

Del mismo modo, a la pregunta planteada por Kev ''¿qué pasa con todas las otras bases de datos que residen en el servidor de base de datos? Todo lo que has perdido es una base de datos.

si estuviera alojando una aplicación y base de datos en un servidor, solo alojaría bases de datos en ese servidor relacionadas con esa aplicación. Por lo tanto, no perderá ninguna base de datos adicional en una configuración de servidor único si se compara con una configuración de servidor múltiple.

Por el contrario, en una configuración de 2 servidores, donde el atacante tenía acceso al servidor web, y por proxy, derechos limitados (en el mejor de los casos) al servidor de la base de datos, podían poner en riesgo las bases de datos de cualquier otra aplicación llevando fuera lento, consultas intensivas en memoria o maximizando el espacio de almacenamiento disponible en el servidor de la base de datos. Al separar las aplicaciones en sus propias preocupaciones, de forma muy similar a la virtualización, también las aíslas por motivos de seguridad de manera positiva.

La seguridad es una gran preocupación. Idealmente, su servidor de base de datos debería estar sentado detrás de un firewall con solo los puertos necesarios para realizar el acceso a datos abierto. Su aplicación web se debe conectar al servidor de la base de datos con una cuenta SQL que tenga los derechos suficientes para que la aplicación funcione y no más. Por ejemplo, debe eliminar los derechos que permiten la caída de objetos y, sin duda, no debe conectarse con cuentas como ''sa''.

En caso de que pierda el servidor web a un secuestro (es decir, una escalada de privilegios completa a derechos de administrador), el peor escenario es que la base de datos de su aplicación puede verse comprometida, pero no todo el servidor de la base de datos (como sería el caso si servidor de base de datos y servidor web eran la misma máquina). Si ha cifrado las cadenas de conexión de su base de datos y el hacker no es lo suficientemente inteligente como para descifrarlas, todo lo que ha perdido es el servidor web.

Las licencias de base de datos no son fáciles de usar y, a menudo, se cobran por CPU, por lo tanto, al separar los servidores web, puede reducir el costo de las licencias de la base de datos.

Por ejemplo, si tiene 1 servidor que realiza tanto la web como la base de datos que contiene 8 CPU, tendrá que pagar una licencia de 8 cpu. Sin embargo, si tiene dos servidores, cada uno con 4 CPU y ejecuta la base de datos en un servidor, solo tendrá que pagar por una licencia de 4 CPU

Por otro lado, refiriéndose a un blog diferente Scott (Watermasyck, de Telligent), descubrieron que la mayoría de los usuarios podían acelerar los sitios web (usando el servidor comunitario de Telligent), colocando la base de datos en la misma máquina que el sitio web. Sin embargo, en el caso de sus clientes, generalmente el servidor de base de datos y el servidor web son las únicas aplicaciones en esa máquina, y el sitio web no está forzando tanto la máquina. Entonces, la eficiencia de no tener que enviar datos a través de la red más compensó la mayor tensión.

Puedo decir de primera mano que a menudo es una buena idea colocar el servidor web y la base de datos en diferentes máquinas. Si tiene una aplicación que consume muchos recursos, puede hacer que los ciclos de la CPU en la máquina lleguen a su punto máximo, esencialmente paralizando la máquina. Sin embargo, si su aplicación tiene un uso limitado de la base de datos, probablemente no sea gran cosa hacer que compartan un servidor.

Tom tiene razón en esto. Algunas otras razones son que no es rentable y que existen riesgos de seguridad adicionales.

Los servidores web tienen diferentes requisitos de hardware que los servidores de bases de datos. A los servidores de bases de datos les va mejor con mucha memoria y una matriz de discos realmente rápida, mientras que los servidores web solo requieren suficiente memoria para almacenar en caché los archivos y solicitudes frecuentes de bases de datos (dependiendo de su configuración). En cuanto a la rentabilidad, los dos servidores no serán necesariamente menos costosos, sin embargo, la relación entre rendimiento y costo debería ser mayor ya que no es necesario que diferentes aplicaciones compitan por los recursos. Por esta razón, es probable que tenga que gastar mucho más para un servidor que atienda a ambos y ofrezca un rendimiento equivalente a 2 especializados.

La preocupación de seguridad es que si la única máquina se ve comprometida, tanto el servidor web como la base de datos son vulnerables. Con dos servidores, tiene algo de espacio para respirar, ya que el segundo servidor seguirá siendo seguro (al menos por un tiempo).

Además, existen algunos beneficios de escalabilidad, ya que es posible que solo deba mantener unos pocos servidores de bases de datos que son utilizados por varias aplicaciones web diferentes. De esta forma, tendrá que trabajar menos para aplicar actualizaciones o parches y realizar ajustes de rendimiento. Sin embargo, creo que hay herramientas de administración de servidor para facilitar estas tareas (en el caso de una sola máquina).

Un factor que aún no se ha mencionado es el equilibrio de carga. Si comienza pensando en el servidor web y la base de datos como máquinas separadas, optimiza para menos viajes redondos de red y también es más fácil agregar un segundo servidor web o un segundo motor de base de datos a medida que aumentan las necesidades.

Una preocupación adicional es que a las bases de datos les gusta tomar toda la memoria disponible y mantenerla en reserva para cuando quiera usarla. Puede obligarlo a limitar la memoria, pero esto puede ralentizar considerablemente el acceso a los datos.

Wow, nadie menciona el hecho de que si realmente compra SQL Server con 5k bucks, es posible que desee usarlo para más de su aplicación web. Si usas express, tal vez no te importe. Veo que los servidores SQL ejecutan bases de datos para 20 a 30 aplicaciones, por lo que ponerlo en el servidor web no sería inteligente.

En segundo lugar, depende de para quién es el servidor. Trabajo para las compañías financieras y el gobierno. Por lo tanto, utilizamos un método alocado para el dolor de usar sprocs y limitar puertos desde el servidor web a SQL. Entonces, si la aplicación web es pirateada Lo único que el hacker puede hacer es llamar a sprocs ya que la cuenta de usuario en el servidor web está bloqueada para solo ver / llamar a sprocs en la base de datos. Entonces, el hacker tiene que descubrir cómo ingresar al DB. Si está en el servidor web, es fácil de encontrar.