Protegendo aplicativos no Microsoft Azure App Service com NGINX Plus

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

Esta postagem de blog mostra como hospedar aplicativos no Microsoft Azure App Service e protegê-los com o NGINX Plus para evitar ataques 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 que organizações implantem aplicativos da Web, API e móveis no Microsoft Azure sem gerenciar a infraestrutura subjacente, conforme mostrado na Figura 1. O Azure App Service fornece os seguintes recursos principais:

• Os aplicativos da Web permitem que você implante e execute aplicativos da Web em várias linguagens e estruturas (ASP.NET, Node.js, Java, PHP e Python). Ele também gerencia aplicativos da Web escaláveis e confiáveis usando o Internet Information Services (IIS) com recursos abrangentes de gerenciamento de aplicativos (monitoramento, troca de preparação para produção, exclusão de aplicativos implantados e assim por diante). Ele também fornece um tempo de execução Docker para executar aplicativos web no Linux com contêineres.
• O API Apps traz as ferramentas para implantar APIs REST com suporte a CORS (Cross‑Origin Resource Sharing). Os aplicativos da API do Azure podem ser facilmente protegidos com o Azure Active Directory, logon único (SSO) de rede social ou OAuth, sem necessidade de alterações de código.
• Os aplicativos móveis fornecem uma maneira rápida de implantar serviços de backend móvel que oferecem suporte a recursos essenciais, como autenticação, notificações push, gerenciamento de usuários, armazenamento em nuvem, etc.

Com o Azure App Service, a Microsoft oferece uma maneira avançada e rápida de executar aplicativos Web na nuvem. De fato, os desenvolvedores podem desenvolver seus aplicativos localmente usando ASP.NET, Java, Node.js, PHP e Python e implantá-los facilmente no Azure App Service com o Microsoft Visual Studio ou o Azure CLI. As equipes de DevOps também podem se beneficiar do recurso de implantação contínua do Azure App Service para implantar lançamentos de aplicativos de forma rápida e confiável em vários ambientes.

Os aplicativos no Serviço de Aplicativo do Azure podem acessar outros recursos implantados no Azure ou podem estabelecer conexões por VPNs com recursos corporativos locais.

Compreendendo ambientes do Azure App Service

Basicamente, um aplicativo criado com o Azure App Service é exposto diretamente à Internet e atribuído a um subdomínio de azurewebsites.net . Para mais 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 de entrada e saída refinadas ou aplicar middleware, como um firewall de aplicativo da Web (WAF), para evitar ataques maliciosos ou explorações provenientes da Internet.

Se você executar aplicativos confidenciais no Serviço de Aplicativo do Azure e quiser protegê-los, poderá usar os Ambientes do Serviço de Aplicativo do Azure (ASEs). Um ASE é um ambiente isolado implantado em uma rede virtual e dedicado aos aplicativos de um único cliente. Assim, você obtém mais controle sobre o tráfego de rede de aplicativos de entrada e saída.

Com os ASEs, você pode implantar aplicativos da web, API, móveis ou de funções dentro de um ambiente mais seguro em uma escala muito alta, conforme mostrado na Figura 2.

Criando um novo ASE v2

Existem duas versões do ASE: ASE v1 e ASE v2. Neste post estamos discutindo 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ê deve 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 ILB ASE 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, estamos escolhendo um ILB ASE para impedir o acesso da Internet. Assim, os aplicativos implantados em nosso ASE são acessíveis apenas a partir de 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 ILB ASE v2 :

$ azure config mode arm $ azure group deployment create meu-grupo-de-recursos meu-nome-de-implantação --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

Se, por outro lado, você quiser que seu aplicativo seja acessível pela Internet, será preciso protegê-lo contra invasores mal-intencionados que podem tentar roubar informações confidenciais armazenadas em seu aplicativo.

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

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

