BLOG | NGINX

Automatize a segurança com o F5 NGINX App Protect e o F5 NGINX Plus para reduzir o custo de violações

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Thelen Blum Miniatura
Thelen Blum
Publicado em 07 de julho de 2022
Matthieu Dierick Miniatura
Matthieu Dierick
Publicado em 07 de julho de 2022

Você pode se surpreender ao saber que o dinheiro gasto para melhorar sua postura de segurança com automação e inteligência artificial (IA) acaba economizando quantias muito maiores de dinheiro. Em seu Relatório sobre o Custo de uma Violação de Dados de 2021 , a equipe de Segurança da IBM revela que uma violação de segurança custa às organizações sem automação de segurança e IA uma média impressionante de 80% a mais do que às organizações com automação e IA totalmente implantadas — US$ 6,71 milhões contra US$ 2,90 milhões , uma diferença de US$ 3,81 milhões . Ao priorizar a automação de segurança e a IA, as organizações podem identificar e conter uma violação mais rapidamente, economizando tempo e dinheiro.

Gráfico de barras mostrando o custo médio de uma violação de dados por nível de implantação de automação de segurança
Violações de dados custam milhões a mais às organizações sem automação de segurança e IA
(Fonte: Relatório sobre o custo de uma violação de dados de 2021 )

No entanto, ao integrar a segurança ao seu pipeline de CI/CD, é importante não sobrecarregar suas ferramentas. Quanto menos vezes você inspecionar o tráfego, menos latência você introduzirá. O corolário empresarial é que a complexidade técnica é inimiga da agilidade.

Na F5 NGINX, oferecemos uma plataforma de segurança única em sua integração perfeita e capacidade de ajudar as equipes a “ mudar a segurança para a esquerda ” durante o ciclo de vida de desenvolvimento de software. Quando as organizações integram “segurança como código” em seu pipeline de CI/CD, elas permitem a automação de segurança e a IA, levando às enormes economias descritas pela IBM. Com a segurança incorporada em cada estágio do desenvolvimento de aplicativos e APIs, os arquivos de configuração e política de segurança são consumidos como código e sua equipe de SecOps pode criar e manter uma política de segurança declarativa para DevOps usar ao criar aplicativos. Essas mesmas políticas podem ser aplicadas repetidamente a novos aplicativos, automatizando assim sua segurança no pipeline de CI/CD.

Vamos descascar a cebola e analisar três fases do processamento de tráfego em que o F5 NGINX App Protect e o F5 NGINX Plus ajudam você a automatizar as proteções de segurança:

  • Fase 1 – F5 NGINX App Protect DoS detecta e defende contra ataques de negação de serviço (DoS)
  • Fase 2 – F5 NGINX App Protect WAF protege contra ataques OWASP Top 10 e bots maliciosos
  • Fase 3 – O F5 NGINX Plus autentica clientes de aplicativos e APIs e aplica requisitos de autorização usando recursos nativos e integrações com soluções de terceiros de logon único (SSO)
Diagrama de solução de segurança trifásica para gerenciamento eficiente de tráfego de aplicativos para bloquear tráfego ilegítimo e automatizar a segurança, usando NGINX App Protect DoS e WAF mais NGINX Plus
Uma solução de segurança trifásica para gerenciamento eficiente de tráfego de aplicativos para bloquear tráfego ilegítimo e automatizar a segurança, economizando tempo e dinheiro

Esta solução de segurança de três partes economiza seu dinheiro de duas maneiras, especialmente em um ambiente de nuvem pública:

  1. Somente tráfego legítimo chega aos seus aplicativos porque o NGINX App Protect DoS filtra o tráfego de ataques DoS e, em seguida, o NGINX App Protect WAF elimina vários vetores de ataque, como o OWASP Top 10 .
  2. O design altamente eficiente e orientado a eventos do NGINX Plus significa que ele pode processar um grande número de solicitações por segundo com baixo consumo de CPU. Processar apenas tráfego de aplicativos legítimos em uma plataforma altamente eficiente requer significativamente menos recursos de computação, economizando tempo e dinheiro e garantindo proteção contra vários vetores de ataque sem sobrecarregar suas ferramentas.

