[Editor – O módulo NGINX ModSecurity WAF para NGINX Plus deixou oficialmente de ser comercializado em 1º de abril de 2022 e está em processo de descontinuação, que será efetivada em 31 de março de 2024. Para mais detalhes, consulte F5 NGINX ModSecurity WAF está em processo de descontinuação<.htmla> em nosso blog.]
- Autenticação de clientes de API com JWT e NGINX Plus
- NGINX Plus R10 aproveita o poder do IBM POWER
- Autenticando usuários em aplicações existentes com OpenID Connect e NGINX Plus
- Como usar o módulo JavaScript do NGINX para migrar clientes gradualmente para um novo servidor
- Transparência de IP e retorno direto do servidor com NGINX e NGINX Plus como proxy transparente
- Quais são as novidades do NGINX Plus R10? (webinar sob demanda)
]
O NGINX Plus R10 apresenta a versão inicial do nosso firewall de aplicações web (WAF), baseado no ModSecurity e com suporte completo da NGINX, Inc. Os ataques a aplicações web aumentaram 50% no último ano, e os ataques DDoS mais que dobraram, de acordo com a Akamai. Agora, todas as aplicações correm o risco de sofrer ataques. O NGINX ModSecurity WAF ajuda a proteger aplicações web contra usuários mal-intencionados e oferece aos clientes uma ferramenta versátil para ajudar a manter seus aplicativos e dados seguros.
O NGINX ModSecurity WAF bloqueia invasores
NGINX ModSecurity WAF é baseado no novo software ModSecurity 3 e é executado nativamente no NGINX Plus. Disponível como uma opção de custo adicional em nosso repositório de módulos dinâmicos e com suporte da NGINX, Inc., ele foi rigorosamente testado com o NGINX Plus. Estamos trabalhando com a Trustwave e manteremos atualizações testadas à medida que adicionarmos recursos, melhorarmos o desempenho e solucionarmos eventuais problemas.
Dois novos recursos adicionais aprimoram ainda mais os recursos de segurança do NGINX Plus:
- Tokens Web JSON – Muitos de nossos clientes usam o NGINX Plus como um gateway de API e nos pediram uma maneira comum e padronizada de autenticar o acesso às APIs na camada do NGINX Plus. Para atender a essa necessidade, nesta versão estamos adicionando suporte à autenticação por meio de Tokens Web JSON (JWTs). O NGINX Plus agora pode validar um JWT antes de permitir que os clientes acessem as APIs. Esse recurso permite que os administradores de aplicações protejam o acesso às suas APIs com um padrão aberto, evitando a dependência de um padrão proprietário. O suporte nativo a JWT também reduz a complexidade para os administradores de aplicações ao transferir as operações de autenticação – como a validação de tokens do OpenID Connect compatíveis com OAuth 2.0 – dos servidores de aplicações para o NGINX Plus.
- Suporte a “pilha dupla” para certificados ECC e RSA – Com o NGINX Plus R10, você pode disponibilizar serviços SSL/TLS usando certificados RSA e ECC. O NGINX Plus seleciona o certificado ideal com base nos recursos de cada cliente, permitindo que clientes modernos usem certificados ECC mais rápidos sem deixar de oferecer suporte a clientes legados compatíveis apenas com RSA. Os certificados ECC podem ser até três vezes mais rápidos do que certificados RSA com nível de segurança equivalente, o que resulta em mais conexões SSL/TLS por servidor e handshakes SSL/TLS mais rápidos.
Além dos recursos de segurança, o NGINX Plus R10 inclui:
- Suporte a proxy transparente – Embora muitos aplicativos HTTP modernos possam ser configurados para usar um cabeçalho
X-Forwarded-For, alguns aplicativos legados e outros serviços TCP ou UDP usam o endereço IP de origem da transação para fins de registro, segurança ou autenticação. Agora, o NGINX Plus pode “simular” o endereço IP e a porta de origem de HTTP e conexões TCP e datagramas UDP que encaminha aos servidores upstream. Isso pode ser usado para fornecer transparência de IP, uma configuração na qual o NGINX Plus envia pacotes com o endereço IP do cliente remoto, para que o servidor upstream identifique os pacotes como provenientes desse endereço, e não de um endereço IP local no servidor NGINX Plus. Esse recurso também pode ser usado para habilitar o retorno direto do servidor para protocolos baseados em UDP. - Suporte ao módulo JavaScript do NGINX – O módulo JavaScript do NGINX é a linguagem de configuração e controle de última geração para o NGINX e o NGINX Plus, oferecendo aos usuários um controle avançado e granular sobre como seus aplicativos são disponibilizados e protegidos. Nesta versão de prévia, o módulo JavaScript do NGINX amplia seu controle sobre o tráfego HTTP, TCP e UDP, gerando respostas e tomando decisões precisas para encaminhar solicitações aos servidores ideais.
- Mais melhorias no balanceamento de carga TCP e UDP – As extensões do módulo Stream adicionam suporte a mais variáveis do NGINX, cálculos usando a diretiva
map, suporte a testes A/B com a diretivasplit_clients, operações de Geo e GeoIP, além de roteamento seletivo (parâmetro variável para a diretivaproxy_passdirective). Essas extensões permitem criar políticas de balanceamento de carga TCP e UDP mais sofisticadas, orientadas pela linguagem de configuração do NGINX e pela nova integração do NGINX com JavaScript.
NGINX Plus R10 em detalhes
Firewall de Aplicações Web NGINX ModSecurity
O principal destaque do NGINX Plus R10 é a versão inicial do nosso WAF, desenvolvido com base na conhecida e confiável tecnologia ModSecurity. Desde seu lançamento inicial como software de código aberto, em 2002, o ModSecurity vem ajudando a proteger algumas das maiores propriedades web do mundo contra usuários mal-intencionados. Ele é frequentemente chamado de “canivete suíço®” da segurança. O NGINX ModSecurity WAF é uma opção com custo adicional, disponibilizada aos assinantes por meio do nosso repositório de módulos dinâmicos.
O NGINX ModSecurity WAF é uma solução indispensável para ajudar a proteger aplicações críticas. Ele oferece uma alternativa econômica a dispositivos de hardware caros, como os fornecidos pela F5, Citrix e Imperva, além de superar seus recursos graças à flexibilidade do software. O NGINX ModSecurity WAF pode ser implantado em qualquer ambiente – servidores locais e nuvens públicas, privadas e híbridas.
O NGINX ModSecurity WAF ajuda a proteger contra ataques DDoS
Um WAF opera com base em um banco de dados de “regras” que definem comportamentos maliciosos a serem bloqueados e/ou registrados. O conjunto de regras principais do OWASP ModSecurity (CRS) é um dos conjuntos de regras mais utilizados com o ModSecurity. O NGINX ModSecurity WAF usa o CRS do OWASP para identificar e bloquear uma ampla variedade de ataques a aplicações, com recursos como:
- Proteção contra ataques na camada 7 – Proteja seus aplicativos contra uma ampla variedade de ataques, como violações de HTTP, injeção de SQL, XSS, RFI, LFI e muito mais.
- Mitigação de DDoS – Mantenha a disponibilidade contínua mitigando e reduzindo o impacto de ataques DDoS sofisticados no nível da aplicação e de botnets.
- Listas de bloqueio em tempo real – Bloqueie automaticamente usuários mal-intencionados conhecidos, negando o tráfego de endereços IP identificados como maliciosos com base na reputação.
- Conformidade com o PCI-DSS 6.6 – Comece a cumprir os requisitos do PCI-DSS 6.6 para realizar transações online com segurança.
- Registro de auditoria – Responda mais rapidamente a ataques e outros tráfegos anômalos de aplicações usando as informações contidas em logs detalhados.
Conjuntos de regras adicionais também estão disponíveis por meio de diferentes fornecedores, como a TrustWave, com diferentes faixas de preço. Além disso, você pode usar a poderosa linguagem de regras do ModSecurity para definir suas próprias regras personalizadas, complementando os conjuntos de regras que estiver usando.
O suporte ao NGINX ModSecurity WAF é fornecido diretamente pela NGINX, Inc. Nossa equipe de suporte pode ajudar a instalar e configurar o WAF e o conjunto de regras principais do OWASP, bem como a solucionar problemas relacionados a eles.
O NGINX ModSecurity WAF está disponível como um módulo dinâmico no repositório do NGINX Plus, que pode ser instalado usando ferramentas padrão de gerenciamento de pacotes. Estes comandos são destinados a sistemas operacionais baseados em Debian:
# apt-get update# apt-get install nginx-plus
# apt-get install nginx-plus-module-modsecurityObserve que somente os assinantes que adquiriram o módulo NGINX ModSecurity WAF e os assinantes e avaliadores que solicitaram acesso podem baixar o pacote nginx-plus-module-modsecurity.
Para carregar o módulo NGINX ModSecurity WAF, inclua a diretiva load_module no contexto “main” de nível superior do arquivo de configuração do NGINX Plus:
Carregando exemplo de código…
Para habilitar o NGINX ModSecurity WAF com o NGINX Plus, inclua a diretiva modsecurity junto com a diretiva modsecurity_rules_file para especificar o conjunto de regras:
Carregando exemplo de código…
Em seguida, recarregue a configuração do NGINX Plus:
# nginx -t && nginx -s reloadSuporte nativo a JWT para OAuth 2.0 e OpenID Connect
Com suporte nativo ao padrão de autenticação JSON Web Token (JWT), o NGINX Plus R10 facilita a adição de soluções sofisticadas de autenticação aos seus aplicativos e APIs.
Os tokens JWT (pronuncia-se “jot”), definidos na RFC 7519, são o formato de dados subjacente para informações de usuários no padrão OpenID Connect, que é a camada de identidade padrão sobre o protocolo OAuth 2.0. Responsáveis pela implantação de APIs e microsserviços também estão adotando o padrão JWT por sua simplicidade e flexibilidade.
[Editor – Para casos de uso que aproveitam o suporte nativo a JWT, consulte estes artigos:
]
NGINX Plus valida o JWT antes de permitir o acesso dos clientes
Como um proxy reverso e balanceador de carga, o NGINX Plus fica à frente das aplicações, o que o coloca em uma posição ideal para simplificar o desenvolvimento de aplicações ao assumir a validação do JWT fornecido em cada solicitação HTTP. Isso oferece dois benefícios. Primeiro, o NGINX Plus pode ajudar a impedir que solicitações não autenticadas, malformadas e maliciosas cheguem à aplicação, protegendo-a do esforço e dos riscos envolvidos no processamento dessas solicitações.
O segundo benefício é que o NGINX Plus tem acesso a todos os campos do JWT validado (após a verificação da assinatura) e pode usar a capacidade e a flexibilidade inerentes à sua sintaxe de configuração para fornecer soluções sofisticadas de autenticação tanto para microsserviços quanto para APIs:
- Um caso de uso típico para microsserviços é fazer com que o NGINX Plus valide o JWT e forneça a identidade do usuário autenticado à aplicação de backend por meio de um cabeçalho HTTP. Isso elimina a necessidade de implementar repetidamente a mesma funcionalidade de autenticação em cada microsserviço.
- Para APIs, o NGINX Plus pode limitar a taxa de acesso efetivamente por usuário, em vez de depender do mapeamento aproximado de endereços IP para usuários finais.
O trecho de exemplo de configuração do NGINX Plus a seguir mostra como usar JWTs para proteger um site.
A diretiva auth_jwt instrui o NGINX Plus a usar JWT para autenticar os usuários que fazem solicitações a um domínio, neste caso, myrealm. A diretiva auth_jwt_key_file indica qual JSON Web Key (JWK) deve ser usada para validar a assinatura do token; ela funciona como a chave pública na criptografia SSL/TLS. O local do arquivo deve estar acessível ao NGINX Plus.
À medida que o NGINX Plus valida e analisa o token, ele cria automaticamente variáveis do NGINX para as “declarações” no JWT, que representam entidades associadas a ele (por exemplo, o emissor, o usuário para o qual ele foi emitido e o destinatário pretendido). Todos os nomes das variáveis começam com $jwt_claim_. Em seguida, você pode usar a diretiva add_header para fazer com que o NGINX Plus transmita uma declaração aos servidores de backend na forma de um cabeçalho HTTP definido com o valor da variável $jwt_claim_. Em nosso exemplo, o NGINX Plus transmite a identidade do usuário ao aplicativo de backend na variável $jwt_claim_sub, que corresponde ao ID do usuário (declaração sub) no JWT.
Carregando exemplo de código…
No NGINX Plus R8, lançamos uma prévia tecnológica do suporte a OAuth2. Na implementação do NGINX Plus R10, incorporamos o feedback de nossos clientes para oferecer uma solução pronta para produção que atende aos casos de uso mais importantes no complexo universo da autenticação de usuários e computadores.
Suporte a certificados RSA e ECC em “pilha dupla”
Agora há muitos motivos para começar a criptografar todo o tráfego de aplicações com SSL/TLS. O Google recompensa sites criptografados com SSL/TLS com melhores posições nos mecanismos de busca. Além disso, padrões modernos da Web, como o HTTP/2, estão tornando obrigatória a criptografia SSL/TLS para todos os sites.
Com o NGINX Plus R10, você pode disponibilizar serviços SSL/TLS usando certificados RSA e ECC. Em nossos testes, os certificados ECC foram até três vezes mais rápidos do que os certificados RSA com nível de segurança equivalente, o que resulta em mais conexões SSL/TLS por servidor e handshakes SSL/TLS mais rápidos. O NGINX Plus seleciona o certificado ideal com base nos recursos de cada cliente, permitindo que clientes modernos usem certificados ECC de maior velocidade sem deixar de oferecer suporte a clientes legados compatíveis apenas com RSA.
Para oferecer suporte a certificados RSA e ECC, basta incluir, na configuração de um servidor virtual, um par das diretivas ssl_certificate e ssl_certificate_key para cada tipo de certificado, conforme mostrado no exemplo a seguir.
Carregando exemplo de código…
Proxy transparente
Estamos continuamente adicionando recursos ao NGINX Plus, como balanceamento de carga TCP e UDP, para oferecer suporte a uma variedade maior de aplicações e modelos de implantação. Com o NGINX Plus R10, adicionamos um recurso de proxy transparente que permite ao NGINX Plus enviar pacotes aos servidores upstream usando qualquer endereço IP e porta de origem. Isso possibilita configurações como Transparência de IP e Retorno Direto do Servidor.
Transparência de IP é uma configuração na qual o balanceador de carga (NGINX Plus) usa o endereço IP do cliente remoto como endereço IP de origem nos pacotes que envia aos servidores upstream. Isso significa que os servidores upstream identificam os pacotes como provenientes do endereço IP do cliente remoto, e não de um endereço IP local no balanceador de carga. Isso é importante quando as aplicações usam o endereço IP de origem para fins de registro em log, segurança, limitação de taxa ou autenticação.
A transparência de IP também é um componente fundamental de uma técnica de balanceamento de carga de rede chamada Retorno direto do servidor (DSR). O NGINX Plus pode executar DSR para protocolos baseados em UDP (mas não TCP ou HTTP), permitindo que os pacotes de retorno ignorem completamente o balanceador de carga e sejam enviados diretamente ao cliente remoto.
No modo DSR, o servidor de backend responde diretamente ao cliente
A transparência de IP e o DSR são configurados com o novo parâmetro transparent nas diretivas proxy_bind, fastcgi_bind, memcached_bind, scgi_bind e uwsgi_bind. O exemplo a seguir mostra como configurar o DSR para um backend de DNS. A diretiva proxy_responses especifica que o NGINX Plus não precisa receber nenhuma resposta do servidor (zero é o valor apropriado para o DSR).
Carregando exemplo de código…
Observe que as verificações de integridade passivas não são eficazes quando o DSR está habilitado, pois elas exigem que o NGINX Plus verifique se o servidor enviou uma resposta ao cliente. A configuração de verificações de integridade ativas com reconhecimento de aplicações é obrigatória para uma configuração de DSR. Para ver um exemplo, consulte nossas instruções detalhadas sobre como configurá-las para servidores DNS com balanceamento de carga.
As configurações de Transparência de IP e DSR são complexas, com requisitos adicionais de roteamento e reescrita de pacotes que estão fora do escopo do software NGINX Plus. Para obter instruções completas, consulte Transparência de IP e Retorno Direto do Servidor com NGINX e NGINX Plus como proxy transparente em nosso blog.
O módulo JavaScript do NGINX para aplicações baseadas em HTTP, TCP e UDP
[Editor – O módulo JavaScript do NGINX era anteriormente chamado de nginScript. O módulo passou a estar disponível para uso geral no NGINX Plus R12 (e no NGINX 1.11.10).
Para análises detalhadas de outros casos de uso do módulo JavaScript do NGINX, consulte Casos de uso do módulo JavaScript do NGINX.
O código nesta seção foi atualizado para usar a js_import diretiva, que substitui a diretiva js_include no NGINX Plus R23 e em versões posteriores. Para obter mais informações, consulte a documentação de referência do módulo JavaScript do NGINX – a seção Exemplo de configuração mostra a sintaxe correta para os arquivos de configuração do NGINX e JavaScript.]
O NGINX Plus R10 inclui uma versão de prévia da nossa nova linguagem de configuração NGINX JavaScript. Ela ainda não conta com todos os recursos, e agradecemos qualquer feedback sobre o trabalho realizado até o momento. O NGINX JavaScript permite usar código JavaScript para executar ações complexas e personalizadas no tráfego HTTP, TCP e UDP. Ele oferece uma nova e poderosa maneira de controlar como seus aplicativos são disponibilizados e protegidos. Com o NGINX JavaScript, você pode:
- Escreva funções “sem servidor” diretamente no NGINX Plus usando a poderosa linguagem de programação JavaScript
- Formate, manipule e transforme dados de API
- Forneça serviços TCP simples, como um servidor de horário
- Use JavaScript para definir variáveis do NGINX, criar decisões personalizadas de balanceamento de carga, chaves de cache e muito mais
A versão prévia do NGINX JavaScript está disponível em nosso repositório de módulos dinâmicos. Você pode instalá-la usando as ferramentas padrão de gerenciamento de pacotes. Estes comandos são para sistemas operacionais baseados no Debian:
# apt-get update
# apt-get install nginx-plus
# apt-get install nginx-plus-module-njsPara carregar os módulos JavaScript do NGINX para HTTP e TCP/UDP, inclua a diretiva load_module no contexto “main” de nível superior do arquivo de configuração do NGINX Plus:
Carregando exemplo de código…
Em seguida, recarregue a configuração do NGINX Plus para carregar os módulos JavaScript do NGINX:
# nginx -t && nginx -s reloadOs usuários do NGINX Open Source podem obter o NGINX JavaScript em nosso repositório de código aberto.
O código JavaScript não é incluído diretamente na configuração do NGINX Plus. Em vez disso, ele é carregado com a diretiva js_import. Neste exemplo, o código JavaScript de uma função “sem servidor” simples é carregado de /etc/nginx/conf.d/functions.js. A diretiva js_content instrui o NGINX Plus a chamar a função JavaScript e retornar os resultados ao cliente.
Carregando exemplo de código…
O código JavaScript em /etc/nginx/conf.d/functions.js preenche uma string de caracteres com um conjunto especificado de caracteres:
Carregando exemplo de código…
Recursos adicionais
O NGINX Plus R10 apresenta diversas melhorias adicionais para ajudar você a fornecer aplicações de forma impecável, incluindo:
- TCP/UDP load balancing, implemented in the Stream module, now has greater feature parity with HTTP load balancing. Newly supported modules include Split Clients for A/B testing, GeoIP to take actions based on the geographical location of clients, and Geo to define variables based on IP address. More information is available through additional NGINX variables, and you can perform routing decisions using a variable as the parameter to the
proxy_passdirective. - Um problema comum em aplicações com alto volume de tráfego é o esgotamento de portas efêmeras, que impede a criação de novas conexões com servidores upstream quando o sistema operacional fica sem números de porta disponíveis. Para solucionar esse problema, o NGINX Plus agora usa a opção de soquete
IP_BIND_ADDRESS_NO_PORTquando disponível. Essa opção permite reutilizar portas de origem em conexões de saída com servidores upstream, desde que a “quádrupla” padrão (endereço IP de origem, endereço IP de destino, porta de origem e porta de destino) seja exclusiva. Ela está disponível em sistemas com a versão 4.2 ou posterior do kernel Linux e com a versão glibc 2.22 ou posterior. - O NGINX Plus gera a nova variável
$request_idautomaticamente para cada nova solicitação HTTP, atribuindo efetivamente à solicitação um “ID de transação” exclusivo. Isso facilita o rastreamento de aplicações e adiciona recursos de APM às ferramentas de análise de logs. O ID de transação é encaminhado por proxy para aplicações de backend e microsserviços, permitindo que todas as partes do sistema registrem um identificador consistente para cada transação. - As diretivas
proxy_request_buffering,fastcgi_request_buffering,scgi_request_bufferingeuwsgi_request_bufferingagora funcionam com HTTP/2 e podem ser usadas para ativar ou desativar o buffer de solicitações. - A nova diretiva
http2_body_preread_sizepermite que clientes HTTP/2 comecem a enviar o corpo da solicitação imediatamente. A diretiva controla o tamanho do buffer usado antes que o NGINX Plus comece a ler o corpo da solicitação do cliente.
O pacote NGINX Plus Extras foi descontinuado
Conforme anunciamos previamente no lançamento do NGINX Plus R9, a R10 é a última versão que incluirá o pacote NGINX Plus Extras.
Recomendamos enfaticamente que você modifique agora seus procedimentos de instalação e configuração para usar o pacote nginx-plus e carregar dinamicamente os módulos do pacote nginx-plus-extras que você realmente utiliza. A partir do NGINX Plus R11, essa será a única maneira possível de usar módulos que não estão integrados ao pacote nginx-plus.
Para mudar para o pacote nginx-plus e os módulos dinâmicos, siga estas etapas:
- Remova o pacote nginx-plus-extras e instale o nginx-plus e os módulos dinâmicos que deseja usar. Para sistemas baseados em Debian, o conjunto de comandos apropriado é:
# apt-get update
# apt-get remove nginx-plus-extras
# apt-get install nginx-plus
# apt-get install module-name- No contexto principal (nível superior) em /etc/nginx/nginx.conf, adicione uma diretiva
load_modulepara cada módulo carregado dinamicamente:Carregando exemplo de código…
- Verifique se a nova configuração é sintaticamente válida e recarregue-a:
# nginx -t && nginx -s reloadAtualize ou experimente o NGINX Plus
Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para a versão 10 o mais rápido possível. Você terá acesso a diversas correções e melhorias, além de facilitar nosso atendimento caso precise abrir um chamado de suporte. As instruções de instalação e atualização estão disponíveis no portal do cliente do NGINX Plus.
OBSERVAÇÃO: o NGINX Plus R10 é a última versão que incluirá o pacote nginx-plus-extras. Consulte O pacote NGINX Plus Extras foi descontinuado, acima.
Se você ainda não experimentou o NGINX Plus, recomendamos que o experimente para aceleração da Web, balanceamento de carga e entrega de aplicações, ou como um servidor Web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Você pode começar gratuitamente hoje mesmo com uma avaliação de 30 dias e conferir por conta própria como o NGINX Plus pode ajudar você a disponibilizar e escalar suas aplicações.
Mais informações sobre o NGINX Plus R10
Para obter mais detalhes sobre os principais novos recursos do NGINX Plus R10, consulte estes materiais relacionados:
- Autenticação de clientes de API com JWT e NGINX Plus
- NGINX Plus R10 aproveita o poder do IBM POWER
- Autenticação de usuários em aplicações existentes com OpenID Connect e NGINX Plus
- Como usar o módulo JavaScript do NGINX para migrar clientes gradualmente para um novo servidor
- Transparência de IP e retorno direto do servidor com NGINX e NGINX Plus como proxy transparente
- Quais são as novidades do NGINX Plus R10? (webinar sob demanda)
[O NGINX ModSecurity WAF saiu oficialmente de comercialização em 1º de abril de 2022 e está em transição para o fim da vida útil, que entrará em vigor em 31 de março de 2024. Para mais detalhes, consulte O F5 NGINX ModSecurity WAF está em transição para o fim da vida útil em nosso blog.]
Sobre o autor

Publicações relacionadas no blog

Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.

Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.

Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.

Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.