Aplicaciones sin servidor front-end

2

Estamos abriendo un servidor que estará expuesto a Internet de un proveedor cuya aplicación no tiene un servidor front-end oficial del proveedor.

Aunque este servidor de aplicaciones web obtendrá datos de los recursos internos de SQL, me preocupa que existe la posibilidad de que este servidor se vea comprometido.

Cuando les pregunté sobre la seguridad de esto, me dijeron que si quería, simplemente podía poner un proxy inverso como NGINX delante de él.

Ya tenemos balanceadores de carga que planeo usar. ¿Es aceptable simplemente poner este servidor detrás de los balanceadores de carga, que básicamente son proxies inversos para comenzar, o uno debería hacer balanceadores de carga y nginx (es decir, un proxy inverso doble?)

El servidor de aplicaciones es un producto web que se ofrecerá en los puertos 80 y 443. Técnicamente, el ssl vivirá en el equilibrador.

Esto también me hizo pensar, nuestros servidores de correo de intercambio modernos webmail tampoco tienen un front end oficial de Microsoft para webmail. Microsoft no hace tal producto.

¿Han pasado los días de DMZ a favor de otras ofertas de seguridad de múltiples capas?

    
pregunta Tom B 22.09.2016 - 23:40
fuente

2 respuestas

2

El uso de la DMZ es una estrategia para "cercar" la aplicación desde una red más amplia, pero no aborda las vulnerabilidades dentro de la aplicación o su entorno de ejecución.

Ciertamente, podría poner en cuarentena el servidor de aplicaciones en una DMZ como parte de sus controles de seguridad. Como @Julian Knight dice que un proxy inverso puede mitigar ciertos ataques.

Con respecto a la introducción de 'otro' proxy inverso (NGINX) en la arquitectura, pregunte '¿qué capacidades adicionales de seguridad o funcional proporciona eso?'. Solo duplicar las capacidades ya proporcionadas por sus proxies inversos existentes solo afectará el rendimiento y la capacidad de mantenimiento, y posiblemente introducirá problemas de seguridad adicionales si no configura correctamente algo. Sin mencionar el costo de ejecutar el servicio / servidores adicionales. Una pregunta descarada a su proveedor de aplicaciones sería '¿Garantiza que mi aplicación será segura si introduzco NGINX en la arquitectura? :) '.

Creo que es importante tener en cuenta la seguridad de la aplicación en sí. ¿Se ha probado la seguridad de forma independiente? ¿Hay vulnerabilidades conocidas? Hay muchas vulnerabilidades que un proxy inverso no lo protegerá contra ... ataques de inyección, por ejemplo.

Además de implementar controles de seguridad adecuados dentro de la aplicación y su entorno de ejecución, un Firewall de aplicaciones web (WAF ) es un tipo de proxy inverso que puede prevenir algunos ataques comunes en aplicaciones web (por ejemplo, inyección de SQL / Comando). Valdría la pena comprobar si sus proxies existentes tienen esta capacidad.

Pero, por supuesto, primero observe el contexto empresarial de la aplicación y el impacto de varios ataques exitosos. Esto debería guiar el esfuerzo que se debe poner en proteger la aplicación.

    
respondido por el feedersec 23.10.2016 - 07:44
fuente
1

El uso de NGINX u otros balanceadores de carga ayudará un poco con la seguridad de la aplicación. Protege de las vulnerabilidades de seguridad del servidor de aplicaciones y ayuda a resistir los ataques DDOS.

Además, la descarga de SSL a la capa proxy puede ayudar al rendimiento general, así como a mitigar de nuevo cualquier posible defecto en la implementación de SSL (TLS) de los servidores de aplicaciones. Ser un servidor común con mucho desarrollo abierto tiende a significar que los problemas de seguridad se encuentran y se solucionan más rápidamente en los servidores web / proxy que en los servidores de aplicaciones.

Lo principal es que algo como NGINX puede configurarse teniendo en cuenta la seguridad y proporcionar una capa externa adicional y bien soportada.

En términos de diseño de red, sus servidores web front-end operarán en una DMZ y, por lo tanto, estarán separados de los servidores de bases de datos y aplicaciones back-end a través de un firewall. También puede optar por colocar los servidores de aplicaciones en la DMZ o incluso tener una DMZ interna y externa si necesita seguridad adicional, aunque también deberá tener en cuenta los problemas de rendimiento.

Si necesita o no una infraestructura adicional, así como la función de equilibrio de carga, también dependerá de factores que no conocemos. Cosas como el rendimiento de los servidores de aplicaciones, la cantidad de conexiones de clientes, el ancho de banda disponible, el rendimiento disponible de los servidores (virtuales), etc.

En cuanto a tu ejemplo de intercambio. Exchange está diseñado específicamente para ser escalado usando muchos servidores de productos básicos. Sin embargo, se implementa comúnmente detrás de varias capas de protección, incluida una capa de transporte de borde, administración de virus / spam, protección contra intrusiones y prevención de pérdida de datos. Como la mayoría de los que requieren inspección de contenido, también es común descargar SSL / TLS al perímetro también.

El diseño detallado depende del valor de los datos, la exposición de los datos, el volumen, el tipo y varios otros factores, así como el apetito de riesgo de las organizaciones y si está operando en una industria regulada. Como no sabemos nada de eso, no podemos comentar sobre esos detalles.

La DMZ no está muerta pero puede tener más matices.

    
respondido por el Julian Knight 23.09.2016 - 01:21
fuente

Lea otras preguntas en las etiquetas