Governança do AWS WAF em grande escala

Grandes organizações, com várias equipes desenvolvendo e operando seus próprios aplicações Web ou APIs, empregam ferramentas e processos para impulsionar a consistência dos controles de segurança entre as equipes, a fim de evitar endpoints expostos com proteções fracas ou inexistentes. O AWS Firewall Manager é uma ferramenta que as organizações podem usar para controlar implantações do AWS WAF e do Shield Avançado em grande escala.

O Firewall Manager permite definir políticas do AWS WAF ou Shield Avançado que são implantadas automaticamente em recursos expostos publicamente, como distribuições do CloudFront, ALBs ou API Gateways. Uma política consiste em:

• Um escopo, que define onde ela se aplica: que tipo de recursos (CloudFront, ALB etc.) incluir ou excluir recursos com etiquetas específicas? Quais contas ou unidades organizacionais incluir ou excluir?
• Regras , que definem quais grupos de regras do WAF devem ser aplicados, se o registro em log deve ser habilitado centralmente e se as proteções do Shield Avançado devem ou não ser adicionadas.
• Uma ação, que define o que fazer quando um recurso é encontrado dentro do escopo de uma política. Por exemplo, você pode aplicar regras de política automaticamente ou pode simplesmente as relatar. Em uma implantação inicial do Firewall Manager, é recomendável começar sem correção automática, para identificar recursos que exigem manuseio manual com impacto mínimo nas aplicações existentes. Quando uma maior confiança for alcançada, você poderá mudar o Firewall Manager para a correção automática.

Para usar o Firewall Manager, considere primeiro seus pré-requisitos. Observe que o AWS Config é um dos pré-requisitos do Firewall Manager. Para otimizar o custo do AWS Config, se habilitado apenas para usar o Firewall Manager, limite a configuração Tipos de recursos para registrar aos recursos relevantes para seu cenário (por exemplo, WAF, distribuição do CloudFront, balanceadores de carga etc.). Observe também que políticas são estruturas regionais (por exemplo, você precisa de uma política global para o CloudFront e de uma política regional em cada região em que você tem recursos regionais, como ALBs e API Gateways). Considere esta Solução da AWS para facilitar a implantação de políticas do Firewall Manager em todas as organizações do AWS Organizations

Quando você cria uma política do WAF, o Firewall Manager implanta uma WebACL do WAF com as regras do WAF da política nas contas da AWS dentro do escopo da política. Em uma política do WAF, você pode definir dois tipos de grupos de regras que são adicionados ao WebACL implantado pelo Firewall Manager:

• Um primeiro grupo de regras, que será avaliado antes de qualquer outra regra.
• Um último grupo de regras, que será avaliado no final.

Isso permite que você ofereça a uma equipe central de segurança a possibilidade de gerenciar grupos de regras comuns em toda a organização, ao mesmo tempo em que oferece às equipes de aplicações a possibilidade de adicionar regras personalizadas relevantes para suas aplicações, entre o primeiro e o último grupo de regras comuns. Como as regras no AWS WAF são avaliadas por ordem, o primeiro grupo de regras comuns é avaliado antes de qualquer outra regra, seguido pelas regras criadas pelas equipes de aplicações e, finalmente, pelo último grupo de regras comuns.

Você pode criar um pipeline de CI/CD para atualizar grupos de regras comuns do WAF na política do AWS WAF na conta administrativa da AWS, que é então implantada pelo Firewall Manager em toda a sua organização em poucos minutos. Saiba neste blog como a OLX implantou uma política central do WAF usando um pipeline de CI/CD, com um sistema de registro em log central.

O Firewall Manager é uma ferramenta flexível que permite estabelecer várias estratégias de governança de segurança dependendo dos requisitos da sua organização. Em qualquer governança de segurança centralizada, você precisa fazer uma compensação entre o quanto você aplica as regras centralmente para aumentar os níveis de proteção e o quanto você deseja lidar com falsos positivos causados por regras comuns implantadas centralmente.

Se você tem equipes de aplicações altamente autônomas e deseja evitar o gerenciamento de falsos positivos, crie uma única política central do WAF que aborde ameaças críticas. Por exemplo, você pode criar regras do WAF com base em limites de taxa com limites altos, combinadas com listas de reputação de IPs mal-intencionados de alta confiança e regras de bloqueio geográfico para países com embargos. Você também pode habilitar o Shield Avançado e ativar a mitigação automática de DDoS na camada da aplicação. Essas regras tendem a ter falsos positivos muito baixos, mas são eficazes na proteção contra inundações de HTTP. Além disso, quando vulnerabilidades Zero Day críticas e de alto impacto são descobertas, você pode aplicar mitigações centralmente usando o grupo de regras comuns do WAF implantado.

É recomendável criar um wiki interno para suas equipes de aplicações, com orientações sobre melhores práticas para adicionar regras do WAF personalizadas nas suas WebACLs que sejam relevantes para suas aplicações. Por exemplo, oriente-as a adicionar proteções contra ataques de SQLi e XSS se a aplicação for vulnerável a esses ataques.

Se quiser aumentar sua cobertura de segurança central para uma variedade maior de ameaças, fortaleça seus grupos centrais de regras comuns, mas dê às equipes de aplicações a possibilidade de gerenciar falsos positivos de maneira autônoma. Para implementar esse modelo de governança do WAF, coloque suas regras comuns no primeiro grupo de regras da política do WAF no modo de contagem. Essas regras emitirão somente rótulos, que você poderá usar no último grupo de regras da política do WAF para bloquear solicitações que correspondem a esses rótulos.

