Protección de aplicaciones en Microsoft Azure App Service con NGINX Plus

Cedric Derue

El auge de la computación en la nube —y, en particular, de las ofertas de plataforma como servicio (PaaS) y contenedores como servicio (CaaS)— está cambiando la forma en que las empresas implementan y gestionan sus aplicaciones empresariales. Uno de los retos más importantes a la hora de diseñar aplicaciones en la nube es elegir servicios en la nube totalmente gestionados que reduzcan los costes y las tareas operativas que requieren mucho tiempo sin comprometer la seguridad.

Esta entrada de blog muestra cómo alojar aplicaciones en Microsoft Azure App Service y protegerlas con NGINX Plus para evitar ataques desde Internet.

Breve descripción general de Microsoft Azure App Service

Microsoft Azure App Service es una plataforma de nivel empresarial y totalmente administrada que permite a las organizaciones implementar aplicaciones web, API y móviles en Microsoft Azure sin tener que gestionar la infraestructura subyacente, como se muestra en la Figura 1. Azure App Service ofrece las siguientes características principales:

• Web Apps permite implementar y ejecutar aplicaciones web en diversos lenguajes y marcos de trabajo (ASP.NET, Node.js, Java, PHP y Python). También permite gestionar aplicaciones web escalables y fiables mediante Internet Information Services (IIS), con completas funciones de administración de aplicaciones (supervisión, intercambio entre los entornos de ensayo y producción, eliminación de aplicaciones implementadas, etc.). Asimismo, proporciona un entorno de ejecución de Docker para ejecutar aplicaciones web en Linux mediante contenedores.
• API Apps proporciona las herramientas necesarias para implementar API REST compatibles con CORS (uso compartido de recursos entre orígenes). Azure API Apps se puede proteger fácilmente mediante Azure Active Directory, el inicio de sesión único (SSO) de redes sociales u OAuth, sin necesidad de modificar el código.
• Mobile Apps proporciona una forma rápida de implementar servicios de backend para aplicaciones móviles que admiten funciones esenciales como autenticación, notificaciones push, gestión de usuarios, almacenamiento en la nube, etc.

Con Azure App Service, Microsoft ofrece una forma completa y rápida de ejecutar aplicaciones web en la nube. De hecho, los desarrolladores pueden crear sus aplicaciones localmente con ASP.NET, Java, Node.js, PHP y Python, e implementarlas fácilmente en Azure App Service mediante Microsoft Visual Studio o la CLI de Azure. Los equipos de DevOps también pueden aprovechar la función de implementación continua de Azure App Service para implementar versiones de aplicaciones de forma rápida y fiable en varios entornos.

Las aplicaciones de Azure App Service pueden acceder a otros recursos implementados en Azure o establecer conexiones mediante VPN con recursos corporativos locales.

Descripción de los entornos de Azure App Service

Básicamente, una aplicación creada con Azure App Service queda expuesta directamente a Internet y se asigna a un subdominio de azurewebsites.net. Para reforzar la seguridad, puede proteger su aplicación mediante la terminación SSL o protocolos de autenticación y autorización como OAuth2 u OpenID Connect (OIDC). Sin embargo, no es posible personalizar la red con reglas de seguridad granulares para el tráfico entrante y saliente, ni aplicar middleware como un firewall de aplicaciones web (WAF) para evitar ataques maliciosos o vulnerabilidades procedentes de Internet.

Si ejecuta aplicaciones sensibles en Azure App Service y desea protegerlas, puede usar Azure App Service Environments (ASE). Un ASE es un entorno aislado que se implementa en una red virtual y está dedicado a las aplicaciones de un único cliente. De este modo, tendrá un mayor control sobre el tráfico de red entrante y saliente de las aplicaciones.

Con los ASE, puede implementar aplicaciones web, de API, móviles o de funciones en un entorno más seguro y a una escala muy elevada, como se muestra en la Figura 2.

Creación de un nuevo ASE v2

Hay dos versiones de ASE: ASE v1 y ASE v2. En esta publicación hablaremos de ASE v2.

Puede crear un nuevo ASE v2 manualmente mediante Azure Portal o automáticamente mediante Azure Resource Manager.

Al crear un nuevo ASE, debe elegir entre dos tipos de implementación:

• Un ASE externo expone las aplicaciones hospedadas en el ASE a través de una dirección IP pública.
• Un ASE con ILB expone las aplicaciones hospedadas en el ASE en una dirección IP privada a la que solo se puede acceder desde la red virtual de Azure. El punto de conexión interno es lo que Azure denomina equilibrador de carga interno (ILB).

En el siguiente ejemplo, elegimos un ASE con ILB para impedir el acceso desde Internet. Por tanto, solo se puede acceder a las aplicaciones implementadas en nuestro ASE desde máquinas virtuales (VM) que se ejecuten en la misma red. Los dos comandos siguientes utilizan Azure Resource Manager y la CLI de Azure para aprovisionar un nuevo ASE v2 con ILB:

$ azure config mode arm$ azure group deployment create my-resource-group my-deployment-name --template-uri https://raw.githubusercontent.com/azure/azure-quickstart-templates/master/201-web-app-asev2-ilb-create/azuredeploy.json

