Antecipando a segurança com o F5 NGINX App Protect no Amazon EKS

Fabrizio FiorucciArquiteto de Soluções NGINX | F5 (EMEA)

Thelen BlumGerente Sênior de Marketing de Produto, NGINX App Protect | F5

De acordo com o relatório The State of Application Strategy in 2022 da F5, a transformação digital nas empresas continua se acelerando em todo o mundo. A maioria das empresas implanta entre 200 e 1.000 aplicativos distribuídos por várias zonas de nuvem, enquanto os aplicativos atuais migram de arquiteturas monolíticas para arquiteturas distribuídas modernas.

O Kubernetes surgiu no cenário tecnológico para uso generalizado em 2016, há apenas seis anos. No entanto, hoje mais de 75% das organizações em todo o mundo executam aplicações em contêineres em produção, um aumento de 30% em relação a 2019. Uma questão crítica nos ambientes Kubernetes, incluindo o Amazon Elastic Kubernetes Service (EKS), é a segurança. Com muita frequência, a segurança é “acrescentada” apenas no final do processo de desenvolvimento da aplicação e, às vezes, somente depois que uma aplicação em contêiner já está em execução.

A atual onda de transformação digital, acelerada pela pandemia de COVID‑19, obrigou muitas empresas a adotar uma abordagem mais holística em relação à segurança e a considerar uma estratégia de “shift left”. Deslocar 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 todas as etapas do pipeline de CI/CD para aplicações, contêineres, microsserviços e APIs. Isso representa a transição para um novo paradigma chamado DevSecOps, no qual a segurança é incorporada aos processos de DevOps e integrada aos ciclos rápidos de lançamento típicos do desenvolvimento e da entrega de aplicações de software modernas.

O DevSecOps representa uma mudança cultural significativa. As equipes de segurança e DevOps trabalham com um objetivo comum: lançar produtos de alta qualidade no mercado com rapidez e segurança. Os desenvolvedores não se sentem mais impedidos a todo momento por procedimentos de segurança que interrompem seu fluxo de trabalho. As equipes de segurança não precisam mais corrigir repetidamente os mesmos problemas. Isso permite que a organização mantenha uma postura de segurança robusta, detectando e prevenindo vulnerabilidades, configurações incorretas e violações de conformidade ou de políticas à medida que ocorrem.

Antecipar a segurança no ciclo de desenvolvimento e automatizá-la como código protege seu ambiente do Amazon EKS desde o início. Aprender a estar pronto para produção em escala é uma parte importante da criação de uma base para o Kubernetes. A governança adequada do Amazon EKS ajuda a promover eficiência, transparência e responsabilização em toda a empresa, além de controlar os custos. Uma governança sólida e mecanismos de proteção de segurança criam uma estrutura que proporciona maior visibilidade e controle dos seus clusters. Sem eles, sua organização fica exposta a um risco maior de violações de segurança e aos custos de longo prazo decorrentes de danos à receita e à reputação.

Para saber mais sobre o que considerar ao adotar uma estratégia que prioriza a segurança, confira este relatório recente da O’Reilly, Antecipando a segurança de aplicações.

Automatizando a segurança do Amazon EKS com GitOps

A automação é um importante facilitador do DevSecOps, ajudando a manter a consistência mesmo diante de um ritmo acelerado de desenvolvimento e implantação. Assim como ocorre com a infraestrutura como código, automatizar 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 aplicações e o gerenciamento de clusters. A principal ideia do GitOps é ter um repositório Git que armazene, como código, políticas declarativas de objetos do Kubernetes e das aplicações executadas no Kubernetes. Um processo automatizado completa o paradigma GitOps, fazendo com que o ambiente de produção corresponda a todas as descrições de estado armazenadas.

O repositório atua como uma fonte única da 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. Por exemplo, a NGINX mantém um repositório no GitHub com uma função do Ansible para o F5 NGINX App Protect, que esperamos ser útil para ajudar as equipes que desejam antecipar a segurança no ciclo de desenvolvimento.

Com um repositório desse tipo, para implantar uma nova aplicação ou atualizar uma existente, basta atualizar o repositório. O processo automatizado cuida de todo o restante, incluindo a aplicação das configurações e a verificação de que as atualizações foram bem-sucedidas. Isso garante que tudo aconteça no sistema de controle de versão usado pelos desenvolvedores e seja sincronizado para reforçar a segurança das aplicações essenciais aos negócios.

Ao ser executado no Amazon EKS, o GitOps torna a segurança simples e robusta, praticamente eliminando erros humanos e mantendo um registro de 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 projeto robusto de política de segurança para Kubernetes deve atender às necessidades tanto de SecOps quanto de DevOps e incluir medidas que permitam a adaptação à medida que o ambiente cresce. Os clusters do Kubernetes podem ser compartilhados de várias maneiras. Por exemplo, um cluster pode executar vários aplicativos que compartilham seus recursos, enquanto, em outro caso, pode haver várias instâncias de um mesmo aplicativo, cada uma destinada a um usuário final ou grupo diferente. Isso significa que os limites de segurança nem sempre são claramente definidos e que são necessárias políticas de segurança flexíveis e granulares.

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