Se você estiver usando atualmente o F5 BIG-IP Advanced WAF para proteger aplicativos em execução no seu data center, é simples adicionar o NGINX Plus como um controlador Ingress para o Kubernetes com o NGINX App Protect Dos e o WAF como uma solução abrangente para dimensionar e proteger seus aplicativos modernos e orquestrar aplicativos do Kubernetes na nuvem. Usando a abordagem de segurança como código da F5, você pode definir controles de infraestrutura e política de segurança como código por meio de uma API declarativa ou definições declarativas formatadas em JSON em um arquivo, e também pode converter arquivos XML do BIG-IP em arquivos JSON. Suas políticas – os controles de segurança corporativa padrão de propriedade e mantidos pela SecOps – podem residir em um repositório de código do qual são obtidas e integradas ao seu pipeline de desenvolvimento, assim como qualquer outro pedaço de código. Essa abordagem ajuda DevOps e SecOps a preencher lacunas operacionais e levar aplicativos ao mercado mais rapidamente, com menor custo e melhor segurança.

O F5 incorpora a construção e a linha de base da política WAF no processo de desenvolvimento, uma parte importante da “mudança de segurança para a esquerda” no pipeline de desenvolvimento de aplicativos e da automação da implantação de aplicativos.

As ferramentas de visibilidade no BIG-IP e no NGINX se complementam e permitem que o SecOps crie processos de automação no início do seu ciclo de vida do DevOps. O BIG‑IP permite que equipes convertam arquivos XML em arquivos JSON usados pelo NGINX para manter suas políticas de segurança consistentes. O NGINX permite que as equipes ajustem os aplicativos já existentes, ao mesmo tempo em que traz automação moderna de segurança de aplicativos para ajudar a compensar futuras violações e o custo desses ataques em potencial.

Fase 1: O aplicativo NGINX Protect DoS se defende contra ataques DoS

A primeira parada em nossa jornada de gerenciamento de tráfego seguro é eliminar ataques de negação de serviço (DoS) . Acabar com esse abuso desde o início é uma primeira linha de defesa necessária.

Observamos anteriormente que os invasores estão cada vez mais migrando de ataques volumétricos tradicionais para o uso de solicitações HTTP e HTTPS ou chamadas de API para atacar na Camada 7. Porquê?Eles estão seguindo o caminho de menor resistência. Engenheiros de infraestrutura passaram anos construindo defesas eficazes contra ataques de Camada 3 e Camada 4, tornando-os mais fáceis de bloquear e menos propensos a serem bem-sucedidos. Ataques de camada 7 podem contornar essas defesas tradicionais.

Nem todos os ataques DoS são volumétricos. Ataques projetados para consumir recursos do servidor por meio de métodos “baixos e lentos”, como Slow POST ou Slowloris, podem ser facilmente ocultados no tráfego legítimo. E embora estruturas de chamada de procedimento remoto HTTP/2 de código aberto, como o gRPC, forneçam a velocidade e a flexibilidade necessárias para aplicativos modernos, sua natureza caracteristicamente aberta os torna potencialmente mais vulneráveis a ataques DoS do que protocolos proprietários.

Diferentemente das proteções DoS tradicionais, o NGINX App Protect DoS detecta os ataques atuais aproveitando a análise automatizada do comportamento do usuário e do site, verificações de integridade proativas e configuração sem toque. É uma solução de baixa latência para interromper ataques comuns , incluindo inundação HTTP GET , inundação HTTP POST , Slowloris, leitura lenta e POST lento.

Para combater esses ataques, as equipes de SecOps e DevOps precisam integrar a automação de “segurança como código” em seu fluxo de trabalho de CI/CD – parte da mentalidade de mudança para a esquerda. O NGINX App Protect DoS permite isso. Ele protege aplicativos e APIs modernos e distribuídos com proteção avançada contra ameaças DoS e ajuda a alinhar as prioridades às vezes conflitantes de SecOps e DevOps, facilitando esse modelo com um pacote de software leve, ciclo de feedback contínuo de mitigação de ameaças e integração com ferramentas DevOps conhecidas por meio de APIs RESTful.

O NGINX App Protect DoS integra a tecnologia de aprendizado de máquina (ML) que o relatório da IBM Security destaca como essencial para economias de custos significativas. Ele analisa o comportamento do cliente e a integridade do aplicativo para modelar padrões normais de tráfego, usa algoritmos exclusivos para criar um modelo estatístico dinâmico que fornece as proteções mais precisas e implanta assinaturas dinâmicas para mitigar ataques automaticamente. Ele também mede continuamente a eficácia da mitigação e se adapta a mudanças de comportamento ou condições de saúde. Esses recursos permitem que o NGINX App Protect DoS bloqueie ataques DoS em que cada solicitação de ataque parece completamente legal, e um único invasor pode até gerar menos tráfego do que o usuário legítimo médio.

Diagrama representando oito tipos de ataques bloqueados pelo NGINX App Protect WAF e DoS
Solução de Segurança Fase 1 e Fase 2: Segurança de aplicações com processamento de tráfego eficiente usando
Aplicativo NGINX protege DoS e WAF

