Melhore o desempenho e a segurança do aplicativo Azure com NGINX

O NGINXaaS para Azure permite que as empresas entreguem com segurança applications de alto desempenho na nuvem. Desenvolvido pelo NGINX Plus, é um serviço totalmente gerenciado que se tornou disponível ao público em janeiro de 2023. Desde seu lançamento e no futuro, continuamos aprimorando o NGINXaaS para Azure adicionando novos recursos .

Neste blog, destacamos alguns dos mais recentes recursos de desempenho e segurança que permitem que você aproveite mais benefícios do NGINX Plus sem precisar implantar, manter e atualizar suas próprias instâncias do NGINX Plus. Para obter informações gerais sobre o NGINXaaS para Azure e seus recursos abrangentes, leia Simplifique e acelere as migrações para a nuvem com o F5 NGINXaaS para Azure .

Figura 1: Visão geral do NGINXaaS para Azure

Protegendo o tráfego upstream com mTLS

Enquanto os proxies reversos exigem SSL/TLS para criptografar o tráfego do lado do cliente na internet pública, o TLS mútuo (mTLS) se torna essencial para autenticar e garantir a confidencialidade no lado do servidor. Com a mudança para Zero Trust , também é necessário verificar se o tráfego do servidor upstream não foi alterado ou interceptado.

Figura 2: mTLS com NGINXaaS

O NGINXaaS para Azure agora oferece suporte a diretivas NGINX para proteger o tráfego upstream com certificados SSL/TLS. Com essas diretivas, você não apenas pode manter o tráfego upstream criptografado via mTLS, como também pode verificar se os servidores upstream estão apresentando um certificado válido de uma autoridade de certificação confiável.

Rotação de Certificados

Uma parte fundamental (trocadilho intencional) do uso de certificados TLS com o NGINXaaS para Azure é gerenciar esses certificados com segurança por meio do uso do Azure Key Vault (AKV) . O AKV mantém o material criptográfico sensível seguro e permite que o NGINXaaS para Azure use esses certificados, evitando a divulgação acidental ou intencional do material da chave por meio do portal do Azure.

Figura 3: Rotação de certificados com o Azure Key Vault

O NGINXaaS para Azure agora pode rotacionar certificados automaticamente por meio de suas implantações NGINX sempre que eles forem atualizados no AKV. Novas versões de certificados são rotacionadas em suas implantações em até quatro horas.

Proxy HTTP/2 (e opções de protocolo adicionais)

Feche os olhos e pense no ano de 1997. Estávamos fazendo Tubthumping junto com Chumbawamba, vestindo nossos jeans JNCO (ou Modrobes para qualquer canadense por aí), e o HTTP/1.1 foi lançado. Naquela época, a maioria dos usuários finais acessava a Internet por meio de um modem discado, as páginas da web continham apenas algumas dezenas de elementos e, quando se tratava da experiência do usuário, a largura de banda era uma preocupação muito maior do que a latência.

Vinte e cinco anos depois, uma parcela considerável de applications da web ainda usa HTTP/1.1 para entregar conteúdo. Isso pode ser um problema. Embora o HTTP/1.1 ainda funcione, ele só permite a entrega de um recurso por conexão por vez. Enquanto isso, os aplicativos da web modernos podem fazer centenas de solicitações para atualizar uma interface de usuário.

Embora a maioria dos usuários tenha consideravelmente mais largura de banda à disposição, a velocidade de transmissão de dados (limitada pela velocidade fundamental da luz) não avançou tão rapidamente. Portanto, a latência cumulativa de todas essas solicitações pode ter um impacto significativo no desempenho percebido do seu application. Os navegadores modernos abrem várias conexões TCP para o mesmo servidor, mas cada solicitação nessas conexões ainda é sequencial, o que significa que um recurso lento pode atrasar todos os outros recursos por trás dele.

Dê uma olhada na página inicial do F5 quando ele carrega usando apenas HTTP/1.1:

Figura 4: F5.com acessado via HTTP/1.1

