Mudando a segurança para a esquerda com o F5 NGINX App Protect no Amazon EKS

De acordo com o relatório The State of Application Strategy in 2022 da F5, a transformação digital nas empresas continua a acelerar globalmente. A maioria das empresas implanta entre 200 e 1.000 aplicativos em diversas zonas de nuvem, com os aplicativos atuais migrando de arquiteturas monolíticas para arquiteturas distribuídas modernas.

O Kubernetes chegou ao cenário tecnológico para uso geral em 2016, há apenas seis anos. No entanto, hoje, mais de 75% das organizações em todo o mundo executam aplicativos em contêineres em produção, um aumento de 30% em relação a 2019. Um problema crítico em ambientes Kubernetes, incluindo o Amazon Elastic Kubernetes Service (EKS), é a segurança. Muitas vezes, a segurança é "acrescentada" no final do processo de desenvolvimento do aplicativo e, às vezes, nem mesmo depois que o aplicativo em contêiner já está instalado e funcionando.

A atual onda de transformação digital, acelerada pela pandemia da COVID-19, forçou muitas empresas a adotar uma abordagem mais holística à segurança e a considerar uma estratégia de “mudança para a esquerda”. Mudar a segurança para a esquerda significa introduzir medidas de segurança no início do ciclo de vida de desenvolvimento de software (SDLC) e usar ferramentas e controles de segurança em cada estágio do pipeline de CI/CD para aplicativos, contêineres, microsserviços e APIs. Representa uma mudança para um novo paradigma chamado DevSecOps, onde a segurança é adicionada aos processos DevOps e se integra aos ciclos de lançamento rápidos típicos do desenvolvimento e entrega de aplicativos de software modernos.

DevSecOps representa uma mudança cultural significativa. As equipes de segurança e DevOps trabalham com um propósito comum: levar produtos de alta qualidade ao mercado de forma rápida e segura. Os desenvolvedores não se sentem mais limitados a cada passo por procedimentos de segurança que interrompem seu fluxo de trabalho. As equipes de segurança não precisam mais corrigir os mesmos problemas repetidamente. Isso possibilita que a organização mantenha uma postura de segurança forte, detectando e prevenindo vulnerabilidades, configurações incorretas e violações de conformidade ou política à medida que ocorrem.

Mudar a segurança para a esquerda e automatizar a segurança como código protege seu ambiente Amazon EKS desde o início. Aprender como se tornar pronto para produção em escala é uma parte importante da construção de uma base do Kubernetes. A governança adequada do Amazon EKS ajuda a impulsionar a eficiência, a transparência e a responsabilidade em toda a empresa, ao mesmo tempo que controla os custos. Governança forte e proteções de segurança criam uma estrutura para melhor visibilidade e controle de seus clusters. Sem eles, sua organização fica exposta a um risco maior de violações de segurança e aos custos associados a danos à receita e à reputação.

Para saber mais sobre o que considerar ao migrar para uma estratégia de segurança em primeiro lugar, dê uma olhada neste relatório recente da O'Reilly, Shifting Left for Application Security .

Automatizando a segurança para Amazon EKS com GitOps

A automação é um facilitador importante para o DevSecOps, ajudando a manter a consistência mesmo em um ritmo rápido de desenvolvimento e implantação. Assim como a infraestrutura como código, a automação com uma abordagem de segurança como código envolve o uso de políticas declarativas para manter o estado de segurança desejado.

GitOps é uma estrutura operacional que facilita a automação para dar suporte e simplificar a entrega de aplicativos e o gerenciamento de clusters. A ideia principal do GitOps é ter um repositório Git que armazena políticas declarativas de objetos do Kubernetes e aplicativos em execução no Kubernetes, definidos como código. Um processo automatizado completa o paradigma do GitOps para fazer com que o ambiente de produção corresponda a todas as descrições de estado armazenadas.

O repositório atua como uma fonte de verdade na forma de políticas de segurança, que são então referenciadas por descrições declarativas de configuração como código como parte do processo de pipeline de CI/CD. Como exemplo, o NGINX mantém um repositório GitHub com uma função Ansible para o F5 NGINX App Protect , que esperamos que seja útil para ajudar equipes que desejam mudar a segurança para a esquerda.

Com esse repositório, tudo o que é preciso para implantar um novo aplicativo ou atualizar um existente é atualizar o repositório. O processo automatizado gerencia todo o resto, incluindo a aplicação de configurações e a garantia de que as atualizações sejam bem-sucedidas. Isso garante que tudo aconteça no sistema de controle de versão para desenvolvedores e seja sincronizado para reforçar a segurança em aplicativos essenciais aos negócios.

