Anunciando o NGINX Plus R25

Zach WestallGerente Sênior de Marketing de Produto

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 25 (R25). Baseado no NGINX Open Source, o NGINX Plus é a única solução de software completa que reúne servidor web, balanceador de carga, proxy reverso, cache de conteúdo e gateway de API.

Os novos recursos do NGINX Plus R25 incluem:

• Casos de uso adicionais e mais avançados de JSON Web Token – O NGINX Plus R25 amplia o suporte a JSON Web Tokens criptografados (JWE) introduzido no NGINX Plus R24.
• Relatórios mais granulares dos códigos de resposta HTTP – A API do NGINX Plus agora contabiliza os códigos de resposta HTTP individualmente e também de forma agregada por classe. Talvez seja necessário aumentar a alocação de memória; consulte Alocar memória suficiente para evitar falhas na inicialização.
• Carregamento dinâmico de certificados de cliente SSL/TLS para conexões com proxy – Você pode usar variáveis para selecionar dinamicamente os certificados para conexões mTLS entre o NGINX Plus e os servidores de backend.
• Segurança reforçada para o processamento de solicitações HTTP – O NGINX Plus realiza várias verificações adicionais nas solicitações HTTP para proteger seus aplicativos contra possíveis ataques.
• Persistência do status das verificações de integridade após recarregamentos para aplicações TCP/UDP – Os resultados das verificações de integridade obrigatórias dos servidores TCP/UDP agora podem ser mantidos após o recarregamento da configuração.
• Aprimoramentos no módulo JavaScript do NGINX – A compatibilidade com o JavaScript ES6 foi aprimorada.

Mudanças importantes de comportamento

Maior requisito de memória para zonas upstream

Conforme descrito em detalhes em Relatórios mais granulares de códigos de resposta HTTP, o NGINX Plus R25 fornece contagens de códigos de status individuais, bem como contagens agregadas por classe. Quando o NGINX Plus é configurado como proxy reverso ou balanceador de carga, talvez seja necessário aumentar o tamanho da zona de memória compartilhada usada para monitorar os “peers” upstream (servidores de backend), caso haja mais de 20 peers.

O NGINX Plus R25 não será iniciado se as zonas de memória compartilhada tiverem memória insuficiente, causando falhas nas atualizações. Antes de atualizar, é importante verificar a utilização da memória de cada zona upstream. Para obter instruções sobre como verificar e ajustar a alocação de memória, consulte Alocar memória suficiente para evitar falhas na inicialização.

Alterações na organização do repositório e no procedimento de instalação do NGINX Plus

Com o lançamento do NGINX Plus R24, os repositórios de pacotes de todos os softwares da NGINX foram reorganizados, o que resultou em alterações no procedimento de instalação do NGINX Plus.

Ao instalar ou atualizar o NGINX Plus, o gerenciador de pacotes do sistema operacional (apt, yum ou equivalente) é configurado com o repositório de software do NGINX Plus. Em sistemas existentes configurados para usar o repositório antigo (aqueles que executam o NGINX Plus R23 ou uma versão anterior), é necessário atualizar o gerenciador de pacotes para que ele aponte para o novo repositório. Consulte as instruções na Base de Conhecimento da F5.

Se estiver realizando uma instalação inicial do NGINX Plus R25, consulte Instalação do NGINX Plus no Guia de Administração do NGINX Plus.

Observação: Você deve usar o novo repositório de software. O repositório antigo não será mais atualizado e poderá causar erros em futuras instalações e atualizações.

Módulo Cookie-Flag obsoleto

Conforme anunciado no lançamento do NGINX Plus R23, o módulo Cookie-Flag de terceiros foi descontinuado e será removido do repositório de módulos dinâmicos no NGINX Plus R26. A diretiva set_cookie_flag definida nesse módulo foi substituída pela diretiva integrada proxy_cookie_flags. Recomendamos que você substitua todas as diretivas set_cookie_flag da sua configuração por diretivas proxy_cookie_flags o mais rápido possível.

Alterações no suporte a plataformas

