Nesta publicação, você aprenderá sobre os conceitos básicos do AWS Web Application Firewall (WAF) e escreverá código CDK para proteger um serviço REST API Gateway. Habilitaremos métricas WAF, adicionaremos regras gerenciadas à ACL e habilitaremos o registro em um grupo de logs do Cloudwatch.
Este é o segundo de três posts da série WAF.
Noprimeiropost , forneci dicas e truques para usar o AWS WAF para um serviço SaaS pronto para produção.
No terceiro post, revisaremos o AWS Firewall Manager e como ele permite que uma organização gerencie ACLs do AWS Application Web Firewall em escala.
Índice
Introdução ao AWS Web Application Firewall (WAF)
O AWS WAF é um firewall de aplicativo da Web que permite monitorar ou bloquear as solicitações HTTP(S) encaminhadas para seus recursos de aplicativo da Web protegidos. Você pode proteger os seguintes tipos de recursos:
Distribuição do Amazon CloudFront
API REST do Amazon API Gateway
Balanceador de carga de aplicativo
API GraphQL do AWS AppSync
Grupo de usuários do Amazon Cognito
Serviço AWS App Runner
Instância de acesso verificado da AWS
Como você pode ver na lista acima, o AWS WAF pode proteger seus serviços baseados em contêiner e sem servidor. Eu abordei as ameaças das quais o WAF protege você noprimeiro post da série.
Para entender como o WAF fornece uma camada extra de segurança, primeiro precisamos entender como ele funciona. Vamos ver como podemos configurar o WAF para proteger nosso serviço SaaS.
ACL e regras
Para usar o WAF com seus recursos da AWS (conforme definido acima), crie uma lista de controle de acesso (ACL) do WAF, defina suas regras e associe a ACL ao recurso que você deseja proteger.
Os recursos associados encaminham solicitações de entrada para o AWS WAF para inspeção pela ACL da web. Na sua ACL da web, você cria regras para definir padrões de tráfego a serem procurados em solicitações e para especificar as ações a serem tomadas em solicitações correspondentes. - AWS
Cada regra tem ação a ser executada quando correspondida. As opções de ação incluem o seguinte:
Permita que as solicitações vão para o recurso protegido para processamento e resposta.
Bloqueie as solicitações.
Conte os pedidos.
Execute verificações de CAPTCHA ou de desafio em solicitações para verificar usuários humanos e o uso padrão do navegador.
A AWS fornece regras gerenciadas que são prontas para uso, e eu recomendo fortemente que você as use o máximo possível. Essas regras, constantemente atualizadas pela AWS, são fáceis de usar e não há realmente nenhuma razão para reinventar a roda. No entanto, às vezes, precisamos usar regras personalizadas.
Uma regra pode ter várias condições com um 'e', 'ou' ou 'não' entre elas. Uma condição pode usar um regex para corresponder ao cabeçalho HTTP, elemento baseado em taxa, bloquear tráfego originário de países específicos ou até mesmo um conjunto de IP (por exemplo, bloquear tráfego que não se origina dos intervalos de IP da sua VPN de trabalho). O WAF também tem a opção de alterar cabeçalhos (transformar) antes de examiná-los. Você tem muitas opções personalizadas; apenas esteja ciente de que quanto mais avançado e personalizado você for, mais WCU você usará (veja a seção WCU ).
Outra noção importante a lembrar é que regras têm prioridade . O WAF examina o tráfego da prioridade mais alta para a mais baixa, e quando uma regra corresponde às suas condições, ele executa a ação definida, seja ela qual for.
O registro também é um aspecto essencial da depuração do WAF. Neste post, abordarei o registro em um grupo de logs CW, mas há duas outras opções - eu as abordei com minhas recomendações noprimeiro post .
Por fim, você pode habilitar as métricas do CloudWatch para suas regras do WAF. Eu sugiro que você as habilite, pois elas fornecem insights valiosos sobre se elas fazem alguma diferença (saiba o que e por que você está pagando!). Para mais informações, confira os documentos da AWS .
Agora que temos o básico, vamos passar para o código CDK.
Exemplo de arquitetura de serviço sem servidor
O serviço 'orders' permite que os usuários peçam produtos. Usaremos meu projeto de template Serverless de código aberto: AWS Lambda Handler Cookbook .
Este repositório fornece um modelo de serviço funcional, implantável, de código aberto e sem servidor com uma função AWS Lambda e código Python AWS CDK, todas as melhores práticas e um pipeline CI/CD completo. Você pode iniciar um serviço sem servidor em 3 cliques!
Agora, vamos proteger nosso API Gateway contra DDoS e outros ataques ou interrupções.
Vamos adicionar uma ACL do AWS WAF à mistura e associá-la ao nosso API Gateway:
O API Gateway passará o tráfego para nossa ACL do AWS WAF para inspeção. A ACL tentará corresponder o tráfego com sua lista de regras (ordenadas por prioridade) e executará a ação da primeira regra que corresponder.
Código AWS CDK
Para o código CDK do API Gateway, clique aqui .
Para o código WAF completo, clique aqui .
Vamos revisar o código do CDK do WAF abaixo. Queremos criar uma nova ACL do WAF com três regras gerenciadas pela AWS e habilitar métricas e logs:
Na linha 10, obtemos a construção do API Gateway que desejamos associar à nossa ACL do WAF.
Nas linhas 14 a 88, definimos a ACL do WAF, habilitamos métricas de CW e definimos a lista de regras da ACL.
Entre as linhas 23 e 88, definimos as regras com uma prioridade, instruções e uma configuração de visibilidade que inclui métricas do CloudWatch para monitoramento e controle abrangentes.
Na linha 91, associamos nosso serviço API Gateway à ACL.
Nas linhas 94-128, adicionamos a configuração de log. Criamos o grupo de log, permitimos que o WAF crie fluxos de log dentro dele e habilitamos as configurações de log.
Após a implantação, obtemos as regras gerenciadas pela AWS que definimos, ordenadas por prioridade:
e esta configuração de registro:
É isso!
Confira os recursos avançados de registro do WAF, como filtros ou campos redigidos na documentação oficial .