Quando executado no Amazon EKS, o GitOps torna a segurança perfeita e robusta, ao mesmo tempo em que elimina virtualmente erros humanos e monitora todas as alterações de versão aplicadas ao longo do tempo.

NGINX App Protect e NGINX Ingress Controller protegem seus aplicativos e APIs no Amazon EKS

Um design robusto para a política de segurança do Kubernetes deve acomodar as necessidades de SecOps e DevOps e incluir disposições para adaptação conforme o ambiente é dimensionado. Os clusters do Kubernetes podem ser compartilhados de várias maneiras. Por exemplo, um cluster pode ter vários aplicativos em execução e compartilhando seus recursos, enquanto em outro caso há várias instâncias de um aplicativo, cada uma para um usuário final ou grupo diferente. Isso implica que os limites de segurança nem sempre são claramente definidos e há necessidade de políticas de segurança flexíveis e refinadas.

O design geral de segurança deve ser flexível o suficiente para acomodar exceções, deve integrar-se facilmente ao pipeline de CI/CD e deve oferecer suporte a multilocação. No contexto do Kubernetes, um locatário é um agrupamento lógico de objetos e aplicativos do Kubernetes que estão associados a uma unidade de negócios, equipe, caso de uso ou ambiente específico. Multilocação, então, significa vários locatários compartilhando com segurança o mesmo cluster, com limites entre locatários impostos com base em requisitos técnicos de segurança que estão intimamente conectados às necessidades comerciais.

Uma maneira fácil de implementar segurança de baixa latência e alto desempenho no Amazon EKS é incorporar os módulos NGINX App Protect WAF e DoS com o NGINX Ingress Controller . Nenhum dos nossos concorrentes oferece esse tipo de solução em linha. Usar um produto com tecnologia sincronizada oferece diversas vantagens, incluindo redução de tempo de computação, custos e proliferação de ferramentas. Aqui estão alguns benefícios adicionais.

• Protegendo o perímetro do aplicativo – Em uma implantação bem arquitetada do Kubernetes, o NGINX Ingress Controller é o único ponto de entrada para o tráfego do plano de dados fluindo para serviços em execução no Kubernetes, tornando-o um local ideal para proteção WAF e DoS.
• Consolidando o plano de dados – Incorporar o WAF no NGINX Ingress Controller elimina a necessidade de um dispositivo WAF separado. Isso reduz a complexidade, o custo e o número de pontos de falha.
• Consolidando o plano de controle – a configuração WAF e DoS pode ser gerenciada com a API do Kubernetes, tornando significativamente mais fácil automatizar os processos de CI/CD. A configuração do NGINX Ingress Controller está em conformidade com as práticas de controle de acesso baseado em função (RBAC) do Kubernetes, para que você possa delegar com segurança as configurações de WAF e DoS a uma equipe dedicada de DevSecOps.

Os objetos de configuração para NGINX App Protect WAF e DoS são consistentes no NGINX Ingress Controller e no NGINX Plus . Uma configuração mestre pode ser facilmente traduzida e implantada em qualquer dispositivo, tornando ainda mais fácil gerenciar a configuração WAF como código e implantá-la em qualquer ambiente de aplicativo

Para criar o NGINX App Protect WAF e DoS no NGINX Ingress Controller, você deve ter assinaturas do NGINX Plus e do NGINX App Protect WAF ou DoS. Bastam algumas etapas simples para criar a imagem integrada do NGINX Ingress Controller (contêiner Docker). Depois de implantar a imagem ( manualmente ou com gráficos do Helm , por exemplo), você pode gerenciar políticas de segurança e configuração usando a conhecida API do Kubernetes.

O NGINX Ingress Controller baseado no NGINX Plus fornece controle granular e gerenciamento de autenticação, autorização baseada em RBAC e interações externas com pods. Quando o cliente estiver usando HTTPS, o NGINX Ingress Controller pode encerrar o TLS e descriptografar o tráfego para aplicar o roteamento da Camada 7 e reforçar a segurança.

O NGINX App Protect WAF e o NGINX App Protect DoS podem então ser implantados para aplicar políticas de segurança para proteger contra ataques pontuais na Camada 7 como uma solução de segurança de software leve. O NGINX App Protect WAF protege aplicativos Kubernetes contra os 10 principais ataques do OWASP e fornece assinaturas avançadas e proteção contra ameaças, defesa contra bots e proteção Dataguard contra exploração de informações de identificação pessoal (PII). O NGINX App Protect DoS fornece uma linha adicional de defesa nas camadas 4 e 7 para mitigar ataques DoS sofisticados na camada de aplicativo com análise do comportamento do usuário e verificações de integridade do aplicativo para proteger contra ataques que incluem Slow POST , Slowloris, ataques de inundação e Challenger Collapsar.

