Talvez você se surpreenda ao saber que o dinheiro investido na melhoria da sua postura de segurança com automação e inteligência artificial (IA) acaba gerando uma economia muito maior. Em seu Relatório sobre o Custo de uma Violação de Dados de 2021, a equipe da IBM Security revela que uma violação de segurança custa, em média, impressionantes 80% a mais para organizações que não utilizam automação de segurança e IA do que para aquelas que implementaram plenamente essas tecnologias — 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.
(Fonte: Relatório de 2021 sobre o custo de uma violação de dados)
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, menor será a latência introduzida. A consequência para os negócios é que a complexidade técnica é inimiga da agilidade.
Na F5 NGINX, oferecemos uma plataforma de segurança única por sua integração perfeita e sua capacidade de ajudar as equipes a “deslocar a segurança para a esquerda” durante o ciclo de vida de desenvolvimento de software. Quando as organizações integram a “segurança como código” ao pipeline de CI/CD, elas viabilizam a automação da segurança e o uso de IA, gerando a enorme economia descrita pela IBM. Com a segurança incorporada a cada etapa do desenvolvimento de aplicações e APIs, os arquivos de configuração e de políticas de segurança são processados como código, e sua equipe de SecOps pode criar e manter uma política de segurança declarativa para que a equipe de DevOps a utilize ao desenvolver aplicações. Essas mesmas políticas podem ser aplicadas repetidamente a novas aplicações, automatizando assim a segurança no pipeline de CI/CD.
Vamos analisar mais a fundo 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 – O F5 NGINX App Protect DoS detecta e protege contra ataques de negação de serviço (DoS)
- Fase 2 – O WAF do F5 NGINX App Protect protege contra os 10 principais riscos da OWASP 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 logon único (SSO) de terceiros
Esta solução de segurança em três partes ajuda você a economizar de duas maneiras, especialmente em um ambiente de nuvem pública:
- Somente o tráfego legítimo chega aos seus aplicativos, pois o NGINX App Protect DoS filtra o tráfego de ataques de DoS e, em seguida, o NGINX App Protect WAF elimina diversos vetores de ataque, como os do OWASP Top 10.
- O design altamente eficiente e orientado a eventos do NGINX Plus permite processar um enorme número de solicitações por segundo com baixo consumo de CPU. Processar apenas o tráfego legítimo de aplicações em uma plataforma altamente eficiente exige significativamente menos recursos computacionais, economizando tempo e dinheiro e garantindo proteção contra diversos vetores de ataque sem sobrecarregar suas ferramentas.
Se você usa atualmente o F5 BIG-IP Advanced WAF para proteger aplicações executadas em seu data center, é fácil adicionar o NGINX Plus como controlador de Ingress para Kubernetes, com NGINX App Protect DoS e WAF, formando uma solução abrangente para dimensionar e proteger suas aplicações modernas e orquestrar aplicações Kubernetes na nuvem. Com a abordagem de segurança como código da F5, você pode definir controles de infraestrutura e de políticas de segurança como código por meio de uma API declarativa ou de definições declarativas em formato JSON em um arquivo, além de converter arquivos XML do BIG-IP em arquivos JSON. Suas políticas — os controles de segurança corporativos padrão gerenciados e mantidos pela equipe de SecOps — podem ficar em um repositório de código, de onde são obtidas e integradas ao pipeline de desenvolvimento como qualquer outro trecho de código. Essa abordagem ajuda as equipes de DevOps e SecOps a eliminar lacunas operacionais e lançar aplicações no mercado com mais rapidez, menor custo e mais segurança.
A F5 incorpora a criação e o estabelecimento de uma linha de base para políticas de WAF ao processo de desenvolvimento, uma parte importante da abordagem de “antecipar a segurança” no pipeline de desenvolvimento de aplicações e de automatizar a implantação de aplicações.
As ferramentas de visibilidade do BIG‑IP e do NGINX se complementam e permitem que as equipes de SecOps incorporem processos de automação desde o início do ciclo de vida de DevOps. O BIG‑IP permite que as equipes convertam arquivos XML em arquivos JSON usados pelo NGINX para manter políticas de segurança consistentes. O NGINX permite que as equipes façam ajustes finos nos aplicativos já implantados, além de oferecer automação moderna de segurança de aplicativos para ajudar a reduzir futuras violações e os custos desses possíveis ataques.
Fase 1: NGINX App Protect DoS protege contra ataques de DoS
A primeira etapa da nossa jornada de gerenciamento seguro de tráfego é eliminar os ataques de negação de serviço (DoS). Bloquear esse abuso logo de início é uma primeira linha de defesa essencial.
Já observamos anteriormente que os invasores estão migrando cada vez mais dos ataques volumétricos tradicionais para o uso de solicitações HTTP e HTTPS ou chamadas de API para atacar na Camada 7. Por quê? Porque estão seguindo o caminho de menor resistência. Os engenheiros de infraestrutura passaram anos desenvolvendo defesas eficazes contra ataques nas Camadas 3 e 4, tornando-os mais fáceis de bloquear e menos propensos a ter sucesso. Os ataques na Camada 7 podem contornar essas defesas tradicionais.
Nem todos os ataques de DoS são volumétricos. Ataques projetados para consumir recursos do servidor por meio de métodos lentos e graduais, como Slow POST ou Slowloris, podem ser facilmente ocultados no tráfego legítimo. Embora frameworks de código aberto para chamadas de procedimento remoto via HTTP/2, como o gRPC, ofereçam a velocidade e a flexibilidade necessárias para aplicações modernas, sua natureza tipicamente aberta pode torná-los mais vulneráveis a ataques de DoS do que os protocolos proprietários.
Diferentemente das proteções tradicionais contra DoS, o NGINX App Protect DoS detecta os ataques atuais por meio da análise automatizada do comportamento dos usuários e do site, de verificações proativas de integridade e de uma configuração sem intervenção manual. Trata-se de uma solução de baixa latência para impedir ataques comuns como inundação de solicitações HTTP GET, inundação de solicitações 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” ao fluxo de trabalho de CI/CD — parte da abordagem shift-left. O NGINX App Protect DoS viabiliza isso. Ele protege aplicações e APIs modernas e distribuídas contra ameaças de DoS com recursos avançados e ajuda a alinhar as prioridades, por vezes conflitantes, de SecOps e DevOps, facilitando esse modelo com um pacote de software leve, um ciclo contínuo de feedback para mitigação de ameaças e integração com ferramentas de DevOps conhecidas por meio de APIs RESTful.
NGINX App Protect DoS integra a tecnologia de aprendizado de máquina (ML) que o relatório da IBM Security destaca como essencial para uma redução significativa de custos. Ele analisa o comportamento dos clientes e a integridade das aplicações para modelar padrões normais de tráfego, usa algoritmos exclusivos para criar um modelo estatístico dinâmico que oferece 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 no comportamento ou nas condições de integridade. Esses recursos permitem que o NGINX App Protect DoS bloqueie ataques de DoS nos quais cada solicitação mal-intencionada parece totalmente legítima, e um único invasor pode até mesmo gerar menos tráfego do que um usuário legítimo médio.
NGINX App Protect DoS e WAF
Fase 2: o NGINX App Protect WAF oferece proteção contra os dez principais riscos da OWASP
Embora a proteção contra DoS impeça claramente que tráfego malicioso entre na sua infraestrutura, alguns ataques ainda podem passar. Por isso, na próxima fase de uma defesa eficaz, você precisa de um firewall de aplicações web (WAF), que se concentra no tráfego de agentes mal-intencionados disfarçado de legítimo.
Leve e de alto desempenho, NGINX App Protect WAF oferece proteção de segurança abrangente que inspeciona respostas, garante 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 oferece proteção contra o OWASP Top 10 atualizado:
Falhas no controle de acesso
Falhas criptográficas
Injeção
Design inseguro
Configuração incorreta de segurança
Componentes vulneráveis e desatualizados
Falhas de identificação e autenticação
Falhas de integridade de software e dados
Falhas no registro e monitoramento de segurança
Falsificação de solicitação do lado do servidor
Não é de surpreender que os ataques cibernéticos contra vulnerabilidades do OWASP Top 10, como A03:2021 Injeção continuem comuns. Em julho de 2021, o site de comércio eletrônico de código aberto WooCommerce anunciou que muitos de seus plug-ins estavam vulneráveis à injeção de SQL, e vários ataques estavam ocorrendo naquele momento. Como empresas e clientes operam principalmente on-line, faz sentido que os invasores se concentrem em aplicativos web, que muitas vezes são complexos, compostos por microsserviços e distribuídos em ambientes com muitas APIs que se comunicam entre si, aumentando o número de endpoints vulneráveis à exploração.
Os ataques modernos também mudam e se adaptam rapidamente. É aí que entra a IA e por que a IBM destacou sua importância. Assim como no NGINX App Protect DoS, o avançado sistema de ML do NGINX App Protect WAF facilita o compartilhamento de tendências e dados de ataques entre as equipes de Platform Ops, DevOps e SecOps. Um novo recurso – o Adaptive Violation Rating – ampliará ainda mais o uso de ML ao detectar mudanças no comportamento de uma aplicação. Com esse recurso de ML, o NGINX App Protect WAF avalia constantemente o comportamento preditivo de cada aplicação. Com base nesse aprendizado, ele pode permitir solicitações de clientes que, de outra forma, seriam bloqueadas, reduzindo a pontuação de classificação de violações de uma aplicação e diminuindo significativamente os falsos positivos, o que proporciona uma melhor experiência do usuário e reduz os custos de gerenciamento.
O NGINX App Protect WAF também oferece proteção contra bots. Atualmente, quase 50% do tráfego da Internet vem de bots. Ao eliminar previamente o tráfego malicioso conhecido, o NGINX App Protect WAF pode bloquear rapidamente o tráfego de bots usando seu banco de dados de assinaturas de bots.
Introduzir o WAF como uma camada de segurança logo no início do pipeline de CI/CD ajuda a reduzir os riscos 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 desde as etapas iniciais do processo de desenvolvimento de aplicações. Com a conscientização antecipada sobre segurança e a colaboração adequada entre as equipes, você também elimina gargalos, como o risco de entrega. A proteção em vários estágios contra DoS e por WAF cria diversos pontos de inspeção, proporcionando às equipes de Segurança visibilidade sobre o uso das aplicações e às equipes de Aplicações conhecimento sobre como elas estão sendo mantidas.
Fase 3: o NGINX Plus autentica e autoriza clientes de aplicativos e APIs
Mesmo depois que o NGINX App Protect Dos e o NGINX App Protect WAF eliminam o tráfego malicioso, ainda é necessário verificar se os clientes são legítimos e estão autorizados a acessar os recursos solicitados. É aí que o NGINX Plus entra em cena, realizando a autenticação e a autorização e, em seguida, encaminhando as solicitações aos servidores apropriados. Ao implantar o NGINX Plus como um gateway de API, você pode oferecer um ponto de entrada único e consistente para várias APIs e, mais uma vez, simplificar sua pilha de tecnologia.
A autenticação e a autorização também podem ser automatizadas com o logon único (SSO), permitindo que as equipes de DevOps mantenham a agilidade desejada. O NGINX Plus oferece suporte ao OpenID Connect (OIDC), uma camada de identidade baseada no protocolo OAuth 2.0. Na documentação do NGINX, explicamos como usar o OIDC para habilitar o SSO em aplicações que utilizam o NGINX Plus como proxy.
Devido à sua natureza tipicamente aberta, 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 em aplicações Web empresariais. Essa previsão vem se confirmando à medida que avançamos em 2022 e observamos a superfície de ataque das APIs continuar crescendo nas organizações.
O relatório Incidentes de autenticação de APIs: Relatório de proteção de aplicações de 2020 da F5 Labs destaca três motivos comuns para incidentes de API:
- Ausência de autenticação nos endpoints da API
- Autenticação de API comprometida
- Autorização de API comprometida
Ausência de autenticação nos endpoints 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. Em seguida, o cliente apresenta o token de acesso em cada solicitação HTTP. Antes de encaminhar a solicitação ao aplicativo, o NGINX Plus garante a autenticação e a autorização do cliente, validando o token e extraindo a identidade e outros dados (como a associação a grupos) codificados nele. Se o token for validado e o cliente estiver autorizado a acessar o recurso, a solicitação será encaminhada ao servidor de aplicativos. Há vários métodos para realizar essa validação, mas o OpenID Connect (baseado no protocolo OAuth 2.0) é uma forma popular de habilitar a autenticação de terceiros para solicitações de API.
No entanto, muitas APIs disponíveis no mercado não contam com proteção na camada de autenticação. Em 2021, foi revelado que a plataforma de fitness interativo Peloton tinha uma API vulnerável. Um pesquisador de segurança descobriu que era possível fazer solicitações não autenticadas à API da Peloton, obtendo facilmente dados de usuários sem autenticação. Embora a Peloton tenha corrigido o código antes que ocorresse qualquer violação grave, esse incidente evidencia que uma abordagem monolítica de segurança não leva em conta a multiplicidade inerente das estruturas de API e a consequente necessidade de agilidade para protegê-las.
Falha na autenticação de APIs
As APIs são projetadas para conectar computadores entre si, por isso muitas equipes de DevOps presumem que as pessoas não interagem com o endpoint da API. Um dos exemplos apresentados no relatório da 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 gerava continuamente tokens destinados a evitar abusos, mas não definia datas de expiração para eles, permitindo que fossem usados repetidas vezes.
Se você não validar corretamente os tokens de autenticação da API, invasores poderão explorar vulnerabilidades nela. Se esse tipo de vulnerabilidade for descoberto por um agente mal-intencionado, em vez de um pesquisador, toda a empresa poderá ser comprometida.
Autorização de API comprometida
Uma autenticação de API malsucedida naturalmente leva a falhas na autorização da API. O relatório da F5 Labs também descreve um incidente em que um bug no sistema operacional permitiu o envio de solicitações HTTP maliciosas à API, facilitando o acesso de agentes mal-intencionados a tokens de autorização. Depois que os invasores obtiveram esse token de autorização, passaram a ter permissões de administrador.
O NGINX oferece várias abordagens para proteger APIs e autenticar clientes de API. Para obter mais informações, consulte a documentação sobre listas de controle de acesso baseadas em endereço IP (ACLs), autenticação por 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 APIs. Saiba mais no artigo Autenticação de clientes de API com JWT e NGINX Plus em nosso blog.
Comece hoje mesmo
Automatizar a segurança faz com que ela seja responsabilidade de todos. Ao priorizar a automação da segurança, sua organização pode desenvolver aplicativos mais confiáveis, mitigar riscos, reduzir as despesas operacionais (OpEx) e acelerar o ritmo de lançamentos. Isso significa que seus microsserviços, aplicativos e APIs contam com uma segurança ágil, escalável e rápida o suficiente para acompanhar a concorrência atual.
Essa estrutura de segurança em três fases também oferece o melhor fluxo, pois você não quer sobrecarregar seu WAF com a inspeção do tráfego de um ataque de DoS nem desperdiçar recursos valiosos tentando autenticar e autorizar agentes mal-intencionados. Ao eliminar antecipadamente os ataques facilmente identificáveis, você pode economizar tempo e dinheiro, além de melhorar o desempenho do seu aplicativo.
Pronto para experimentar o NGINX Plus e o NGINX App Protect? Comece hoje mesmo uma avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso.
Sobre os autores
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.