• Novos sistemas operacionais compatíveis:
  • Debian 11 (x86_64, aarch64)
  • Alpine Linux 3.14 (x86_64, aarch64)
• Sistemas operacionais mais antigos removidos:
  • Alpine Linux 3.10; a versão mais antiga com suporte é a 3.11
  • Amazon Linux 1 (2018.03+); migre para o Amazon Linux 2 LTS
  • FreeBSD 11.4+; a versão mais antiga com suporte é a 12.1+
  • Ubuntu 16.04 LTS; a versão mais antiga com suporte é a 18.04 LTS
• Sistemas operacionais mais antigos descontinuados e com remoção programada no NGINX Plus R26:
  • Alpine Linux 3.11

Novos recursos em detalhes

Casos de uso e funcionalidades adicionais do JSON Web Token

NGINX Plus R24 introduziu o suporte inicial a JSON Web Tokens criptografados (JWE), acrescentando confidencialidade de dados a um dos métodos mais populares de autenticação de clientes. O NGINX Plus R25 amplia esse recurso e introduz suporte a casos de uso de autenticação adicionais e mais avançados, que ajudam a aumentar a segurança da autenticação baseada em JWT tanto para tokens assinados (JWS) quanto para tokens criptografados (JWE). As melhorias reduzem o risco de vazamento de informações de identificação pessoal (PII) e oferecem mais flexibilidade. As novas funcionalidades e melhorias de JWT do NGINX Plus incluem:

• Uma nova variável para o texto cifrado JWE descriptografado
• Suporte a JWTs aninhados
• Criptografia assimétrica para JWE
• Suporte a JSON Web Keys de múltiplas fontes
• Regras adicionais personalizadas de validação de JWT

Variável para o texto cifrado JWE descriptografado

Os JWTs são um método amplamente utilizado e confiável para a autenticação sem estado de solicitações HTTP (ou seja, autenticação baseada em token). Ao transmitir atributos do usuário final no payload do token, os JWTs ajudam a tornar as solicitações mais seguras. No entanto, pesquisadores de segurança e profissionais de DevSecOps concordam que o risco de armazenar PII não criptografadas em clientes web é uma preocupação urgente — daí o desenvolvimento do padrão JSON Web Encryption (RFC 7516), que fornece diretrizes para a implementação de tokens criptografados.

O NGINX Plus R24 introduziu suporte a JWE, garantindo a integridade e a confidencialidade dos dados de todo o conjunto de declarações. A codificação de PII no token criptografado reduz significativamente o risco de vazamento de dados ao usar JWTs.

O NGINX Plus R25 amplia o suporte inicial a JWE com uma nova variável, $jwt_payload, que permite ao NGINX Plus descriptografar o JWE e o texto cifrado e, em seguida, acessar o texto simples durante o processamento da solicitação HTTP. Essa nova funcionalidade pode ser usada para implementar políticas avançadas de controle de acesso e decisões de roteamento de solicitações, além de permitir que os usuários implantem o NGINX Plus como uma camada de descriptografia de JWE para aplicações de backend.

Suporte a JWTs aninhados

Os tokens JWE são eficazes na proteção de informações de identificação pessoal (PII), pois o texto cifrado preserva a confidencialidade mesmo ao passar por CDNs e outros proxies que encerram conexões TLS. No entanto, a criptografia é uma faca de dois gumes, já que os JWEs podem aumentar a complexidade do ambiente da aplicação. Uma forma de resolver esse problema é usar JWTs aninhados.

Anatomia de um JWT aninhado

Os JWTs aninhados incorporam o JWS como o texto cifrado de um JWE. O NGINX Plus R25 permite usar JWTs aninhados como método de autenticação de solicitações HTTP, oferecendo suporte simultâneo a JWS e JWE. Em uma única operação, o NGINX Plus agora pode descriptografar o texto cifrado no JWE, validar o texto simples resultante como um JWS e usar as declarações exp (tempo de expiração) e nbf (não antes de) no token encapsulado para verificar se ele é válido. Isso permite atualizar um ambiente JWS existente com criptografia de payload, encapsulando-o em um JWE.