Se as suas equipes de aplicações encontrarem falsos positivos, elas poderão criar regras de exclusão usando os rótulos emitidos pelas suas regras. Para ilustrar isso com um exemplo, considere o cenário em que o Amazon Managed Rules (AMR) para proteção contra SQLi é adicionado no modo de contagem ao primeiro grupo de regras. No último grupo de regras, uma regra bloqueia solicitações com o rótulo label_matched=”SQLi_BODY” emitido pela AMR mencionada anteriormente. Se a AMR introduzir um falso positivo em uma aplicação em um URL específico (url=”/form1”), a equipe da aplicação poderá criar uma regra de exclusão na WebACL que mitigue esse falso positivo (por exemplo. IF url=”/form1” AND label_matched=”SQLi_BODY” then ALLOW). A ação da regra de permissão é encerrar, o que significa que o AWS WAF deixará de avaliar regras de bloqueio subsequentes.

Para implementar alterações nessa política sem afetar as aplicações existentes, considere criar uma réplica dessa política para ser usada em ambientes de teste pelas equipes de aplicações. Ambas as políticas precisam ter escopos mutuamente exclusivos. Por exemplo, a política de produção é aplicável a todas as distribuições do CloudFront, exceto aquelas com a etiqueta preparação, e a política de preparação é aplicável a todas as distribuições do CloudFront com a etiqueta preparação. Para a maioria das atualizações, você pode primeiro implementá-las na política de preparação e notificar todas as equipes de aplicações usando um tópico do SNS. Depois de notificadas sobre uma mudança, as equipes de aplicações testam a nova versão da política em seu ambiente de preparação, que pode ser automatizado, e gerenciam falsos positivos, se necessário. Depois de um atraso combinado, a equipe central propagará a alteração à política de produção. Atualizações críticas que não podem durar uma semana, como proteções contra o CVE Log4j, poderão ser aplicadas imediatamente às custas de alguns falsos positivos temporários até que as equipes de aplicações lidem com as exceções.

Se você deseja impor uma linha de base de segurança consistente e, ao mesmo tempo, permitir alguma personalização pelos administradores da conta. Este artigo descreve as etapas para projetar e implementar uma política básica de segurança gerenciada centralmente. Ele também detalha as melhores práticas para testar e implantar a política.

Se você tem os mesmos requisitos de antes, mas deseja reduzir a carga cognitiva de fortalecer a segurança das aplicações nas equipes de aplicações, considere criar um catálogo de políticas para diferentes tipos de aplicações presentes na sua organização. Por exemplo, você pode ter um catálogo com duas políticas:

• Primeira política: recomendada para proteger aplicações baseadas no Wordpress
• Segunda política: recomendada para proteger aplicações PHP com um banco de dados SQL. Você pode criar duas versões dessa política, com diferentes níveis de sensibilidade a bloqueios. Dessa forma, as equipes de aplicações podem escolher aquela que atenda aos requisitos de segurança (nível de paranóia) e à disposição de gerenciar falsos positivos.
  
  

O escopo de cada política é definido por uma etiqueta específica (por exemplo, wordpress para a primeira política e LAMP_HIGH/LAMP_LOW para a segunda política). As equipes de aplicação consultam o catálogo de políticas disponíveis e aplicam a etiqueta da política desejada aos seus recursos. O Firewall Manager associa automaticamente as WebACLs do WAF aos seus recursos.

Observe que, com essa abordagem, é possível gerenciar falsos positivos e alterações de estágio da mesma forma descrita na seção anterior.

No nível da sua aplicação, você pode usar sinais personalizados para identificar um comportamento anormal, com base no que é esperado pela sua aplicação. Por exemplo, você pode esperar que os usuários naveguem na sua aplicação em uma determinada ordem ou provavelmente não espere que um usuário solicite determinados produtos de/para determinados países com base em seu endereço registrado. Usando esses sinais, você pode automatizar sua resposta usando o AWS WAF, por exemplo, bloqueando ou desafiando o uso de solicitações CAPTCHA provenientes de IPs com comportamento suspeito no nível da aplicação. Para começar a usar o conceito de automação do WAF com base em sinais de aplicações, considere os exemplos desta solução da AWS.

As automações avançadas incluem:

• Consumir eventos de alto risco emitidos pelo Cognito durante o processo de inscrição/registro.
• Consumir eventos de alto risco identificados pelo Fraud Detector. O Fraud Detector usa machine learning (ML) e 20 anos de experiência em detecção de fraudes da Amazon Web Services (AWS) e da Amazon.com para identificar automaticamente possíveis padrões fraudulentos executados por humanos e bots em tempo real. O Fraud Detector permite a detecção de fraudes analisando o comportamento do usuário no nível da aplicação, usando seus próprios dados históricos de fraude para treinar, testar e implantar modelos personalizados de machine learning de detecção de fraudes adaptados ao seu caso de uso.

Se você prefere transferir completamente o gerenciamento do WAF das equipes de aplicações para a sua equipe central de segurança, crie uma política dedicada para cada equipe de aplicações, com um escopo que seja aplicável às contas da AWS delas. Nesse cenário, você precisa criar processos para a configuração inicial e canais de comunicação entre as equipes de aplicações e sua equipe central de segurança para operações como o gerenciamento de falsos positivos.

• Whitepaper: exemplos de governança do whitepaper Diretrizes para implementar o AWS WAF
• Palestra do AWS Re:inforce 2024: Como a Twilio gerencia as políticas do AWS WAF em grande escala
• Encontre parceiros de entrega do AWS WAF
• Blog: Modelos operacionais para governança da segurança de aplicações Web na AWS