¿Protecciones de servidor web y de base de datos no sensibles / no críticas?

El servidor de base de datos no crítico no necesariamente tiene que estar detrás de un segundo servidor de seguridad, pero se recomienda que resida en una DMZ separada o en una VLAN separada dentro de la misma DMZ (con ACL en su lugar) como mínimo .

Si entiendo su explicación correctamente, ¿parece que el servidor de base de datos no crítico en la DMZ está conectado a través de ODBC a los servidores de base de datos críticos en la LAN?

¿Qué lado tiene permiso para iniciar la comunicación a través del firewall?

Si se permite que el servidor de base de datos no crítico inicie la comunicación con los servidores de base de datos críticos en la LAN (para extraer datos), esto es muy malo.

Si los servidores de base de datos críticos en la LAN están iniciando la comunicación con el servidor de base de datos no crítico (para enviar datos), es más preferible.

Sin conocer los detalles íntimos, estoy cuestionando por qué este servidor de base de datos no crítico necesita interactuar con los servidores de base de datos críticos si no almacena datos confidenciales.

Cosas a tener en cuenta:

Si esta aplicación web no sensible es vulnerable a la inyección de SQL, la base de datos no crítica se verá comprometida.

Si el servidor web está comprometido por la vulnerabilidad XYZ, se puede usar como un punto de ataque para el servidor de base de datos no crítico.

La respuesta de k1BLITZ aborda un punto clave: es la necesidad de que la DMZ solo reciba tráfico entrante. Esto asegurará que, si alguien se hace cargo de los servidores de la DMZ, no podrá ir más lejos (a la LAN).

Para abordar sus otras preocupaciones:

• si el servidor web DMZ está comprometido, obviamente puede mostrar cualquier cosa, incluida una solicitud para que los usuarios se autentiquen, proporcionen detalles confidenciales, etc. Así que incluso si la integridad de los datos se conserva en las bases de datos de LAN, Todavía puede filtrarse a través de los usuarios.

• no intentes reinventar la rueda. Utilice OWASP como guía, especialmente en su caso la sección sobre SQL .

Odio ser crítico, pero creo que hay que señalarlo. Primero, la solución al problema es realmente un problema centrado en la aplicación y no un problema centrado en la red. Su método de corrección se basa en los métodos de protección de procesos y puertos heredados. Ignora las realidades de tus otras superficies de ataque.

Primero, dependiendo del tipo de firewalls que tenga, sus capacidades pueden ser limitadas de dpi (inspección profunda de paquetes). La mayoría de las vulnerabilidades ocurren en la capa de la aplicación y esta es la principal área de preocupación que se tratará en la capa de la aplicación. Su área de superficie primaria de internet será el servidor web. Algo con lo que DPI ayudará es limitar el tipo de declaraciones que se pueden ejecutar contra el servidor, a menos que la conexión esté encriptada desde el servidor web a la base de datos.

Incluso si los recursos no son críticos o tienen datos confidenciales, existe un nivel de impacto si la base de datos se ve afectada.

Una solución que puede ser más segura basada en el digram. Aquí hay un diagrama rápido de foo stick.

HTTP REQ- > endpoint_filter- > SQL-Statment-code- > statement-filter > SQL_Connection_timer- > foo

HTTP_RESP < -DPI < -Return Function < -foo             -Longitud             -filtro N

Veo que muchas compañías se hacen estallar debido al pensamiento centrado en la red.