O trecho de configuração a seguir ilustra o processo. O novo parâmetro nested da diretiva auth_jwt_type instrui o NGINX Plus a realizar tanto a descriptografia de JWE quanto a validação de JWS. Ele também afeta a forma como as variáveis dos cabeçalhos e das declarações JWT são avaliadas:

• A diretiva auth_jwt_header_set opera nos cabeçalhos JWE externos.
• A diretiva auth_jwt_claim_set opera nas declarações do JWS aninhado.
• $jwt_header_name contêm as propriedades do cabeçalho JWE externo.
• $jwt_claim_name contêm as declarações do JWS aninhado.

Carregando exemplo de código…

Com a configuração a seguir, o NGINX Plus cria e envia cabeçalhos adicionais de requisição HTTP para a aplicação de backend. O algoritmo de criptografia do cabeçalho JWE (a variável $jwt_header_enc) e a declaração de assunto do JWT presente no payload JWS (a variável $jwt_claim_sub) são encaminhados por proxy junto com a requisição original. Isso significa que as aplicações podem usar a autenticação baseada em JWE simplesmente consumindo cabeçalhos HTTP, sem precisar implementar código ou bibliotecas de criptografia.

Carregando exemplo de código…

Para usuários que operam em arquiteturas de confiança zero, a configuração a seguir permite que a aplicação de backend valide o token JWS conforme capturado na variável $jwt_payload. A variável contém a versão em texto simples descriptografada do texto cifrado JWE. Se houver um JWT aninhado, o JWS poderá ser transmitido à aplicação de backend como um token de portador.

Carregando exemplo de código…

Em essência, os JWTs aninhados simplificam as operações e aumentam a segurança das aplicações, permitindo que o NGINX Plus descriptografe e valide tokens seguros simultaneamente, enquanto analisa ou encaminha por proxy o token assinado de “JWT comum” para as aplicações de backend.

Criptografia assimétrica para JWE

O NGINX Plus R24 introduziu suporte à criptografia simétrica de tokens usando o padrão AES. O NGINX Plus R25 adiciona suporte à criptografia assimétrica com o uso de pares de chaves RSA. A criptografia assimétrica usa chaves diferentes (pública e privada) para criptografar e descriptografar, que são matematicamente vinculadas entre si pelo algoritmo RSA (Rivest–Shamir–Adleman), o mesmo mecanismo usado na criptografia SSL/TLS do tráfego HTTPS entre cliente e servidor.

O NGINX Plus R25 oferece suporte a RSA com Optimal Asymmetric Encryption Padding (OEAP) como algoritmo de gerenciamento de chaves, sem exigir configuração explícita no NGINX Plus. Os valores compatíveis com o cabeçalho JWS alg (algoritmo) são RSA-OAEP, RSA-OAEP-256, RSA-OAEP-384 e RSA-OAEP-512.

A configuração a seguir mostra que, para implementar a criptografia assimétrica para JWE, basta especificar o arquivo JSON Web Key (JWK) que contém as chaves privadas RSA (de desembrulhamento) como parâmetro da diretiva auth_jwt_key_file (a diretiva auth_jwt_key_request também pode ser usada).

Carregando exemplo de código…

Suporte a JWK de múltiplas fontes

O uso de JWTs aninhados significa que as JWKs associadas provavelmente virão de mais de uma fonte. O NGINX Plus R25 oferece suporte a várias diretivas auth_jwt_key_file e auth_jwt_key_request no mesmo contexto. O NGINX Plus carrega chaves de todas as fontes especificadas e procura a chave de verificação correspondente no conjunto combinado de chaves — algo extremamente útil ao trabalhar com um JWS emitido por um provedor de identidade externo e aninhado em um JWE, cuja criptografia foi realizada por um processo separado.

Esse recurso proporciona ainda mais flexibilidade, segurança e capacidade ao NGINX Plus implantado como gateway de API.

Regras personalizadas de validação de JWT

