Servidores web con diferentes modelos de riesgo en la misma red

Question

Servidores web con diferentes modelos de riesgo en la misma red

#1 de dFrancisco (2 votos)
#2 de Suedish (0 votos)

2

Esta pregunta proviene de un aspecto de seguridad en lugar de un aspecto de enrutamiento / red (es por eso que elegí aquí en lugar del error del servidor).

Estamos creando una arquitectura de red y tenemos 2 servidores web. Uno de los servidores web tiene acceso a una base de datos muy sensible (en la "capa de base de datos") con una evaluación de riesgos completamente diferente. En una escala de 1-10, estos datos son un 7. El otro servidor web tiene datos sin sentido, un 2/10.

Un asociado mío cree que, dado que ambos son servidores web y que ambos permiten el puerto 443,80, deben colocarse en la misma red. Ellos creen que si establecemos una política (servidores web en una zona insegura), todos los servidores web que cumplan con esta "política" deberían ubicarse en la misma red. No estoy de acuerdo con este enfoque. Tenemos toneladas de espacio de direcciones, ¿por qué no lanzar el servidor web sin sentido y su base de datos en una red separada? Entiendo que es importante definir un modelo para su arquitectura, es decir, "red insegura", "capa de base de datos", capa de aplicación ". Pero cuestiono que solo porque dos servidores sean un servidor web, no necesariamente significa que deban estar en contacto. Con seguridad. Podríamos implementar un servidor de seguridad basado en host y un enrutamiento inteligente, pero POR QUÉ ... Me preocupa que si se produce una brecha en el servidor web sin sentido, el atacante podría, en teoría, obtener acceso al servidor web muy sensible .

No estoy buscando quién tiene razón, porque veo ambos lados.

Mi pregunta es que si dos servidores ejecutan el mismo software (servidor web), deben colocarse en la misma red, ya que requieren acceso a información que se encuentra en niveles de amenaza diferentes (por falta de un término mejor). ?

risk-management webserver risk-analysis

pregunta pm1391 02.02.2018 - 21:49

fuente

2 respuestas

Lea otras preguntas en las etiquetas risk-management webserver risk-analysis

UDP vs ICMP flood conjuntos de cifrado TLS / SSL

score 2 · Answer 1

El aislamiento nunca es malo. En un sentido general muy genérico, imagina un submarino. Están diseñados con el conocimiento de que las cosas van a explotar, sobre o cerca de ellos. Es por eso que están compartimentados, lo que permite que un casco roto rompa solo el piso 1/16 del submarino. No por casualidad, los submarinos también son muy buenos para no hundirse (y permanecer hundidos).

Presumiblemente, sus dos servidores web tienen diferentes credenciales de escritorio remoto (o telnet o SSH de su elección) y si no lo tienen, eso ya es un problema importante. En general, un servidor web que contiene información secreta de nivel 7/10 (supondré al menos información bastante personal si no es información financiera o relacionada con impuestos o salud) la contraseña para esa máquina podría ser mucho mejor pensada, por ejemplo, una contraseña crpyto-aleatoria de caracteres. Al menos eso es lo que podría hacer. Alternativamente, mi servidor web secreto 2/10 podría tener una contraseña fácil de recordar, porque somos humanos y perezosos. Por ejemplo, tal vez el nombre de usuario es admin y la contraseña es adminCompanyNameSecret. Aún no es fácil de adivinar, pero es mucho más predecible que una contraseña criptográfica aleatoria.

Espero que veas a dónde voy aquí. Naturalmente, como administradores, practicaremos precauciones de seguridad más relajadas en servidores que tienen un objetivo de menor valor. El problema es que estoy seguro de que, una vez que un atacante pueda acceder al servidor A, llegar al servidor B (servidor seguro) en la misma red será mucho más fácil que acceder al servidor B desde fuera de la red.

Por lo tanto, no hay nada de malo en mantener ambos servidores en la misma red y, como usted dijo, podría tener sentido desde el punto de vista de la arquitectura, pero si lo hace, debe hacer lo siguiente:

Trate AMBOS los servidores de secreto 2/10 y 7/10 como si fueran servidores de secreto 7/10. Asegúrese de que ambos estén completamente actualizados en todas las actualizaciones del sistema operativo, siga las buenas prácticas con acceso físico y seguridad, contraseñas criptográficas aleatorias y nombres de usuario únicos. Asegúrese de que solo unos pocos conozcan las contraseñas, etc. Si sigue esto, estará tan seguro como si hubiera aislado los dos servidores. Si trata el 2/10 como un servidor de secreto 2/10, prácticamente acaba de degradar el valor de los datos en el otro servidor a 2/10 también.

score 0 · Answer 2

Sugiero encarecidamente que deben estar separados. Como son dos servidores web diferentes y sirven contenido diferente, hay más lugares posibles de introducción de vulnerabilidades. O tal vez el servidor web "menos importante" no esté parcheado / probado con frecuencia, ya que de todos modos no contiene datos confidenciales, entonces ese es un lugar donde un atacante podría girar al servidor sensible.