Protegendo aplicações no Serviço de Aplicativo do Microsoft Azure com NGINX Plus

Cedric Derue

A ascensão da computação em nuvem — e, em particular, das ofertas de Plataforma como Serviço (PaaS) e Contêiner como Serviço (CaaS) — está mudando a forma como as empresas implantam e operam suas aplicações de negócios. Um dos desafios mais importantes ao projetar aplicações em nuvem é escolher serviços de nuvem totalmente gerenciados que reduzam os custos e as tarefas operacionais demoradas sem comprometer a segurança.

Esta publicação no blog mostra como hospedar aplicações no Microsoft Azure App Service e protegê-las com o NGINX Plus para evitar ataques provenientes da Internet.

Breve visão geral do Microsoft Azure App Service

O Microsoft Azure App Service é uma plataforma de nível empresarial e totalmente gerenciada que permite às organizações implantar aplicativos Web, de API e móveis no Microsoft Azure sem precisar gerenciar a infraestrutura subjacente, conforme mostrado na Figura 1. O Azure App Service oferece os seguintes recursos principais:

• Aplicativos Web permite implantar e executar aplicativos Web em várias linguagens e estruturas (ASP.NET, Node.js, Java, PHP e Python). Também gerencia aplicativos Web escaláveis e confiáveis usando os Serviços de Informações da Internet (IIS), com recursos abrangentes de gerenciamento de aplicativos (monitoramento, troca do ambiente de preparo para o de produção, exclusão de aplicativos implantados e assim por diante). Além disso, fornece um runtime do Docker para executar aplicativos Web no Linux com contêineres.
• Aplicativos de API oferece as ferramentas necessárias para implantar APIs REST com suporte a CORS (Compartilhamento de Recursos entre Origens). Os Aplicativos de API do Azure podem ser facilmente protegidos com o Azure Active Directory, logon único (SSO) de redes sociais ou OAuth, sem a necessidade de alterar o código.
• Aplicativos móveis oferecem uma maneira rápida de implantar serviços de back-end para dispositivos móveis compatíveis com recursos essenciais, como autenticação, notificações por push, gerenciamento de usuários, armazenamento em nuvem etc.

Com o Azure App Service, a Microsoft oferece uma maneira rápida e completa de executar aplicações Web na nuvem. Os desenvolvedores podem criar suas aplicações localmente usando ASP.NET, Java, Node.js, PHP e Python e implantá-las facilmente no Azure App Service com o Microsoft Visual Studio ou a CLI do Azure. As equipes de DevOps também podem aproveitar o recurso de implantação contínua do Azure App Service para implantar versões de aplicações de forma rápida e confiável em vários ambientes.

Os aplicativos no Azure App Service podem acessar outros recursos implantados no Azure ou estabelecer conexões por VPNs com recursos corporativos locais.

Entendendo os Ambientes do Serviço de Aplicativo do Azure

Basicamente, um aplicativo criado com o Azure App Service fica exposto diretamente à Internet e é associado a um subdomínio de azurewebsites.net. Para aumentar a segurança, você pode proteger seu aplicativo com terminação SSL ou com protocolos de autenticação e autorização, como OAuth2 ou OpenID Connect (OIDC). No entanto, não é possível personalizar a rede com regras de segurança granulares para o tráfego de entrada e saída nem aplicar um middleware, como um firewall de aplicações Web (WAF), para impedir ataques mal-intencionados ou a exploração de vulnerabilidades provenientes da Internet.

Se você executa aplicações confidenciais no Azure App Service e deseja protegê-las, pode usar os Ambientes do Serviço de Aplicativo do Azure (ASEs). Um ASE é um ambiente isolado implantado em uma rede virtual e dedicado às aplicações de um único cliente. Assim, você obtém mais controle sobre o tráfego de rede de entrada e saída das aplicações.

Com os ASEs, você pode implantar aplicativos Web, de API, móveis ou de funções em um ambiente mais seguro e em altíssima escala, conforme mostrado na Figura 2.

Criando um novo ASE v2

Há duas versões do ASE: ASE v1 e ASE v2. Neste post, abordaremos o ASE v2.

Você pode criar um novo ASE v2 manualmente usando o Portal do Azure ou automaticamente usando o Azure Resource Manager.

Ao criar um novo ASE, você precisa escolher entre dois tipos de implantação:

• Um ASE externo expõe os aplicativos hospedados no ASE por meio de um endereço IP público.
• Um ASE com ILB expõe os aplicativos hospedados no ASE em um endereço IP privado acessível somente dentro da sua Rede Virtual do Azure. O ponto de extremidade interno é o que o Azure chama de balanceador de carga interno (ILB).

No exemplo a seguir, escolhemos um ASE com ILB para impedir o acesso pela Internet. Assim, os aplicativos implantados em nosso ASE podem ser acessados somente por máquinas virtuais (VMs) em execução na mesma rede. Os dois comandos a seguir usam o Azure Resource Manager e a CLI do Azure para provisionar um novo ASE v2 com 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