Quando o NGINX Plus é implantado como um gateway de API, é comum inspecionar as declarações JWT para implementar um controle de acesso granular. Isso pode resultar em configurações complexas. Em versões anteriores do NGINX Plus, era possível usar blocos de configuração if para avaliar declarações JWT, mas essa abordagem era um tanto limitada e não funcionava com tokens criptografados.

O NGINX Plus R25 resolve essa limitação ao oferecer uma maneira nativa de realizar verificações adicionais no token durante o processo de validação do JWT. A diretiva auth_jwt_require adiciona uma etapa opcional e personalizável ao processo de validação do JWT. Ela aceita uma lista de strings separadas por espaços, e todas devem ser não vazias e diferentes de 0 (zero) para que a validação do JWT seja bem-sucedida. Isso proporciona enorme flexibilidade ao processo de validação do JWT.

O padrão JWT não determina quais declarações são obrigatórias, portanto, você pode usar auth_jwt_require para listar as declarações apropriadas para cada ambiente.

A configuração a seguir garante que as declarações exp e sub estejam presentes em todos os tokens.

Carregando exemplo de código…

Você pode configurar casos de uso mais complexos usando blocos map ou o armazenamento de chave-valor do NGINX Plus para passar valores booleanos para a diretiva auth_jwt_require. Você também pode usar o módulo JavaScript do NGINX para implementar soluções avançadas de autenticação, como tokens de acesso vinculados a certificados de cliente TLS mútuo (mTLS), definidos na RFC 8705.

A configuração a seguir realiza tanto a autenticação por certificado de cliente (mTLS) quanto a validação de JWT. A diretiva auth_jwt_require na linha 14 determina que a variável $thumbprint_match seja avaliada, e a validação de JWT só será bem-sucedida se ela tiver um valor diferente de zero. Essa variável é avaliada por meio da execução da função JavaScript invocada na linha 2.

Carregando exemplo de código…

Este é o código da função validate chamada na linha 2 do trecho anterior:

Carregando exemplo de código…

Relatórios mais detalhados dos códigos de resposta HTTP

O monitoramento e a visibilidade são fundamentais para o desempenho, a disponibilidade e a segurança das aplicações. Os códigos de resposta HTTP são uma das fontes mais importantes de informações sobre a integridade das aplicações. A API do NGINX Plus monitora os códigos de resposta HTTP tanto nas interações entre o NGINX e os clientes quanto entre o NGINX e os servidores upstream; as contagens são exibidas nas respectivas guias do painel de monitoramento de atividades em tempo real.

As versões anteriores da API do NGINX Plus agregavam as contagens de códigos de resposta HTTP por classe (2xx, 4xx e assim por diante). Agora, os códigos também são contabilizados individualmente (200, 404, 503 etc.). Isso oferece uma visão mais detalhada do que exatamente está acontecendo com uma aplicação, permitindo distinguir entre erros com causas muito diferentes, como picos de falhas de autenticação (403) e conteúdo não encontrado (404). Para obter informações sobre como configurar a coleta de métricas, consulte o Guia de Administração do NGINX Plus.

A versão mais recente da API do NGINX Plus (versão 7), lançada com o NGINX Plus R25, inclui um objeto codes dentro do objeto responses para permitir a contagem individual dos códigos de resposta HTTP. As respostas agregadas continuam disponíveis, e as versões anteriores da API do NGINX Plus – que não incluem o objeto codes – ainda podem ser usadas com o NGINX Plus R25. Veja um exemplo do novo conjunto de métricas:

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq{
  "processing": 31,
  "requests": 63192,
  "responses": {
    "1xx": 0,
    "2xx": 54368,
    "3xx": 8454,
    "4xx": 330,
    "5xx": 9,
    "codes": {
      "200": 54368,
      "302": 8454,
      "401": 30,
      "404": 200,
      "429": 100,
      "503": 9
    },
    "total": 63161
  },
  "discarded": 0,
  "received": 693436,
  "sent": 13843478
}

Aloque memória suficiente para evitar falhas na inicialização