Fase 2: O aplicativo NGINX Protect WAF protege contra os dez principais OWASP

Embora a proteção DoS claramente impeça que tráfego malicioso entre na sua infraestrutura, ataques ainda podem passar. É por isso que você precisa de um firewall de aplicativo web (WAF) para a próxima fase de defesa bem-sucedida, onde ele se concentra no tráfego de agentes mal-intencionados que são mascarados como legítimos.

Leve e com alto desempenho, o NGINX App Protect WAF fornece proteção de segurança abrangente que inspeciona respostas, reforça a conformidade com o protocolo HTTP, detecta técnicas de evasão, mascara números de cartão de crédito e outras informações pessoais confidenciais com o Data Guard e verifica metacaracteres e tipos de arquivo não permitidos, JSON e XML malformados e parâmetros confidenciais. Ele também protege contra o OWASP Top 10 atualizado:

Não é surpresa que os ataques cibernéticos contra as 10 principais vulnerabilidades do OWASP, como o A03:2021 Injection, continuem populares. Em julho de 2021, o site de comércio eletrônico de código aberto WooCommerce anunciou que muitos de seus plug-ins eram vulneráveis à injeção de SQL , e vários ataques estavam ocorrendo naquela época. Com empresas e clientes operando principalmente online, faz sentido que os invasores se concentrem em aplicativos baseados na web, que geralmente são complexos, compostos de microsserviços e abrangem ambientes distribuídos com muitas APIs se comunicando entre si, aumentando o número de endpoints vulneráveis à exploração.

Os ataques modernos também mudam e se adaptam rapidamente. É aqui que entra a IA e é por isso que a IBM destacou sua importância. Assim como no NGINX App Protect DoS, o rico sistema de ML no NGINX App Protect WAF facilita o compartilhamento de tendências e dados de ataques por equipes de Platform Ops, DevOps e SecOps. Um novo recurso — o recurso Adaptive Violation Rating — alavancará ainda mais o ML ao detectar quando o comportamento de um aplicativo muda. Com esse recurso de ML, o NGINX App Protect WAF avalia constantemente o comportamento preditivo de cada aplicativo. Com base nesse aprendizado, ele pode habilitar solicitações de clientes que, de outra forma, seriam bloqueadas, diminuindo a pontuação de classificação de violação de um aplicativo e reduzindo significativamente os falsos positivos para uma melhor experiência do usuário com menores custos de gerenciamento.

O NGINX App Protect WAF também fornece proteção contra bots. Hoje, quase 50% do tráfego da Internet vem de bots . Ao eliminar o tráfego malicioso conhecido antecipadamente, o NGINX App Protect WAF pode bloquear rapidamente o tráfego de bots usando seu banco de dados de assinaturas de bots.

A introdução do WAF como uma camada de segurança no início do seu pipeline de CI/CD ajuda a mitigar o risco de segurança. Como o NGINX App Protect WAF é compatível com CI/CD, você pode incorporar e automatizar a segurança como código no início do processo de desenvolvimento do seu aplicativo. Com a conscientização antecipada sobre segurança e a colaboração correta entre as equipes, você também elimina gargalos como riscos de entrega. A proteção DoS e WAF em vários estágios cria muitos pontos de inspeção, dando às equipes de segurança visibilidade sobre o uso do aplicativo e conhecimento sobre como eles estão sendo mantidos.

Fase 3: NGINX Plus autentica e autoriza clientes de aplicativos e APIs

Mesmo depois que o NGINX App Protect Dos e o NGINX App Protect WAF eliminarem o tráfego malicioso, você ainda precisa verificar se os clientes são legítimos e estão autorizados a acessar os recursos que estão solicitando. É aí que o NGINX Plus entra em cena, gerenciando a autenticação e a autorização e, em seguida, encaminhando as solicitações para os servidores apropriados. Ao implantar o NGINX Plus como um gateway de API , você pode fornecer um ponto de entrada consistente para diversas APIs e, novamente, simplificar sua pilha.

A autenticação e a autorização também podem ser automatizadas com logon único (SSO) para permitir que as equipes de DevOps mantenham a agilidade desejada. O NGINX Plus oferece suporte ao OpenID Connect (OIDC), uma camada de identidade sobre o protocolo OAuth 2.0 . Na documentação do NGINX, explicamos como usar o OIDC para habilitar o SSO para aplicativos com proxy do NGINX Plus .

Solução de Segurança Fase 3: Autenticação e autorização usando NGINX Plus e exemplos compatíveis com OAuth 2.0/OIDC IdP para SSO