Uma maneira fácil de implementar segurança de alto desempenho e baixa latência no Amazon EKS é incorporar os módulos NGINX App Protect WAF and DoS ao NGINX Ingress Controller. Nenhum dos nossos outros concorrentes oferece esse tipo de solução integrada. Usar um único produto com tecnologia sincronizada proporciona várias vantagens, incluindo a redução do tempo de computação, dos custos e da proliferação de ferramentas. Veja alguns benefícios adicionais.

• Proteção do perímetro da aplicação – Em uma implantação do Kubernetes com arquitetura adequada, o NGINX Ingress Controller é o único ponto de entrada para o tráfego do plano de dados direcionado aos serviços executados no Kubernetes, o que o torna o local ideal para proteção contra WAF e DoS.
• Consolidação do plano de dados – Incorporar o WAF ao 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.
• Consolidação do plano de controle – As configurações de WAF e DoS podem ser gerenciadas com a API do Kubernetes, facilitando significativamente a automação dos 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, permitindo delegar com segurança as configurações de WAF e DoS a uma equipe dedicada de DevSecOps.

Os objetos de configuração do NGINX App Protect WAF e de DoS são consistentes tanto no NGINX Ingress Controller quanto no NGINX Plus. Uma configuração mestre pode ser facilmente convertida e implantada em qualquer um dos dispositivos, facilitando ainda mais o gerenciamento da configuração do WAF como código e sua implantação em qualquer ambiente de aplicações

Para incorporar o NGINX App Protect WAF e a proteção contra DoS ao NGINX Ingress Controller, você precisa ter assinaturas do NGINX Plus e do NGINX App Protect WAF ou da proteção contra DoS. Bastam algumas etapas simples para criar a imagem do NGINX Ingress Controller integrada (contêiner Docker). Depois de implantar a imagem (manualmente ou usando charts do Helm, por exemplo), você pode gerenciar as políticas e configurações de segurança usando a conhecida API do Kubernetes.

O NGINX Ingress Controller baseado no NGINX Plus oferece controle e gerenciamento granulares da autenticação, da autorização baseada em RBAC e das interações externas com pods. Quando o cliente usa HTTPS, o NGINX Ingress Controller pode encerrar o TLS e descriptografar o tráfego para aplicar o roteamento de 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 e proteger contra ataques pontuais na Camada 7, atuando como uma solução leve de segurança de software. O NGINX App Protect WAF protege aplicações Kubernetes contra ataques do OWASP Top 10 e oferece assinaturas avançadas e proteção contra ameaças, defesa contra bots e proteção Dataguard contra a 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 sofisticados de DoS na camada de aplicação, usando análise do comportamento do usuário e verificações da integridade da aplicação para proteger contra ataques como Slow POST, Slowloris, ataques de inundação e Challenger Collapsar.

Essas medidas de segurança protegem tanto as APIs REST quanto os aplicativos acessados por meio de navegadores da Web. A segurança das APIs também é aplicada no nível do Ingress, 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: essa é uma visão mais útil do tráfego da Camada 7 e uma maneira muito melhor de aplicar SLAs e a segurança de WAF no sentido norte-sul.

O mais recente relatório Testes de firewall de aplicações web de alto desempenho da GigaOm mostra como o NGINX App Protect WAF oferece consistentemente uma segurança robusta para aplicações e APIs, mantendo alto desempenho e baixa latência, além de superar os outros três WAFs testados – AWS WAF, Azure WAF e Cloudflare WAF – em todas as taxas de ataque avaliadas.

Como exemplo, a Figura 4 mostra os resultados de um teste em que o WAF precisou processar 500 solicitações por segundo (RPS), sendo 95% (475 RPS) das solicitações válidas e 5% (25 RPS) “maliciosas” (simulando injeção de scripts). No 99º percentil, a latência do NGINX App Protect WAF foi 10 vezes menor que a do AWS WAF, 60 vezes menor que a do Cloudflare WAF e 120 vezes menor que a do Azure WAF.

A Figura 5 mostra a maior taxa de transferência alcançada por cada WAF com 100% de sucesso (sem erros 5xx ou 429) e latência inferior a 30 milissegundos em cada solicitação. O NGINX App Protect WAF processou 19.000 RPS, em comparação com 14.000 RPS do Cloudflare WAF, 6.000 RPS do AWS WAF e apenas 2.000 RPS do Azure WAF.

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

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

O NGINX Ingress Controller fornece várias definições de recursos personalizados (CRDs) para gerenciar todos os aspectos da segurança de aplicações web e oferecer suporte a um modelo de responsabilidade compartilhada e multilocatário. Os manifestos de CRD podem ser aplicados de acordo com o agrupamento de namespaces usado pela organização, permitindo que mais de um grupo de operações seja responsável por eles.

