Eu trabalho em uma empresa de segurança cibernética, a CyberArk , e segurança é um conceito que está constantemente em minha mente quando construo serviços SaaS na AWS. Tem que ser — atores mal-intencionados estão constantemente procurando vulnerabilidades, esperando que alguém deslize ou o momento perfeito para lançar um ataque DDoS contra seu serviço de nuvem. Como resultado, precisamos preparar e proteger nossos serviços. Podemos delegar a maior parte do trabalho pesado (a um custo) à AWS.
Nesta postagem, você aprenderá sobre o AWS Web Application Firewall (WAF), para que ele serve, dicas e insights sobre visibilidade, propriedade, governança (e muito mais) para proteger seus serviços SaaS.
Este é o primeiro de três posts da série.
No segundo post, fornecerei o código AWS CDK para implantação do WAF e associação ao API Gateway.
No terceiro post, revisaremos o AWS Firewall Manager e como ele permite que a organização gerencie ACLs do AWS Application Web Firewall em escala e de maneira centralizada.
Índice
Você precisa proteger seu aplicativo SaaS
Ataques DDoS, sejam implantados por indivíduos ou botnets, inundam servidores com solicitações e os sobrecarregam com tráfego, o que faz com que os serviços e sites hospedados fiquem indisponíveis para usuários e visitantes - Akamai
Ao criar APIs públicas ou aplicativos baseados em nuvem, agentes mal-intencionados acabarão tentando interromper e prejudicar a experiência dos seus clientes.
Esses ataques, conhecidos como ataques de negação de serviço distribuídos ( ataques DDoS ), são realizados automaticamente. Eles são orquestrados por uma rede de máquinas comprometidas e controladas remotamente, também conhecidas como bots, que são usadas para inundar o alvo com uma quantidade avassaladora de tráfego.
Um bot é um programa de computador que automatiza interações com propriedades da web pela Internet - CloudFlare
No entanto, os bots nem sempre lançam ataques em larga escala. Eles acessam sites por vários motivos, incluindo indexação (pense no mecanismo de busca do Google), o que os torna bots "bons".
Um bot ruim é um programa de computador que tenta roubar dados raspando dados ou sondando vulnerabilidades em preparação para um ataque de entrada. Felizmente, podemos nos proteger de bots maliciosos enquanto permitimos que os bots "bons" façam seu trabalho. Se você quiser saber mais sobre bots bons e ruins, confira o artigo da CloudFlare .
Bloquear ataques DDoS e bots maliciosos manterá a integridade e o desempenho do seu serviço SaaS. Vamos ver como podemos fazer isso com o AWS Web Application Firewall .
Se você quiser saber mais sobre DDoS e os ataques DDoS mais famosos da história, confira este artigo .
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.
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.
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 .
Para outras dicas de criação de regras, confira esta postagem e sempre consulte um especialista em segurança.
Agora que já entendemos o básico, vamos para a minha seção de dicas e truques, que discute como trabalhar com WAF e usá-lo em um ambiente SaaS empresarial.
Dicas e truques do AWS WAF
Nesta seção, fornecerei insights e dicas que reuni usando o AWS WAF na minha organização. As dicas abrangem propriedade da equipe, governança organizacional, logs e problemas de depuração na produção e manutenção contínua do WAF ACL.
Propriedade
Especialistas em segurança, sejam eles arquitetos de segurança internos ou consultores de segurança externos, desempenham um papel crucial na análise do vetor de ataque do seu serviço e na construção do conjunto de regras de ACL. O arquiteto de segurança também tem a tarefa de monitorar a adoção geral do WAF em toda a organização e as métricas das regras ao longo do tempo (elas estão causando impacto? Elas correspondem?).
Os desenvolvedores, por outro lado, são responsáveis por traduzir essas regras em modelos AWS CDK ou Terraform IaC (mais sobre isso no segundo post da série). Os desenvolvedores implantarão o WAF ACL, associarão ao seu recurso de serviço (API Gateway) e adicionarão regras personalizadas, se necessário.
Se houver um problema de WAF, os clientes não conseguirem se conectar ao serviço, etc., os desenvolvedores podem visualizar os logs e o tráfego do WAF e resolver o incidente com a ajuda dos arquitetos de segurança.
Essa abordagem é um bom equilíbrio entre governança e independência da equipe.
Governança
Falando em governança, no próximo post, discutiremos como gerenciar essas regras de forma centralizada. Enquanto isso, é recomendado usar uma construção CDK ou um modelo Terraform como um padrão arquitetônico de caixa preta contendo todas as regras recomendadas e implantá-las em toda a organização. Você pode ler mais sobre esse conceito no meu artigo AWS.com com Anton Aleksandrov " simplificando a governança sem servidor por meio da codificação de blueprints arquitetônicos ".
No meu terceiro artigo da série, discutiremos como levar a governança adiante e utilizar o AWS Firewall Manager para governança de segurança centralizada com o AWS WAF.
Adicionando regras ACL ao longo do tempo
A segurança muda e se adapta ao longo do tempo. Suas regras de ACL mudarão. No entanto, adicionar uma nova regra (especialmente com uma ação de "bloqueio") pode prejudicar a experiência dos clientes ou até mesmo bloqueá-los quando mal configurados. Como tal, ter duas variantes de ACL é essencial: dev e produção. Como o nome indica, as ACLs dev são usadas nas contas de desenvolvimento e são um ótimo campo de testes para testar novas regras, padrões de bloqueio ou outras técnicas. Tente pensar fora da caixa e simular o tráfego do cliente o máximo possível.
Depois de ter certeza de que as novas regras não alterarão a experiência do cliente, adicione-as à ACL do WAF de produção.
Erros ainda podem ocorrer, e fluxos inesperados de clientes podem ser prejudicados. Como tal, você precisa planejar um método rápido de "quebra de vidro" que os desenvolvedores treinarão de antemão e saberão iniciar em caso de um problema de produção. O método de quebra de vidro pode ser tão simples quanto uma rápida reversão do GitHub para remover ou ajustar a nova regra ACL. Os desenvolvedores devem saber sobre uma alteração pendente do WAF e como depurá-la corretamente.
Visibilidade e Logs
Os desenvolvedores devem entender facilmente os problemas dos clientes que se originam do bloqueio de suas solicitações pelo WAF. Felizmente, o AWS WAF tem suporte a log, que você deve habilitar por ACL.
Há três destinos possíveis de registro WAF:
Balde S3
Mangueira de incêndio Kinesis
Grupo de logs do CloudWatch
As opções um e dois são boas opções para monitoramento centralizado, onde todos os logs são enviados para uma conta AWS, armazenados, analisados e analisados. A desvantagem é que isso requer que você crie um pipeline de dados para esses logs e, em seguida, gerencie o acesso para todos os desenvolvedores na organização, pois eles precisam de meios para depurar seus problemas de produção de serviço.
A AWS lançou recentemente um vídeo mostrando como você pode construir esse pipeline:
No entanto, minha opção preferida é a opção número três , usando um grupo local do CloudWatch, pois é simples e permite que os desenvolvedores usem insights e ferramentas do CloudWatch para depurar os logs do WAF em suas contas, portanto, nenhuma permissão especial é necessária. Se você escolher esta opção, defina o tempo de retenção de log para 7 a 14 dias no máximo para reduzir os custos de armazenamento de log.
Para mais informações, confira a documentação da AWS .
WAF WCU e preços
O AWS WAF usa WCUs para calcular e controlar os recursos operacionais necessários para executar suas regras, grupos de regras e ACLs da Web. Os requisitos de WCU para um grupo de regras são determinados pelas regras que você define dentro do grupo de regras. A capacidade máxima para um grupo de regras é de 5.000 WCUs. - AWS
Embora eu prefira adicionar segurança máxima e construir a ACL perfeita com todas as regras possíveis, isso não é possível devido ao limite de 5000 WCU. Você precisa encontrar o equilíbrio correto entre cobertura de segurança e WCU geral. Tente usar regras gerenciadas pela AWS o máximo possível, pois elas são mais otimizadas para WCU e bem mantidas.
Outra questão crítica é o custo. O WAF é caro, pois você paga por regras, ACLs e volume de tráfego que passa pelo ACL. Para mais detalhes, confira a calculadora de preços .
Resumo
Neste post, apresento o AWS Web Application Firewall e explico por que você deve usá-lo. Também cobrimos os conceitos básicos de ACLs e regras. Por fim, compartilhei algumas dicas cruciais que aprendi ao usar e atualizar o WAF em uma grande empresa.
No próximo post da série , fornecerei o código AWS CDK para implantação do WAF e o associarei a um API Gateway.
Nesta terceira postagem, revisaremos o AWS Firewall Manager e como ele permite que a organização gerencie as ACLs do AWS Application Web Firewall em escala.