Microsserviços costumam ser implantados em sub-redes privadas dentro de uma Amazon Virtual Private Cloud (VPC) para garantir isolamento e proteção contra acesso direto pela internet. Há duas abordagens comuns para configurar o acesso externo a microsserviços:
- Private Link: recurso de rede que usa interface endpoints para expor com segurança recursos privados da VPC ao API Gateway, sem expô-los à internet pública. Assim, o tráfego permanece dentro da rede da AWS.
- HTTP Integration (voltada à internet): permite que o API Gateway encaminhe requisições para endpoints HTTP de acesso público, como um Application Load Balancer (ALB) voltado à internet, deixando os serviços acessíveis por um endpoint público.
Vamos focar em proteger a segunda abordagem — um ALB voltado à internet por trás de um API Gateway. Mais especificamente, vamos tratar do desafio de restringir o acesso direto ao ALB público, permitindo que apenas clientes confiáveis interajam com a aplicação pelo API Gateway.
Definição do problema
Quando um ALB voltado à internet é configurado por trás de um API Gateway com uma HTTP integration, o ALB fica acessível publicamente. Mesmo que os clientes confiáveis se conectem à aplicação pelo API Gateway, essa configuração traz um risco de segurança importante: o endpoint público do ALB pode ser acessado diretamente, contornando os recursos de segurança do API Gateway.
Essa falta de restrição abre espaço para várias vulnerabilidades. Para preservar a segurança e a integridade da sua aplicação, é fundamental impedir o acesso direto ao ALB. Ao garantir que todo o tráfego passe pelo API Gateway, você consegue aplicar recursos de segurança essenciais, como validação de requisições, throttling, autenticação e autorização. Sem essas proteções, invasores podem explorar vulnerabilidades, burlar mecanismos de autenticação e sobrecarregar os serviços de backend, abrindo caminho para ataques de negação de serviço (DoS).
A AWS oferece uma solução com REST API Gateway e AWS Web Application Firewall (WAF) para bloquear requisições que não tragam um header exclusivo, mas essa abordagem adiciona complexidade e custo. Vale lembrar que, em casos de uso que exigem medidas avançadas de segurança, como proteção contra SQL injection, cross-site scripting (XSS) ou mitigação de bots, o AWS WAF continua sendo uma ferramenta poderosa.
Neste post, apresentamos uma alternativa mais simples e econômica. Com headers customizados e condições de regra do ALB, chegamos ao mesmo nível de segurança sem depender do AWS WAF. O método funciona perfeitamente tanto com REST quanto com HTTP API Gateways e reduz bastante o esforço operacional.
**Solução proposta**
Essa abordagem elimina a necessidade do AWS WAF ao aproveitar o roteamento baseado em conteúdo do ALB. A solução envolve:
- Adicionar um header customizado e seu valor às requisições HTTP no API Gateway.
- Configurar regras do ALB para validar o header. Apenas as requisições com o header e o valor corretos vão corresponder às regras desejadas do ALB; as demais cairão na regra padrão.
- Definir a regra padrão do ALB para retornar um código de erro HTTP, como 403 Forbidden.
Veja uma visão geral da arquitetura:
Fluxo da requisição HTTP.
**Passos detalhados de implementação**
Passo 1: definir um header customizado no API Gateway
No HTTP API Gateway, use parameter mappings para modificar as requisições enviadas à integração com o ALB.
- Acesse o console do API Gateway.
- Vá até sua HTTP API.
- Na seção "Integrations", abra "Manage Integrations".
- Crie um parameter mapping para incluir o header customizado e seu valor.
Configuração do parameter mapping.
Se o seu API Gateway for baseado em REST, siga este link para adicionar um header HTTP customizado.
Passo 2: configurar as regras do ALB
- Abra a configuração do ALB no console do EC2.
- Para cada regra do listener (exceto a regra padrão):
- Adicione uma condição AND.
- Defina "HTTP header" como o tipo de condição.
- Informe o nome do header e o valor esperado.
3. Configure a regra padrão para retornar uma resposta de erro HTTP (por exemplo, 403 Forbidden).
Condições e ações das regras do ALB.
Para saber mais sobre roteamento baseado em conteúdo no ALB, confira este artigo do blog da AWS.
Passo 3: testar a configuração
- Envie uma requisição pelo ALB sem o header customizado. Confira se ela aciona a regra padrão do ALB e retorna a resposta de erro.
- Envie uma requisição pelo API Gateway. Confira se ela é encaminhada para a aplicação.
**Conclusão**
Esta solução simplifica a arquitetura ao eliminar a dependência do AWS WAF. Ao aproveitar o roteamento baseado em conteúdo nativo do ALB, essa abordagem oferece uma forma segura e eficiente de restringir o acesso direto ao seu Application Load Balancer.
Se quiser saber mais ou tem interesse em nossos serviços, fale com a gente. É só entrar em contato aqui.