Protegendo o acesso a aplicativos em um ASE acessível publicamente

Por outro lado, se você quiser que seu aplicativo possa ser acessado pela Internet, será necessário protegê-lo contra invasores mal-intencionados que possam tentar roubar informações confidenciais armazenadas nele.

Para proteger aplicações na Camada 7 em um ASE, você tem duas opções principais:

• Gateway de Aplicativo do Azure
• NGINX Plus com o NGINX ModSecurity WAF módulo

(Você pode substituí-lo por um controlador de entrega de aplicações [ADC] personalizado com recursos de WAF, mas não abordamos esse caso de uso aqui.)

A escolha da solução depende das suas restrições de segurança. Por um lado, o Azure Application Gateway oferece uma solução pronta para uso que aplica as políticas de segurança sem exigir que você mantenha a infraestrutura subjacente. Por outro lado, a implantação do NGINX Plus em máquinas virtuais oferece uma stack avançada, com mais controle e flexibilidade para ajustar suas regras de segurança.

A escolha entre o Azure Application Gateway e o NGINX Plus para balancear a carga e proteger aplicações criadas em um ASE exige um bom entendimento dos recursos oferecidos por cada solução. Embora o Azure Application Gateway funcione para casos de uso simples, em casos de uso complexos ele não oferece muitos dos recursos incluídos por padrão no NGINX Plus.

A tabela a seguir compara o suporte a recursos de balanceamento de carga e segurança no Azure Application Gateway e no NGINX Plus. Mais detalhes sobre os recursos do NGINX Plus são apresentados abaixo da tabela.

Recurso Azure Application Gateway NGINX PlusCapacidade de mitigação Camada de aplicação (Camada 7) Camada de aplicação (Camada 7)Compatível com HTTP ✅ ✅Compatível com HTTP/2 ❌ ✅Compatível com WebSocket ❌ ✅Descarregamento de SSL ✅ ✅Recursos de roteamento Decisão simples baseada na URL da solicitação ou afinidade de sessão baseada em cookies Recursos avançados de roteamentoListas de controle de acesso baseadas em endereço IP ❌ (devem ser definidas no nível do aplicativo Web no Azure) ✅Endpoints Qualquer endereço IP interno do Azure, endereço IP público da Internet, VM do Azure ou Serviço de Nuvem do Azure Qualquer endereço IP interno do Azure, endereço IP público da Internet, VM do Azure ou Serviço de Nuvem do AzureCompatibilidade com Vnet do Azure Aplicativos voltados para a Internet e internos (Vnet) Aplicativos voltados para a Internet e internos (Vnet)WAF ✅ ✅Ataques volumétricos Parcial ParcialAtaques de protocolo Parcial ParcialAtaques à camada de aplicação ✅ ✅Autenticação HTTP Basic ❌ ✅Autenticação JWT ❌ ✅SSO com OpenID Connect ❌ ✅

Como você pode ver, tanto o NGINX Plus quanto o Azure Application Gateway atuam como ADCs, com recursos de balanceamento de carga na Camada 7 e um WAF para garantir uma proteção robusta contra vulnerabilidades e explorações comuns na Web.

O NGINX Plus oferece vários recursos adicionais que não estão disponíveis no Azure Application Gateway:

• Reescrita e redirecionamento de URLs – Com o NGINX Plus, você pode reescrever a URL de uma solicitação antes de encaminhá-la a um servidor de backend. Isso significa que você pode alterar a localização dos arquivos ou os caminhos das solicitações sem modificar a URL divulgada aos clientes. Você também pode redirecionar solicitações. Por exemplo, é possível redirecionar todas as solicitações HTTP para um servidor HTTPS.
• Limites de conexão e de taxa – Você pode configurar vários limites para controlar o tráfego de entrada e saída das suas instâncias do NGINX Plus. Isso inclui limites para o número de conexões de entrada, a taxa de solicitações recebidas, as conexões com os nós de backend e a taxa de transmissão de dados do NGINX Plus para os clientes.
• Suporte a HTTP/2 e WebSocket – O NGINX Plus oferece suporte a HTTP/2 e WebSocket na camada de aplicação (Camada 7). O Azure Application Gateway não oferece esse suporte; em vez disso, o Azure Load Balancer oferece suporte a esses protocolos na camada de rede (Camada 4), na qual operam o TCP e o UDP.

Para aumentar a segurança, você pode implantar a Proteção contra DDoS do Azure para mitigar ameaças nas camadas 3 e 4, complementando os recursos de mitigação de ameaças da camada 7 fornecidos pelo Gateway de Aplicativo do Azure ou pelo NGINX Plus.

Como usar o NGINX Plus com o Azure App Service para proteger aplicações

A Figura 3 mostra como combinar o NGINX Plus e o Azure App Service para oferecer um ambiente seguro para a execução de aplicações empresariais em produção. Essa estratégia de implantação utiliza o NGINX Plus por seus recursos de balanceamento de carga e WAF.

A implantação combina os seguintes componentes:

• Azure Virtual Network (VNet) – Representa uma rede virtual na nuvem do Azure dedicada à sua organização. Ela fornece um isolamento lógico que permite que os recursos do Azure se comuniquem entre si com segurança em uma rede virtual. Aqui, definimos duas sub-redes: Internal para aplicações web que não são expostas diretamente à Internet e Waf para o NGINX Plus e a infraestrutura subjacente.
• Ambiente do Serviço de Aplicativo do Azure – Esta implantação de exemplo utiliza dois aplicativos Web de exemplo – Aplicativo Web 1 e Aplicativo Web 2 – para demonstrar como proteger e balancear a carga de diferentes aplicativos Web com o NGINX Plus. No NGINX Plus, você distribui as solicitações entre diferentes aplicativos Web configurando blocos upstream distintos e realiza o roteamento de conteúdo com base no URI usando blocos location. A seguir, é apresentada a configuração mínima do NGINX Plus que atende a esse objetivo (aqui, todas as solicitações são encaminhadas para o mesmo grupo upstream):

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

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

• NGINX Plus – Balanceia a carga de conexões HTTP(S) entre vários aplicativos Web. A implantação do NGINX Plus em uma VM oferece mais controle sobre a infraestrutura do que outros serviços do Azure. Por exemplo, com uma VM, você pode escolher o sistema operacional (Linux ou Windows) executado em uma rede virtual isolada. De fato, as VMs do Azure estão disponíveis para todas as distribuições Linux compatíveis com o NGINX Plus (exceto o Amazon Linux, por motivos óbvios).
• Conjuntos de dimensionamento de VMs do Azure – Os conjuntos de dimensionamento de VMs são um recurso de computação do Azure que você pode usar para implantar e gerenciar um conjunto de VMs idênticas. Você pode configurar o tamanho da VM e atribuí-la à VNet adequada. Todas as VMs executadas no conjunto de dimensionamento têm a carga balanceada por um Azure Load Balancer, que fornece conectividade TCP entre as instâncias de VM. Nesse caso, cada VM do conjunto de dimensionamento é baseada na imagem do NGINX Plus disponível no Azure Marketplace. Os conjuntos de dimensionamento foram projetados para oferecer dimensionamento automático de verdade.

O Azure também oferece suporte a grupos de recursos como uma maneira fácil de agrupar logicamente os recursos do Azure de um aplicativo. O uso de um grupo de recursos não afeta o design nem a topologia da infraestrutura e, por isso, não os mostramos aqui.

Alta disponibilidade e dimensionamento automático do NGINX Plus com Conjuntos de Dimensionamento de Máquinas Virtuais do Azure

Um conjunto de dimensionamento de VMs do Azure oferece o poder da virtualização e a capacidade de escalar a qualquer momento, sem a necessidade de adquirir e manter o hardware físico que dá suporte ao dimensionamento. No entanto, você ainda é responsável pela manutenção da VM, realizando tarefas como configuração, aplicação de patches, atualizações de segurança e instalação do software executado nela.

Na arquitetura mostrada na Figura 4, as instâncias do NGINX Plus são implantadas para oferecer alta disponibilidade no modo ativo-ativo em um conjunto de dimensionamento de VMs do Azure. Uma configuração ativo-ativo é excelente porque todas as VMs do NGINX Plus podem processar solicitações recebidas e encaminhadas pelo Azure Load Balancer, proporcionando capacidade com boa relação custo-benefício.

Com os conjuntos de dimensionamento de VMs do Azure, você também pode configurar facilmente o dimensionamento automático das instâncias do NGINX Plus com base no uso médio da CPU. Nesse caso, é necessário garantir a sincronização dos arquivos de configuração do NGINX Plus. Para isso, você pode usar o recurso de compartilhamento de configuração do NGINX Plus, conforme descrito no Guia de Administração do NGINX Plus.

Resumo

Ao usar o Azure App Service para suas aplicações em nuvem e o NGINX Plus à frente de suas aplicações web, APIs e back-ends móveis, você pode balancear a carga e proteger essas aplicações em escala global. Ao usar o NGINX Plus em conjunto com o Azure App Service, você obtém uma infraestrutura com balanceamento de carga completo e um alto nível de proteção contra explorações de vulnerabilidades e ataques provenientes da web. Isso garante uma arquitetura robusta para executar aplicações críticas em produção com segurança.

Recursos

Visão geral dos Aplicativos Web (Microsoft)
Introdução aos Ambientes do Serviço de Aplicativo (Microsoft)
Criar um gateway de aplicativo com um firewall de aplicativo Web usando o portal do Azure (Microsoft)
Comparar os recursos do NGINX Open Source e do NGINX Plus (NGINX)
Balanceamento de carga HTTP (NGINX)

O coautor convidado Cedric Derue é arquiteto de soluções e Microsoft MVP na Altran. O coautor convidado Vincent Thavonekham é diretor regional da Microsoft e Azure MVP na VISEO.

Sobre o autor

Cedric Derue

Mais publicações de Cedric Derue