Essas medidas de segurança protegem tanto as APIs REST quanto os aplicativos acessados usando navegadores da web. A segurança da API também é aplicada no nível de entrada, seguindo o fluxo de tráfego norte-sul.

O NGINX Ingress Controller com NGINX App Protect WAF e DoS pode proteger o tráfego do Amazon EKS por solicitação em vez de por serviço: esta é uma visão mais útil do tráfego da Camada 7 e uma maneira muito melhor de impor SLAs e segurança WAF norte-sul.

O mais recente relatório de testes de firewall de aplicativo Web de alto desempenho da GigaOm mostra como o NGINX App Protect WAF oferece consistentemente segurança forte para aplicativos e APIs, mantendo alto desempenho e baixa latência, superando os outros três WAFs testados — AWS WAF, Azure WAF e Cloudflare WAF — em todas as taxas de ataque testadas.

Como exemplo, a Figura 4 mostra os resultados de um teste onde o WAF teve que lidar com 500 requisições por segundo (RPS), com 95% (475 RPS) das requisições válidas e 5% das requisições (25 RPS) “ruins” (simulando injeção de script). No 99º percentil, a latência do NGINX App Protect WAF foi 10x menor que a do AWS WAF, 60x menor que a do Cloudflare WAF e 120x menor que a do Azure WAF.

A Figura 5 mostra o maior rendimento que cada WAF atingiu com 100% de sucesso (sem 5xx ou429 erros) com latência inferior a 30 milissegundos para cada solicitação. O NGINX App Protect WAF processou 19.000 RPS, enquanto o Cloudflare WAF processou 14.000 RPS, o AWS WAF processou 6.000 RPS e o Azure WAF processou apenas 2.000 RPS.

Como implantar o NGINX App Protect e o NGINX Ingress Controller no Amazon EKS

O NGINX App Protect WAF e DoS aproveita uma abordagem de segurança centrada em aplicativos com configurações e políticas de segurança totalmente declarativas, facilitando a integração da segurança ao seu pipeline de CI/CD para o ciclo de vida do aplicativo no Amazon EKS.

O NGINX Ingress Controller fornece diversas definições de recursos personalizadas (CRDs) para gerenciar todos os aspectos da segurança de aplicativos da web e dar suporte a um modelo de responsabilidade compartilhada e multilocatário. Os manifestos do CRD podem ser aplicados seguindo o agrupamento de namespaces usado pela organização, para dar suporte à propriedade de mais de um grupo de operações.

Ao publicar um aplicativo no Amazon EKS, você pode aumentar a segurança aproveitando o pipeline de automação já em uso e adicionando a política de segurança do WAF por cima.

Além disso, com o NGINX App Protect no NGINX Ingress Controller, você pode configurar limites de uso de recursos para utilização de CPU e memória, para evitar que o NGINX App Protect interfira com outros processos. Isso é particularmente importante em ambientes multilocatários, como o Kubernetes, que dependem do compartilhamento de recursos e podem sofrer com o problema do "vizinho barulhento".

Configurando o registro com CRDs NGINX

Os logs do NGINX App Protect e do NGINX Ingress Controller são separados por design, para refletir como as equipes de segurança geralmente operam independentemente do DevOps e dos proprietários de aplicativos. Você pode enviar logs do NGINX App Protect para qualquer destino de syslog que possa ser acessado pelos pods do Kubernetes, definindo o parâmetro para a anotação app-protect-security-log-destination para o endereço IP do cluster do pod de syslog. Além disso, você pode usar o recurso APLogConf para especificar quais logs do NGINX App Protect são importantes para você e, por implicação, quais logs são enviados ao pod syslog. Os logs do NGINX Ingress Controller são encaminhados para a saída padrão local, assim como para todos os contêineres do Kubernetes.

Este recurso APLogConf de exemplo especifica que todas as solicitações são registradas (não apenas as maliciosas) e define os tamanhos máximos de mensagens e solicitações que podem ser registradas.

apiVersion: appprotect.f5.com/v1beta1 tipo: APLogConf 
metadados: 
nome: logconf 
namespace: dvwa 
especificação: 
conteúdo: 
formato: padrão 
max_message_size: 64k
max_request_size: qualquer
filtro:
request_type: todos