Protección del acceso a las aplicaciones en un ASE de acceso público

Si, por el contrario, quieres que tu aplicación sea accesible desde Internet, debes protegerla frente a atacantes malintencionados que podrían intentar robar información confidencial almacenada en ella.

Para proteger las aplicaciones en la capa 7 de un ASE, tiene dos opciones principales:

• Azure Application Gateway
• NGINX Plus con el módulo NGINX ModSecurity WAF module

(Puede sustituirlo por un controlador de entrega de aplicaciones [ADC] personalizado con funciones de WAF, pero ese caso de uso no se aborda aquí.)

La elección de la solución depende de sus requisitos de seguridad. Por un lado, Azure Application Gateway ofrece una solución lista para usar que permite aplicar las políticas de seguridad sin necesidad de mantener la infraestructura subyacente. Por otro lado, implementar NGINX Plus en máquinas virtuales proporciona una potente plataforma con mayor control y flexibilidad para ajustar con precisión las reglas de seguridad.

Para elegir entre Azure Application Gateway y NGINX Plus a fin de equilibrar la carga y proteger las aplicaciones creadas dentro de un ASE, es necesario conocer bien las funcionalidades que ofrece cada solución. Aunque Azure Application Gateway resulta adecuado para casos de uso sencillos, en casos de uso complejos no ofrece muchas de las funcionalidades incluidas de serie en NGINX Plus.

La siguiente tabla compara la compatibilidad con las funciones de equilibrio de carga y seguridad de Azure Application Gateway y NGINX Plus. Debajo de la tabla se ofrece más información sobre las funciones de NGINX Plus.

Característica Azure Application Gateway NGINX PlusCapacidad de mitigación Capa de aplicación (capa 7) Capa de aplicación (capa 7)Compatible con HTTP ✅ ✅Compatible con HTTP/2 ❌ ✅Compatible con WebSocket ❌ ✅Descarga de SSL ✅ ✅Capacidades de enrutamiento Decisión sencilla basada en la URL de la solicitud o afinidad de sesión basada en cookies Capacidades de enrutamiento avanzadasListas de control de acceso basadas en direcciones IP ❌ (deben definirse en el nivel de la aplicación web en Azure) ✅Puntos de conexión Cualquier dirección IP interna de Azure, dirección IP pública de Internet, máquina virtual de Azure o servicio en la nube de Azure Cualquier dirección IP interna de Azure, dirección IP pública de Internet, máquina virtual de Azure o servicio en la nube de AzureCompatibilidad con redes virtuales de Azure Aplicaciones tanto accesibles desde Internet como internas (red virtual) Aplicaciones tanto accesibles desde Internet como internas (red virtual)WAF ✅ ✅Ataques volumétricos Parcial ParcialAtaques de protocolo Parcial ParcialAtaques a la capa de aplicación ✅ ✅Autenticación HTTP básica ❌ ✅Autenticación JWT ❌ ✅SSO con OpenID Connect ❌ ✅

Como puede ver, tanto NGINX Plus como Azure Application Gateway actúan como ADC con funciones de equilibrio de carga de capa 7 y un WAF que garantiza una protección sólida frente a vulnerabilidades y ataques web habituales.

NGINX Plus ofrece varias funciones adicionales que no están disponibles en Azure Application Gateway:

• Reescritura y redirección de URL – Con NGINX Plus puede reescribir la URL de una solicitud antes de pasarla a un servidor backend. Esto significa que puede cambiar la ubicación de los archivos o las rutas de las solicitudes sin modificar la URL que se muestra a los clientes. También puede redirigir solicitudes. Por ejemplo, puede redirigir todas las solicitudes HTTP a un servidor HTTPS.
• Límites de conexiones y velocidad – Puede configurar varios límites para controlar el tráfico entrante y saliente de sus instancias de NGINX Plus. Estos incluyen límites en el número de conexiones entrantes, la frecuencia de las solicitudes entrantes, las conexiones a los nodos de backend y la velocidad de transmisión de datos de NGINX Plus a los clientes.
• Compatibilidad con HTTP/2 y WebSocket – NGINX Plus admite HTTP/2 y WebSocket en la capa de aplicación (capa 7). Azure Application Gateway no los admite; en su lugar, Azure Load Balancer los admite en la capa de red (capa 4), donde operan TCP y UDP.

Para reforzar la seguridad, puede implementar Azure DDoS Protection para mitigar las amenazas en las capas 3 y 4, como complemento de las funciones de mitigación de amenazas de la capa 7 que proporcionan Azure Application Gateway o NGINX Plus.

Uso de NGINX Plus con Azure App Service para proteger aplicaciones

La figura 3 muestra cómo combinar NGINX Plus y Azure App Service para proporcionar un entorno seguro en el que ejecutar aplicaciones empresariales en producción. Esta estrategia de implementación utiliza las funciones de equilibrio de carga y WAF de NGINX Plus.

La implementación combina los siguientes componentes:

• Azure Virtual Network (VNet) – Representa una red virtual en la nube de Azure dedicada a su organización. Proporciona un aislamiento lógico que permite que los recursos de Azure se comuniquen entre sí de forma segura dentro de una red virtual. En este caso, hemos definido dos subredes: Internal para las aplicaciones web que no están expuestas directamente a Internet y Waf para NGINX Plus y la infraestructura subyacente.
• Azure App Service Environment – Esta implementación de ejemplo utiliza dos aplicaciones web de muestra: «Aplicación web 1» y «Aplicación web 2»; con ellas se muestra cómo proteger y equilibrar la carga de distintas aplicaciones web con NGINX Plus. En NGINX Plus, las solicitudes se distribuyen entre distintas aplicaciones web configurando bloques upstream independientes, y el enrutamiento de contenido basado en el URI se realiza mediante bloques location. A continuación se muestra la configuración mínima de NGINX Plus necesaria para lograr este objetivo (en este caso, todas las solicitudes se dirigen al mismo grupo de servidores upstream):

upstream backend {    server IP-address-of-your-ASE-ILB;
}

server {
    location / {
        proxy_set_header Host $host;
        proxy_pass http://backend;
    }
}

• NGINX Plus – Equilibra la carga de las conexiones HTTP(S) entre varias aplicaciones web. Implementar NGINX Plus en una máquina virtual le proporciona más control sobre la infraestructura que otros servicios de Azure. Por ejemplo, con una máquina virtual puede elegir el sistema operativo (Linux o Windows) que se ejecuta dentro de una red virtual aislada. De hecho, las máquinas virtuales de Azure están disponibles para todas las distribuciones de Linux compatibles con NGINX Plus (excepto Amazon Linux, por razones obvias).
• Conjuntos de escalado de máquinas virtuales de Azure – Los conjuntos de escalado de máquinas virtuales son un recurso de proceso de Azure que permite implementar y administrar un conjunto de máquinas virtuales idénticas. Puede configurar el tamaño de la máquina virtual y asignarla a la red virtual adecuada. Todas las máquinas virtuales que se ejecutan en el conjunto de escalado se distribuyen mediante Azure Load Balancer, que proporciona conectividad TCP entre las instancias de máquinas virtuales. En este caso, cada máquina virtual del conjunto de escalado se basa en la imagen de NGINX Plus disponible en Azure Marketplace. Los conjuntos de escalado están diseñados para ofrecer un verdadero escalado automático.

Azure también admite los grupos de recursos como una forma sencilla de agrupar de manera lógica los recursos de Azure de una aplicación. El uso de un grupo de recursos no afecta al diseño ni a la topología de la infraestructura, por lo que no se muestran aquí.

Alta disponibilidad y escalado automático de NGINX Plus con conjuntos de escalado de máquinas virtuales de Azure

Un conjunto de escalado de máquinas virtuales de Azure le ofrece la potencia de la virtualización y la posibilidad de escalar en cualquier momento sin tener que adquirir ni mantener el hardware físico necesario para ello. Sin embargo, sigue siendo responsable del mantenimiento de la máquina virtual, lo que incluye tareas como configurarla, aplicar parches y actualizaciones de seguridad e instalar el software que se ejecuta en ella.

En la arquitectura que se muestra en la figura 4, las instancias de NGINX Plus se implementan con alta disponibilidad activo-activo dentro de un conjunto de escalado de máquinas virtuales de Azure. Una configuración activo-activo resulta muy ventajosa porque todas las máquinas virtuales de NGINX Plus pueden gestionar las solicitudes entrantes que enruta Azure Load Balancer, lo que proporciona capacidad de forma rentable.

Con los conjuntos de escalado de máquinas virtuales de Azure, también puede configurar fácilmente el escalado automático de las instancias de NGINX Plus en función del uso medio de la CPU. En este caso, debe asegurarse de sincronizar los archivos de configuración de NGINX Plus. Para ello, puede utilizar la función de uso compartido de la configuración de NGINX Plus, tal como se describe en la Guía de administración de NGINX Plus.

Resumen

Al utilizar Azure App Service para sus aplicaciones en la nube y NGINX Plus delante de sus aplicaciones web, API y backends móviles, puede equilibrar la carga y proteger estas aplicaciones a escala global. Al utilizar NGINX Plus junto con Azure App Service, obtiene una infraestructura con equilibrio de carga completo y un alto nivel de protección frente a vulnerabilidades y ataques procedentes de la web. Esto garantiza un diseño robusto para ejecutar aplicaciones críticas en producción de forma segura.

Recursos

Introducción a Web Apps (Microsoft)
Introducción a App Service Environment (Microsoft)
Crear una puerta de enlace de aplicaciones con un firewall de aplicaciones web mediante Azure Portal (Microsoft)
Comparar las características de NGINX Open Source y NGINX Plus (NGINX)
Equilibrio de carga HTTP (NGINX)

El coautor invitado Cedric Derue es arquitecto de soluciones y Microsoft MVP en Altran. El coautor invitado Vincent Thavonekham es director regional de Microsoft y Azure MVP en VISEO.

Sobre el autor

Cedric Derue

Más artículos de Cedric Derue