Aplicación web única: ¿ventajas de seguridad para dos modelos de servidor?

3

Estoy buscando implementar infraestructura para una aplicación web que vivirá en una pila LAMP. La infraestructura es tal que esta es la única aplicación que vivirá en este servidor y debe ser lo más segura posible.

Tradicionalmente, implementamos un servidor front-end en una DMZ y tenemos un servidor DB en una red segregada y entre ellos hay una regla de firewall que solo permite que las llamadas TCP 3306 del servidor web vuelvan al servidor de la base de datos. Cuando varias aplicaciones viven en un servidor, veo la relevancia allí como si una aplicación / sitio fuera comprometido, entonces existe la posibilidad de poner en cuarentena los daños a la aplicación & Credenciales que se han cosechado.

Con una sola aplicación web, estoy luchando para ver cómo esto podría proporcionar un beneficio de seguridad. En teoría, si su servidor web se ve comprometido, la gente tendrá acceso a las credenciales de la base de datos que utiliza la aplicación en qué punto finaliza el juego, ¿no?

Desde una perspectiva estrictamente de seguridad, ¿cuáles son las razones principales para dividir la aplicación en servidores front-end y back-end?

    
pregunta user116218 30.06.2016 - 15:04
fuente

3 respuestas

1

En general, estoy de acuerdo con su implicación de que si solo tiene una aplicación web única, hay pocos beneficios de seguridad para mover la base de datos a un servidor separado. Dicho esto, podría haber algunos escenarios ideados donde podría haber un beneficio de seguridad. Por ejemplo, si la aplicación web no tiene derechos de administrador completos para la base de datos, un servidor web comprometido revelaría las credenciales para algún acceso a la base de datos, pero no todas. Si la base de datos residía en el mismo servidor web, presumiblemente, el atacante podría obtener acceso completo a la base de datos también, en lugar del acceso limitado para las credenciales encontradas. Un ejemplo de derechos de base de datos parciales puede dar a la aplicación web acceso de escritura a una tabla de registro pero no acceso de lectura.

    
respondido por el TTT 30.06.2016 - 16:20
fuente
0
  1. El rendimiento y la escalabilidad se mejoran implementándolo en dos servidores.
  2. Puedo imaginarme a alguien cometiendo errores de configuración y abriendo más puertos en el servidor de la base de datos. Debido a la presencia del firewall, esto no conducirá a una vulnerabilidad fácilmente.
respondido por el Silver 30.06.2016 - 16:01
fuente
0

Separarlos puede hacer que tu sistema sea mucho más difícil de atacar.

Por ejemplo, supongamos que hay un error de inyección de SQL en su sitio web. El atacante puede usar SELECT INTO OUTFILE para escribir un shell en su sistema.

por ejemplo

http://192.0.2.42/comment.php?id=738
union
all
select
1,2,3,4,"<?php
echo
shell_exec($_GET['cmd']);?>",6
into
OUTFILE
'c:/xampp/htdocs/backdoor.php'

Debido a que la base de datos se ejecuta en el mismo servidor, esto permite escribir el shell en la raíz web donde el atacante puede acceder a través del sitio web y obtener el control de su servidor.

Por supuesto, el permiso del sistema de archivos para la cuenta de proceso mysql y la raíz web normalmente se debe establecer de manera apropiada con el mínimo requerido, pero la separación de servicios en servidores diferentes es una buena defensa en profundidad enfoque.

Además, no todos los ataques son iguales. Podría haber un ataque que obtenga permisos de root para su servidor web, pero el atacante solo podría acceder a las tablas de la base de datos que el usuario del sitio web tiene permisos para leer (de nuevo, defensa en profundidad; asegúrese de que los permisos de la base de datos estén configurados con el principio de privilegio mínimo como objetivo). Si el DB estuviera en el mismo cuadro, el atacante tendría el control total de todos los datos.

    
respondido por el SilverlightFox 01.07.2016 - 08:32
fuente

Lea otras preguntas en las etiquetas