Ao publicar uma aplicação no Amazon EKS, você pode incorporar segurança aproveitando o pipeline de automação já em uso e adicionando a política de segurança do WAF como uma camada adicional.

Além disso, com o NGINX App Protect no NGINX Ingress Controller, você pode configurar limites de uso de recursos tanto para a utilização da CPU quanto da memória, evitando que o NGINX App Protect prive outros processos de recursos. 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”.

Configuração de logs com CRDs do NGINX

Os logs do NGINX App Protect e do NGINX Ingress Controller são separados por design, refletindo a forma como as equipes de segurança geralmente operam de maneira independente das equipes de DevOps e dos proprietários das aplicações. Você pode enviar os logs do NGINX App Protect para qualquer destino syslog acessível pelos pods do Kubernetes, definindo o parâmetro da anotação app-protect-security-log-destination como o endereço IP do cluster do pod syslog. Além disso, você pode usar o recurso APLogConf para especificar quais logs do NGINX App Protect são relevantes para você e, consequentemente, quais logs são enviados ao pod syslog. Os logs do NGINX Ingress Controller são encaminhados para a saída padrão local, como ocorre com todos os contêineres do Kubernetes.

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

apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf 
metadata: 
 name: logconf 
 namespace: dvwa 
spec: 
 content: 
   format: default 
   max_message_size: 64k 
   max_request_size: any 
 filter: 
   request_type: all

Definindo uma política de WAF com CRDs do NGINX

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

apiVersion: appprotect.f5.com/v1beta1 kind: APPolicy 
metadata: 
  name: sample-policy
spec: 
  policy: 
    name: sample-policy 
    template: 
      name: POLICY_TEMPLATE_NGINX_BASE 
    applicationLanguage: utf-8 
    enforcementMode: blocking 
    signature-sets: 
    - name: Command Execution Signatures 
      alarm: true 
      block: true
[...]

Depois que o manifesto da política de segurança for aplicado ao 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 de WAF:

apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf 
metadata: 
  name: log-violations
spec: 
  content: 
    format: default 
    max_message_size: 64k 
    max_request_size: any 
  filter: 
    request_type: illegal

O objeto Policy waf-policy faz referência a sample-policy para que o NGINX App Protect WAF a aplique ao tráfego de entrada quando a aplicação é exposta pelo NGINX Ingress Controller. Ele faz referência a log-violations para definir o formato das entradas de log enviadas ao servidor syslog especificado no campo logDest.

apiVersion: k8s.nginx.org/v1 kind: Policy 
metadata: 
  name: waf-policy 
spec: 
  waf: 
    enable: true 
    apPolicy: "default/sample-policy" 
    securityLog: 
      enable: true 
      apLogConf: "default/log-violations" 
      logDest: "syslog:server=10.105.238.128:5144"

A implantação é concluída quando a equipe de DevOps publica um objeto VirtualServer que configura o NGINX Ingress Controller para disponibilizar a aplicação no Amazon EKS:

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: eshop-vs
spec:
  host: eshop.lab.local
  policies:
  - name: default/waf-policy
  upstreams:
  - name: eshop-upstream
    service: eshop-service
    port: 80
  routes:
  - path: /
    action:
      pass: eshop-upstream

O objeto VirtualServer facilita a publicação e a proteção de aplicações em contêineres executadas no Amazon EKS, mantendo o modelo de responsabilidade compartilhada, no qual a equipe de SecOps fornece um catálogo abrangente de políticas de segurança, e a equipe de DevOps utiliza esse catálogo para incorporar a segurança desde o primeiro dia. Isso permite que as organizações adotem uma estratégia de DevSecOps.

Conclusão

Para empresas com aplicações legadas e soluções de segurança desenvolvidas ao longo dos anos, a adoção do conceito de shift left em segurança no Amazon EKS provavelmente será um processo gradual. No entanto, reformular a segurança como código, gerenciado e mantido pela equipe de segurança e utilizado pela equipe de DevOps, ajuda a disponibilizar serviços com mais rapidez e a deixá-los prontos para produção.

Para proteger o tráfego norte-sul no Amazon EKS, você pode usar o NGINX Ingress Controller com o NGINX App Protect WAF integrado para se proteger contra ataques pontuais na camada 7 e o NGINX App Protect DoS para mitigar ataques de negação de serviço 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 conversar sobre seus casos de uso.

Para descobrir como 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 da AWS, do Azure e da Cloudflare, baixe o relatório Testes de firewall de aplicações web de alto desempenho da GigaOm e inscreva-se no webinar de 6 de dezembro, no qual o analista da GigaOm Jake Dolezal analisa os resultados.

Sobre os autores

Fabrizio FiorucciArquiteto de Soluções NGINX | F5 (EMEA)

Mais publicações de Fabrizio Fiorucci

Thelen BlumGerente Sênior de Marketing de Produto, NGINX App Protect | F5

Mais publicações de Thelen Blum