Está vendo todas essas barras cinzas? Esse é um tempo valioso que o navegador está desperdiçando enquanto espera o estabelecimento da sessão, bloqueia um único recurso lento ou procura uma nova conexão TCP para ficar disponível.

Vamos habilitar o HTTP/2 e tentar novamente:

Figura 5: A mesma solicitação, mas usando HTTP/2

Muito melhor. Ainda há alguns recursos lentos, mas eles não estão atrasando outras solicitações e significativamente menos tempo está sendo gasto esperando por atrasos relacionados a filas. O HTTP/2 mantém a mesma semântica com a qual os navegadores e servidores da web estão familiarizados do HTTP/1.1, ao mesmo tempo em que adiciona novos recursos para abordar alguns motivos de desempenho de application mal percebido (por exemplo, priorização de solicitações, compactação de cabeçalhos e multiplexação de solicitações).

Dada essa diferença clara, o NGINXaaS para Azure agora oferece suporte ao atendimento de solicitações de clientes por HTTP/2 . As conexões do lado do cliente têm maior probabilidade de serem afetadas por tempos de ida e volta mais longos, então você pode entregar esse tráfego com os benefícios de redução de latência do HTTP/2, deixando seus servidores upstream inalterados.

Apesar do que alguns no ramo de application web podem querer acreditar, reconhecemos que há opções de protocolo adicionais além do HTTP disponíveis para você. É por isso que o módulo NGINX gRPC agora também está disponível no NGINXaaS para Azure. Ele fornece diversas diretivas de configuração para trabalhar com tráfego gRPC, incluindo interceptação de erros, manipulação de cabeçalhos e muito mais.

Para tráfego não HTTP/gRPC, o módulo de fluxo agora está disponível no NGINXaaS para Azure. Este módulo oferece suporte a proxy e balanceamento de carga de tráfego TCP e UDP.

Suporte para balanceamento de carga de camada 4 e camada 7

O NGINXaaS para Azure agora pode funcionar como um balanceador de carga nativo da nuvem TCP/UDP de Camada 4 e HTTP/HTTP de Camada 7. Por que isso é importante? Em vez de implantar dois serviços ou balanceadores de carga diferentes, o NGINXaaS para Azure permite que você implante um único balanceador de carga e o configure para funcionar em ambas as camadas ao mesmo tempo, facilitando sua arquitetura de nuvem e reduzindo seus custos.

Você pode aprender sobre a configuração aqui .

Maior capacidade (até 160 NCUs)

O NGINXaaS para Azure é um serviço baseado em consumo que é medido por hora e cobrado mensalmente em Unidades de Capacidade NGINX (NCUs) . Recentemente, dobramos essa capacidade de implantação de 80 NCUs para 160 NCUs. Os clientes podem implantar um sistema menor de 20 NCUs e, se a carga de trabalho aumentar, podem escalar até 160 NCUs. Além disso, os clientes também têm a opção de implantar até 160 NCUs no início.

Adição de diretivas NGINX Plus

Para fornecer uma experiência de configuração fácil de elevação e mudança de uma oferta local para uma oferta de nuvem totalmente gerenciada, adicionamos muitas diretivas do NGINX Plus. Consulte todas as diretivas do NGINX Plus que oferecemos suporte no NGINXaaS para Azure aqui .

Comece hoje mesmo

Estamos sempre aprimorando e expandindo as maneiras como você pode usar a tecnologia NGINX e F5 para proteger, entregar e otimizar cada aplicativo e API – em qualquer lugar. Com os recursos mencionados acima e outros novos adicionados ao NGINXaaS para Azure, mais usuários do Azure podem resolver vários problemas de aplicativos e APIs com o poder do NGINX Plus, sem a sobrecarga de gerenciar uma VM adicional ou infraestrutura de contêiner.

Se quiser saber mais sobre o NGINXaaS para Azure, recomendamos que você consulte a documentação do produto . Se você estiver pronto para experimentar o NGINXaaS para Azure, visite o Azure Marketplace ou entre em contato conosco para discutir seus casos de uso.