Definindo uma política WAF com CRDs NGINX

O objeto APPolicy Policy é um CRD que define uma política de segurança WAF com conjuntos de assinaturas e regras de segurança baseadas em uma abordagem declarativa. Essa abordagem se aplica tanto ao NGINX App Protect WAF quanto ao DoS, enquanto o exemplo a seguir se concentra no WAF. As definições de políticas geralmente são armazenadas na fonte de verdade da organização como parte do catálogo SecOps.

apiVersion: appprotect.f5.com/v1beta1 tipo: APPolicy
metadados:
nome: sample-policy
especificação:
política:
nome: sample-policy
modelo:
nome: POLICY_TEMPLATE_NGINX_BASE 
applicationLanguage: utf-8 
enforcementMode: bloqueio 
signature-sets: 
- nome: Assinaturas de execução de comando
alarme: verdadeiro
bloco: verdadeiro
[...]

Depois que o manifesto da política de segurança for aplicado no cluster do Amazon EKS, crie um objeto APLogConf chamado log-violations para definir o tipo e o formato das entradas gravadas no log quando uma solicitação viola uma política do WAF:

apiVersion: appprotect.f5.com/v1beta1 tipo: APLogConf 
metadados: 
nome: log-violations
especificação: 
conteúdo: 
formato: padrão 
max_message_size: 64k
max_request_size: qualquer
filter:
request_type: ilegal

O objeto de política waf-policy faz referência à sample-policy para que o NGINX App Protect WAF seja aplicado ao tráfego de entrada quando o aplicativo for exposto pelo NGINX Ingress Controller. Ele faz referência a violações de log para definir o formato das entradas de log enviadas ao servidor syslog especificado no campo logDest .

apiVersion: k8s.nginx.org/v1 tipo: Política
metadados:
nome: waf-policy
especificação:
waf:
habilitar: verdadeiro
apPolicy: "padrão/política-de-amostra"
securityLog:
habilitar: verdadeiro
apLogConf: "padrão/violações-de-log"
logDest: "syslog:server=10.105.238.128:5144"

A implantação é concluída quando o DevOps publica um objeto VirtualServer que configura o NGINX Ingress Controller para expor o aplicativo no Amazon EKS:

apiVersão: k8s.nginx.org/v1kind: VirtualServer
metadados:
nome: eshop-vs
especificação:
host: eshop.lab.local
políticas:
-nome: default/waf-policy
upstreams:
-nome: eshop-upstream
serviço: eshop-service
porta: 80
rotas:
- caminho: /
ação:
senha: eshop-upstream

O objeto VirtualServer facilita a publicação e a proteção de aplicativos em contêineres em execução no Amazon EKS, mantendo o modelo de responsabilidade compartilhada, em que o SecOps fornece um catálogo abrangente de políticas de segurança e o DevOps depende dele para mudar a segurança desde o primeiro dia. Isso permite que as organizações façam a transição para uma estratégia DevSecOps.

Conclusão

Para empresas com aplicativos legados e soluções de segurança desenvolvidas ao longo dos anos, transferir a segurança para o Amazon EKS provavelmente será um processo gradual. Mas reformular a segurança como código gerenciado e mantido pela equipe de segurança e consumido pelo DevOps ajuda a entregar serviços mais rapidamente e torná-los prontos para produção.

Para proteger o tráfego norte-sul no Amazon EKS, você pode aproveitar o NGINX Ingress Controller incorporado ao NGINX App Protect WAF para proteção contra ataques pontuais na Camada 7 e o NGINX App Protect DoS para mitigação de DoS nas Camadas 4 e 7 .

Para experimentar o NGINX Ingress Controller com o NGINX App Protect WAF, inicie uma avaliação gratuita de 30 dias no AWS Marketplace ou entre em contato conosco para discutir seus casos de uso .

Para descobrir como você pode evitar violações de segurança e proteger seus aplicativos Kubernetes em escala usando o NGINX Ingress Controller e o NGINX App Protect WAF e DoS no Amazon EKS, baixe nosso e-book, Adicione segurança ao seu Amazon EKS com o F5 NGINX .

Para saber mais sobre como o NGINX App Protect WAF supera os WAFs nativos para AWS, Azure e Cloudflare, baixe o relatório de teste de firewall de aplicativo Web de alto desempenho da GigaOm e registre-se no webinar em 6 de dezembro, onde o analista da GigaOm, Jake Dolezal, analisa os resultados.