Dada a sua natureza aberta característica, as APIs são alvos vulneráveis. Em seu relatório anual, a Gartner Research previu que as APIs se tornariam o vetor de ataque mais comum em 2022, causando inúmeras violações de dados para aplicativos da web corporativos. Essa previsão se confirma à medida que avançamos em 2022 e observamos que a superfície de ataque de API continua crescendo em todas as organizações.

Incidentes de autenticação da API: O Relatório de Proteção de Aplicativos de 2020 da F5 Labs destaca três motivos comuns para incidentes de API:

  1. Nenhuma autenticação nos pontos de extremidade da API
  2. Autenticação de API quebrada
  3. Autorização de API quebrada

Nenhuma autenticação nos pontos de extremidade da API

Ao implementar a autenticação do tráfego de API, os clientes que comprovam sua identidade com sucesso recebem um token de um provedor de identidade confiável. O cliente então apresenta o token de acesso com cada solicitação HTTP. Antes que a solicitação seja passada para o aplicativo, o NGINX Plus garante a autenticação e autorização do cliente validando o token e extraindo a identidade e outros dados (associação ao grupo, por exemplo) codificados no token. Supondo que o token seja validado e o cliente esteja autorizado a acessar o recurso, a solicitação é passada ao servidor de aplicativos. Existem vários métodos para realizar essa validação, mas o OpenID Connect (construído no protocolo OAuth 2.0) é uma maneira popular de habilitar a autenticação de terceiros de solicitações de API.

No entanto, muitas APIs no mercado não são protegidas na camada de autenticação. Em 2021, a plataforma de fitness interativa Peloton revelou ter uma API com vazamento . Um pesquisador de segurança descobriu que era possível fazer solicitações não autenticadas à API da Peloton, recuperando facilmente dados do usuário sem autenticação. Embora a Peloton tenha corrigido o código antes de qualquer violação grave, esse contratempo destaca como uma abordagem monolítica de segurança não considera a multiplicidade inerente de estruturas de API e a consequente necessidade de agilidade para defendê-las.

Autenticação de API quebrada

As APIs são projetadas para conectar computadores, então muitas equipes de DevOps presumem que humanos não se comunicam com o ponto de extremidade da API. Um exemplo no relatório do F5 Labs envolve um pesquisador que encadeou várias solicitações de API para “ganhar” centenas de milhares de dólares em créditos em um aplicativo móvel. O aplicativo gerou continuamente tokens projetados para evitar abusos, mas não definiu datas de expiração para eles, permitindo que fossem usados repetidamente.

Se você não validar corretamente os tokens de autenticação da API, os invasores poderão explorar vulnerabilidades da API. Se esse tipo de vulnerabilidade for descoberto por um criminoso, e não por um pesquisador, ele pode comprometer todo um negócio.

Autorização de API quebrada

A autenticação de API malsucedida naturalmente leva à quebra da autorização de API. Os relatórios do F5 Labs também descrevem um incidente em que um bug no sistema operacional permitiu solicitações HTTP maliciosas à API, dando aos criminosos acesso fácil aos tokens de autorização. Depois que os invasores adquiriram esse token de autorização, eles obtiveram permissões de administrador.

O NGINX oferece diversas abordagens para proteger APIs e autenticar clientes de API. Para obter mais informações, consulte a documentação sobre listas de controle de acesso (ACLs) baseadas em endereço IP , autenticação de certificado digital e autenticação HTTP Basic . Além disso, o NGINX Plus oferece suporte nativo à validação de JSON Web Tokens (JWTs) para autenticação de API. Saiba mais em Autenticação de clientes de API com JWT e NGINX Plus em nosso blog.

Comece hoje mesmo

Automatizar a segurança torna-a responsabilidade de todos. Ao priorizar a automação de segurança, sua organização pode criar aplicativos mais confiáveis, mitigar riscos, reduzir OpEx e acelerar a velocidade de lançamento. Isso significa que seus microsserviços, aplicativos e APIs obtêm segurança ágil, escalável e rápida o suficiente para acompanhar a concorrência atual.

Essa estrutura de segurança de três fases também oferece o melhor fluxo porque você não quer atolar seu WAF inspecionando tráfego de um ataque DoS ou desperdiçar recursos valiosos tentando autenticar e autorizar agentes mal-intencionados. Ao eliminar ataques facilmente identificados precocemente, você pode economizar tempo, dinheiro e acelerar o desempenho do seu aplicativo.

Pronto para experimentar o NGINX Plus e o NGINX App Protect? Comece hoje mesmo um teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."