(Você pode substituir um controlador de entrega de aplicativo personalizado [ADC] por recursos 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 fornece uma solução pronta para uso para aplicação de segurança e não exige que você mantenha a infraestrutura subjacente. Por outro lado, a implantação do NGINX Plus em VMs oferece uma pilha poderosa com mais controle e flexibilidade para ajustar suas regras de segurança.

Escolher entre o Azure Application Gateway e o NGINX Plus para balancear a carga e proteger aplicativos criados dentro de um ASE requer um bom entendimento dos recursos fornecidos por cada solução. Embora o Azure Application Gateway funcione para casos de uso simples, para casos de uso complexos ele não fornece muitos recursos que vêm como padrão no NGINX Plus.

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

Como você pode ver, o NGINX Plus e o Azure Application Gateway atuam como ADCs com recursos de balanceamento de carga de Camada 7, além de um WAF para garantir forte proteção contra vulnerabilidades e explorações comuns da Web.

O NGINX Plus fornece vários recursos adicionais ausentes no Azure Application Gateway:

• Reescrita e redirecionamento de URL – Com o NGINX Plus você pode reescrever a URL de uma solicitação antes de passá-la para um servidor de backend. Isso significa que você pode alterar a localização dos arquivos ou solicitar caminhos sem modificar a URL anunciada aos clientes. Você também pode redirecionar solicitações. Por exemplo, você pode redirecionar todas as solicitações HTTP para um servidor HTTPS.
• Limites de conexão e taxa – Você pode configurar vários limites para controlar o tráfego de e para suas instâncias do NGINX Plus. Isso inclui limites no número de conexões de entrada, na taxa de solicitações de entrada, nas conexões com nós de backend e na taxa de transmissão de dados do NGINX Plus para 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; em vez disso, o Azure Load Balancer oferece suporte a eles na camada de rede (Camada 4), onde TCP e UDP operam.

Para segurança adicional, você pode implantar a Proteção 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 Azure Application Gateway ou NGINX Plus.

Usando o NGINX Plus com o Azure App Service para proteger aplicativos

A Figura 3 mostra como combinar o NGINX Plus e o Azure App Service para fornecer um ambiente seguro para executar aplicativos de negócios em produção. Esta estratégia de implantação usa o NGINX Plus para seus recursos de balanceamento de carga e WAF.

A implantação combina os seguintes componentes:

• Rede Virtual do Azure (VNet) – Representa uma rede virtual na nuvem do Azure dedicada à sua organização. Ele fornece um isolamento lógico que permite que os recursos do Azure se comuniquem com segurança entre si em uma rede virtual. Aqui, definimos duas sub-redes: Interno para aplicativos da web que não são expostos diretamente à Internet e Waf para NGINX Plus e a infraestrutura que o sustenta.

• Ambiente do Azure App Service – Esta implantação de exemplo utiliza dois aplicativos Web de exemplo – Web App 1 e Web App 2 – para demonstrar como proteger e balancear a carga de diferentes aplicativos Web com o NGINX Plus. No NGINX Plus, você distribui solicitações para diferentes aplicativos da web configurando blocos upstream distintos e faz o roteamento de conteúdo com base no URI com blocos de localização . A seguir, é mostrada a configuração mínima do NGINX Plus que atende a esse objetivo (aqui, todas as solicitações vão para o mesmo grupo upstream):

  upstream backend { servidor endereço IP-do-seu-ASE-ILB ; } servidor { localização / { proxy_set_header Host $host; proxy_pass http://backend; } }
  

• NGINX Plus – Balanceia a carga de conexões HTTP(S) em vários aplicativos da web. A implantação do NGINX Plus em uma VM oferece mais controle sobre a infraestrutura do que outros serviços do Azure oferecem. Por exemplo, com uma VM você pode escolher o sistema operacional (Linux ou Windows) que será executado dentro de 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 Amazon Linux, por motivos óbvios).
• Conjuntos de dimensionamento de VM do Azure – Conjuntos de dimensionamento de VM 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 atribuir a VM à VNet correta. Todas as VMs executadas dentro do conjunto de dimensionamento são balanceadas por um Balanceador de Carga do Azure que fornece conectividade TCP entre as instâncias de VM. Aqui, cada VM no conjunto de dimensionamento é baseada na imagem NGINX Plus disponível no Azure Marketplace. Os conjuntos de escalas são projetados para fornecer dimensionamento automático verdadeiro.

O Azure também oferece suporte a grupos de recursos como uma maneira fácil de agrupar os recursos do Azure para um aplicativo de maneira lógica. O uso de um grupo de recursos não tem impacto no design nem na topologia da infraestrutura, e não os mostramos aqui.

NGINX Plus Alta disponibilidade e dimensionamento automático com conjuntos de dimensionamento de VM do Azure

Um conjunto de dimensionamento de VM do Azure oferece o poder da virtualização com a capacidade de dimensionar a qualquer momento sem precisar comprar e manter o hardware físico que dá suporte ao dimensionamento. No entanto, você ainda é responsável por manter a VM executando tarefas como configuração, aplicação de patches, atualização 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 alta disponibilidade ativa-ativa dentro de um conjunto de dimensionamento de VM do Azure. Uma configuração ativa-ativa é ótima porque todas as VMs NGINX Plus podem manipular uma solicitação de entrada roteada pelo Balanceador de Carga do Azure, oferecendo capacidade com boa relação custo-benefício.

Com os conjuntos de dimensionamento de VM do Azure, você também pode configurar facilmente o dimensionamento automático de instâncias do NGINX Plus com base no uso médio da CPU. Você precisa tomar cuidado para sincronizar os arquivos de configuração do NGINX Plus neste caso. Você pode usar o recurso de compartilhamento de configuração do NGINX Plus para essa finalidade, conforme descrito no Guia de administração do NGINX Plus .

Resumo

Ao usar o Azure App Service para seus aplicativos de nuvem e o NGINX Plus na frente de seus aplicativos da Web, API e backends móveis, você pode balancear a carga e proteger esses aplicativos em escala global. Ao usar o NGINX Plus em conjunto com o Azure App Service, você obtém uma infraestrutura totalmente balanceada de carga com um alto nível de proteção contra explorações e ataques da Web. Isso garante um design robusto para executar aplicativos críticos em produção de forma segura.

Recursos

Visão geral de aplicativos da Web (Microsoft)
Introdução aos ambientes de serviço de aplicativo (Microsoft)
Crie um gateway de aplicativo com um firewall de aplicativo da Web usando o portal do Azure (Microsoft)
Compare 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.