Observação importante: Quando o NGINX Plus é configurado como proxy reverso ou balanceador de carga, a contagem de códigos individuais aumenta o uso de memória na zona de memória compartilhada de cada grupo upstream. Se houver mais de 20 peers no grupo upstream, talvez seja necessário aumentar o tamanho da memória, conforme configurado com a diretiva zone.

O NGINX Plus R25 não inicia se as zonas upstream tiverem recursos insuficientes, causando falhas nas atualizações.

Veja uma configuração típica da zona de memória compartilhada para um grupo upstream:

Carregando exemplo de código…

Antes de fazer upgrade para o NGINX Plus R25, é importante verificar a utilização de memória das zonas upstream existentes. Para isso, certifique-se de que a API do NGINX Plus esteja habilitada antes de usar um destes métodos:

• Verifique a guia Upstreams HTTP do painel de monitoramento de atividades em tempo real, como neste exemplo de demo.nginx.com, em que a utilização é de 54%:
  
• Use a API do NGINX Plus diretamente no host executando o comando a seguir. Primeiro:

$ API=http://localhost:8080/api; for i in `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'`; do echo -n $i; curl -s $API/1/slabs/$i | jq -r '.pages | 100*(.used / (.used + .free)) | " \(round)% used"'; done

• Instale o utilitário jq utility se necessário
• Defina a variável API como o local onde a diretiva api está habilitada

Se a utilização atual estiver acima de 40% (como na captura de tela), aumente o segundo parâmetro (tamanho) da diretiva zone em pelo menos 2,5 vezes. Por exemplo, recomendamos aumentar 64k para 160k no trecho de configuração acima.

Carregamento dinâmico de certificados de cliente SSL/TLS para proxy

O TLS mútuo (mTLS) é uma prática comum de autenticação que envolve a verificação da identidade tanto do cliente quanto do servidor. Com o NGINX Plus, você pode definir os servidores em um grupo upstream dinamicamente e com variáveis. Isso significa que talvez você também precise selecionar dinamicamente o certificado TLS usado pelo NGINX Plus para se autenticar nesses servidores upstream.

O NGINX Plus R25 amplia as diretivas de configuração usadas para mTLS com um servidor de backend, permitindo que aceitem uma variável que represente o certificado. A variável pode fazer referência a qualquer uma destas opções:

• Um arquivo no disco
• Dados brutos no formato PEM, prefixados com data:

Isso permite que o NGINX Plus selecione dinamicamente um certificado e uma chave privada, o que é útil para ambientes de aplicações modernos sujeitos a mudanças constantes. Você pode armazenar o certificado e a chave privada no armazenamento de chave-valor do NGINX Plus, o que aumenta a segurança, pois a chave privada é armazenada na memória, e não no disco. Outro caso de uso é a rotação automatizada de certificados, na qual você usa uma chamada de API para atualizar os certificados no armazenamento de chave-valor.

Na configuração a seguir, o NGINX Plus encaminha as solicitações para diferentes grupos de upstream com base no nome do host. A conexão com proxy é estabelecida usando mTLS, e o certificado de cliente apropriado para cada upstream é selecionado dinamicamente.

Carregando exemplo de código…

As diretivas a seguir oferecem suporte ao carregamento dinâmico de certificados para mTLS com servidores upstream:

• grpc_ssl_certificate
• grpc_ssl_certificate_key
• proxy_ssl_certificate
• proxy_ssl_certificate_key
• uwsgi_ssl_certificate
• uwsgi_ssl_certificate_key

Segurança reforçada para o processamento de requisições HTTP

Um dos princípios fundamentais da filosofia do NGINX é a melhoria contínua, especialmente no que diz respeito à segurança. Utilizamos todos os recursos disponíveis, incluindo a colaboração com pesquisadores de segurança, a integração das tecnologias de segurança líderes do setor da F5 aos nossos produtos e os esforços internos de desenvolvimento.

Como exemplo desse último recurso, o NGINX Plus R25 realiza várias verificações adicionais nas solicitações HTTP para proteger seus aplicativos contra possíveis ataques, como o contrabando de requisições. Ele retorna um erro nas seguintes condições:

• Uma solicitação HTTP/1.0 inclui o cabeçalho Transfer-Encoding header
• Os cabeçalhos Transfer-Encoding e Content-Length estão ambos presentes
• Há espaços ou caracteres de controle na linha da solicitação ou no nome de algum cabeçalho
• Há espaços ou caracteres de controle no cabeçalho Host header
• O método CONNECT é usado

Além disso, os seguintes caracteres agora são sempre escapados em um URI com proxy: ", <, >, \, ^, `, {, |, }.

Observe que essas alterações são melhorias proativas de segurança e não foram feitas em resposta a nenhuma vulnerabilidade conhecida.

Persistência do status obrigatório da verificação de integridade ao recarregar aplicações TCP/UDP

O NGINX Plus usa verificações de integridade obrigatórias para garantir que os novos servidores adicionados aos grupos upstream sejam testados e estejam íntegros antes que as solicitações dos clientes sejam encaminhadas a eles por proxy. No NGINX Plus R23 e em versões anteriores, os servidores upstream eram considerados não íntegros após uma recarga da configuração, independentemente do status que tinham antes da recarga. Como resultado, o NGINX Plus não enviava solicitações a um servidor até que ele fosse aprovado na primeira verificação obrigatória.

O NGINX Plus R24 introduziu, para aplicações HTTP, a persistência opcional do status das verificações de integridade obrigatórias entre recarregamentos. Se a última verificação de integridade obrigatória antes de um recarregamento tiver sido bem-sucedida, o NGINX Plus poderá enviar solicitações a um servidor imediatamente, em vez de ter que aguardar o êxito de uma verificação de integridade obrigatória após o recarregamento.

O NGINX Plus R25 estende essa funcionalidade a aplicações TCP/UDP (no contexto stream). Assim como no HTTP, adicione o parâmetro persistent à diretiva health_check junto com o parâmetro mandatory.

Carregando exemplo de código…

Aprimoramentos no módulo JavaScript do NGINX

O módulo JavaScript do NGINX (njs) foi atualizado para a versão 0.6.2, com várias correções de bugs e alguns aprimoramentos funcionais que reforçam a compatibilidade com o JavaScript ES6.

Declaração de variáveis com as palavras-chave let e const Keywords

O NGINX JavaScript agora permite declarar variáveis com escopo usando as palavras-chave let e const. As versões anteriores do NGINX Plus e do njs permitiam apenas a palavra-chave var para declarar e atribuir variáveis. Isso não permitia criar variáveis limitadas ao escopo de uma instrução block específica, necessárias para lidar com a complexidade que costuma surgir quando diferentes projetos, linguagens de programação e equipes de engenharia colaboram em bases de código ou bibliotecas compartilhadas.

O JavaScript ES6 fornece as palavras-chave let e const para definir variáveis com escopo:

• let variáveis são limitadas ao escopo de uma instrução block ou de uma expressão na qual são usadas. Em contrapartida, a palavra-chave var declara uma variável globalmente ou localmente em uma função inteira, independentemente do escopo de bloco.
• const têm escopo de bloco, assim como as variáveis declaradas usando a palavra-chave let. O valor de uma constante não pode ser alterado por reatribuição nem pode ser redeclarado.

Suporte a todos os métodos construtores de Promise Constructor Methods

Com a adição dos métodos construtores Promise.all(), Promise.allSettled(), Promise.any(), e Promise.race(), o njs agora oferece suporte ao conjunto completo de métodos construtores definidos no padrão JavaScript ES6.

Atualize ou experimente o NGINX Plus

Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para o NGINX Plus R25 o mais rápido possível. Você também terá acesso a várias correções e melhorias adicionais, além de facilitar o suporte da NGINX quando precisar abrir um chamado.

Se você ainda não experimentou o NGINX Plus, recomendamos que o teste – para segurança, balanceamento de carga e gateway de API, ou como um servidor web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Você pode começar hoje mesmo com uma avaliação gratuita de 30 dias.

Sobre o autor

Zach WestallGerente Sênior de Marketing de Produto

Mais publicações de Zach Westall